May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Moment of fun

by stephane ducasse

On May 1, 2013, at 7:01 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, great superpowers! > A bit more lightweight and efficient than abort(); gdb myApp core > > A small reminder for myself: > > [ > (Delay forSeconds: 2 hours asSeconds) wait. > WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re Smalltalking too much > There are other nice things worth in life' ]. > ] fork Excellent! I added that one too :) Stef

May 1, 2013

Re: [Pharo-project] Moment of fun

by stephane ducasse

Yes! That's a great one :) I added to my presentation. Stef On May 1, 2013, at 6:38 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I really love the use of fuel to serialize errors on the build server: > ------------------------------------------------------------------------- > > [ > "some code causing an error" > Error signal > ] on: Error do: [ :error | > FLSerializer serialize: error toFileNamed: 'error.fuel' ] > > ------------------------------------------------------------------------- > Then in a new image open a debugger on the serialized error: > ------------------------------------------------------------------------- > > error := FLMaterializer materializeFromFileNamed: 'error.fuel'. > error debug. >

May 1, 2013

Re: [Pharo-project] [update 3.0] #30080

by stephane ducasse

>> 30080 >> ----- >> >> 10461 Fixes for NewList >> https://pharo.fogbugz.com/f/cases/10461 >> >> 10432 Move API of Decompiler to Compiler facade >> https://pharo.fogbugz.com/f/cases/10432 >> >> 10465 Better syntax hilighting of start of existing identifier >> https://pharo.fogbugz.com/f/cases/10465 > > > that one too! :) I just noticed :) :) try it first :). Ideally I would like to be able to express that the incomplete should just be italic of the plain one but this is not simple to express. Stef

May 1, 2013

[Pharo-project] Issue ML doesn't thread

by Sean P. DeNigris

This is kind of a small thing, but it definitely effects readability... Each issue update shows up as a whole different conversation, while when we used google, they were properly organized. Any idea how (if possible) to fix it? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-ML-doesn-t-thread-tp4684851.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2013

Re: [Pharo-project] date and time delays

by Igor Stasenko

On 1 May 2013 20:16, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-01, at 14:06, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> On May 1, 2013, at 1:33 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> Igor, >>> >>> How far is the fix, can I download it somewhere and test it? >> >> the changes of nicolas are nice and we should integrate them. > > yes, they address many of the missed-out refactorings for the new > UTC-based time if I'm not mistaken. > > What Igor started was avoid the whole complex startup logic of > DateAndTime. > > So BUMP: Igor where do you have the sources for that? > > Otherwise we look at it during the sprint on friday... > sources is on my machine. yes, lets wait till friday. -- Best regards, Igor Stasenko.

May 1, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by Camillo Bruni

Camillo Bruni 0033 7 86 95 40 On 2013-05-01, at 20:24, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Me too. > Thx for sending me a phone to call. > > Phil > Le 1 mai 2013 14:19, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > >> >> On 17 Apr 2013, at 13:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Hi, >>> >>> We are planning a sprint the 3rd of May: >>> >>> http://rmod.lille.inria.fr/web/pier/blog/2013-04-17 >>> >>> When? Friday May 3 >>> Where? Inria Lille Building B, RMoD Offices >>> >>> If you want to join, please send a mail so we can plan and open the >>> door for you. >>> >>> Marcus >> >> I am coming as well. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >>

May 1, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by phil＠highoctane.be

Me too. Thx for sending me a phone to call. Phil Le 1 mai 2013 14:19, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > On 17 Apr 2013, at 13:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > Hi, > > > > We are planning a sprint the 3rd of May: > > > > http://rmod.lille.inria.fr/web/pier/blog/2013-04-17 > > > > When? Friday May 3 > > Where? Inria Lille Building B, RMoD Offices > > > > If you want to join, please send a mail so we can plan and open the > > door for you. > > > > Marcus > > I am coming as well. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

May 1, 2013

Re: [Pharo-project] Playing with Opal AST->BC Translator

by ClÃ©ment Bera

Hum several of your improvements look cool. Marcus and I are currently working on Opal. We are quite busy for the next two weeks but we'll find some time to have a deeper look on your changes. Then we'll mail you back. 2013/5/1 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Opal is fun. > I have a few simplifications to propose for the AST->BC OCASTTranslator > > 1) instead of testing isEffectTranslator or refining in subclass, most > often we could just let self visit the node. Indeed, self will already be > either a Translator ForEffect or ForValue. > > For example, this could apply to emitIfFalseIfTrue: emitIfNilIfNotNil: > visitCascadeNode: > > This might also remove a few useless pushNil; pop BC sequences. > > > 2) I think we can simplify the #visitBlockNode: / #visitSequenceNode: pair. > > Indeed, visitSequenceNode: tests if its parent isBlock, and if so will > emitValue, else emitEffect. > Inversely visitBlockNode: always ask to emitEffect, but since it contains > a SequenceNode, this is a big lie. > > I suggest to always let the valueTranslator emitValue visitBlockNode: and > simplify #visitSequenceNode: to just let (self visitNode: statements last). > > > 3) I suggest changing the BC generated for or: and and: > > instead of: > > valueTranslator visitNode: aMessageNode receiver. > methodBuilder > jumpAheadTo: #else if: false; > pushLiteral: true; > jumpAheadTo: #end; > jumpAheadTarget: #else. > valueTranslator visitInlinedBlockNode: aMessageNode arguments first. > methodBuilder jumpAheadTarget: #end. > > We could just use dup and thus remove a jump: > > valueTranslator visitNode: aMessageNode receiver. > methodBuilder > pushDup; > jumpAheadTo: #end if: true; > popTop. > self visitInlinedBlockNode: aMessageNode arguments first. > methodBuilder jumpAheadTarget: #end. > > ForEffect, this would just be > > self emitIfFalse: aMessageNode > > Of course, that last change might disturb the Decompiler a bit, but since > we care far less now... > > I can open 1 or more issues if there is an interest. > > Nicolas > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

May 1, 2013

Re: [Pharo-project] Moment of fun

by Nicolas Cellier

Oh, sure much more expressive! I learned some of those low level snippets 25 years ago and seems to have an inability to forget them ;) 2013/5/1 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-05-01, at 19:01, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Yes, great superpowers! > > A bit more lightweight and efficient than abort(); gdb myApp core > > > > A small reminder for myself: > > > > [ > > (Delay forSeconds: 2 hours asSeconds) wait. > > WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re > > Smalltalking too much > > There are other nice things worth in life' ]. > > ] fork > > in Pharo 3.0 you can write that a tad more elegant: > > [ > WorldState addDeferredUIMessage: [ > UIManager default inform: 'You''re Smalltalking too much > There are other nice things worth in life' ]. > ] valueAfterWaiting: 2 hours > > and in general for waiting on delays you now can do: > > 2 hours wait > > that hides away quite some details :) >

May 1, 2013

Re: [Pharo-project] date and time delays

by Camillo Bruni

On 2013-05-01, at 14:06, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On May 1, 2013, at 1:33 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Igor, >> >> How far is the fix, can I download it somewhere and test it? > > the changes of nicolas are nice and we should integrate them. yes, they address many of the missed-out refactorings for the new UTC-based time if I'm not mistaken. What Igor started was avoid the whole complex startup logic of DateAndTime. So BUMP: Igor where do you have the sources for that? Otherwise we look at it during the sprint on friday...

May 1, 2013