- Pharo-dev - lists.pharo.org

[Pharo-project] new Cog VMs available

by Torsten Bergmann

>So StackToRegisterMappingCogit should be faster than the other ? If so, >why does the SimpleStackBasedCogit still exist ? Read here: http://forum.world.st/Teleplace-Cog-VMs-are-now-available-td2261896.html Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Feb. 7, 2011

Re: [Pharo-project] Where is OB Was: [what do we do for OmniBrowser?]

by Guillermo Polito

Since the groups in the config are: group: 'default' with: #('Core' ); group: 'Core' with: #( 'OmniBrowser' 'OB-Morphic' 'OB-Standard' ); group: 'Core RB' with: #( 'Core' 'OB-Refactory' ); group: 'Core Tests' with: #( 'OB-Tests-Core' 'OB-Tests-Morphic' 'OB-Tests-Standard' ); group: 'Dev' with: #( 'Core' 'OB-SUnitIntegration' 'OB-Shout' 'OB-Refactory' 'OB-Regex' 'OCForOB'); group: 'Dev Tests' with: #( 'Core Tests' 'Refactoring Tests' 'OCompletion Tests' ); I guess you can do: (ConfigurationOfOmnibrowser project version: '1.2.4') load: #( 'Dev' 'Dev Tests' ) Guille On Sun, Feb 6, 2011 at 11:10 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Guillermo, > > how can I load it including the tests? > > 2011/2/5 Guillermo Polito <guillermopolito(a)gmail.com>: > > Ok, now > > > > Gofer it > > squeaksource: 'PharoOB'; > > package: 'ConfigurationOfOmniBrowser'; > > load > > > > (ConfigurationOfOmniBrowser project version: '1.2.4') load > > > > > > Downloads OB from PharoOB ;). > > > > Have a nice weekend! > > Guille > > > > On Fri, Feb 4, 2011 at 3:55 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> > > wrote: > >> > >> Go for PharoOB and we will delete files from PharoTaskForces > >> > >> Stef > >> > >> On Feb 4, 2011, at 1:15 AM, Guillermo Polito wrote: > >> > >> > Today's ConfigurationOfOmniBrowser relies on lukas repo and > >> > PharoTaskForces (in SS). > >> > > >> > When there is an 1.2 specific fix, I'm commiting it to > PharoTaskForces. > >> > When there is a fix on Lukas repo, I merge it and commit it to > >> > PharoTaskForces. > >> > > >> > BTW, If we push everything in PharoOB, we'll have everything there (OB > >> > code and metacello configurations). PharoOB has global read and write > >> > access (I recreated it a few hours ago since it got lost :P ), so > everyone > >> > may contribute :). > >> > > >> > > >> > Guille > >> > > >> > On Thu, Feb 3, 2011 at 8:57 PM, HernÃ¡n Morales Durand > >> > <hernan.morales(a)gmail.com> wrote: > >> > Guillermo please tell us which code base you are using otherwise OB > >> > will continue to be one-man show. > >> > > >> > 2011/2/3 Guillermo Polito <guillermopolito(a)gmail.com>: > >> > > > >> > > I'm integrating already the fixes into PharoTaskForces. If I have > >> > > some tome > >> > > tomorrow I'll push OB from Lukas repo to PharoOB and merge. > >> > > > >> > > Guille :) > >> > > > >> > >> > >> > >> Stef > >

Feb. 7, 2011

Re: [Pharo-project] new Cog VMs available

by Francois Stephany

So StackToRegisterMappingCogit should be faster than the other ? If so, why does the SimpleStackBasedCogit still exist ? (Sorry but I'm a total newbie) On 07/02/11 15:42, Igor Stasenko wrote: > On 7 February 2011 12:28, Krishsmalltalk > <krishnamachari.sudhakar(a)gmail.com> wrote: >> StackToRegisterMappingCogit maps values to machine registers when generating >> code, >> while stack-based one uses stack for everything. >> >> Guess that is what is meant.. >> Register based vms like Parrot will offer more info... As to motivation for >> this mapping >> > > a motivation is simple: speed. > Access to CPU registers usually 2-5 orders of magnitude faster than > memory access. > >> >> On Feb 7, 2011, at 2:53 PM, Igor Stasenko<siguctua(a)gmail.com> wrote: >> >> On 7 February 2011 09:12, Francois Stephany<tulipe.moutarde(a)gmail.com> >> wrote: >> >> Hi Eliot, >> >> Probably a stupid question but what's the difference between >> >> SimpleStackBasedCogit and c? >> >> SimpleStackBasedCogit maps values to machine registers when generating code, >> while stack-based one uses stack for everything. >> >> new Cog VMs are available, SimpleStackBasedCogit @ >> >> http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and >> >> StackToRegisterMappingCogit @ >> >> http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code >> >> generator is ready for prime time now. I fixed a number of bugs over >> >> the past three weeks and we're now using the StackToRegisterMappingCogit >> >> internally at Teleplace. >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > -- francois.stephany(a)agilitic.com http://www.agilitic.com +32 (0)484/580.322

Feb. 7, 2011

Re: [Pharo-project] Primitive calls in one package

by Guillermo Polito

On Mon, Feb 7, 2011 at 3:24 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: > I understand your point :), > Now, with my problem with Network, we can see that some primitives do not > exist in the image of pharo nor squeak. > But are inside etoys image.... > :3 I smell we need to open a ticket to remove that! > > Where I think that all these images should have the same primitives, > because based on same VM. > My idea is in that way: how can we maintain primitives and match them with > the vm ? > > Cheers, > Jannik > > > On Feb 6, 2011, at 17:47 , Noury Bouraqadi wrote: > > > I totally agree with Bill. > > > > Noury > > > > On 5 fÃ©vr. 2011, at 21:40, Schwab,Wilhelm K wrote: > > > >> If there is a problem finding primitives, then that probably deserves > attention in the browsers. Given that collections, sockets, streams, etc. > all use primitives, will likely continue to do so, and will also find > competition (Nile, new sockets package, etc.), I think it would be > inappropriate to set up a presumption that all primitives lurk in one > package. It cannot (or should not) be enforced, and would interfere with > evolution. > >> > >> With respect, -1. > >> > >> Bill > >> > >> > >> > >> ________________________________________ > >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Laval Jannik [ > jannik.laval(a)inria.fr] > >> Sent: Saturday, February 05, 2011 3:06 PM > >> To: Pharo Development > >> Subject: [Pharo-project] Primitive calls in one package > >> > >> Hi, > >> > >> What is your opinion about having all primitive calls in one package ? > >> It would be easier to maintain and to find them. > >> > >> Another question: why all existing primitive in VM have not a method in > the image ? > >> > >> Cheers, > >> --- > >> Jannik Laval > >> > >> > >> > > > > > > >

Feb. 7, 2011

Re: [Pharo-project] new Cog VMs available

by Igor Stasenko

On 7 February 2011 12:28, Krishsmalltalk <krishnamachari.sudhakar(a)gmail.com> wrote: > StackToRegisterMappingCogitÂ maps values to machine registers when generating > code, > while stack-based one uses stack for everything. > > Guess that is what is meant.. > Register based vms like Parrot will offer more info... As to motivation for > this mapping > a motivation is simple: speed. Access to CPU registers usually 2-5 orders of magnitude faster than memory access. > > On Feb 7, 2011, at 2:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 7 February 2011 09:12, Francois Stephany <tulipe.moutarde(a)gmail.com> > wrote: > > Hi Eliot, > > Probably a stupid question but what's the difference between > > SimpleStackBasedCogit and c? > > SimpleStackBasedCogit maps values to machine registers when generating code, > while stack-based one uses stack for everything. > > Â Â new Cog VMs are available, SimpleStackBasedCogit @ > > http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and > > StackToRegisterMappingCogit @ > > http://www.mirandabanda.org/files/Cog/VM/VM.r2361. Â I think the new code > > generator is ready for prime time now. Â I fixed a number of bugs over > > the past three weeks and we're now using the StackToRegisterMappingCogit > > internally at Teleplace. > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Best regards, Igor Stasenko AKA sig.

Feb. 7, 2011

Re: [Pharo-project] copying all versions to squeaksource

by Guillermo Polito

The other day I used: Gofer it squeaksource: 'YourSqueakSourceRepo'; package: 'onePackage'; package: 'otherPackage'; push. And to load all versions into your cache: Gofer it squeaksource: 'YourSqueakSourceRepo'; package: 'onePackage'; package: 'otherPackage'; fetch. Guille On Mon, Feb 7, 2011 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > This may perfectly be part of the image, under an appropriate menu entry in > Monticello. > > Alexandre > > > > Le 7 fÃ©vr. 2011 Ã 03:47, HwaJong Oh <daliot.oh(a)gmail.com> a Ã©crit : > > > > > Hi, > > > > I've figured out how to copy 97 version of mine to squeaksource, quickly. > Is > > there a standard way to do this? > > > > MCVersionInspector >> copyAllVersionsToSqueakSourceRepository > > > > | repository | > > repository := MCHttpRepository > > location: 'http://www.squeaksource.com/3748782' > > user: '2034' > > password: '34058'. > > 1 to: self versionList size do: [:ii| > > self versionSelection: ii. > > repository storeVersion: version > > ]. > > > > Best Regards > > HwaJong Oh > > -- > > View this message in context: > http://forum.world.st/copying-all-versions-to-squeaksource-tp3263732p326373… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > >

Feb. 7, 2011

Re: [Pharo-project] Issue 3658 in pharo: Dictionaries corrupt when loaded from image segment

by pharo＠googlecode.com

Comment #8 on issue 3658 by ryd...(a)gmail.com: Dictionaries corrupt when loaded from image segment http://code.google.com/p/pharo/issues/detail?id=3658 ... under "in 1.1 onwards:" :)

Feb. 7, 2011

Re: [Pharo-project] Issue 3658 in pharo: Dictionaries corrupt when loaded from image segment

by pharo＠googlecode.com

Comment #7 on issue 3658 by ryd...(a)gmail.com: Dictionaries corrupt when loaded from image segment http://code.google.com/p/pharo/issues/detail?id=3658 hups, copy paste error that was supposed to read: s = d false d = s false

Feb. 7, 2011

Re: [Pharo-project] Issue 3579 in pharo: "declare temp" adds the variable twice

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #9 on issue 3579 by marcus.d...(a)gmail.com: "declare temp" adds the variable twice http://code.google.com/p/pharo/issues/detail?id=3579 (No comment was entered for this change.)

Feb. 7, 2011

Re: [Pharo-project] Issue 3664 in pharo: MacUnicodeInputInterpreter use utf32 keycode unconditionally

by pharo＠googlecode.com

Updates: Status: Invalid Comment #1 on issue 3664 by ryd...(a)gmail.com: MacUnicodeInputInterpreter use utf32 keycode unconditionally http://code.google.com/p/pharo/issues/detail?id=3664 There are no InputInterpreters in Pharo anymore. If the unicode keyCode is present, it is always used. (See HandMorph >> #generateKeyboardEvent:)

Feb. 7, 2011