February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.2 broken on Hudson

by Guillermo Polito

Ok, I changed ConfigurationOfShout to load the last (and empty) SHWorkspace. On Fri, Feb 18, 2011 at 12:21 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > What about removing SHWorkspace from configurationOfPharo since styling is > handled in core? > > > ---------- Forwarded message ---------- > From: Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > Date: Thu, Feb 17, 2011 at 10:45 AM > Subject: Re: [Pharo-project] Pharo 1.2 broken on Hudson > To: Guillermo Polito <guillermopolito(a)gmail.com> > > > FixSHWorkspaceToFixMenu.1.cs have to b e applied in a 1.2 dev image. > You can also applied it in SHWorkspace, but basically, SHWorkspace is > useless now since Workspace handle shout by itself. > > > Ben > > On Feb 17, 2011, at 2:42 PM, Guillermo Polito wrote: > > So, the problem is that FixSHWorkspaceToFixMenu.1.cs must be integrated > into SHWorkspace, is it? :) > > On Thu, Feb 17, 2011 at 10:35 AM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> It;s because of FixWorkspaceMenu.2.cs >> Normally the cs PrepareFixWorkspaceMenu.2.cs have to be applied before to >> avoid this problem >> >> >> Ben >> >> >> On Feb 17, 2011, at 1:52 PM, Guillermo Polito wrote: >> >> Ok, I fixed OB, but now is failing because: >> >> DuplicatedVariableError: stylingActive is already defined in Workspace >> >> >> :( >> >> >> >> On Wed, Feb 16, 2011 at 9:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Pharo 1.2. is broken on Hudson. >>> >>> The ConfigurationOfPharo is not loadable on a core image due >>> to changes on OmniBrowser. >>> >>> Reason: >>> ======= >>> ConfigurationOfOmniBrowser-GuillermoPolito.102.mcz in >>> http://www.squeaksource.com/MetacelloRepository >>> references "OB-Shout-JohanBrichau.13" in spec for: #pharo in its >>> version 1.2.4 >>> >>> But OB-Shout-JohanBrichau.13 is not in >>> http://www.squeaksource.com/PharoOB >>> Should we use "OB-Shout-GuillermoPolito.13.mcz" instead? >>> >>> Guillermo: can you give me access to PharoOB too? >>> >>> Thx >>> T. >>> >>> >>> -- >>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>> >> >> >> > > >

Feb. 18, 2011

[Pharo-project] Fwd: Pharo 1.2 broken on Hudson

by Guillermo Polito

What about removing SHWorkspace from configurationOfPharo since styling is handled in core? ---------- Forwarded message ---------- From: Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> Date: Thu, Feb 17, 2011 at 10:45 AM Subject: Re: [Pharo-project] Pharo 1.2 broken on Hudson To: Guillermo Polito <guillermopolito(a)gmail.com> FixSHWorkspaceToFixMenu.1.cs have to b e applied in a 1.2 dev image. You can also applied it in SHWorkspace, but basically, SHWorkspace is useless now since Workspace handle shout by itself. Ben On Feb 17, 2011, at 2:42 PM, Guillermo Polito wrote: So, the problem is that FixSHWorkspaceToFixMenu.1.cs must be integrated into SHWorkspace, is it? :) On Thu, Feb 17, 2011 at 10:35 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It;s because of FixWorkspaceMenu.2.cs > Normally the cs PrepareFixWorkspaceMenu.2.cs have to be applied before to > avoid this problem > > > Ben > > > On Feb 17, 2011, at 1:52 PM, Guillermo Polito wrote: > > Ok, I fixed OB, but now is failing because: > > DuplicatedVariableError: stylingActive is already defined in Workspace > > > :( > > > > On Wed, Feb 16, 2011 at 9:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Pharo 1.2. is broken on Hudson. >> >> The ConfigurationOfPharo is not loadable on a core image due >> to changes on OmniBrowser. >> >> Reason: >> ======= >> ConfigurationOfOmniBrowser-GuillermoPolito.102.mcz in >> http://www.squeaksource.com/MetacelloRepository >> references "OB-Shout-JohanBrichau.13" in spec for: #pharo in its >> version 1.2.4 >> >> But OB-Shout-JohanBrichau.13 is not in >> http://www.squeaksource.com/PharoOB >> Should we use "OB-Shout-GuillermoPolito.13.mcz" instead? >> >> Guillermo: can you give me access to PharoOB too? >> >> Thx >> T. >> >> >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> > > >

Feb. 18, 2011

Re: [Pharo-project] A new GUI visual designer

by Craig Latta

Hi GÃ¶ran-- > Thinking about this a bit more I realize one interesting aspect: > > Your stuff is basically low level serialization support - right? It is, but what makes it interesting is that it's *interactive* serialization; the producing and consuming systems interact. Traditionally, you serialize to a file, and at the time the consuming system reads it, the producing system is long gone. The consumer can't ask the producer anything about it if finds something confusing, and the producer can't take any information about the consumer into account when creating the bits. Speaking of recipes, imagine following a recipe from a cookbook. You might wonder if you can leave some ingredient out (because you forgot to go the store), but you're on your own figuring that out. All you have is the recipe. But if the author of the recipe were there with you, telling you what to do, you could just ask. And the author might not even bother mentioning the missing ingredient, because he can already see when you start that you don't have it. It's this sort of synchronization that Naiad (Spoon's module system) supports. It's important when transferring individual method literals, entire methods, and entire modules. It's all messages going across the wire between producer and consumer, and their precise content may vary significantly from one consumer to another. Expecting one set of bits to convey the correct thing to all consumers, in a system as dynamic as Smalltalk, always struck as me a bit crazy. :) > So... it all boils down to what kind of object model you pick. Now... > come to think of it - readable and editable? Not sure how you mean > there... I meant it in the sense that I thought you did... the way I'd store GUI information is even more readable than viewspec arrays or XML because it's just the original objects from which we derived the viewspecs and XML. It's more editable for the same reason; we can use the same powerful inspectors and browsers that we used during development. > ...counting the designer tool as the editor is kinda cheating :) Hey, if it's useful, why not? :) > One nice way to make a GUI description to be very robust against > change is to let it be the representation of "a sequence of commands > aimed at a builder API". Thus, the actual UI framework can change all > it wants, as long as the builder API still works. > > So, if your object model is such a "command sequence" then I agree, it > would be as robust as the same thing in Tirade. But... if your model > is the actual built UI then I don't agree that it is as robust - > supporting "migration" from one object model to a new one is kinda > complex. Well, builder APIs can change, too. But sure, I'm not attached to any particular GUI object model, or style of model (declarative or otherwise). I do think, though, that using the actual built UI becomes an interesting option when you have live synchronization. I view the complexity as similar to writing correct "postCopy" methods (not too bad). You could ask a UI object to spit out builder commands, for example, as I suggested in an earlier message. Builder commands could be an exchange format, used occasionally when necessary. -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Feb. 18, 2011

Re: [Pharo-project] [BUG] 1.2 UTF8TextConverter: Invalid utf8 input detected

by Henrik Sperre Johansen

On 17.02.2011 22:44, Igor Stasenko wrote: > On 17 February 2011 18:20, StÃ©phane Ducasse<Stephane.Ducasse(a)inria.fr> wrote: >> **tx** >>> Can you open a ticket? >>> >>> Already done: http://code.google.com/p/pharo/issues/detail?id=3721 >>> >>> Janko >> Igor could you have a look? >> > yes. I've been looking into it, it's the SecurityPlugin sources used by Cog not doing conversion from system codepage to utf8. The one in standard vm does it, but it's still suboptimal compared to using GetUserNameW. Hopefully find time to finish up and post proposal code to vmdev tomorrow. Cheers, Henry.

Feb. 17, 2011

Re: [Pharo-project] [BUG] 1.2 UTF8TextConverter: Invalid utf8 input detected

by Igor Stasenko

On 17 February 2011 18:20, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > **tx** >> >> Can you open a ticket? >> >> Already done: http://code.google.com/p/pharo/issues/detail?id=3721 >> >> Janko > > Igor could you have a look? > yes. > Stef > > -- Best regards, Igor Stasenko AKA sig.

Feb. 17, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Douglas Brebner

On 17/02/2011 18:08, Eliot Miranda wrote: > > > On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner > <squeaklists(a)fang.demon.co.uk <mailto:squeaklists@fang.demon.co.uk>> > wrote: > > On 16/02/2011 20:13, Eliot Miranda wrote: >> >> >> On Wed, Feb 16, 2011 at 12:04 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> >> >> On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote: >> >> > >> > >> > On Tue, Feb 15, 2011 at 11:50 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr >> <mailto:stephane.ducasse@inria.fr>> wrote: >> > Eliot a final question. >> > So how will you handle OPAL compiler change in Cog? >> > Do you require that marcus and jorge have to deal with >> decompiler of caseOf: in addition to all the rest? >> > Is it a strong requirement? Because then this is clear that >> Opal will be delayed. But may be it is not that important >> after all. >> > Just curious. >> > >> > OPAL is a Smalltalk compiler. I can therefore assume that >> it will compile Smalltalk. caseOf: is valid Smalltalk and so >> will be compiled by OPAL. Whether Marcus chooses to optimise >> caseOf: or not is up to him. >> >> This is exactly my point. >> >> >> No it's not. Your point was to raise two straw-=man arguments: >> 1. that Marcus and Jorge would have to deal with the decompiler >> (not an issue; the decompiler already deals with optimized >> caseOf: and the new decompiler will deal with optimized caseOf: >> just as it'll deal with optimized ifTrue: ifNotNil: et al). >> 2. that supporting caseOf: in optimized form will delay Opal (not >> an issue; Opal will optimize certain constructs, this is just one >> more and won't add a lot of time). >> >> So your point appears to be to try and justify removing caseOf: >> on spurious grounds by spreading FUD. >> >> This is so unlike you I'm having a hard time really understanding >> what's going on. >> >> > > Correct me if I'm wrong but isn't Stephane essentially saying that > Opal will just demote #caseOf: from inlined special form to normal > method? (Possibly so it can be unloadable instead of being pinned > in the system by the compiler support). > It seems to me that this shouldn't affect caseOf: use in Cog since > the inlining there is handled by the SLang translator. > > > It certainly won't affect the production Cog since indeed that goes > through Slang to emerge as C. However it will affect developing in > Cog, which is done by rnning the simulator, and as I've shown case > statements are used in some performance-critical parts of the system > (byte access). Wasn't there mention of Opal having optimisations as extensions so you can have an optimised caseOf: without having it hardwired into the compiler? > > Or have I totally misunderstood? > > Of course, where caseOf: is kept afterwards another question :) > > > I don't see why one would want to get rid of this useful > functionality. There is nothing inherrently wrong with a flexible > case statement. Its certainly far more preferrable than a > performance-equivalent set of nested ifTrue:ifFalse:'s. Further, the > dictionary/perform or multiple classes approaches only make sense at a > certain scale (that's especially true of the dictionary/perform > alternative since maintaining the dictionary is painful). So for me > it makes absolutely no sense for a Squeak-derived Smalltalk dialect to > eliminate a construct that is really useful in certain circumstances. > That kind of thinking eliminates things like contexts and that's a > slippery slope to eliminating the essential flexibility of the system. > I wasn't arguing for getting rid of it entirely, I prefer it to dictionary/perform which I dislike for some reason

