Squeak-dev March 2009

squeak-dev@lists.squeakfoundation.org

134 participants
173 discussions

Sorry, I did vote
by Ralph Boland 04 Mar '09

04 Mar '09

In my previous posting I claimed I couldn't vote. Sorry, my mistake. I sorted it out and voted but forgot to remove the comment. Ralph Boland

1 0

[Ann] Rio Update
by Keith Hodges 03 Mar '09

03 Mar '09

Rio has recently received an update... - All tests that can pass do pass on windows and unix - Instanciation code is cleaner and more consistent. File new: 'afilename' is the basic form. - File/http/ftp urls are now supported - 'aString' asFile now uses the file extension to determine the resultant class - coercion is now consistent using #as: aClass e.g. 'aFile' asFile as: FileXML. - files can have a lineEndConvention which is honoured for text files - stream/reader code is cleaner - more tests - '/a/b/c' asFile relativeTo: '/a/b' returns 'c', but previously 'c' would not be a usable file reference, it is now. - addTree: now accepts a directory or a list of directories/files - New class demonstrating specialised readers - FileXML + fileMatching: + resolveMatchAll + resolveMatchOne 'file.*' asFile resolveMatchOne - "find one file that matches" + #entries/#filesMatching:/#select all ignore .DS_Store and __MACOSX for normal use. + someDir all delete doesnt ignore .DS_Store and __MACOSX + #clean equivalent of "all delete", but it uses OSProcess to run "rm -rf" or "del \s *.*" if possible. + addAll: addTree: bulk copying of files use OSProcess cp/ftp if it is loaded on windows and unix. + addAll: addTree: bulk copying of files is done n at a time (n = 5 ish) + addAll: addTree: bulk copying of files respects the new beOverwriting flag/mode, default is to not overwrite. + pretending - If you need to pretend to be on a different file system within a certain scope you can, we use this for testing. Keith

3 2

didn't get a ballot
by Craig Latta 03 Mar '09

03 Mar '09

Hi-- I got the test message a few days ago, but I haven't received a ballot (I searched all mail for "CIVS"). Help? I'm often reachable by IRC, in case that helps. thanks, -C

1 0

Crash dump
by Ang Beepeng 03 Mar '09

03 Mar '09

Is there any reference to learn on reading the crash dump report? Especially the stack dump, the exception code. Is there any way to trace back to the exact line of C code that causes the crash of Squeak VM? -- View this message in context: http://www.nabble.com/Crash-dump-tp22314485p22314485.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

2 3

Re: [Pharo-project] A point a.k.a excuse to you
by Keith Hodges 03 Mar '09

03 Mar '09

