September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fix for Explorer->Browse full

by Marcus Denker

On Sep 21, 2011, at 10:29 AM, Dennis Schetinin wrote: > I have that issue in my 1.3 images (including the PharoOneClick1.3 #13299, for instance). > It was fixed in an update after 13299. The current version is 13307 Marcus > 2011/9/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > it is integrated in 1.3 and 1,4 so this is fixed no? > > Stef > On Sep 21, 2011, at 4:17 AM, Dennis Schetinin wrote: > > > Yea, that irritates me, thanks for the fixâ¦ but the links look broken for me. > > > > 2011/9/13 Sean P. DeNigris <sean(a)clipperadams.com> > > You may have noticed the very annoying bug in 1.3 and 1.4, where when you try > > to browse the class, the browser always takes you to ByteString, no matter > > what's selected. This has been fixed in both 1.3 and 1.4 > > (http://code.google.com/p/pharo/issues/detail?id=4548) > > > > If you have a version of 1.3 dev without the fix, you can file > > http://forum.world.st/file/n3810137/Inspector-browseMethodFull.st > > Inspector-browseMethodFull.st in. > > > > Cheers, > > Sean > > > > -- > > View this message in context: http://forum.world.st/Fix-for-Explorer-Browse-full-tp3810137p3810137.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > Dennis Schetinin > > > > > > -- > Dennis Schetinin -- Marcus Denker -- http://marcusdenker.de

Sept. 21, 2011

Re: [Pharo-project] Fix for Explorer->Browse full

by Dennis Schetinin

I have that issue in my 1.3 images (including the PharoOneClick1.3 #13299, for instance). 2011/9/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > it is integrated in 1.3 and 1,4 so this is fixed no? > > Stef > On Sep 21, 2011, at 4:17 AM, Dennis Schetinin wrote: > > > Yea, that irritates me, thanks for the fixâ¦ but the links look broken for > me. > > > > 2011/9/13 Sean P. DeNigris <sean(a)clipperadams.com> > > You may have noticed the very annoying bug in 1.3 and 1.4, where when you > try > > to browse the class, the browser always takes you to ByteString, no > matter > > what's selected. This has been fixed in both 1.3 and 1.4 > > (http://code.google.com/p/pharo/issues/detail?id=4548) > > > > If you have a version of 1.3 dev without the fix, you can file > > http://forum.world.st/file/n3810137/Inspector-browseMethodFull.st > > Inspector-browseMethodFull.st in. > > > > Cheers, > > Sean > > > > -- > > View this message in context: > http://forum.world.st/Fix-for-Explorer-Browse-full-tp3810137p3810137.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > -- > > Dennis Schetinin > > > -- Dennis Schetinin

Sept. 21, 2011

Re: [Pharo-project] Fix for Explorer->Browse full

by StÃ©phane Ducasse

it is integrated in 1.3 and 1,4 so this is fixed no? Stef On Sep 21, 2011, at 4:17 AM, Dennis Schetinin wrote: > Yea, that irritates me, thanks for the fixâ¦ but the links look broken for me. > > 2011/9/13 Sean P. DeNigris <sean(a)clipperadams.com> > You may have noticed the very annoying bug in 1.3 and 1.4, where when you try > to browse the class, the browser always takes you to ByteString, no matter > what's selected. This has been fixed in both 1.3 and 1.4 > (http://code.google.com/p/pharo/issues/detail?id=4548) > > If you have a version of 1.3 dev without the fix, you can file > http://forum.world.st/file/n3810137/Inspector-browseMethodFull.st > Inspector-browseMethodFull.st in. > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/Fix-for-Explorer-Browse-full-tp3810137p3810137.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Dennis Schetinin

Sept. 21, 2011

[Pharo-project] Moose presentation

by laurent laffont

Hi, Doru has introduced Moose to my local developer group. This one hour presentation through Skype was recorded and you can watch it here: http://vimeo.com/29338546 Laurent

Sept. 21, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Martin Dias

Hi > if you look at the problem in wider perspective, then right question > to ask, is how to deal > with objects which are register themselves in global facilities, like > weak finalization, > startup/shutdown lists etc. Fuel can handle globals... but I don't understand how can weak objects be accessed as global. Could you give a snippet exemplifying, please? Martin On Tue, Sep 20, 2011 at 11:03 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 September 2011 03:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: > > But how does Fuel "know" that the objects are not otherwise referenced? > The idea of ignoring weak collections sounds a lot like a compiler > optimization that sounds efficient and harmless - sometimes they cause huge > problems. Think of it this way, if the objects are not otherwise > referenced, sure they will be gc's soon - why are are they still around??? > > the main problem i think is to make fuel to know which objects are > belong to your model, and which is not. > because in Levente's suggestion, this makes a difference between > either serializing a pointer or just replacing it with nil. > > But then, once you introduce "this object belongs to my model" logic, > a new question immediately arises: what if some object strongly > referencing an object outside your model? > So, the problem is more general than just do it selectively only for > weak containers. Either you doing it uniformly (providing facilities > to deal with everything which outside your domain/model somehow), > or you just walk the graph and storing everything (treating all object > found as ones , who belong to your model). And there is nothing > special to do with weak containers. > > > The comments re globally registered objects are well taken too. > Dolphin's proxies are a great way to handle such things: some objects > delegate their serialization to a proxy that contains logic to do global > registration, etc. > > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > [nicolas.cellier.aka.nice(a)gmail.com] > > Sent: Tuesday, September 20, 2011 6:08 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] Should a serializer do something in > particular with weak references? > > > > 2011/9/21 Levente Uzonyi <leves(a)elte.hu>: > >> On Tue, 20 Sep 2011, Mariano Martinez Peck wrote: > >> > >>> Hi guys. Martin and I were discussing whether we should do something in > >>> particular in Fuel with Weak references, such as WeakArray. Should we > >>> serialize it the same way we serialize all objects, or should we do > >>> something special? what could be the impact of materializing such weak > >>> references in a new image for example? > >> > >> You should ignore (serialize nil instead of them) the elements of a weak > >> object (#weakSubclass:...) which aren't referenced strongly from other > >> serialized objects. > >> > >> > >> Levente > >> > > > > Ach, you commited shorter and quicker ;) > > > > Nicolas > > > >>> > >>> Thanks your sharing your thoughts. > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Sept. 21, 2011

Re: [Pharo-project] what are the frameworks to develop 3d interactive world like codecity in Pharo

by Luc Fabresse

Hi Guys, I think that depending on your goals both approaches are good: - binding to OpenGL it would be very cool to have a working/solid solution in this area. As Henrik and Marcus said, native support would be great. If I remember correctly, Lumiere is not very usable. Perhaps with NativeBoost and its GL bindings could be a way to go. - software 3D (no hardware support) As Alex said, for simple stuff it could be enough and it is easier to ensure portability. But be carreful of the size of your scenes because I think that Moose graphs could be huge and it could be really really slow... Cheers, #Luc 2011/9/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Ok what is your experience with lumiere? > I would like to see if we can have Plotz or another solution to display > metrics in Moose. > > Stef > > On Sep 20, 2011, at 1:53 PM, Alexandre Bergel wrote: > > > I think that recoding a 3d engine is easier and much less frustrating > that making Pharo talk to OpenGl. I am not aware of the last progresses made > on that front, but I burnt 1 student on this. > > > > Codecity visualizations are not complex, it is just a matter of > displaying triangles and multiplying matrixes. A student here learnt > Smalltalk that way: > > http://bergel.eu/download/papers/Jaca11a-Klotz.pdf > > > > Cheers, > > Alexandre > > > > On 20 Sep 2011, at 08:45, StÃ©phane Ducasse wrote: > > > >> Hi guys > >> > >> we would like to propose a fun project and the idea would be to build a > little codecity. > >> Now what are the frameworks to develop 3d interactive world in Pharo? > >> > >> - Lumiere? > >> - opengl binding? > >> > >> Stef > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > >

Sept. 21, 2011

Re: [Pharo-project] Fix for Explorer->Browse full

by Dennis Schetinin

Yea, that irritates me, thanks for the fixâ¦ but the links look broken for me. 2011/9/13 Sean P. DeNigris <sean(a)clipperadams.com> > You may have noticed the very annoying bug in 1.3 and 1.4, where when you > try > to browse the class, the browser always takes you to ByteString, no matter > what's selected. This has been fixed in both 1.3 and 1.4 > (http://code.google.com/p/pharo/issues/detail?id=4548) > > If you have a version of 1.3 dev without the fix, you can file > http://forum.world.st/file/n3810137/Inspector-browseMethodFull.st > Inspector-browseMethodFull.st in. > > Cheers, > Sean > > -- > View this message in context: > http://forum.world.st/Fix-for-Explorer-Browse-full-tp3810137p3810137.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Dennis Schetinin

Sept. 21, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Igor Stasenko

On 21 September 2011 03:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > But how does Fuel "know" that the objects are not otherwise referenced? Â The idea of ignoring weak collections sounds a lot like a compiler optimization that sounds efficient and harmless - sometimes they cause huge problems. Â Think of it this way, if the objects are not otherwise referenced, sure they will be gc's soon - why are are they still around??? the main problem i think is to make fuel to know which objects are belong to your model, and which is not. because in Levente's suggestion, this makes a difference between either serializing a pointer or just replacing it with nil. But then, once you introduce "this object belongs to my model" logic, a new question immediately arises: what if some object strongly referencing an object outside your model? So, the problem is more general than just do it selectively only for weak containers. Either you doing it uniformly (providing facilities to deal with everything which outside your domain/model somehow), or you just walk the graph and storing everything (treating all object found as ones , who belong to your model). And there is nothing special to do with weak containers. > The comments re globally registered objects are well taken too. Â Dolphin's proxies are a great way to handle such things: some objects delegate their serialization to a proxy that contains logic to do global registration, etc. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Tuesday, September 20, 2011 6:08 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Should a serializer do something in particular with weak references? > > 2011/9/21 Levente Uzonyi <leves(a)elte.hu>: >> On Tue, 20 Sep 2011, Mariano Martinez Peck wrote: >> >>> Hi guys. Martin and I were discussing whether we should do something in >>> particular in Fuel with Weak references, such as WeakArray. Should we >>> serialize it the same way we serialize all objects, or should we do >>> something special? Â what could be the impact of materializing such weak >>> references in a new image for example? >> >> You should ignore (serialize nil instead of them) the elements of a weak >> object (#weakSubclass:...) which aren't referenced strongly from other >> serialized objects. >> >> >> Levente >> > > Ach, you commited shorter and quicker ;) > > Nicolas > >>> >>> Thanks your sharing your thoughts. >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> > > > -- Best regards, Igor Stasenko.

Sept. 21, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Schwab,Wilhelm K

But how does Fuel "know" that the objects are not otherwise referenced? The idea of ignoring weak collections sounds a lot like a compiler optimization that sounds efficient and harmless - sometimes they cause huge problems. Think of it this way, if the objects are not otherwise referenced, sure they will be gc's soon - why are are they still around??? The comments re globally registered objects are well taken too. Dolphin's proxies are a great way to handle such things: some objects delegate their serialization to a proxy that contains logic to do global registration, etc. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Tuesday, September 20, 2011 6:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Should a serializer do something in particular with weak references? 2011/9/21 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 20 Sep 2011, Mariano Martinez Peck wrote: > >> Hi guys. Martin and I were discussing whether we should do something in >> particular in Fuel with Weak references, such as WeakArray. Should we >> serialize it the same way we serialize all objects, or should we do >> something special? what could be the impact of materializing such weak >> references in a new image for example? > > You should ignore (serialize nil instead of them) the elements of a weak > object (#weakSubclass:...) which aren't referenced strongly from other > serialized objects. > > > Levente > Ach, you commited shorter and quicker ;) Nicolas >> >> Thanks your sharing your thoughts. >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Sept. 21, 2011

Re: [Pharo-project] Should a serializer do something in particular with weak references?

by Nicolas Cellier

2011/9/21 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 20 Sep 2011, Mariano Martinez Peck wrote: > >> Hi guys. Martin and I were discussing whether we should do something in >> particular in Fuel with Weak references, such as WeakArray. Should we >> serialize it the same way we serialize all objects, or should we do >> something special? Â what could be the impact of materializing such weak >> references in a new image for example? > > You should ignore (serialize nil instead of them) the elements of a weak > object (#weakSubclass:...) which aren't referenced strongly from other > serialized objects. > > > Levente > Ach, you commited shorter and quicker ;) Nicolas >> >> Thanks your sharing your thoughts. >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Sept. 20, 2011