- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About sqnappy and LZ4

by Igor Stasenko

On 18 April 2013 06:25, Masashi UMEZAWA <masashi.umezawa(a)gmail.com> wrote: > Hi, > > Actually, I have never noticed that you have LZ4 bindings already. It > is indeed a great news! > I would never have started sqnappy if I knew the fact. As you say, the > project has a similar goal. > > Anyway, it is good to have another option. > > Some Sqnappy characteristics: > - it has a minimum dependency (it does not use FFI, NativeBoost) so > that it can be run on older images - having a separate plugin/VM , which users always have trouble dealing wih :) > - Streaming format support (to be soon) - you can compress very big > data with relatively small memory footprint. > > Best regards, > > 2013/4/18 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> 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 > -- > [:masashi | ^umezawa] > -- Best regards, Igor Stasenko.

April 18, 2013

[Pharo-project] the fun theory

by Torsten Bergmann

I read about this game today. It is written in Lua and one can play the game by editing Lua scripts (in an external editor) to optimize trains for transportation: http://trainsportedgame.no-ip.org/index.php http://www.youtube.com/watch?v=yFKZd8nEQyA This game combines learning and playing and is a nice attempt to get people into coding. Maybe we can raise the Pharo fun factor by getting people into something similar...

April 18, 2013

Re: [Pharo-project] Update error

by Marcus Denker

On Apr 18, 2013, at 4:47 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Starting with 30039, and updating from the world menu... "Error: Could not > load OpalCompiler-Core-ClementBera.178.mcz: ZnHttpUnsuccessful: 404 Not > Found" > Somehow the .mcz files where not copied to the main repository. This worked fine until the Opal repo was removed. I copied over the files. (This means that "just loading a Config" style of integrating something is not working at all) Marcus

April 18, 2013

Re: [Pharo-project] Versionner in 2.0 again

by Marcus Denker

On Apr 18, 2013, at 5:16 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > 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.…> > > Lets just load it in 2.0 and 3.0, no need to have wrong version in the image. Marcus

April 18, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by stephane ducasse

add a bug entry and tag it so that we simply do not forget. Stef On Apr 18, 2013, at 5:25 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Johan Brichau-2 wrote >> fwiw, I changed the implementation of NECController... >> NECController-Changes.cs (5K) >> <http://forum.world.st/attachment/4679910/0/NECController-Changes.cs> > > I think at minimum Johan's change should be integrated immediately and > backported to 2.0. I simply can not use enterToAccept, and without it now > it's currently impossible to complete with common prefix matching enabled. > > Are there any objections to the last suggested set of default preferences? > If not, maybe those should be included as well - but not worth holding up > Johan's change, which is essential. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp… > 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 stephane ducasse

I should say that I LOVVVVVVVEEEEE the comments in the method. Yes Yes Yes. Stef > > 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 18, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by S Krish

+1 On Thu, Apr 18, 2013 at 10:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > +1 > > Doru > > > On Apr 18, 2013, at 5:25 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> > wrote: > > > Johan Brichau-2 wrote > >> fwiw, I changed the implementation of NECController... > >> NECController-Changes.cs (5K) > >> < > http://forum.world.st/attachment/4679910/0/NECController-Changes.cs> > > > > I think at minimum Johan's change should be integrated immediately and > > backported to 2.0. I simply can not use enterToAccept, and without it now > > it's currently impossible to complete with common prefix matching > enabled. > > > > Are there any objections to the last suggested set of default > preferences? > > If not, maybe those should be included as well - but not worth holding up > > Johan's change, which is essential. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > >

April 18, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by Tudor Girba

+1 Doru On Apr 18, 2013, at 5:25 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Johan Brichau-2 wrote >> fwiw, I changed the implementation of NECController... >> NECController-Changes.cs (5K) >> <http://forum.world.st/attachment/4679910/0/NECController-Changes.cs> > > I think at minimum Johan's change should be integrated immediately and > backported to 2.0. I simply can not use enterToAccept, and without it now > it's currently impossible to complete with common prefix matching enabled. > > Are there any objections to the last suggested set of default preferences? > If not, maybe those should be included as well - but not worth holding up > Johan's change, which is essential. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

April 18, 2013

Re: [Pharo-project] About sqnappy and LZ4

by Masashi UMEZAWA

Hi, Actually, I have never noticed that you have LZ4 bindings already. It is indeed a great news! I would never have started sqnappy if I knew the fact. As you say, the project has a similar goal. Anyway, it is good to have another option. Some Sqnappy characteristics: - it has a minimum dependency (it does not use FFI, NativeBoost) so that it can be run on older images - Streaming format support (to be soon) - you can compress very big data with relatively small memory footprint. Best regards, 2013/4/18 Mariano Martinez Peck <marianopeck(a)gmail.com>: > 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 -- [:masashi | ^umezawa]

April 18, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by Sean P. DeNigris

Johan Brichau-2 wrote > fwiw, I changed the implementation of NECController... > NECController-Changes.cs (5K) > <http://forum.world.st/attachment/4679910/0/NECController-Changes.cs> I think at minimum Johan's change should be integrated immediately and backported to 2.0. I simply can not use enterToAccept, and without it now it's currently impossible to complete with common prefix matching enabled. Are there any objections to the last suggested set of default preferences? If not, maybe those should be included as well - but not worth holding up Johan's change, which is essential. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 18, 2013