December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] An excellent news

by Mariano Martinez Peck

Excellent news indeed. Thanks INRIA and good to know Igor can continue working for Pharo!! On Thu, Dec 6, 2012 at 3:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > My thanks. I will try to do my best :) > > -- > Best regards, > Igor Stasenko. > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2012

[Pharo-project] [ANN] Pharo 2.0 enters BETA

by Esteban Lorenzano

Hi, Today I finished the pending integrations for move to Pharo 2.0. There is still a problem with the VMs (for NB), but that's not a stopper for moving on. What does this means? Starting now, no new changes of API will be allowed, just bug fixes and minor enhancements that does not change the system behavior. We still have a long stabilization path until we can release, but we hope a couple of months will put us in shape :) Esteban

Dec. 6, 2012

Re: [Pharo-project] [Fuel] Materialization error, #DoIt Not found

by Vanessa PeÃ±a Araya

Hi Mariano, It works, thank you very much! Vanessa. On 12/05/2012 07:13 PM, Mariano Martinez Peck wrote: > quick answer (later with more detail): > Install also de package: FuelMetalevel and instantiate the serializer > this way (instead of #newDefault) > > FLSerializer newDefaultWithMethodSupport > > let me know if it works. > > On Wed, Dec 5, 2012 at 10:40 PM, Vanessa PeÃ±a Araya > <van.c.pena(a)gmail.com <mailto:van.c.pena@gmail.com>> wrote: > > Hi, > > I was working with Fuel to save and load a Roassal view (serialize > and materialize), and everything works perfect (so far) except for > one thing: if I have an Anouncer which its registry has an > announcementSubscription with a nil subscriber, it does not work > is gives me this error: > > > > Standard Roassal interactions are OK, but if I do: > > aRoElement on: ROMouseClick do: [something] in a Wokspace > materialization does not work. If I execute the same code in a > method send as message to an object I have not this error and > materialization works perfectly. This means I can not save some > visualizations created in the Workspace. > > Have anyone experience something like this? > > Thanks, > Vanessa. > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Guillermo Polito

On Thu, Dec 6, 2012 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 December 2012 16:44, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 6 December 2012 16:28, Guillermo Polito <guillermopolito(a)gmail.com> > >> wrote: > >> > Wait, all delays are signaled when the image is saved? So, if I have a > >> > five > >> > minute delay in a process and I save the image 2 seconds later... > >> > > >> > [ d := 5 minutes asDelay. > >> > d wait. > >> > Transcript logCr: 'asd' ] fork. > >> > > >> > Smalltalk snapshot: true andQuit: false. > >> > > >> > That is a limitation but is also a bug :/... > >> > > >> no.. they are not.. sorry my first comment was not correct.. i > >> corrected myself in followup :) > > > > > > I understand the 1 delay<->1 semaphore. But I am not creating several > ones. > > What if a second process saves the image while another one is waiting? > > > > This piece of code shows that problem. > > > > [ d := 5 minutes asDelay. > > d wait. > > Transcript logCr: 'asd' ] fork. > > Smalltalk snapshot: true andQuit: false. > > > > It will not honor the delay :/ > > > ah.. ok. then that's indeed a problem. > about not honors: is it signal it prematurely or not signaling it at all? > > prematurely :) > -- > Best regards, > Igor Stasenko. > >

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Igor Stasenko

On 6 December 2012 16:44, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 6 December 2012 16:28, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > Wait, all delays are signaled when the image is saved? So, if I have a >> > five >> > minute delay in a process and I save the image 2 seconds later... >> > >> > [ d := 5 minutes asDelay. >> > d wait. >> > Transcript logCr: 'asd' ] fork. >> > >> > Smalltalk snapshot: true andQuit: false. >> > >> > That is a limitation but is also a bug :/... >> > >> no.. they are not.. sorry my first comment was not correct.. i >> corrected myself in followup :) > > > I understand the 1 delay<->1 semaphore. But I am not creating several ones. > What if a second process saves the image while another one is waiting? > > This piece of code shows that problem. > > [ d := 5 minutes asDelay. > d wait. > Transcript logCr: 'asd' ] fork. > Smalltalk snapshot: true andQuit: false. > > It will not honor the delay :/ > ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all? -- Best regards, Igor Stasenko.

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Guillermo Polito

> > I understand the 1 delay<->1 semaphore. But I am not creating several ones. Meant "I am not using it several times" :).

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Guillermo Polito

On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 December 2012 16:28, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Wait, all delays are signaled when the image is saved? So, if I have a > five > > minute delay in a process and I save the image 2 seconds later... > > > > [ d := 5 minutes asDelay. > > d wait. > > Transcript logCr: 'asd' ] fork. > > > > Smalltalk snapshot: true andQuit: false. > > > > That is a limitation but is also a bug :/... > > > no.. they are not.. sorry my first comment was not correct.. i > corrected myself in followup :) > I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting? This piece of code shows that problem. [ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false. It will not honor the delay :/ > > > > > On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 6 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > this is not a bug, but limitation. > >> > delay object(s) are not reentrant: means that you shall not use same > >> > delay instance multiple times, i.e. > >> > > >> > delay := 1 seconds asDelay. > >> > 10 timesRepeat: [ [ delay wait ] fork ]. > >> > > >> > instead you shall create a fresh instance for each "delay" intent: > >> > > >> > 10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ]. > >> > > >> > > >> if Delay could implement #copy, then you could write like: > >> > >> > >> delay := 1 seconds asDelay. > >> 10 timesRepeat: [ [ delay copy wait ] fork ]. > >> > >> this is because a Delay has 1:1 correspondence with its semaphore > object. > >> and when you scheduling it multiple times, it will end up using same > >> semaphore for all instances of it... > >> and that's why you get weird behavior. > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Igor Stasenko

On 6 December 2012 16:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Wait, all delays are signaled when the image is saved? So, if I have a five > minute delay in a process and I save the image 2 seconds later... > > [ d := 5 minutes asDelay. > d wait. > Transcript logCr: 'asd' ] fork. > > Smalltalk snapshot: true andQuit: false. > > That is a limitation but is also a bug :/... > no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :) > > On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 6 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > this is not a bug, but limitation. >> > delay object(s) are not reentrant: means that you shall not use same >> > delay instance multiple times, i.e. >> > >> > delay := 1 seconds asDelay. >> > 10 timesRepeat: [ [ delay wait ] fork ]. >> > >> > instead you shall create a fresh instance for each "delay" intent: >> > >> > 10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ]. >> > >> > >> if Delay could implement #copy, then you could write like: >> >> >> delay := 1 seconds asDelay. >> 10 timesRepeat: [ [ delay copy wait ] fork ]. >> >> this is because a Delay has 1:1 correspondence with its semaphore object. >> and when you scheduling it multiple times, it will end up using same >> semaphore for all instances of it... >> and that's why you get weird behavior. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Igor Stasenko

On 6 December 2012 16:15, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> this is not a bug, but limitation. >> delay object(s) are not reentrant: means that you shall not use same >> delay instance multiple times, i.e. >> >> delay := 1 seconds asDelay. >> 10 timesRepeat: [ [ delay wait ] fork ]. >> >> instead you shall create a fresh instance for each "delay" intent: >> >> 10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ]. >> >> > if Delay could implement #copy, then you could write like: > > > delay := 1 seconds asDelay. > 10 timesRepeat: [ [ delay copy wait ] fork ]. > > this is because a Delay has 1:1 correspondence with its semaphore object. > and when you scheduling it multiple times, it will end up using same > semaphore for all instances of it... > and that's why you get weird behavior. > err.. sorry.. not for "all instances".. since there's only one instance.. so single semaphore will be used to schedule multiple delays (but using single Delay object). and when that semaphore get signaled.. you'll get strange results . if you want to fix that, then it will require disassociating delay object from its semaphore.. the delay will no longer need to hold a 'semaphore' directly by itself but then without it, it will not require to hold any more state than simple Duration. so, to do it right, we will need to make quite some changes in delay scheduling code.. basicaly we will need to create a private object, which will hold 'semaphore + delay object ' pair and put that object in schedule. which at the end will just make same as following: delay := 1 seconds. 10 timesRepeat: [ [ delay asDelay wait ] fork ]. so, to make you happy, just add #wait protocol to Duration: wait ^ self asDelay wait so you can write: delay := 1 seconds. 10 timesRepeat: [ [ delay wait ] fork ]. end of story :) -- Best regards, Igor Stasenko.

Dec. 6, 2012

Re: [Pharo-project] Delay bug

by Guillermo Polito

Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later... [ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false. That is a limitation but is also a bug :/... On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > > this is not a bug, but limitation. > > delay object(s) are not reentrant: means that you shall not use same > > delay instance multiple times, i.e. > > > > delay := 1 seconds asDelay. > > 10 timesRepeat: [ [ delay wait ] fork ]. > > > > instead you shall create a fresh instance for each "delay" intent: > > > > 10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ]. > > > > > if Delay could implement #copy, then you could write like: > > > delay := 1 seconds asDelay. > 10 timesRepeat: [ [ delay copy wait ] fork ]. > > this is because a Delay has 1:1 correspondence with its semaphore object. > and when you scheduling it multiple times, it will end up using same > semaphore for all instances of it... > and that's why you get weird behavior. > > > -- > Best regards, > Igor Stasenko. > >

Dec. 6, 2012