- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20430

by StÃ©phane Ducasse

We make progress no bikshed discussion :) Stef On Dec 6, 2012, at 3:58 PM, Esteban Lorenzano wrote: > yeah, but it looks more "childish", IMO... anyway, there is not a discussion with this: it will be the rounded one :) > > On Dec 6, 2012, at 3:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 06 Dec 2012, at 15:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> well... I agree with you (that was the icon I was using with the first ones, in mac), but Stef likes more the other: >>> >>> >>> <Pharo.icns> >>> >>> :) >> >> Yes, the larger, rounder one make a better click target. >> >>> On Dec 6, 2012, at 3:39 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >>> >>>>> I'm working now in produce branded Pharo VMs with NB support out of the box. >>>> >>>> Please - can we use the attached icon for the new "branded" >>>> windows VM. It is more Pharo like than the "Cog wheel" one and >>>> includes all sizes. >>>> >>>> Thanks >>>> T. >>>> <Windows.ico> >>> >> >> > >

Dec. 6, 2012

Re: [Pharo-project] Progress Update

by StÃ©phane Ducasse

Camillo I do not know. Now I will have a look at your change because I was also fixing a bit the progressBar class. Removing some useless methods and I grouped all the job class under kernel-job and progressbar under morphic progress bar because I was fed up to see them in process and system support mixed with other. > I promised to fix my partial refactoring for the ProgressBar. > Finally this evening I hacked on the whole progress mess :), now I am almost done with one little bug left.\\ Cool you are addicted! > - the progress bar is always responsive > - all processes showing a progress with priority <60 can be interrupted > - refreshes periodically 16 times per second > - only forces a manual refresh when blocking the UI > - no more out of bounds progress bars > - no more ugly display buffer pattern when resizing the screen during a running progress > > this is a massive improvement for me :) For instance now you can simply interrupt the test runner > with a click on the progress bar. Did you check that it works with 1 to: 1 because in the past I got a zeroDivide > I have one bug left, that is when I run the test runner, the UI event handling gets > somehow disturbed. Windows no longer receive events, but everything is directly forwarded > to the World. Opening the World menu is the only thing you can do :/ > > > Anyone has a clue? The slice is in the inbox, see issue > > http://code.google.com/p/pharo/issues/detail?id=7103 > > > best > cami

Dec. 6, 2012

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

by Tudor Girba

Great. We will release Moose 4.7 on top of Pharo 1.4 soon (probably next week or so), and afterwards we will immediately switch to Pharo 2.0. Cheers, Doru On 6 Dec 2012, at 18:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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 -- www.tudorgirba.com "Presenting is storytelling."

Dec. 6, 2012

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

by Mariano Martinez Peck

On Thu, Dec 6, 2012 at 5:21 PM, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com>wrote: > Hi Mariano, > > It works, thank you very much! > Excellent. So for next version of Fuel we will fix it. You will only need the package Fuel (not FuelMetalevel) and you will use the normal #newDefault instead of #newDefaultWithMethodSupport. So far, I just created the issue: http://code.google.com/p/fuel/issues/detail?id=172 > > > 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>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 > > > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2012

Re: [Pharo-project] Spec bindings assignment

by Benjamin

I changed the widget mechanism a coupe of weeks ago. Now the idea is that the interpreter use a default set of bindings (by default Morphic, but can be changed) and then you can specify for a widget build to use a specific set of bindings. Then this bindings is used for the whole build phase, then the default bindings are reset as default. I will experiment with your package and see :) Thanks, Ben On Dec 6, 2012, at 3:01 PM, Pavel Krivanek wrote: > Gofer new > smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; > package: 'Periscope'; > load. > > Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} > > Look at PeriscopeMorphicBindings and references. > Spec needs to find a way how to specify custom widgets needed by an application based on some UI while on other UIs the default widgets will be used (or the programmer will need to create this widget for the new UI too). The main problem with bindings was that it was not shared with subwidgets so if you created the window widget with specific binding, you had to manually set this binding for the elements in the window too. > > Cheers, > -- Pavel > > On Thu, Dec 6, 2012 at 2:36 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Now the bindings are provided to the interpreter and not to the model it self. > > Can you point me where to load your code, like that I have an interesting use case :) > > Thanks > Ben > > On Dec 6, 2012, at 9:28 AM, Pavel Krivanek wrote: > > > Hi Ben, > > > > what was changed in the Spec bindings assignment in the new Spec versions? Because Periscope uses own subclass of MorphicBindings to provide own widgets including window widget but now only standard widgets are used and the different binding is not taken into account. > > > > Cheers, > > -- Pavel > > >

Dec. 6, 2012

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