Squeak-dev February 2003

squeak-dev@lists.squeakfoundation.org

195 participants
766 discussions

Re: [ANN] Closure Compiler
by Avi Bryant 05 Feb '03

05 Feb '03

Anthony, This is great work. Thank you. I very much hope this gets properly tested and evaluated for inclusion in the mainstream release. I personally especially appreciate that you made an effort to cleanly support continuations. I made some changes to your Continuation class - first, I added #currentDo: to the class side, which is the interface I currently use in Seaside: Continuation currentDo: [:k | ...] feels slightly more "Smalltalky" to me than [:k | ...] callCC does. More importantly, I've made sure that Continuation>>value and #value: properly terminate the current stack before jumping to the new one. This cleans up a number of small problems, particulary when dealing with BlockContexts. I've attached a fileOut that includes the modified Continuation class, an SUnit test case for Continuation, and an example of using continuations: the Amb class (you can find some background on Amb at http://mitpress.mit.edu/sicp/full-text/sicp/book/node89.html, and see the methods of AmbTest for example usage in Smalltalk). Cheers, Avi

1 0

NetNameResolver not resolving -djb
by Derek Brans 05 Feb '03

05 Feb '03

NetNameResolver class>>addressForName: timeout: This method seems to hang indefinitely and I'm forced to do a user interupt. Any ideas why? Thank you in advance, Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

1 0

Re: [BUG]Compiler screws up bigtime with same global on both sides of an assign
by Anthony Hannan 05 Feb '03

05 Feb '03

Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > I was attempting to test some code that happened to have > Smalltalk := SmalltalkEnvironment newFrom: Smalltalk. > in there. It failed. Not, I must point out because of the rather > annoying readonlybinding stuff that seems to have crept into the system. > No, this is a fullscale failure of the Compiler. Sound the alarms! Call > the Fire Brigade! The Closure Compiler does not have this bug.

1 0

[ANN] Closure Compiler
by Anthony Hannan 05 Feb '03

05 Feb '03

Hello fellow Squeakers, At http://minnow.cc.gatech.edu/squeak/ClosureCompiler you will find a zip of changesets that adds a closure compiler to the standard Squeak image (without replacing the existing compiler). A new "general" preference called #compileBlocksAsClosures determines which compiler to use for new methods. When true the closure compiler is used, when false the existing compiler is used (default). The closure compiler compiles non-inlined blocks as separate compiledMethods. These block methods are held in the literals of the home method and sent the #createBlock... message at runtime to create BlockClosures. Outer temps referenced by the block are given as args to the #createBlock... message which adds them to the closure it creates, which consists of the method in its sole named field and the captured temps in its indexable fields. When #value... is sent to a BlockClosure its method is executed in a new MethodContext with the BlockClosure remaining as the receiver. The block method accesses captured temps in indexed fields as if they were named instance variables. Captured temps that may change after being captured are wrapped in SharedTempHolders and all methods (home and block) access their values indirectly through the holders. If a captured temp may not change (most common) then no holder is created saving time. BlockClosures that return to its home context hold the home context as one of its captured temps. Actually, to support safe continuations, it holds the tag of its home context. A ContextTag is a unique object for each context that stays the same for all copies of each context. When a BlockClosure attempts to return to its home context it searches the sender chain for the context that has the right ContextTag and returns to it. This works with copied contexts (continuations) as well as original contexts. Thanks to captured temps and context tags, block closures are totally separate from their home context. They are reentrant and each activation has its own block-local temps. BlockClosures are slower primarily because each activation is a new context. BlockContexts are fater because they reuse the same context. An optimizing VM (Jitter, VI4) that stack allocates contexts should rectify this problem. For an example of its slowness (and general slowness of context activation) execute "[(1 to: 100000) do: [:i | i]] timeToRun" under each compiler (toggle the preference). The above example will be really slow for the closure compiler until you generate interp.c and recompile your VM to include a couple of new primitives (186 and 187) added with the closure compiler. They implement BlockClosure>>value... directly. Without them the failure code has to add the closure method to the BlockClosure method dictionary then call #perform:. Please read further comments in the ReadMe file and in BlockClosure class>>#aboutClosures (both repeated on the Closure Compiler website). A package has been added to SqueakMap that just provides a link to this website. Cheers, Anthony

1 0

Re: timestamp
by Anthony Hannan 05 Feb '03

05 Feb '03

