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

Re: [Pharo-project] Pharo Logo SVG

by stephane ducasse

this is cool :) Stef On May 4, 2013, at 7:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > And here how it looks in Athens.. > yeah SVG importer needs more love, but my hands is too busy right now :( > > AthensSceneView new > scene: (AthensSVGConverter fromFile: 'logo.svg'); > openInWindow > > > But this version of svg is much better, because old one contained > bitmap data ... (brrr). > Thanks for taking care! > > -- > Best regards, > Igor Stasenko. > <Screen Shot 2013-05-04 at 7.43.25 PM.png>

May 4, 2013

Re: [Pharo-project] Pharo Logo SVG

by Igor Stasenko

And here how it looks in Athens.. yeah SVG importer needs more love, but my hands is too busy right now :( AthensSceneView new scene: (AthensSVGConverter fromFile: 'logo.svg'); openInWindow But this version of svg is much better, because old one contained bitmap data ... (brrr). Thanks for taking care! -- Best regards, Igor Stasenko.

May 4, 2013

Re: [Pharo-project] How to Debug :D

by Frank Shearar

A trampoline looks like this: Foo >> trampoline: initialValue into: aUnaryBlock | v | v := [initialValue]. [v isBlock] whileTrue: [v := aUnaryBlock value: v value]. ^ v. and then used: | f factorial | factorial := 1. f := Foo new. f trampoline: 10 into: [ :n | n <= 0 ifTrue: [factorial] ifFalse: [factorial := factorial * n. [n - 1]]]. The important thing is that the block returns a value for the base case/cases of the recursion, and a block that, when evaluated, will yield the next value on which to recurse. (So the block replaces the recursive call.) The trampoline thus turns the recursive algorithm into an iteration. frank On 4 May 2013 17:42, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > can you explain? > Because I read something like that olong time ago and I forgot > > On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > So use a trampoline. Then you can define your recursion naturally, in > constant stack space. > > frank > > On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > I understand why he wants that :) > no stack explosionâ¦ > > Stef > > On May 4, 2013, at 12:37 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > To be more precise, for the method : > > foo > ^ 1 + 2 > > AST will be : > ^ > \ > + > / \ > 1 2 > > AST Interpreter, to interpret ^, will do something like : > start interpret ^ > interpret subnode of ^ > start interpret + > interpret subnodes of + > interpret 1 > interpret 2 > interpret + with subnodes interpretation result > end interpret + > interpret ^ with subnode interpretation result > end interpret ^ > > Igor would like to have a flatten AST that would be in an array like : > #( 1 2 + ^ ) > Then you can interpret it with a loop > [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode > nextNode ]. > And interpretation looks like : > interpret 2 > interpret 1 > interpret + with two precedent results on stack > interpret ^ with precedent result on stack > > 2013/5/4 ClÃ©ment Bera <bera.clement(a)gmail.com> >> >> 2013/5/4 stephane ducasse <stephane.ducasse(a)free.fr> >>> >>> >>> On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > Did i said already that i don't like how ASTInterpreter implemented? :) >>> >>> >>> We will let perfection for later :) >> >> >> It is not a question of perfection or so. >> >> Igor does not like that we interpret recursively the AST instead of with a >> loop (ASTInterpreter>>interpret: calls itself again and again). He would >> like to have a flatten-AST-interpreter, with a loop like: >> >> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode >> nextNode ]. >> >> But Camillo and I don't want that because it interprets a flatten AST, >> not a tree. >> >>> >>> > >>> > Nevertheless, it is useful.. and this case clearly demonstrates that. >>> > >>> > On 4 May 2013 00:14, Clara Allende <clari.allende(a)gmail.com> wrote: >>> >> This is great news! Are you going to publish the code? it will come in >>> >> handy >>> >> for my summer of code :D >>> >> >>> > >>> > Camillo has the image >>> > >>> >> >>> >> On 3 May 2013 03:21, stephane ducasse <stephane.ducasse(a)free.fr> >>> >> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Begin forwarded message: >>> >>> >>> >>> From: Camillo Bruni <camillobruni(a)gmail.com> >>> >>> Subject: [Lsehub-staff] How to Debug :D >>> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00 >>> >>> To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >>> >>> Reply-To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >>> >>> >>> >>> Igor: Camillo can you help me debugging this strange athens rendering >>> >>> bug >>> >>> Cami: sure >>> >>> >>> >>> Igor: where do you think the bug is? The green path jumps if I change >>> >>> the >>> >>> Y coordinate and it shouldn't... >>> >>> Cami: no clue... >>> >>> >>> >>> Igor: Any clue how to get to the bug? >>> >>> Cami: let's use the ASTInterpreter to interpret two methods with >>> >>> different >>> >>> transformation matrices and see when they diverge. >>> >>> >>> >>> Result: >>> >>> ------- >>> >>> - after 1h comparing AST Debugger is ready >>> >>> - we run the two traces, they do NOT diverge => ???? >>> >>> >>> >>> Conclusion: >>> >>> ----------- >>> >>> Cairo, which was chosen as reference, did not properly draw the >>> >>> path!!! >>> >>> >>> >>> So we should publish the code of the ComparingInterpreter a bit and >>> >>> we >>> >>> can use it for a few more tasks in Pharo ;) >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> > >>> >>> >> >> > > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > >

May 4, 2013

Re: [Pharo-project] [ANN] A SmalltalkHub server for each

by Igor Stasenko

On 4 May 2013 07:29, Ben Coman <btc(a)openinworld.com> wrote: > Igor Stasenko wrote: >> >> On 4 May 2013 01:01, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >> >>> >>> Cool! And I just discovered that typing smalltalk.Browser._open() in the >>> javascript console on smalltalkhub site lets you see how the client side >>> works. >>> >> >> >> Just don't break it please. I need st-hub in working state :) >> >> > > What are the security implications of this ? > I guess no more than plain Javascript - the server should not blindly trust > what the client sends. > Of course. But allow me to not blindly trust that every existing server (including st-hub) "are not blindly trust what the client sends." :) > cheers -ben > > -- Best regards, Igor Stasenko.

May 4, 2013

Re: [Pharo-project] Using Athens for real ...

by Igor Stasenko

On 4 May 2013 12:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Yes that view is very neat! Especially for debugging, maintaining the > Smalltalk immediate feedback principle :0 > and after i finish with path geometry calcucations, you can implement "clickable" things, no matter what their shape :) -- Best regards, Igor Stasenko.

