Hi Esteban,
I also build my own images from scratch. I do it allways and from time to time just to keep project healthy. I set the script that customizes this devel images to load Magma between the first 5 packages to avoid those kind of problems.
cheers,
Sebastian
-----Mensaje original----- De: magma-bounces@lists.squeakfoundation.org [mailto:magma-bounces@lists.squeakfoundation.org] En nombre de Esteban Lorenzano Enviado el: Viernes, 08 de Febrero de 2008 16:14 Para: magma@lists.squeakfoundation.org Asunto: Re: Magma on 3.10
Hi, Thanks for the answers... I'm "rollbacked" my changes and started form zero againg... with 3.10 image but without damien's pre-builts (I don't need Rio or other things, so... I did an image from scratch). And voila! no more problems... so, my wrong hack is not alive anymore. I'm sorry, I did not send an stack trace because I don't know how to get it :(
Cheers, Esteban
On 2008-02-08 02:00:49 -0200, "Chris Muller" asqueaker@gmail.com said:
Hi, I just installed magma on a squeak-dev image (from Damien Cassou) based on build 7159 (latest 3.10 image)
My, that image sure is gettin' pretty these days..
I load packages "magma client 1.0 (r40)", "magma server 1.0 (r40)" and
You don't need to load them all. Server includes client. Tester includes server includes client.
"magma tester 1.0 (r40)" from universes and executed first
"getting
started" code, with a very simple modification:
MagmaRepositoryController create: (FileDirectory default directoryNamed:
'repository') fullName
root: Dictionary new
Great, thanks for the code.
executing this code throws a doesNotUnderstood: #open on
ByteString.
The message call comes from MaFileStreamPool>>renewAccess:
Note for the future, stack traces are useful.
Same code executed on a 3.9 image (from Damien Cassou,
too) works fine.
Is there a possible solution for this? i really need to
run magma on
3.10 images.
Well, the problem is caused by the Rio package overriding
Object>>#in:
with Stream>>#in:. I recommend deleting Stream>>#in: from Rio because:
- It violates Smalltalk best-practices by overriding #in: with
something of different semantics.
- The semantics are different because it answers the FILENAME
string, of all things, instead of the value of the block. So it is less useful too.
- Further, closing the file with such basic method as #in: is too
presumtious. We already have FileStream>>#detectFile:do:
to serve the
intended purpose, but with even more power and flexibility.
The #yourself you added is an incorrect fix, since it will
leave the
file closed instead of open. It probably only worked for
you out of
luck and the resilience of the surrounding code..
Regards, Chris
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma