November 2009 - armedbear-ticket - mailman3.common-lisp.net

[armedbear-ticket] [armedbear] #45: Support for passing unboxed arguments to local functions
by armedbear 15 Mar '10

15 Mar '10

#45: Support for passing unboxed arguments to local functions -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- It would save a great deal of boxing/unboxing, if local functions and self-calling recursive functions could pass and return unboxed values. Although passing unboxed values from the outside world is generally considered 'dependency on implementation details', recursive calls and calls to local functions should be able to depend on this: they get recompiled upon function redefinition anyway. One of the reasons for this ticket: with the improved type-derivations in Jan/Feb 2009, the cl-bench TAK test deteriorated: more boxing was performed. With this change, the (un)boxing can be eliminated, except for the first call (from the outside world). -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/45> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 3

[armedbear-ticket] [armedbear] #70: Unboxing of simple strings / vectors
by armedbear 15 Mar '10

15 Mar '10

#70: Unboxing of simple strings / vectors -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: performance | -------------------------+-------------------------------------------------- When so declared, simple strings and vectors can be unboxed to allow faster access. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/70> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #44: Unboxing of local variables with :float and :double representations
by armedbear 15 Mar '10

15 Mar '10

#44: Unboxing of local variables with :float and :double representations -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: enhancement | Status: new Priority: major | Milestone: Component: compiler | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, variables with :float or :double representations don't get stored unboxed. Since intermediate results of those types do get unboxed, this leads to additional boxing/unboxing. -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/44> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #48: SLIME CVS HEAD as of 2008-12-30 broken
by armedbear 05 Jan '10

05 Jan '10

#48: SLIME CVS HEAD as of 2008-12-30 broken -------------------------------------+-------------------------------------- Reporter: mevenson | Owner: mevenson Type: defect | Status: new Priority: major | Milestone: 0.13 Component: other | Version: 1.0 Keywords: slime emacs application | -------------------------------------+-------------------------------------- Symptom is the failed listening to SlimeInputStream that doesn't detect a pipe close, therefore never closes, so further enviornment bindings are incorrect. *inferior-lisp* buffers needs to evaluate a form before SLIME works properly. Something messed up in the Stream ._finishOuput() calls?? -- Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/48> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

[armedbear-ticket] [armedbear] #71: Stream line counter broken
by armedbear 01 Jan '10

01 Jan '10

#71: Stream line counter broken ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: nobody Type: defect | Status: new Priority: major | Milestone: 0.18 Component: libraries | Version: Keywords: | ------------------------+--------------------------------------------------- Line numbers generated for functions (top-level forms) in compiled code are way off - sometimes. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/71> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #72: Faster startup times
by armedbear 30 Dec '09

30 Dec '09

#72: Faster startup times -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: other | Version: Keywords: performance | -------------------------+-------------------------------------------------- Analysis learned that 40% of the execution time spent loading ABCL was spent finding constructors in the Java reflection code. The idea of this issue is to spread the cost of that 40% better over the life time of the application by loading - but not resolving - function classes until they're actually used, by introducing a proxy object of some kind which holds only the byte array of class bytes. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/72> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 1

[armedbear-ticket] [armedbear] #64: Caught (general) exceptions not rethrown everywhere
by armedbear 30 Dec '09

30 Dec '09

#64: Caught (general) exceptions not rethrown everywhere ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- The code base uses exceptions derived from ConditionThrowable (Go, Throw, Return) to cause non-local transfers of control. A special exception (ThreadDestroyed) has been derived to cause a jump to the outer-most function in a LispThread. (This doesn't work in the main thread, which isn't enclosed by a function in LispThread like those in other threads.) Some spots in our code seem to discard other exceptions than the ones mentioned above. That's probably wrong in most cases. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/64> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

Re: [armedbear-ticket] [armedbear] #8: Support for easier (web) deployment
by armedbear 03 Nov '09

03 Nov '09

#8: Support for easier (web) deployment --------------------------+------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: too-vague Component: other | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by ehuelsmann): * milestone: => too-vague -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/8#comment:1> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0

[armedbear-ticket] [armedbear] #54: pprint.lisp incompatible with gray-streams.lisp
by armedbear 03 Nov '09

03 Nov '09

#54: pprint.lisp incompatible with gray-streams.lisp ------------------------+--------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: other | Version: Keywords: | ------------------------+--------------------------------------------------- pprint.lisp special-cases the XP-STRUCTURE argument type for the stream argument specified to all the stream functions. Although SBCL uses largely the same approach, it uses a (slightly) different approach, which is important in the details. (Isn't that where the devil usually is?) The difference between ABCL and SBCL is that SBCL - although it uses largely the same structure to store its pprinter values - this structure extends the structure which is used to represent streams. In ABCL, this structure is a structure by itself. To compensate for the fact that the structure isn't recognised as a stream itself, all stream functions special case the XP-STRUCTURE argument handling. Proposed solution: make streams based on dispatch tables stored in structures, just as SBCL does. This way, most of our streams "stuff" can be implemented in Lisp, instead of Java. As a bonus, this issue can be resolved along the same lines as SBCL does. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/54> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 2

Re: [armedbear-ticket] [armedbear] #4: Current CLOS implementation speed improvements
by armedbear 03 Nov '09

03 Nov '09

#4: Current CLOS implementation speed improvements -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Component: other | Version: Resolution: fixed | Keywords: -------------------------+-------------------------------------------------- Changes (by ehuelsmann): * status: new => closed * resolution: => fixed Comment: According to list testimonials, we've increased our performance huge amounts (600seconds->16seconds)(due to accessor caches and less compilation). I consider this issue closed: we need more specific issues in the future. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/4#comment:1> armedbear <http://common-lisp.net/project/armedbear> armedbear

1 0