Michael Roberts wrote: > Keith, your email implies that you believe Pharo should be backwards > compatible at some level with Squeak. Part of the Pharo manifesto is > not to be compatible. So if you want to write code or have apis that > work in a backwards direction from Pharo to Squeak, that's great. I > don't believe it's a goal for Pharo though. The pharo process doesn't > need a rethink at all as far as I'm concerned. > > thanks, > > Mike > No that is not what I am saying at all. Perhaps examples would help. Take Rio. Rio was designed from ground up to be a replacement for a the present non-modular kernel facility FileDirectory. It is a discrete loadable module. Wild and horrible uses of FileDirectory are spread around the image in lots of places, so one thing that Rio tries to do is to anticipate use cases, so that the users of Rio dont have to implement File handling code in their stuff, and so we help to keep the module boundary clear. For example you can ask Rio to get you the next version of a file - 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in itself potentially lightens SmalltalkImage. If you want to read Xml files, you can subclass File, with FileXML, define the #validExtensions that it handles, and implement contents/contents: This means that your code only needs to send, 'myfile.xml' asFile contents, to get the model. There are all sorts of things like that. With Rio as a front end to File and Socket streams it is perfectly possible to innovate on them without users of Rio being any the wiser. If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' asFile contents, now means that I dont have to care about whether HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or HTTPClient returning a MultiByteStream thingy in 3.8 or some other new facility. So, Rio demonstrates that it is possible to innovate, on a kernel module, and you dont need to break anything to do it. Secondly by thinking about APIs and module interface abstractions in this way, you can define specific interfaces and bottlenecks, that potentially turn the ball of tangled string into something designed and architected. There are perhaps hundreds of other modules that could use the same treatment. Rio loads into all squeak images I have tried it in, so this then means that any of my file handling code will work in all images. This benefit comes from managing Rio as module external to the main image. Rio also comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in mind. Having done this, the question of moving the kernel over to make use of the new code arises, this also can be achieved without breaking anything for users that have had Rio available for 2 years in every image that their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, Magma, Etoys, can all migrate their file handling code to the new Rio API now, even if they are using Squeak 3.7/3.8, without having to upgrade to the latest squeak. When they do update, they will be pleased to find that their file handling code works, as well as their gzipping/archiving/remote file handling/and website accessing code. Installer follows the same principles, abstracting an api, freeing the backend to be either old code or new code. If you dont have Universes loaded, then defining Installer>>#universes to call #sake as a fall back would use Sake/Packages and get identical results, your users would be none the wiser. If you dont have SqueakMap loaded, then defining Installer>>#squeakmap to call #websqueakmap instead, would again give your users identical results. and you thought that Installer was just for loading things. Edgar has pointed out that you could use CodeLoader for that, but thats not the point of installer, Installer is providing a DSL for loading things that provides an architectural layer of isolation, and thus both inherrent forward and backward compatibility. I expect my image building scripts to work identically with Monticello2 in squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7. Scripter (who here even knows that Scripter exists?) does the same, if you want to write code to close or tile all the windows, after the installing process has left a mess. Scripter can be the interface to whatever backend GUI there happens to be whether it is ToolBuilder/Tweak/Morphic. Same again with Logging, is a front end abstraction to all of the three+ logging backends out there. I can remove the hardwired calls to Transcript that scatter the image and replace them with a single api to multiple backends, both past (Transcript) present (Syslog) and future (seaside per-user session logging framework). Oh, and again with Sake/Packages.... why does Sake/Packages define class tasks? You can write a task that depends upon a task which removes certain method selectors. You could just call Behaviour direct. Its another architectural layer, that frees up the back end to be old or new code as far as Sake task writers are concerned. I can write a task that says, "if you find this Class with a method categorised as so, then it needs to be recategorised as such", in such a way as this task would run in all images. Oh and again SystemEditor... another layer of abstraction for compiling and loading code atomically. So if you think about it, those who know about the compiler could be considering how to write their stuff, so that it logs to the Kernel Logging API (which is valid even if Logging isnt Loaded). They might consider connecting to SystemEditor in preference to providing a direct api, and another abstracted pluggable Module is needed to handle source code files (replacing RemoteString/ChangeSets etc), with Rio as the local/remote file API. Do you get the idea now? For the same treatment to be available for more significant chunks of squeak, we would need atomic loading to work. Now the code to provide atomic loading for everyone has been available for over a year, and it works if you dont use traits. So where is the expertise to really get it working for everyone with traits? The only difficulty with this approach is that you might need slightly different bits to make your NEW code load into older images. This problem is reasonably easily addressed with Installer-Scripts (LevelPlayingField+) and Sake/Packages. I fully agree with Matthew about core packages like Collections. BUT and this is the big but. If you are going to do that kind of thing, you need to think about it, plan it, and create and participate in a process that supports everyone is diverse images using and testing that package. From what I have seen there is only one person on the Pharo team that understands what LevelPlayingField is for, and how to use it. The biggest risk to this approach is if some other folks decide to fork some significant architectural component in a completely incompatible manner, without thinking about any bigger picture at all. Matthew's comment about how our tools are only just getting there isnt that relevant to the point that I am making. I didnt need a test and build server to innovate Rio for everyone rather than just for the image I am using (trouble was I was using 3 different images), all I needed was an inclusive attitude rather than an exclusive attitude. cheers Keith

8 13

Burn the Squeak Image! (Why I am running for board)
by Matthew Fulmer 03 Mar '09

03 Mar '09