May 4, 2013

Re: [Pharo-project] How to Debug :D

by stephane ducasse

can you explain? Because I read something like that olong time ago and I forgot On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > So use a trampoline. Then you can define your recursion naturally, in constant stack space. > > frank > > On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> I understand why he wants that :) >> no stack explosionâ¦ >> >> Stef >> >> On May 4, 2013, at 12:37 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >>> To be more precise, for the method : >>> >>> foo >>> ^ 1 + 2 >>> >>> AST will be : >>> ^ >>> \ >>> + >>> / \ >>> 1 2 >>> >>> AST Interpreter, to interpret ^, will do something like : >>> start interpret ^ >>> interpret subnode of ^ >>> start interpret + >>> interpret subnodes of + >>> interpret 1 >>> interpret 2 >>> interpret + with subnodes interpretation result >>> end interpret + >>> interpret ^ with subnode interpretation result >>> end interpret ^ >>> >>> Igor would like to have a flatten AST that would be in an array like : >>> #( 1 2 + ^ ) >>> Then you can interpret it with a loop >>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ]. >>> And interpretation looks like : >>> interpret 2 >>> interpret 1 >>> interpret + with two precedent results on stack >>> interpret ^ with precedent result on stack >>> >>> 2013/5/4 ClÃ©ment Bera <bera.clement(a)gmail.com> >>> 2013/5/4 stephane ducasse <stephane.ducasse(a)free.fr> >>> >>> On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > Did i said already that i don't like how ASTInterpreter implemented? :) >>> >>> >>> We will let perfection for later :) >>> >>> It is not a question of perfection or so. >>> >>> Igor does not like that we interpret recursively the AST instead of with a loop (ASTInterpreter>>interpret: calls itself again and again). He would like to have a flatten-AST-interpreter, with a loop like: >>> >>> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ]. >>> >>> But Camillo and I don't want that because it interprets a flatten AST, not a tree. >>> >>> >>> > >>> > Nevertheless, it is useful.. and this case clearly demonstrates that. >>> > >>> > On 4 May 2013 00:14, Clara Allende <clari.allende(a)gmail.com> wrote: >>> >> This is great news! Are you going to publish the code? it will come in handy >>> >> for my summer of code :D >>> >> >>> > >>> > Camillo has the image >>> > >>> >> >>> >> On 3 May 2013 03:21, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Begin forwarded message: >>> >>> >>> >>> From: Camillo Bruni <camillobruni(a)gmail.com> >>> >>> Subject: [Lsehub-staff] How to Debug :D >>> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00 >>> >>> To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >>> >>> Reply-To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >>> >>> >>> >>> Igor: Camillo can you help me debugging this strange athens rendering bug >>> >>> Cami: sure >>> >>> >>> >>> Igor: where do you think the bug is? The green path jumps if I change the >>> >>> Y coordinate and it shouldn't... >>> >>> Cami: no clue... >>> >>> >>> >>> Igor: Any clue how to get to the bug? >>> >>> Cami: let's use the ASTInterpreter to interpret two methods with different >>> >>> transformation matrices and see when they diverge. >>> >>> >>> >>> Result: >>> >>> ------- >>> >>> - after 1h comparing AST Debugger is ready >>> >>> - we run the two traces, they do NOT diverge => ???? >>> >>> >>> >>> Conclusion: >>> >>> ----------- >>> >>> Cairo, which was chosen as reference, did not properly draw the path!!! >>> >>> >>> >>> So we should publish the code of the ComparingInterpreter a bit and we >>> >>> can use it for a few more tasks in Pharo ;) >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> ClÃ©ment BÃ©ra >>> Mate Virtual Machine Engineer >>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >>

