Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

Re: Behaviors vs Modules
by Anthony Hannan 24 May '02

24 May '02

Jecel Assumpcao Jr <jecel(a)merlintec.com> wrote: > On Friday 22 February 2002 23:38, Anthony Hannan wrote: > > - A Smalltalk expression now knows, via the selectors it calls, which > > protocols and corresponding default behaviors it depends on. So > > starting from a Smalltalk expression we can trace selectors and > > methods recursively and load all default behaviors that will be > > needed. > > Two slight problems: > > 1) #perform: perform: will have to take a selector object that already knows its protocol instead of just a symbol. The selector's protocol will be loaded at runtime when the perform is triggered. > 2) if #foo is used in only one protocol in your system, you don't > have to say which one that is, right? Now imagine that you send your > module to me and I load it into my system which also has a #foo in only > one protocol, but it happens to be a different protocol from yours! The compiled method will have the selector object "foo" in its literals which knows its protocol, not the symbol #foo. So if you send the compiled method to another image (via image segments) then the protocol will go with it. If you just send the source code, your right, "foo" will be looked up in the new environment. But this is the same problem we have with globals now. How do I know "String" in my image means the same as "String" in your image? Cheers, Anthony

3 2

Squeakers in Seattle?
by Martin McClure 16 Apr '02

16 Apr '02

Hi all, I'm looking for a 'show of hands' of Squeakers based in the immediate area of Seattle. I'm working on a Seattle-based project that involves Squeak, and we'd like to know what kind of pool of local Squeakers there is to draw on in the unlikely event that I become unavailable to work on the Squeak code. If you are in the Seattle area and would conceivably be interested in such a thing, please mail me off-list. Thanks, -Martin

2 1

[BUG] Hugely inefficient FTP code: coding opportunity
by Henrik Gedenryd 08 Apr '02

08 Apr '02

I've now made remote up-and downloading of module work properly. However, Squeak's underlying FTP code is so painfully inefficient that I recommend that you avoid using it, and instead keep the accessRemoteRepostories preference off, and upload from the local repository cache using some other ftp program. An upload that takes say 5-15 seconds with another FTP program takes some *5 minutes* with Squeak according to the file time stamps. I've made downloads avoid this by using HTTP access. The problem is that Squeak's ftp code logs in and logs out between *every* CWD, load, store, etc. -- every single server action. It is this same deficiency that makes project loading so slow: 0.25 seconds to load an image segment from disk *really quickly*, but eons spent on redundantly logging in and out of the ftp server. It wouldn't be too hard to change the code to allow multiple commands within a single session: Put a socket instvar in ServerDirectory, and make the code either login and logout if that socket instvar is nil, or if not, just use it to send the command without logging in and out. Then wrap sessions in a login and ensured logout. The other option is supporting HTTP PUT, Cees would be willing to make the server support this, but this may not be trivial. I am not planning to spend my time on this. Henrik

3 6

[SqF]Report of VM Construction Project for Feb '02
by Tim Rowledge 06 Apr '02

06 Apr '02

This is the initial report for the VM Construction Project group. Since this is the first such report, I'll start with my view of the goals of the project. Goal: The purpose of this project is to create a vm building process and associated code that makes vm building as simple, reliable and maintainable as we can manage. Participants: tim, John McIntosh, Rob Withers, David Lewis, and of course Ian Piuumarta and Andreas Raab. Other participants to represent the other vm ports are sought. Stefan Rudlof, Goran Hultgren and others have provided advise and help. Background: From the initial release of Squeak, the image has included all the code needed to create a vm for a Mac. For other platforms there has been a variety of places and approaches used over time, mostly the provision of an archive of some sort with a file tree suited to the platform. Sometimes this has included 'common' files (files such as sq.h etc) that are derived from but not identical to those in the release image. This situation could continue into the future without being a major embarassment to the Squeak community, but some time ago I felt that it could be improved with some fairly simple changes. One of the original driving forces for the work that has been released as the VMMaker and VMMakerTool was the need at exobox to be able to produce frequent vm builds automatically without extensive user intervention. Another original aim was to find a way to produce a file tree that reasonably suited all known platforms and that was compatible with automated vm production. The time-honoured vm production routine was not very suited to thise aims. For example, generating the core of the vm required two unrelated incantations and produced a dump of files in the current wrking directory; these files needed moving, sometimes editing, before being compiled. Producing a vm for a Mac required a different incantation and produced a different group of files. Changing which set of plugins were produced and whether they were internal or external, required editing a method. None of this prevented a rudimentary script from being used succesfully, but it apearred untidy and suboptimal to some users. A secondary concern was the scattered provenance of the code for non-Mac machines and the varied update levels of that code. Using some common repository was suggested and seemed a sensible experiment. The initial attempts to use SourceForge mainly served to demonstrate that a better file organisation would be very helpful. Current status: The VMMaker has been the major focus of the work for this project thus far. It is currently able to produce vms for any of the four most active platform from a codebase stored on SourceForge. A UI exists that makes it easy to configure the plugins and to save and use said configurations. The basic tool is scriptable and has been documented on the swiki and in SqueakNews, as well as having been demonstrated at OOPSLA. Work is still in progress to bring all platforms to the same level of compliance (for want of a better word). Future Plans: The VMMaker codebase is reasonably complete but there are enhancements that might be worth pursuing - makefile (or at least makefile fragment) production, integration with sqCVS, vm internal configuration (cache size etc) amongst them. The codebase currently on SF is in good order, barring the mostly makefile related updating needed by non-unix platforms, but tools to make it easier to fetch the code in release-matched sets, to tag release sets, deal with branches and bug fixes are all needed. The most important goal is to reach agreement on adopting VMMaker or on an acceptable alternative. No other interesting alternative is currently proposed. Once a reasonable level of agreement is reached the artifact can be integrated into the main release, presumably by creating a module for it. tim. chair, VM construction project. "We live for the VM, we debug for the VM. But we don't debug stupidly"