Squeak is a growing community with diverse needs. We have long outgrown the monolithic image left to us by our founders, Dan Ingalls and company. The community has long been building its own images for many purposes, targeting many audiences: end-users, application developers, core developers, and researchers. Some examples: 2001: Squeakland Etoys 2002: Croquet 2003: Spoon, by Craig Latta. An experiment in very high modularity 2004: DPON, by Michael van der Gulik: A project to revive Henrik Godenryd's modularity framework abandoned in Squeak 3.3 2005: Morphic removal, by Edgar J. de Cleene 2006: Scratch, by MIT Media Lab: An end-user application for easily building and sharing animations, and teaching basic programming 2007: squeak-dev, by Damien Cassau. A distribution targeted toward application developers. 2008: Pharo, by Stephane Ducasse and others. A team focused on dramatically raising the code quality, usabily, and standards conformance of squeak overall. We need to burn from our minds the idea that there is one "official" squeak image that serves the needs of the whole community. It is a lie. Given that no "official image" can meet the needs of everybody, who should we target when building something official? We need to build things for those who would build better images themselves. Having many good images to choose from makes everybody happier. The only issue with the situation is that they are not always compatible. I believe this is the core issue that the board and the squeak release team needs to address. A standard "kernel image" that everyone builds off of has long been a pipe dream of nearly everyone in the community. I believe that such an image is not achievable in the short term; convincing all of the squeak distributions to adopt it would be nearly impossible to adopt incrementally. A more practical approach to that end is Standard Packages. A major issue we have currently is that bugs get fixed in one distribution, but never applied to another. However, if all distributions of squeak used the same version of a package, it would be very easy: fix the bug in the common package, and each distribution will eventually upgrade to it. I would like the board to do the following project, and I can manage it: By this time next year, every squeak distribution (squeak.org, Pharo, eToys, cobalt) will be running a standard version of the following three packages: - Collections - Streams - Compiler We will also fix and close all of the issues on mantis relating to these packages If we start this process and continue it, we will eventually have enough standard packages to build a kernel image, and everybody will already be running on it. I do not believe the board should do this to the exclusion of all else, just as one of several projects. I fully support Andreas's election platform: we should indeed start having both a stable and unstable release, both happening in parallel -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

23 71

Newspeak has been released. TIme to be reeducated :)
by Eliot Miranda 03 Mar '09

03 Mar '09

Hi All, Gilad Bracha, Vassili Bykov and Peter von der Ahé have announced the first public release of Newspeak<http://gbracha.blogspot.com/2009/02/newspeak-prototype-escapes-into-wild.ht…>, Gilad's modular Smalltalk (r)evolution for cloud computing. There's already a lively forum discussion <http://forums.newspeaklanguage.org/index.php>. Enjoy! Best Eliot

5 4

FFI on linux
by Sebastian Sastre 02 Mar '09

02 Mar '09

hi there, I can't make it work FFI in linux. I have all test red. The external function handle is '@ 16r00000000' for all tests. Sounds like a an installation issue. I'm on an ubuntu 8.04 and I've installed via apt-get packages: squeakvm squeak squeak-plugins >From the image (runing as root) I've installed FFI from universes. And is all red any ideas? sebastian

4 13

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
by Daniel Ingalls 02 Mar '09

02 Mar '09

Eliot Miranda <eliot.miranda(a)gmail.com> wrote... > You're absolutely right. The major image-level change I will > require is for Behavior to implement identityHash with a primitive > that is different form that in Object. Doing this allows me to > implement a hidden class table in the VM where a class's identity > hash is the index into the class table. An instance of a class has > the class's class table index (the class's id hash) stored in its > header, not a direct pointer to the class. So every object has a > more compact class reference, say 16, 20 or 24 bits. Also, class > references in in-line and method caches are class indices, not > direct class references, which means less work on GC. But to ensure > a class can be entered in the table by the VM at an unused index > Behaviour>>identityHash must be a special primitive that the VM > implements as searching the table for an unused index. Hi, Eliot - I've been mostly lurking for a while here, but this topic has become more interesting with each tidbit. I just wanted to say that I love the synergy between hash and class table rolled into the elimination of compact classes. It's an improvement in every way. I can't wait to see this all come to life. You go, guy! - Dan

2 1

[ANN] Syslog for Toothpick
by Udo Schneider 02 Mar '09

02 Mar '09

All, From a project I'm currently working on I just extracted an Syslog Extension for Toothpick. So if you are running (headless) Squeak or Seaside apps on *nix this might be usefull. http://www.squeaksource.com/Toothpick.html CU, Udo

4 7

Jump to page: