- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by StÃ©phane Ducasse

Well well well >> Good but what is your point? > > Compatibility and simplicity. do you want to tie us with strings on the temple of compatibility? We do not want that. We are sorry but we do not want to lose what we designed as it is what we need/want, just because squeak has a worse solution that you call compatible and simple. >> That Setting is a cool framework. We knew it alreaady :) > > That's where you're confused. You keep talking about "cool" and I keep talking about "simple". These two are not the same yet you keep confusing them. You know me and my english sometimes I'm easily confused. > If we want to have a certain amount of compatibility between Squeak and Pharo the defining property needs to be simplicity, not coolness. I don't care about the Settings framework, after having looked at it I find it difficult to understand and to follow. Too much "coolness" if you will and a lack of simplicity. But that's my opinion. If you think Settings is cool, use it. thanks for your permission. > I'm still interested in compatibility though, and as a consequence, I think we should agree on some basics. It's unlikely that anyone is going to implement the entire Pharo Settings framework in Squeak, so instead I'm giving you a trivial implementation of Squeak's preference annotation, along the way making a point about simplicity. yes but what can we do with it? Since it does not fit our needs. >> That we could get other preferences than the ones we have? We also knew it but we decided >> to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. > > I'm not trying to "tell" you anything. I'm presenting to you the option to be compatible with Squeak regarding simple preferences by giving you an implementation for Pharo. It seems to me that this is the best way to ensure a level of compatibility. It's your choice to take it or leave it. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Andreas Raab

On 4/28/2010 11:32 PM, StÃ©phane Ducasse wrote: > Good but what is your point? Compatibility and simplicity. > That Setting is a cool framework. We knew it already :) That's where you're confused. You keep talking about "cool" and I keep talking about "simple". These two are not the same yet you keep confusing them. If we want to have a certain amount of compatibility between Squeak and Pharo the defining property needs to be simplicity, not coolness. I don't care about the Settings framework, after having looked at it I find it difficult to understand and to follow. Too much "coolness" if you will and a lack of simplicity. But that's my opinion. If you think Settings is cool, use it. I'm still interested in compatibility though, and as a consequence, I think we should agree on some basics. It's unlikely that anyone is going to implement the entire Pharo Settings framework in Squeak, so instead I'm giving you a trivial implementation of Squeak's preference annotation, along the way making a point about simplicity. > That we could get other preferences than the ones we have? We also knew it but we decided > to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. I'm not trying to "tell" you anything. I'm presenting to you the option to be compatible with Squeak regarding simple preferences by giving you an implementation for Pharo. It seems to me that this is the best way to ensure a level of compatibility. It's your choice to take it or leave it. Cheers, - Andreas

April 29, 2010

[Pharo-project] [NativeBoost] new win32 build available

by Igor Stasenko

Hello, i just uploaded a new VM, i built tonight and new NativeBoost code. VM is built from latest SVN + VMMaker + NativeBoostPlugin sources, and now NativeBoost can use all latest additions to interpreterProxy function table, such as addGCRoot, stackPointer etc. And there's already a code which using that, named NBExternalTypeRegistry. It serves as a dictionary of name->object values, where you can register any object under given name and then use it in native code (during native code generation). This is analoguous to what SpecialObjectArray serving for, where you can put an object and then use that object in primitives through well-known index. But in contrast to SpecialObjectArray, a NBExternalTypeRegistry doesn't requires from you to use indexes. You can use just names! Also, it doesn't requires from you to statically assign or initialize the same set of name/value pairs at each image startup. All what you need is just register an object first: NBExternalTypeRegistry current at: #MyName put: #(10 12 13) and then, in your assembler, emit code to load it: NBExternalTypeRegistry current emitOopAt: #MyName generator: gen When your restarting a VM, it makes sure that this registry are initially clean. So, it is get refilled only when some new native methods is generated which are using registry to fetch some named object(s). The most often use of named objects is, of course, instantiating the objects of specific class, like: self typeRegistry emitFetchClass: objectClass generator: gen. proxy instantiateClass: asm EAX indexableSize: 0. Or, checking that argument is of correct type. Here, the method which generates a code to verify that argument class (held in oop) will be an objectClass: validateClassOf: oop generator: gen | asm class | asm := gen asm. class := gen reserveTemp. gen proxy fetchClassOf: oop. asm mov: asm EAX to: class. self typeRegistry emitFetchClass: objectClass generator: gen. asm cmp: asm EAX with: class; jne: gen failedLabel. gen releaseTemps: 1. -- Best regards, Igor Stasenko AKA sig.

April 29, 2010

Re: [Pharo-project] Virtual Pharo sprints

by StÃ©phane Ducasse

On Apr 28, 2010, at 11:29 PM, Henrik Sperre Johansen wrote: > On 28.04.2010 21:11, StÃ©phane Ducasse wrote: >> tell us how what would help you? >> I thought about logging on the irc channel and mentioning who is fixing what. >> We will start from around 13h. >> >> Stef > I won't be available that early, I'm afraid :( > I'll join after work though. > > Thought mostly of the possibility of online pair programming, and in that regard what software would need to be installed up front. > If it's more of an "here's a list of issues in prioritized order, go fix" event, I'm ok with that :) ok ok I see the message I will do a pass on the items this evening :) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by StÃ©phane Ducasse

Good but what is your point? That Setting is a cool framework. We knew it already :) That we could get other preferences than the ones we have? We also knew it but we decided to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. On Apr 29, 2010, at 8:03 AM, Andreas Raab wrote: > On 4/28/2010 2:44 PM, Henrik Sperre Johansen wrote: >> My point was rather the pragmas in Squeak are more closely coupled with >> the point it is actually defined, in that you defined the pragma itself >> in the accessor method for the variable, rather than having 1-N >> declarations in a single method, pointing to 1-N places where those >> settings values can actually be found. > > Right. The other advantage is that the simple "pragma" > (which we've already established isn't a pragma at all) I do not understand your sentence. That the name is bad and should be called annotation? Yes we know it since ages we followed VW naming. > is trivial to support. Here is an implementation for Pharo, taking all of six methods (it would have been three methods if the Settings framework had been structured a little different :-) > > Oh, and as a free goodie you get the ability to browse the implementors of both, #systemsettings as well as #preference:category:description:type: if you're curious where and how these annotations are used. > > Cheers, > - Andreas > <SqueakPrefs-ar.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] status of i18n for Pharo

by StÃ©phane Ducasse

:) no time is a better qualification. When I see the list of bugs and the list of items I would like to work on :( Stef On Apr 28, 2010, at 11:42 PM, Henrik Sperre Johansen wrote: > On 28.04.2010 23:08, StÃ©phane Ducasse wrote: >> if you extract the code from Etoy .... >> we are open you know :) >> >> On Apr 28, 2010, at 10:35 PM, Hilaire Fernandes wrote: >> >>> I was thinking more about something like the Gettext support as found in Etoys. >>> >>> Hilaire > I *think* I remember Bert mentioning interest in extracting the code for inclusion in Squeak some time ago, not 100% sure though. > There hasn't been a mention of it on the Pharo list so far though, so I wouldn't sit around and wait for someone else to port it if I really wanted it... :) > > i.e. The main reason it's not in Pharo is probably more of a lack of interest than anything against having such functionality. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 29, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Andreas Raab

On 4/28/2010 2:44 PM, Henrik Sperre Johansen wrote: > My point was rather the pragmas in Squeak are more closely coupled with > the point it is actually defined, in that you defined the pragma itself > in the accessor method for the variable, rather than having 1-N > declarations in a single method, pointing to 1-N places where those > settings values can actually be found. Right. The other advantage is that the simple "pragma" (which we've already established isn't a pragma at all) is trivial to support. Here is an implementation for Pharo, taking all of six methods (it would have been three methods if the Settings framework had been structured a little different :-) Oh, and as a free goodie you get the ability to browse the implementors of both, #systemsettings as well as #preference:category:description:type: if you're curious where and how these annotations are used. Cheers, - Andreas

April 29, 2010

Re: [Pharo-project] [Vm-dev] Fwd: is it possible to know the memory occupation (bytes) of an object?

by David T. Lewis

On Wed, Apr 28, 2010 at 11:26:54AM -0700, Andreas Raab wrote: > > BTW, SpaceTally>>spaceForInstancesOf:withInstanceCount: has the correct > computation (except for 64 bit :-) Somebody should do something about that one of these days, so I put it on Mantis: http://bugs.squeak.org/view.php?id=7518 Dave

April 29, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Mariano Martinez Peck

On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < alexandre.bergel(a)inria.fr> wrote: > It is a bit more subtle than that. > > If I take a Core 1.1, and doit: ConfigurationOfPharo project lastVersion > load > Then I get a warning coming from OBSearchBrowser class related to the world > menu registration. > > Yes, I noticed that. > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > > Doing twice a proceed resume the loading. > It then blocks on SHWorkspace, for the very same reason. > > yes.. > After having manually fixed the Nile problem (isInMemory), Pharo loads > well. ProfStef is open. > > I did the same... > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means that > OmniBrowser is loaded twice. Is this the intended behavior? > > I saw directly the final versions: 469 and 116. I didn't notice it was first trying to load 458 and 112. I know that in such conflict, Metacello will load the last one, but I didnt know that it actually LOADS also the previous versions. I thought that it only loads the final version, not both of them. In such case, I think it is a metacello bug. See this link: http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b… Dale, can you help us? Thanks Mariano > Alexandre > > > > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > > >> >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel <alexandre(a)bergel.eu> >> wrote: >> Hi! >> >> I am now trying to make ConfigurationOfPharo load the last version of >> OmniBrowser. >> If I do in a fresh core: ConfigurationOfPharo project lastVersion load >> >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. >> >> >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate ConfigurationOfPharo >> project lastVersion load >> >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 >> which are correct as those are defined in ConfigurationOfOmniBrowser >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. >> >> >> The loading blocks on the deprecated warning (yes, the registration in the >> World menu). >> In ConfigurationOfPharo>>version11: I have >> >> spec >> project: 'PharoNonCorePackages' with: >> '1.1.0'; >> project: 'NewInspector' with: '1.1'; >> project: 'Shout' with: '1.0'; >> project: 'Shout Tests' with: '1.0'; >> project: 'OCompletion' with: '1.1'; >> project: 'OCompletion Tests' with: '1.1'; >> project: 'OB Dev' with: '1.1.3'; >> project: 'OB Dev Tests' with: '1.1.3'; >> ... >> >> I therefore assume that the version 1.1.3 of OmniBrowser is loaded. >> 1.1.3 is indeed the last version specified in ConfigurationOfOmniBrowser: >> ConfigurationOfOmniBrowser project lastVersion >> => ~1.1.3 [ConfigurationOfOmniBrowser] >> >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion load >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and >> OmniBrowser-lr.469 are loaded. >> >> >> Exactly. And that's correct. Those are the versions that are defined in >> ConfigurationOfOmnibrowser 1.1.3 >> >> I find it is very hard to keep track of what is actually loaded. >> >> >> I don't understand your problem. Everything seems to work as exepected. >> >> >> I haven't closely followed the evolution of Metacello, but there is not a >> way to say: >> spec project: 'OB Dev' with: 'lastestVersion' >> >> Yes. Don't put any version. If you don't define a version, metacallo will >> load the last one. >> >> project: 'OB Dev'; >> >> or even remove that line from the version method. Even more, if you want >> ALL the last, you can load the baseline instead of the version. In such >> case, as you don't specify any version, it will download all the last ones. >> >> Cheers >> >> Mariano >> >> >> Or Something? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010

Re: [Pharo-project] ConfigurationOfPharo

by Mariano Martinez Peck

Torsten: I saw you changed version 1.0 of ConfigurationOfOmniBrowser to change the version of OmniBrowser package. However, I don't think this is a good thing. When a version is released, it should be "modifieded". For any reason. The good behavior, from my point of view, in this case is to put bless the 1.0 version as broken and create a new version 1.0.1 with such change/fix What do you think ? Cheers Mariano On Tue, Apr 27, 2010 at 11:41 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 27, 2010 at 7:15 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Mariano, >> >> now he complains about "OmniBrowser-DamineCassou.462" >> (which comes from 1.0 of ConfigurationOfAutomaticMethodCategorizer >> which loads 1.0 of ConfigurationOfOmniBrowser >> which loads OmniBrowser-DamienCassou.462) >> >> Looks like this conflicts with "OmniBrowser-lr.469" >> which is noted in version 1.1.3 of ConfigurationOfOmniBrowser >> >> Looks like a conflict: >> You now use 1.1.3 of ConfigurationOfOmniBrowser, but the >> ConfigurationOfAutomaticMethodCategorizer that you use in >> ConfigurationOfPharo still points to 1.0 of ConfigurationOfOmniBrowser. >> >> > Yes, but it doesn't matter. In such situation (conflict), Metacello will > load the latest version, in this case, 1.1.3. > I cannot mantain all configurations. If you think > ConfigurationOfAutomaticMethodCategorizer should have 1.1.3 instead of 1.0, > just do it. > > > >> Lesson learned: take care when you edit configs since you may break other >> peoples code. >> > > I do take care, but I cannot test all configurations. Even more, when they > are not stable releases. > In addition, I didn't break anything: > > OmniBrowser-DamienCassou.462 > > existed at the point I did the configuration. Now, if I browse the > repository http://source.wiresong.ca/ob > I don't see it. So, maybe Colin removed that version and put Lukas ones and > that's why it is failing. > Colin, do you know if this was what happened ? > > >> So I would not call this a reproducable Pharo 1.0 Release ;) >> >> > I don't understand. Pharo 1.0 is completly reproducable. I take a PharoCore > 1.0 I avaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-10517') > perform: #silently: with: true; perform: #load. > > > And I have the PharoDev 1.0 stable release in perfect state and without any > problem. > > Cheers > > Mariano > > > >> >> Just try in a clean 1.0 core image: >> >> -------------------------- >> Gofer new >> squeaksource: 'MetaSource'; >> package: 'ConfigurationOfMetaSource'; >> load. >> >> ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.0-alpha1') >> load >> -------------------------- >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

April 28, 2010