10 33

Annoyance: Hierarchical Browser
by Ross Boylan 02 Apr '02

02 Apr '02

Most of the time when I open a hierarchical class browser the focal class is invisible, since it is below the very tiny scroll area that is shown. This seems a bit odd, since that class is highlighted (when scrolled into view, and it is controlling what you see in the other windows anyway). I see this both on MS Windows and Linux, though I wonder if it's a font thing and it looks OK on, e.g., a Mac.

3 2

RE: XML Parser choice (was Re: [ENH] ??? MD5 in Squeak.)
by Richard A. O'Keefe 25 Mar '02

25 Mar '02

"Andreas Raab" <Andreas.Raab(a)gmx.de> wrote: Code size isn't but complexity is. Usually these two go hand in hand and therefore it's no strange argument at all. In fact I'd argue that programmer time is (in this particular case) mostly dictated by the complexity involved in the parser itself - most people will want to do pretty simple stuff. But this is precisely why a non-validating parser would be a *bad* idea. Non-validating parsers are easy to write. But if anyone were to try to process DocBook using Squeak (hey, guess what I'm trying to learn?) such a parser would be as much use as an Apple ][ simulator (maybe less, come to think of it). If you really want to avoid complexity for people trying to use XML in Squeak, then choose a parser than implements *ALL* of XML, not just the dead easy bits. Do the hard stuff *once*.

13 16

Re: [ANN] [GOODIE] rST - Remote Smalltalk
by Diego Gomez Deck 25 Mar '02

25 Mar '02

Hi, >Really good. So, actually rST looks like RMI for Java. That's cool. >What do you have plan to do next ? The folowing steps are: 1) remote garbage collector (in progress) 2) replace the squeak serialization for other thing. I plan to port to others smalltalks and we need an serialization multi-smalltalk 3) I'll see > What do you want to do if you get instances from a server where the class does not exit on client ? And about migration. The framework support pass objects by copy or by reference. The problem only occurrs with "by copy" option, becouse in the "by reference" all the messages are processed in the image where the objec lives. The final goal is to interoperate with diferents smalltalks, so the problem to send the class to the other side is a REAL problem. >I have works for a good while on a similar system for Java. So perhaps I can contribute to go further. Of course! just tell me what do you want to do... >That is very nice, but better will certainly come. > >Best regards, >Alexandre Thanks, Diego Gomez Deck

6 5

[FIX] Color >> asColorref
by Hannes Hirzel 22 Mar '02

22 Mar '02

>From the preamble: "Change Set: ColorRefFix Date: 24 February 2002 Author: Hannes Hirzel The method Color >> asColorref which converts a Color to a RBG value now gives back really Red-Green-Blue." Conversion examples: Color red asColorref hex '16rFF0000' Color green asColorref hex '16rFF00' Color blue asColorref hex '16rFF' Color cyan asColorref hex '16rFFFF' Color yellow asColorref hex '16rFFFF00' Color magenta asColorref hex '16rFF00FF'

2 1

Updating BC to 3.3alpha (was: [BC][FIX] Block Closures, Version 2 Fix)
by Anthony Hannan 19 Mar '02

19 Mar '02

PhiHo Hoang <phiho.hoang(a)rogers.com> wrote: > Does Block Closures, Version 2 supports Squeak 3.3 Alpha with modules ? > My current image now is at update 4716. The system chokes at > update 4717CharBlockScannerFix-slg.(Syntax Error: 'DummyReceiverClass as > yet unclassified' in the upper pane, then 'Unmatched comment quote > ->"Change' in the lower pane) I see the problem. Changeset 4717 is missing a closing quote on its preamble. That is what produces the syntax error. For some reason the standard image does not choke on this syntax error but BC does. To work around it add the closing quote in the Syntax Error window (and remove the "Unmatched comment quote ->" tag), save, and then proceed through the notifier. If your using the pre-converted image, before getting updates you have to change "SystemVersion current" version to 'Squeak3.3alpha' and rollback its highestUpdate to 4653 before getting 3.3alpha updates. You also have to remove all number above 4653 in its updates set. (PhiHo might have figured this out already). The next time I put up a pre-converted image, I will only update it to 3.2alpha-4652, so you can easily go to 3.2gamma or 3.3alpha (or maybe I'll post both image versions). > BTW, will you incorporate Scott's enhancements into next version of BC ? Yes, but I'm going to call that VM "BC++" to distinguish it from core BC changes. > P.S: Does any one know if I can bypass that changeset to proceed to the next ones ? See above. Cheers, Anthony

3 2

Re: VM Profiling in Linux
by Anthony Hannan 11 Mar '02

11 Mar '02

Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: > Do a search on the mailing list for a couple of months ago, I give an > exact recipe. I believe someone added it to the swiki. I did follow the instructions from the swiki, but still no luck. Any Ideas? Thanks again, Anthony

2 1

Jump to page: