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

Re: [Pharo-project] Delay bug

by Guillermo Polito

Cool it's not just me and a strange setup :) tx. I'll open an issue then. On Thu, Dec 6, 2012 at 2:59 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > that is indeed very strange. I can fully reproduce your issues. > > that means all delays are corrupted when saving the image? :D > However this has only nasty side-effects for Delays that are currently used > for waiting, otherwise the endTime will simply be refreshed when waiting > the > next time. > > => serious bug report! > > On 2012-11-29, at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi, > > > > When using a Delay and saving the image, the delay becomes stupidly > broken. > > Look at this: > > > > With the following code > > > > Object subclass: #DelayBug > > instanceVariableNames: 'delay process' > > classVariableNames: '' > > poolDictionaries: 'private' > > category: 'DelayBug' > > > > start > > delay := Delay forMilliseconds: 300. > > process := [ [ Transcript logCr: 'test'. delay wait . false ] > whileFalse: [ > > ] ] fork. > > > > > > - Then evaluate. > > > > *db := DelayBug new.* > > *db start.* > > > > - inspect > > > > *db instVarAt: 'delay'.* > > * > > * > > The delay seems ok. > > > > - save the image > > > > The delay has a stupid time to be finished :/ > > > > Guille > > >

Dec. 6, 2012

[Pharo-project] OrderedCollectionInspector>>fieldList confused about XMLOrderedList

by Sven Van Caekenberghe

Hi, I am using the excellent XML-Parser package in Pharo 2.0 and there is a strange problem where OrderedCollectionInspector>>fieldList seems to be confused about XMLOrderedList. To reproduce inspect the following: (XMLDOMParser parse: '<doc><p>1</p><p>1</p></doc>') nodes elements. This produces the following stack trace: XMLOrderedList(Object)>>errorSubscriptBounds: XMLOrderedList(Object)>>basicAt: XMLOrderedList(Object)>>instVarAt: OrderedCollectionInspector>>fieldList PluggableListMorph>>getList PluggableListMorph>>getListSize LazyListMorph>>getListSize LazyListMorph>>listChanged PluggableListMorph>>updateList PluggableListMorph>>on:list:selected:changeSelected:menu:keystroke: MorphicUIManager>>openInspector:asMorphOn:withLabel: Inspector class>>openAsMorphOn:withLabel: Inspector class>>openAsMorphOn:withEvalPane:withLabel:valueViewClass: Inspector class>>openOn:withEvalPane:withLabel: Inspector class>>openOn:withEvalPane: Inspector class>>openOn: ToolRegistry>>inspect: XMLOrderedList(Object)>>inspect PluggableTextMorph>>inspectIt in Block: [:result | result inspect] SmalltalkEditor>>evaluateSelectionAndDo: PluggableTextMorph>>inspectIt in Block: [textMorph editor... PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>inspectIt SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph inspectIt] BlockClosure>>cull: BlockClosure>>cull:cull: BlockClosure>>cull:cull:cull: KMCategoryTarget>>completeMatch:buffer: Anyone ever seen this ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 6, 2012

Re: [Pharo-project] Spec bindings assignment

by Pavel Krivanek

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] Delay bug

by Camillo Bruni

that is indeed very strange. I can fully reproduce your issues. that means all delays are corrupted when saving the image? :D However this has only nasty side-effects for Delays that are currently used for waiting, otherwise the endTime will simply be refreshed when waiting the next time. => serious bug report! On 2012-11-29, at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, > > When using a Delay and saving the image, the delay becomes stupidly broken. > Look at this: > > With the following code > > Object subclass: #DelayBug > instanceVariableNames: 'delay process' > classVariableNames: '' > poolDictionaries: 'private' > category: 'DelayBug' > > start > delay := Delay forMilliseconds: 300. > process := [ [ Transcript logCr: 'test'. delay wait . false ] whileFalse: [ > ] ] fork. > > > - Then evaluate. > > *db := DelayBug new.* > *db start.* > > - inspect > > *db instVarAt: 'delay'.* > * > * > The delay seems ok. > > - save the image > > The delay has a stupid time to be finished :/ > > Guille

Dec. 6, 2012

[Pharo-project] [update 2.0] #20431

by Esteban Lorenzano

20431 ----- Issue 6509: KeyChain http://code.google.com/p/pharo/issues/detail?id=6509 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-EstebanLorenzano.741.d… http://ss3.gemstone.com/ss/Pharo20/FamFam-Icons-EstebanLorenzano.13.diff http://ss3.gemstone.com/ss/Pharo20/KeyChain-EstebanLorenzano.15.diff

Dec. 6, 2012

Re: [Pharo-project] Spec bindings assignment

by Benjamin

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] Progress Update

by Sven Van Caekenberghe

Thanks a lot for all the hard work, Camillo. You are improving Pharo a lot - often by just doing the hard work on your own. All these UX improvements are the icing on the internal cleanups. On 06 Dec 2012, at 13:05, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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. > > - 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. > > 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] [update 2.0] #20430

by Guillermo Polito

:D!!!!! On Thu, Dec 6, 2012 at 1:18 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > 20430 > ----- > > Issue 7056: integrate NativeBoost > http://code.google.com/p/pharo/issues/detail?id=7056 > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1264.diff > > Yep, finally NativeBoost (v 1.7) is integrated into the system. You still > need a special VM to use it, I'm working now in produce branded Pharo VMs > with NB support out of the box. > > > >

Dec. 6, 2012

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

by Camillo Bruni

yes !! On 2012-12-06, at 09:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20430 > ----- > > Issue 7056: integrate NativeBoost > http://code.google.com/p/pharo/issues/detail?id=7056 > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1264.diff > > Yep, finally NativeBoost (v 1.7) is integrated into the system. You still need a special VM to use it, I'm working now in produce branded Pharo VMs with NB support out of the box. > > >

Dec. 6, 2012

Re: [Pharo-project] An excellent news

by Peter Hugosson-Miller

On Wed, Dec 5, 2012 at 9:41 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > We mentioned it in the past but now this is really official. To support > the consortium, Inria is paying one full year > to Igor Stasenko. > > We want to thank Inria for its continuous support. > > Stef > Nice! Thanks INRIA, and congratulations Igor :-) -- Cheers,

Dec. 6, 2012