May 4, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Camillo Bruni

On 2013-05-04, at 17:40, no-reply(a)ci.inria.fr wrote: > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… > > 1 regressions found. > Tests.System.OSEnvironmentTest.testAtPut ok I will check that ;) at least the tests work!

May 4, 2013

Re: [Pharo-project] How to Debug :D

by Frank Shearar

So use a trampoline. Then you can define your recursion naturally, in constant stack space. frank On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I understand why he wants that :) > no stack explosionâ¦ > > Stef > > On May 4, 2013, at 12:37 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> To be more precise, for the method : >> >> foo >> ^ 1 + 2 >> >> AST will be : >> ^ >> \ >> + >> / \ >> 1 2 >> >> AST Interpreter, to interpret ^, will do something like : >> start interpret ^ >> interpret subnode of ^ >> start interpret + >> interpret subnodes of + >> interpret 1 >> interpret 2 >> interpret + with subnodes interpretation result >> end interpret + >> interpret ^ with subnode interpretation result >> end interpret ^ >> >> Igor would like to have a flatten AST that would be in an array like : >> #( 1 2 + ^ ) >> Then you can interpret it with a loop >> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ]. >> And interpretation looks like : >> interpret 2 >> interpret 1 >> interpret + with two precedent results on stack >> interpret ^ with precedent result on stack >> >> 2013/5/4 ClÃ©ment Bera <bera.clement(a)gmail.com> >> 2013/5/4 stephane ducasse <stephane.ducasse(a)free.fr> >> >> On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > Did i said already that i don't like how ASTInterpreter implemented? :) >> >> >> We will let perfection for later :) >> >> It is not a question of perfection or so. >> >> Igor does not like that we interpret recursively the AST instead of with a loop (ASTInterpreter>>interpret: calls itself again and again). He would like to have a flatten-AST-interpreter, with a loop like: >> >> [currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ]. >> >> But Camillo and I don't want that because it interprets a flatten AST, not a tree. >> >> >> > >> > Nevertheless, it is useful.. and this case clearly demonstrates that. >> > >> > On 4 May 2013 00:14, Clara Allende <clari.allende(a)gmail.com> wrote: >> >> This is great news! Are you going to publish the code? it will come in handy >> >> for my summer of code :D >> >> >> > >> > Camillo has the image >> > >> >> >> >> On 3 May 2013 03:21, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> >> >>> >> >>> >> >>> Begin forwarded message: >> >>> >> >>> From: Camillo Bruni <camillobruni(a)gmail.com> >> >>> Subject: [Lsehub-staff] How to Debug :D >> >>> Date: May 2, 2013 6:22:06 PM GMT+02:00 >> >>> To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >> >>> Reply-To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> >> >>> >> >>> Igor: Camillo can you help me debugging this strange athens rendering bug >> >>> Cami: sure >> >>> >> >>> Igor: where do you think the bug is? The green path jumps if I change the >> >>> Y coordinate and it shouldn't... >> >>> Cami: no clue... >> >>> >> >>> Igor: Any clue how to get to the bug? >> >>> Cami: let's use the ASTInterpreter to interpret two methods with different >> >>> transformation matrices and see when they diverge. >> >>> >> >>> Result: >> >>> ------- >> >>> - after 1h comparing AST Debugger is ready >> >>> - we run the two traces, they do NOT diverge => ???? >> >>> >> >>> Conclusion: >> >>> ----------- >> >>> Cairo, which was chosen as reference, did not properly draw the path!!! >> >>> >> >>> So we should publish the code of the ComparingInterpreter a bit and we >> >>> can use it for a few more tasks in Pharo ;) >> >>> >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> > >> >> >> >> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Mate Virtual Machine Engineer >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >

May 4, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Tests.System.OSEnvironmentTest.testAtPut

May 4, 2013

[Pharo-project] [update 3.0] #30101

by Marcus Denker

May 4, 2013