Janet Abdul-Karim <jn_karim(a)yahoo.com> wrote: > I am trying to get a the current time from squeak. I have played and tried all some of the methods in date and time and they either give me errors or they are values i have to set so they give me nil. I even downloade the timestamp.st file and no such there either. Are there any suggestions that anyone can give me. Thanks in advance. Have you tried "Time now"

1 0

PackageInfo and missing extension members
by Derek Brans 05 Feb '03

05 Feb '03

Avi, Julian, I had an extension method in Date class from MyPackage. Then I filed in someone else's Date class and the changeset demolished my extension method. I'm not mourning that loss: The problem comes when I try to fileout my package. I get an error saying that it can't find the source code for my method (Date class (Behaviour)>>sourceCodeAt: dayOfMonth results in a "key not found error"). Any ideas why PackageInfo>>methods is still including this deleted method? Thank you, Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

1 0

Re: ByteArray and FFI?
by Bob Arning 05 Feb '03

05 Feb '03

On Tue, 4 Feb 2003 23:47:42 +0100 Markus Fritsche <Fritsche.Markus(a)gmx.net> wrote: >Why does >something 'simple' like a ByteArray need ffi? I think it is so that you have a platform-DEPENDENT way of passing numbers to and from your OS in ByteArrays. Cheers, Bob

1 0

ByteArray and FFI?
by Markus Fritsche 05 Feb '03

05 Feb '03

Hi! I had a problem with the following code: (ByteArray new: 50) integerAt: 1 put: 7 size: 4 signed: false why? Because on my fresh gentoo linux, I did not have libffi installed. That leads me to my question: why is ffi used for the above code? I thougt 'ffi' stands for 'foreign function interface', and is slow and should be avoided. Why does something 'simple' like a ByteArray need ffi? Regards, Markus -- http://reauktion.de/archer/

2 1

Croquet UI input handling
by Joshua 'Schwa' Gargus 04 Feb '03

04 Feb '03

Hi Croqueteers, I'm creating a simple interface to Croquet to allow setting of keyframes, sketching, etc., and I need to create my own UI behaviors. As it now stands, the tool support is insufficient (I did read the TPointer class comment, and realize that tool support isn't done). It appears that the tool only operates when there is an object selected. I envision a pen-based system that uses Genie to interpret any stroke made with the pen, even if there is no selected object. I would also like to be able to assign different behaviors to the yellow and red buttons. The approach that I have come up with is to have a hierarchy beneath TPointer, where each class defines a different type of UI behavior. There would be a TStandardPointer that supports the current behavior. Some of the protocol of TCamera (such as snapBack) would be moved into TPointer or TStandardPointer. I also want to add a history to support undo/redo. I haven't decided whether this belongs in the camera, the pointer, or somewhere more global. I'll probably opt for the pointer, and move it later if necessary. I'm writing this so as not to re-invent the wheel in case this area is actively being worked on. If not, I hope that I can do some work that furthers my research and is useful for Croquet. I'm also hoping to generate a bit of discussion, since I'm not sure I have a solid grasp on the design space, and know that there are others out there. If anyone is interested, I'll write something a bit more detailed than this email. Thanks, Joshua

4 4

RE: Traits prototype image
by Brent Vukmer 04 Feb '03

04 Feb '03

Ned -- See the following: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/051750… http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/051749… -----Original Message----- From: Ned Konz [mailto:ned@bike-nomad.com] Sent: Tuesday, February 04, 2003 12:25 PM To: The general-purpose Squeak developers list Subject: Re: Traits prototype image On Tuesday 04 February 2003 05:37 am, Nathanael Schärli wrote: > http://www.iam.unibe.ch/~schaerli/smalltalk/traits/traitsPrototype. >htm > > There, you can also read more about our future plans and why there > is no changeset available yet. Nathanael, thanks for making this available! You say on your page: --- Another reason is that filing in traits requires recompilation of the whole system. This is because we need to add some instance variables to ClassDescription and because we need to generate some data to fill the caches for the incremental reasoning. Unfortunately, the kernel (resp. the ClassBuilder) of Squeak is broken for at least half of the (inofficial) versions since Squeak 3.2, and it is also broken for the latest version of Squeak 3.4 (state January 31). Thus, it would not be possible to load a traits changeset into such an image even if it would exist. --- Can you describe the ClassBuilder bug in such a way that we could fix it? Or maybe I've missed the bug report... Thanks, -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

3 2

← Newer
1
...
70
71
72
73
74
75
76
77
Older →

Jump to page: