- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Versionner in 2.0 again

by Sean P. DeNigris

Christophe Demarey wrote > I was wondering if it is possible to downgrade an already installed > package in a configuration. For now, why don't we just declare a dependency to the correct version of the toolbox? I'm uploading a config to Nabble which does this and seems to work... ConfigurationOfVersionner-SeanDeNigris.101.mcz <http://forum.world.st/file/n4682230/ConfigurationOfVersionner-SeanDeNigris.…> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-in-2-0-again-tp4680376p4682230.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2013

[Pharo-project] Update error

by Sean P. DeNigris

Starting with 30039, and updating from the world menu... "Error: Could not load OpalCompiler-Core-ClementBera.178.mcz: ZnHttpUnsuccessful: 404 Not Found" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Update-error-tp4682228.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2013

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

by Serge Stinckwich

I was also interested to have a DOT parser. Regards, On Thu, Apr 18, 2013 at 3:32 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > 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. >> > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 18, 2013

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