- Pharo-dev - lists.pharo.org

[Pharo-project] SqueakSource down
by Pavel Krivanek July 14, 2011

July 14, 2011

SqueakSource is currently down. -- Pavel

2 1

[Pharo-project] Who is in contact with the SqueakSource admins
by Tobias Pape July 14, 2011

July 14, 2011

Dear all Please, can somebody put me in contact with anyone who administers the SqueakSource.com instance/website? Iâd be glad to talk to this person(s). Best -Tobias

1 0

[Pharo-project] Fwd: [Pharo-bugtracker] Issue 4516 in pharo: copying a class should copy the sharedPools
by Igor Stasenko July 13, 2011

July 13, 2011

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 14 July 2011 00:40 Subject: Re: [Pharo-bugtracker] Issue 4516 in pharo: copying a class should copy the sharedPools To: codesite-noreply(a)google.com wow such evil bug.. and not detected before? good catch, Nicolas On 14 July 2011 00:03, Â <pharo(a)googlecode.com> wrote: > Updates: > Â Â Â Â Labels: -Squeak Type-Squeak > > Comment #2 on issue 4516 by nicolas....(a)gmail.com: copying a class should > copy the sharedPools > http://code.google.com/p/pharo/issues/detail?id=4516 > > (No comment was entered for this change.) > > > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] new Cog VMs available
by Eliot Miranda July 13, 2011

July 13, 2011

Hi All, find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/. These have functional ALien callbacks. Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32. Be aware that there are Newspeak VMs in that same directory. Be sure to use the archives beginning with Cog, not nsvm or Newspeak for Squeak, Pharo et al. enjoy -- best, Eliot

2 1

[Pharo-project] Python like generators for Pharo
by Max Leske July 13, 2011

July 13, 2011

