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

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

by StÃ©phane Ducasse

+1 So now we will be the guys that do not want to be backward compatible, but this is on the web page of pharo so nothing really new to me :) >>> Good but what is your point? >> >> Compatibility and simplicity. > Come on Andreas, "simple" is not so much more precise than "cool" > > and I don't think that having: > > ------------------ > Editor class>>blinkingCursor > ^ BlinkingCursor ifNil: [ true ] > > EditorSetting class>>editorSettingsOn: aBuilder > <systemsettings> > (aBuilder setting: #blinkingCursor) > label:'Blinking Text Cursor') > parent: #Morphic; > target: Editor; description: 'When true, the text cursor will blink.' > ------------------- > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- > > You prefer UI+domain mixing, we prefer UI separated from domain. > And yes, the SettingBrowser implementation could be improved. > I know, but I'm happy because it can be removed or remade > without any other consequence. > And compare it to the PreferenceBrowser ... > > Cheers > Alain > > > > > > > _______________________________________________ > 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 Alain Plantec

Andreas Raab a Ã©crit : > On 4/28/2010 11:32 PM, StÃ©phane Ducasse wrote: >> Good but what is your point? > > Compatibility and simplicity. Come on Andreas, "simple" is not so much more precise than "cool" and I don't think that having: ------------------ Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ] EditorSetting class>>editorSettingsOn: aBuilder <systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' ------------------- is so much more "complicated" than ------------------- Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ] ------------------- You prefer UI+domain mixing, we prefer UI separated from domain. And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ... Cheers Alain

April 29, 2010

Re: [Pharo-project] ConfigurationOfPharo

by Torsten Bergmann

You mean "it should not be modified". I know, but one should also not delete *.mcz's from a repository ;) I was just pragmatic due to lack of time and it should be no problem since it works for now. Bye T. -------- Original-Nachricht -------- > 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 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 29, 2010

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