Feb. 17, 2011

Re: [Pharo-project] Menu creation and invocation

by Alain Plantec

he he he. thanks Fernando. and really really happy that you find it useful. but is see maybe an issue here. It concerns the pragma keyword. It is currently a global keyword. Maybe one should also allow a way to specify where the pragma are to be collected. maybe something like: MyMorph>>menuBuilder ^ (PragmaMenuBuilder localPragmaKeyword: 'tileMenu' model: self ) notice the #localPragmaKeyword:model selector instead of #pragmaKeyword:model. it would constraint the builder to only search pragma locally. does it make sense to you ? Cheers Alain Le 17/02/2011 21:15, Fernando Olivero a Ã©crit : > I want to give the thanks to Alain, for the excellent work on > PragmaMenuBuilder! > Making menus is elegant and straightforward this way! > > I post here how i'm using them: > > MyMorph>>mouseDown: aMouseEvent > aMouseEvent redButtonPressed ifTrue:[ self click: aMouseEvent ]. > aMouseEvent yellowButtonPressed ifTrue:[ self leftClick: aMouseEvent ]. > > MyMorph>>leftClick: aMouseEvent > self menuBuilder menu popUpInWorld > > MyMorph>>menuBuilder > ^ (PragmaMenuBuilder pragmaKeyword: 'tileMenu' model: self) > > And you can nicely decouple the menu invocation from the menu creation! > > Thanks! > > Fernando > >

Feb. 17, 2011

[Pharo-project] Menu creation and invocation

by Fernando Olivero

I want to give the thanks to Alain, for the excellent work on PragmaMenuBuilder! Making menus is elegant and straightforward this way! I post here how i'm using them: MyMorph>>mouseDown: aMouseEvent aMouseEvent redButtonPressed ifTrue:[ self click: aMouseEvent ]. aMouseEvent yellowButtonPressed ifTrue:[ self leftClick: aMouseEvent ]. MyMorph>>leftClick: aMouseEvent self menuBuilder menu popUpInWorld MyMorph>>menuBuilder ^ (PragmaMenuBuilder pragmaKeyword: 'tileMenu' model: self) And you can nicely decouple the menu invocation from the menu creation! Thanks! Fernando

Feb. 17, 2011

Re: [Pharo-project] Render a COLLADA mesh with OpenGL

by Fernando Olivero

Hi, that would be cool to see! I haven't heard of anyone rendering COLLADA or other sort of files ( i think they can render Google sketchpad files also) outside the Croquet/Cobalt community. Just an remark, glad to hear that you find it useful but i stopped maintaining the AlienOpenGL package a while ago, Although it is stable and has enough features. For rendering OpenGL you can also take a look at the squeaksource packages, ( browse previous mails on the list) that rely on FFI. In case AlienOpenGL does not satisfy your needs. Fernando On Wed, Feb 16, 2011 at 11:50 AM, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > > Hi, > > I'm working on parsing COLLADA file and then render it with AlienOpenGL in > squeaksource. (AlienOpenGL was a good example of Alien BTW) > > http://forum.world.st/file/n3308632/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7_20… > > Has anyone done this before? > > I've seen KMZ file successfully load on OpenCobalt. Has anyone done it with > Pharo(or Squeak)? > > Best Regards > -- > View this message in context: http://forum.world.st/Render-a-COLLADA-mesh-with-OpenGL-tp3308632p3308632.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 17, 2011

Re: [Pharo-project] Issue 3728 in pharo: Changed MenuMorph references to go through UIManager default menuClass

by pharo＠googlecode.com

Comment #1 on issue 3728 by fernando...(a)gmail.com: Changed MenuMorph references to go through UIManager default menuClass http://code.google.com/p/pharo/issues/detail?id=3728 Fixed

Feb. 17, 2011