Hi folks I've been reading a bit about Python generators and I think they're awesome. So I quickly looked for a Smalltalk implementation and found that GNU Smalltalk has one (http://smalltalk.gnu.org/blog/bonzinip/fun-generators) Now, I was wondering if there's an implementation for Pharo / Squeak (since I didn't find one on SqueakSource) and if not, if there might be any interest in one. If you're curious you should take a look at these: Generator Tricks for Systems Programmers - Version 2.0 A Curious Course on Coroutines and Concurrency http://www.dabeaz.com/generators-uk/GeneratorsUK.pdf Cheers, Max

4 4

[Pharo-project] About Cocoa VMs
by Igor Stasenko July 13, 2011

July 13, 2011

Hello everyone. I'd like to ask you to try and use the recent VMs built by Esteban. We all understand that it may not fully functional and could have some issues. But the point is, that the only way to discover glitches is to try it. Because if we wait till Esteban deliver perfect VM, it may never happen. Without people who testing it and providing feedback, it will simply won't work. So, Mac owners, lets help Esteban to bring us new shiny toy and try using newly built VMs and give feedback. The VMs i am talking about is located here: - Cog JIT https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Mac-Cocoa/ - Stack VM (no JIT) https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM-Mac-Carbon/ For issues, you can use cog issue tracker (http://code.google.com/p/cog/issues/list) or vm-dev mailing list. Lets not wait, but help in a form, which we can. After all, that's the only way to ensure that in future we will have good VM. -- Best regards, Igor Stasenko AKA sig.

5 11

[Pharo-project] Moose at GotoCon Aarhus / registration discount
by Tudor Girba July 13, 2011

July 13, 2011

Hi, This fall I will give a talk at GotoCon Aarhus (Oct 9-14) on "Humane assessment with Moose": http://gotocon.com/aarhus-2011/speaker/Tudor+Girba GotoCon used to be named JAOO. It is a large industrial software development conference that might of interest to some of you. As part the speaker package I have the possibility to offer discounts to interested participants. So, if you want to go to GotoCon Aarhus and are interested in a discount of about 170 EUR, please send me an email and I will provide the promotion code. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

2 1

[Pharo-project] Fuel vs. StOMP (answer to blog post of Runar Jordahl)
by Mariano Martinez Peck July 13, 2011

July 13, 2011

Hi guys. Several people asked several times the differences between the two "new" serializers Fuel and StOMP. Runar wrote several blog posts about it: http://blog.epigent.com/2011/07/new-smalltalk-object-serializers-fuel.html http://blog.epigent.com/2011/07/comparing-speed-of-stomp-and-fuel.html http://blog.epigent.com/2011/07/fuel-and-stomp-best-of-both.html So I would like to give you my point of view as a Fuel developer. Which are the main differences between Fuel and StOMP? 1) Portability. What that means? "portability" is too wide to just talk without details. For me, portability in this case means two things: portable format and portable code. Portable format: In a dialect/language XXX be able to materialize a stream which was serialized in a dialect/language YYY. Portable code: That the code of the serializer can also work in another dialect/language (not necessary including portable format). Fuel will does not do focus in portable format. At least, we will not do extra effort to support that. Regarding portable code, it is not Fuel first goal to be portable to other dialects but it is not that difficult anyway. In fact, Fuel has been even ported to Newspeak. In the contrary to Fuel, StOMP wants to be portable in both ways, format and code. But of course, it is difficult to find portable representation of certain objects like BlockClosure, MethodContext, Class, Trait, etc. StOMP do not deal which such objects due to the lack of those portable representations. In Fuel, we can serialize those objects but not in a portable way. So...next differences are: 2) In Fuel we want to be able to correctly serialize *any* kind of object. 3) Fuel will try to get the fastest way to serialize or materialize an object. StOMP will use the most fastest available while trying to generate a portable representation. 4) Another important difference is that Fuel is faster in materialization and StOMP in serialization. Why? Because a tool build on top of Fuel will be used for code management and loading is done much more times than saving (think as in parcels). Notice that this doesn't mean we are slow in serialization. We are faster than most of the serializers, but not as much as StOMP. What are the reasons of the differences in performance? because of their design and internals. It is a trade-off. To be faster at materialization, we do some extra work in serialization. StOMP does not do extra optimization for materialization and hence serialization is faster. What is that "extra" we do? Ok, we have wrote a whole paper for IWST 2011 so I won't repeat myself. I will let you know when we get the notifications of the paper so that we can make it public. Regarding your excellent paragraph: "But... A partial solution would be to use an intermediate format for *serialization*. This format would support fast serialization, and therefore be similar to StOMP's format. The intermediate format would for example be used when a user needs to quickly commit changes to a database. Later, the intermediate format could be transformed to a format that is better optimized for *deserialization*. This transformation would typically be done as a background task. The deserializer would be able to (transparently) understand both the intermediate format and the optimized format." I can just tell you that it is an excellent idea and we talked with Martin about it, but I am not sure about how easier it would be. Maybe it is just easier to have 2 serializers with 2 different goals :) Regarding "To me it appears like StOMP has better support for serialization/deserialization "hook" methods<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods>, class renaming<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/renaming> and shape changing<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/shapechangers>. Hopefully, Fuel can learn from StOMP in this field." I totally agree. StOMP's hook methods are awesome and we want to have the same in Fuel. In fact, check the issue tracker and you will see several open issues regarding this :) I think class renaming and shape changing are fine in Fuel. Finally, notice that we are not "competitors". We have sent several private emails between us and Masashi UMEZAWA and we are trying to share as much as possible. -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] Main OS window top most property?
by Denis Kudriashov July 13, 2011

July 13, 2011

Hello. Is it possible to setup main pharo OS window always top most property? For example In fullscreen mode I need no OS messages appear on top of pharo. Best regards, Denis

1 0

[Pharo-project] Group windows as tab screencast
by laurent laffont July 13, 2011

July 13, 2011

Here's a screencast: http://magaloma.blogspot.com/2011/07/twm-docking-windows.html Test and feedback welcome. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

2 2