Squeak-dev October 2000

squeak-dev@lists.squeakfoundation.org

112 participants
424 discussions

[BUG][FIX] Make morphs tick at the same rate whether Transformed or not
by mdr＠scn.org 03 Oct '00

03 Oct '00

Morphs which have been rotated are ticked according to Transformation stepTime. This simple change ensure that the tick rate for a morph is uniform whether it is rotated or not. Example Create a new ClockMorph (or more dramatically a MonthMorph) Create an always ticking script which turns the clock by 5. Morphic experts: is this change is enough? I am *not* forwarding the step message - that seems to happen on it's own well enough. Also, TransformationMorphs seem to sometimes answer self when asked for the renderedMorph, so I have included an explict test for it to avoid infinite recursion. But it seems to work well. Mike

1 0

[ENH] Auto-faces for Badges (aka EToySenderMorph)
by Bijan Parsia 03 Oct '00

03 Oct '00

A simple one line change to eliminate the dang giant question mark one gets when one fails to supply a picture to one's badge. Uses HeadMorph, which is very cool. (No if they could just sync with recorded audio!) Cheers, Bijan Parsia.

1 0

[BUG] Squeak hangs uninterruptably on Form edit
by Ned Konz 03 Oct '00

03 Oct '00

in a Morphic world (latest 2.9a stuff): (Form extent: 10@10) edit The interrupt key doesn't even work; it brings up a notifier, but you can't interact with it. What's up? -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Re: Squeak on Amazon!
by Bob Arning 03 Oct '00

03 Oct '00

On Tue, 3 Oct 2000 09:52:14 +1000 "Mike Thomas" <miketh(a)ptmnet.com> wrote: >> Well, unless Squeak becomes syntax-compatible with Python, gains an >> industrial-strength CORBA implementation, native widgets for BeOS, and a >> Comanche version faster than Apache, then Bubble will surely win and >Squeak >> will DIE!!! > >Maybe you're speaking with your tongue in your cheek here, I wondered quite a bit about that myself until I saw "native widgets for BeOS". He *must* be kidding. Cheers, Bob

1 0

Re: [CCC] The Squeak hits! (was: Re: Squeak on Amazon!)
by Tim Rowledge 03 Oct '00

03 Oct '00

In message <4.2.0.58.20001002235707.00b052f0(a)munich.netsurf.de> Helge Horch <Helge.Horch(a)munich.netsurf.de> wrote: [snip lots] Whatever you're drinking, I want some... -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim For every action, there is an equal and opposite criticism.

1 0

Re: Comments disabled, pretty printing formatting enabled?
by Bob Arning 03 Oct '00

03 Oct '00

On Mon, 02 Oct 2000 18:07:34 -0400 Kevin Fisher <kgf(a)golden.net> wrote: >I just grabbed the latest round of updates and noticed that Squeak no longer >accepts any comments I put in my code...when I hit 'accept' all the comments >I've made are removed. Further, any spacing I put in is also removed (just >like when pretty printing is turned on...but I have it turned off). Kevin, My first suggestion would be to put a beep or write to the Transcript in Browser>>selectedMessage to see which of several paths is followed. Cheers, Bob

2 1

Comments disabled, pretty printing formatting enabled?
by Kevin Fisher 03 Oct '00

03 Oct '00

Hi all: I just grabbed the latest round of updates and noticed that Squeak no longer accepts any comments I put in my code...when I hit 'accept' all the comments I've made are removed. Further, any spacing I put in is also removed (just like when pretty printing is turned on...but I have it turned off). Any ideas? This is on Linux, BTW...

1 0

VM source stucture
by Tim Rowledge 02 Oct '00

02 Oct '00

There seems to have been some confusion over recent months about the layout of the VM sources; all the way back to the time people were attempting to setup the SourceForge site in fact. I'd like to offer some suggestions for a solution to the problem. One of the problems is that the files need to separated along several axes. a) generated vs 'hand-written' b) portable vs platform specific c) main VM vs external plugin d) a tree of platform specifc files for the large list of platforms we support. I'm not altogether convinced that a) is a very useful split, but I don't think it matters much either way. Remember that quite a few of the files that are generated by running the assorted VM making methods are actually handwritten in practice (sq.h, sqPlatformSpecific.h etc). b) & d) is quite important as an organising split to help make it clear what files are platform specific. In a system like sourceForge it would also be important for separating the groups of files for the different machines. Here we would want a tree something like:- src/ portable/ interp.c sq.h etc... platform/ acorn/ sqRPCWindow.c etc... beos/ dos/ epoc/ mac/ windows/ unix/ etc... c) is one aspect that I feel a lot of people have completely missed recently. When you want a plugin to be external it has to be generated seperately from the main vm (by removing it from the list in Interpreter class> tranlsate:doInlining:forBrowser:) and the internal plugins. The code for any external plugin will be generated in a directory named after the plugin; thus FooPlugin will be created with FooPlugin translate which will result in a partial tree like this:- FooPlugin/ FooPlugin.c FooPlugin.h If FooPlugin is generated as an internal plugin, then you leave it in the list mentioned above and the files would be placed in the same directory as intep.c etc. Now, an interesting question is what to do with the platform specific files that go along with the generated plugin files? For example, FilePlugin typically requires sqAcornDirectory.c to go with it (on my Acorn). I suggest that these files need to be in the same directory as the generated files _wherever_ that is. This should make automagically working out what needs compiling in what manner easier; the older unix `autoconf ` stuff managed to work it out on this basis quite easily so I imagine most other similar systems would be happy as well. It would completely obviate any need for some handwritten list of what is an external plugin and what is internal. So, some way to work out where to move the plugin-companion files would be needed. Assuming we know the names of the plugin-companion files, we can look to see where the 'root' plugin file is and move the companions to be in the same place. To know which files belong together I suggest renaming files to include the plugin and platform with which they need to be associated. Thus we might have:- FilePlugin.c FilePlugin.h FilePluginAcornDirectory.c FilePluginAcornURL.c etc. If the file plugin is generated for internal linking then the two Acorn specifc files would be moved to the same directory that FilePlugin.c & interp.c live in. If it were generated for externla linking, then they would be moved to the FilePlugin directory - again, the same location as FilePlugin.c. This should be simple for anyone to follow. Of course, this arangement of files is not the same as that shown above! To compile on any particular platform (using my Acorn as an example again) we need a tree more like:- acorn/ src/ vm/ interp.c sq.h B2DPlugin.c B2DPlugin.h SurfacePlugin.c sqAcornWindow.c etc... plugins/ FilePlugin/ FilePlugin.c FilePlugin.h FilePluginAcorn.c FilePluginAcornURL.c SocketPlugin/ SocketPlugin.c SocketPlugin.h SocketPluginAcorn.c and similarly windows/ src/ vm/ plugins/ etc/ How do we get from one form to another? Well, you only need the one (the latter) form on your machine to compile a vm. Any system with links between files could support both forms trivially; the linux system supporting SourceForge should have no problems with having trees for each platform that are basically nothing more than links across to files laid out in the /portable /platform tree shown above. Such a linking scheme has advantages for future flexibility; when the J3 stuff needs to be included there will be CPU specific files as well as OS specific files. By simply adding directories for each of these and linking to suitable files we would be able to rapidly add support for (say) an Alpha powered MacOS platform. So what needs doing to change things? - a tool to make it easy to choose which plugins are internal or external (though you will I'm sure remember that I claim there is no virture in having any plugin internal on any machine that can support external plugins) - Rob Withers and Stephan Rudlof have done most of the work for this. - rename the files to make the names regular and easily parsable - add code to move plugin-companion files to the same place as the plugin-root file - change the make files to be able to tell the difference between the vm/ tree and the plugins/ tree, much as the release 2.7 unix autoconf could do. I suspect that many IDEs will not be able to do much with this last point - I know that my Acorn can't do it automagically, but then I have makefiles already sorted out for all-external plugins anyway :-) It just means that the platform janitor will have to do a little manual makefile/project file/whatever altering. tim

2 1

ConnectionQueue question???
by jchludzinski＠worldkey.net 02 Oct '00

02 Oct '00

I create an instance of ConnectionQueue to listen on a specified portNumber (hardwiring the queueLength to be 4). When I try to connect to this instance (using an instance of Socket: socket _ Socket newTCP. socket connectTo: (NetNameResolver localHostAddress) port: 54321. socket waitForConnectionUntil: Socket standardDeadline.) nothing shows up in 'connection' (an instance of OrderedCollection). As a consequence, 'getConnectionOrNil' returns 'nil'. Obviously I'm doing something wrong, any suggestions??? ---John

2 1

Font question...
by Mark Mayfield 02 Oct '00

02 Oct '00

Greetings... I've successfully installed some new fonts into Squeak using BitFont to create a data file, FontSet to convert, etc. Now... Is there a straightforward way to change the underscore character to the assignment arrow? Alan Kay once suggested to use a form editor, but I can't seem to make that work. Thanks, Mark

2 1

Jump to page: