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

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by Sean P. DeNigris

StÃ©phane Ducasse wrote > We are really interested by Xtreams for replacing Pharo Streams. > Now we should evaluate again Xtreams. IIRC at ESUG the version on squeaksource is not up to date with the VW version, which is why we were working on handling namespace/prefix mapping in filetree/cypress... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-s-FileDirectory-dependence-tp4682133p4682221.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by Marcus Denker

On Apr 17, 2013, at 10:44 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Apr 17, 2013, at 10:29 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> I really really like this :) >> >> very simple yet powerful! > > Yes this will massively simplify the debugger :) > So we will be able to get a debugger really working without needing an magician to fix > its bugs. Yes, just the AST with Semantic Analysis information (Scope and Semantic Variables), plus bytecodelevel IR that provides the bridge to the low-level pc (bytecode mapping) dataâ¦ e.g. to get the highlight in the debugger, this is now just this in DebuggerMethodMapOpal: rangeForPC: aPC contextIsActiveContext: contextIsActive "return the debug highlight for aPC" | pc | "When on the top of the stack the pc is pointing to right instruction, but deeper in the stack the pc was already advanced one bytecode, so we need to go back this one bytecode, which can consist of multiple bytes. But on IR, we record the *last* bytecode offset as the offset of the IR instruction, which means we can just go back one" pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1]. ^(methodNode ir instructionForPC: pc) sourceNode debugHighlightRange more helper methods will simplify this even more, e.g. we should have a method on RBMethodNode like #nodeForPC: rangeForPC: aPC contextIsActiveContext: contextIsActive "return the debug highlight for aPC" | pc | "When on the top of the stack the pc is pointing to right instruction, but deeper in the stack the pc was already advanced one bytecode, so we need to go back this one bytecode, which can consist of multiple bytes. But on IR, we record the *last* bytecode offset as the offset of the IR instruction, which means we can just go back one" pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1]. ^(methodNode nodeForPC: pc) debugHighlightRange And this method one then can just implement on MethodContext itself. (Caching is handled by ASTCache). Marcus

April 17, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by stephane ducasse

On Apr 17, 2013, at 10:29 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I really really like this :) > > very simple yet powerful! Yes this will massively simplify the debugger :) So we will be able to get a debugger really working without needing an magician to fix its bugs. Stef

April 17, 2013

[Pharo-project] About sqnappy and LZ4

by Mariano Martinez Peck

Hi, I was checking https://github.com/mumez/sqnappy. Some time ago I wrote bindings for LZ4: http://smalltalkhub.com/#!/~marianopeck/LZ4 Do you know which are the differences? It looks both are intended for the same purpose: speed in decompression/compression over compression ratio. From what I can see in http://fastcompression.blogspot.fr/p/lz4.html it says encoding 555 MB/s decoding 1.80 GB/ while in https://code.google.com/p/snappy/ it says "Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more." So...doesn't LZ4 seem to be faster than sqnappy? And I already wrote the bindings for LZ4...so I was wondering that... Best regards, -- Mariano http://marianopeck.wordpress.com

April 17, 2013

Re: [Pharo-project] [FWD] Options for Visualization

by Camille Teruel

Hi Damir, Have a look at Roassal and Mondrian. If you need to parse DOT syntax you can write a parser with PetitParser quickly. On 17 avr. 2013, at 14:30, Damir Majer wrote: > Hi, > > IÂ´m searching for Options to visualize diagrams, for example an > class-diagram. > Is there an graphViz-Implementation in Pharo or better other Options to > display Diagrams? > (here is the graphViz-Dot-Example: > graph ethane { > Car -- tire1 [type=s]; > Car -- tire2 [type=s]; > Car -- tire3 [type=s]; > Car -- tire4 [type=s]; > } > > Thanks for routing me in the right direction! > > Cheers, > Damir > > > > ----- > -- > Damir Majer > ... be agile: www.majcon.de > -- > View this message in context: http://forum.world.st/FWD-Options-for-Visualization-tp4682108.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 17, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by Camillo Bruni

I really really like this :) very simple yet powerful! On 2013-04-17, at 21:28, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Yeah this is really cool. Especially now BlockClosure and optimized > BlockClosure (to:do:, ifTrue:ifFalse:, ifNil:ifNotNil:, and:, or:) have the > same behavior for debugger byte code to source code mapping, for > decompilation, ... > > > 2013/4/17 Marcus Denker <marcus.denker(a)inria.fr> > >> Hi, >> >> We implemented this today: >> >> #sourceNode for MethodContext. It returns the AST node of context, as part >> of the whole AST of the method. >> >> thisContext sourceNode >> >> Returns: >> >> DoIt >> ^ thisContext sourceNode >> >> >> ------------ >> >> [ thisContext sourceNode ] value >> >> ==> >> >> RBBlockNode([ thisContext sourceNode ]) >> >> --------------- >> But even for optimized blocks it works: >> >> >> [ true ifTrue:[thisContext sourceNode ]] value >> >> RBBlockNode([ thisContext sourceNode ]) >> >> The AST is the one used for code generation, with all information of >> Semantic Analysis *and* the possibility to >> get the IR with all information, too. >> >> So: >> >> [ true ifTrue:[|a|thisContext sourceNode ]] value scope >> >> ===> an OCOptimizedBlockScope 4 >> >> >> Marcus >> >> >> > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 17, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by Frank Shearar

On 17 April 2013 20:14, Colin Putney <colin(a)wiresong.com> wrote: > On 2013-04-17, at 7:57 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> Xtreams depends on FileDirectory in at least three places, all in the >> Xtreams-Terminals package. (Three messages on FileUrl, #appending, >> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp >> and #tearDown) >> >> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not >> necessarily simple, nor right) thing to is to break that out into >> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and >> similarly for the tests. > > The usual convention would be Xtreams-Squeak-Terminals and > Xtreams-Pharo-Terminals. > > But actually, I'd kind of like to see separate packages for > FileDirectory terminals and FileSystem terminals. The FS terminals > would be useful in Squeak as well. That's a good idea. It's also less divisive while being more precise to boot. frank

April 17, 2013

Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence

by StÃ©phane Ducasse

We are really interested by Xtreams for replacing Pharo Streams. Now we should evaluate again Xtreams. So any action that make them easier to load is welcome. On Apr 17, 2013, at 4:57 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Xtreams depends on FileDirectory in at least three places, all in the > Xtreams-Terminals package. (Three messages on FileUrl, #appending, > #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp > and #tearDown) > > Pharo 2.0 has no FileDirectory. So it seems like the easiest (not > necessarily simple, nor right) thing to is to break that out into > Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and > similarly for the tests. > > After that, we'd need to adjust the ConfigurationOfXtreams. I think I > forgot to fulfil a promise to submit an updated version of this that > loaded FFI correctly (sorry!). > > Thoughts? Do any Pharo folk load Xtreams? > > frank >

April 17, 2013

Re: [Pharo-project] How to get the AST Node for a Context

by ClÃ©ment Bera

Yeah this is really cool. Especially now BlockClosure and optimized BlockClosure (to:do:, ifTrue:ifFalse:, ifNil:ifNotNil:, and:, or:) have the same behavior for debugger byte code to source code mapping, for decompilation, ... 2013/4/17 Marcus Denker <marcus.denker(a)inria.fr> > Hi, > > We implemented this today: > > #sourceNode for MethodContext. It returns the AST node of context, as part > of the whole AST of the method. > > thisContext sourceNode > > Returns: > > DoIt > ^ thisContext sourceNode > > > ------------ > > [ thisContext sourceNode ] value > > ==> > > RBBlockNode([ thisContext sourceNode ]) > > --------------- > But even for optimized blocks it works: > > > [ true ifTrue:[thisContext sourceNode ]] value > > RBBlockNode([ thisContext sourceNode ]) > > The AST is the one used for code generation, with all information of > Semantic Analysis *and* the possibility to > get the IR with all information, too. > > So: > > [ true ifTrue:[|a|thisContext sourceNode ]] value scope > > ===> an OCOptimizedBlockScope 4 > > > Marcus > > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 17, 2013

Re: [Pharo-project] SPy VM

by Marcus Denker

On Apr 17, 2013, at 8:35 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > yes, I almost worked on it :P > I was in PhD writing modeâ¦ I visited them some times the sprint room, though ;-) Marcus > http://dl.acm.org/citation.cfm?id=1482373.1482382&coll=DL&dl=GUIDE&CFID=205… > > On 2013-04-17, at 18:05, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Did you know that there is smalltalk vm in PyPy? https://bitbucket.org/pypy/lang-smalltalk > >

April 17, 2013