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

Re: [Pharo-project] Pharo changing the game

by Mariano Martinez Peck

On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > > > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > > >>> It is interesting to note that of course, after this was added to 3.9, > >> there was > >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... > >>> > >>> Who that person was is left as an exercise to the reader of course ;-) > >> > >> Hint: FFI has its own proprietary hardcoded pragma format. It > >> unnecessary complicates the compiler even when not loaded. Not to > >> mention that it breaks all tools that have their own parser, such as > >> RB for example. > >> > > > > And I hate having to write <apicall: in windows and <cdecl: in > Unix* > > I would love to be the same and that someone else takes care, not me (the > > user). > > Do you know if there is a reason for this? I imagine that yes. > > AFAIK apicall: uses the stdcall calling convention > (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall) while > cdecl: uses the cdecl calling convention > (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl) > So it depends on the function's calling convention which you should use > (and not the OS). > > Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it) and if you don't want it (the default) just put what you want ? Cheers Mariano > Levente > > > > > > >> > >> Lukas > >> > >> -- > >> Lukas Renggli > >> http://www.lukas-renggli.ch > >> > >> _______________________________________________ > >> 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 >

Feb. 12, 2010

Re: [Pharo-project] FileSystem question

by Henrik Johansen

Den 12.02.2010 16:18, skrev StÃ©phane Ducasse: > I'm trying to move some of the examples of Coral from rio to filesystem and I get some questions. > > Are there some examples (not tests)? > What is the difference between FSReference and FSPath? > > For example how can I print in the Transcript all the files in my current dir? > > Stef > _____________________________________ There's probably an easier way, but: (FSDiskFilesystem current childrenAt: FSDiskFilesystem current workingDirectory) do: [:each | each printOn: Transcript cr ]. Transcript flush. Speaking of current dir... FSDiskFilesystem current workingDirectory isWorkingDirectory -> false, at least on Windows :) Cheers, Henry

Feb. 12, 2010

[Pharo-project] FileSystem

by StÃ©phane Ducasse

hi Colin Is there a way not to have to specify the FileSystem to create a stream for a file on disk? str := FSUnixFilesystem new writeStreamOn: 'giffle'. str nextPutAll: 'zzzzzzzzzz'. str close -> str := 'giffle' asWriteStream str nextPutAll: 'zzzzzzzzzz'. str close is there a way to do currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] Do I have to use an FSPreOrderGuide? Are there some behavior like doWithAllFiles already defined? I have the impression that having some extensions could make the interfaces smoother. I liked some of the aspects of the rio ones, even if I did not like the chaining one. Stef

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Levente Uzonyi

On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> It is interesting to note that of course, after this was added to 3.9, >> there was >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>> >>> Who that person was is left as an exercise to the reader of course ;-) >> >> Hint: FFI has its own proprietary hardcoded pragma format. It >> unnecessary complicates the compiler even when not loaded. Not to >> mention that it breaks all tools that have their own parser, such as >> RB for example. >> > > And I hate having to write <apicall: in windows and <cdecl: in Unix* > I would love to be the same and that someone else takes care, not me (the > user). > Do you know if there is a reason for this? I imagine that yes. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall) while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl) So it depends on the function's calling convention which you should use (and not the OS). Levente > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Feb. 12, 2010

[Pharo-project] FileSystem question

by StÃ©phane Ducasse

I'm trying to move some of the examples of Coral from rio to filesystem and I get some questions. Are there some examples (not tests)? What is the difference between FSReference and FSPath? For example how can I print in the Transcript all the files in my current dir? Stef

Feb. 12, 2010

[Pharo-project] [ANN] HelpSystem (was ProfStef)

by Torsten Bergmann

Laurent Laffont wrote: >And I was just thinking that there may be more value *now* in writing >tutorials than in writing a full featured help browser ? Stef wrote: >+1 > >but let us be incremental and improve step by step. OK, here is my first step: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfHelpSystem'; load. (Smalltalk at: #ConfigurationOfHelpSystem) load Project lives on http://squeaksource.com/HelpSystem.html (Read/Write) If it evolves we can include it into a dev image. Needs improvements, but is a start. Dont know if pragmas or a #pages method would be the way to go to define page order, ... Feel free to comment ... -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

by Nicolas Cellier

2010/2/12 <csrabak(a)bol.com.br>: > Except if my analytical skills are impaired by being tired and groggy due a very short sleep I think the solution to this is only a matter of putting: > > sourceStream peekFor: $+. > > just before eneg := sourceStream peekFor: $-. in SqNumberParser>>readExponent > > Did I miss something fundamental? > > my 0.01999. . . . > > -- > Cesar Rabak > > Yes, it's trivial. It's already implemented in the DolphinNumberParser, because Dolphin syntax allow 1.0e+2 In st-80 and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then send #+ with argument 2 to the result) Other features are not so hard either. We have to measure all the consequences then just decide what is worth. Nicolas > Em 12/02/2010 11:44, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > in pharo too ;( > > Sef > On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote: > >> On Friday 12 February 2010 02:40:36 pm John M McIntosh wrote: >>> '1.0e+2' Â asNumber >>> returns 1.0 >> Squeak (Trunk) shows: >> '1.0e2' asNumber 100 >> '1.0e+2' asNumber 1.0 >> >> :-/ Â .. Subbu >> >> _______________________________________________ >> 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

Feb. 12, 2010

[Pharo-project] Fwd: Issue 1945 in pharo: registration mechanism for the menu

by StÃ©phane Ducasse

>> >> Comment #2 on issue 1945 by aplantec: registration mechanism for the menu >> http://code.google.com/p/pharo/issues/detail?id=1945 >> >> yep!! >> I've retrieved it (I thought I had lost it and I was sad) >> it is the MenuRegistration package in PharoTaskForces. >> Try it with: >> -------------- >> PragmaMenuBuilder popUpKeyword: 'worldMenuExample' title: 'World menu'. >> -------------- >> >> This example popups a world menu fully declared with pragma methods. >> It also shows how an external package can register a new entry in it >> (see WorldMenuSkeletonExample class>> myOwnCoolToolRegistrationOn: and >> WorldMenuSkeletonExample class>> myOwnCoolMenuRegistrationOn: ) >> The principle is exactly the same as for the settings. > > Sounds like quite cool to me.

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Peter Hugosson-Miller

On Fri, Feb 12, 2010 at 3:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi Peter > > there is no stupid question! Only people afraid to ask. > Stupidity is when you ask three times the same question. > In this list we can ask all the stupid question we want. > > So thanks for taking the risk :) > > automatic initialize= calling automatically initialize when calling new > > avoid to have to all the time write > > Box class>>new > ^ super new initialize ; yourself > > kind of desastrous for newbies. You know after two lectures you have to > nearly explain metaclasses, and deep super + method lookup... > > In Squeak 3.7 we got a chance to have an agreement to have > > Behavior>> new > ^ self basicNew initialize > Object>>initialize > ^ self > and some shortcuting behavior on array to speed up the system. > it makes so many things much much nicer. > > > > On Feb 12, 2010, at 3:15 PM, Peter Hugosson-Miller wrote: > > > On Fri, Feb 12, 2010 at 10:30 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > another point, what about automatic initialize? > > At one point in the past VW (eliot) was really for introducing it in VW > since it would not cost > > anything in presence of the JIT. > > Dolphin people did it on Model but they told me that if they could they > would remove it. > > and this is a really important change to lower the entry level and burden > of newcomers. > > > > Now because of "compatibility" we have to code without it for me this is > a drawback. > > > > I know this is probably a stupid question, but rather than miss something > important, I'll take that risk :-p > > > > What do you mean by "automatic initialize"? > > > > -- > > Cheers, > > Peter > > _______________________________________________ > > 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 > Thanks, Stef, Cesar So you're still talking about having the message #initialize being explicitly sent from within the #new method, right up there on Behavior. I definitely like this arrangement: one of the first things I always do is to implement #new that way, as far up as I can in the domain object hierarchy. For a moment there I imagined you meant some "behind-the-scenes-magic", and that the #initialize send would not be explicit anywhere in the code. Now I can relax again ;-) -- Cheers, Peter

Feb. 12, 2010

[Pharo-project] [update 1.1] #11204

by Marcus Denker

11204 ----- Issue 1906: changeStampPerSe and changeStamp should be moved from Utilities to Author Issue 1956: clean mutiCS, multiSt Issue 1905: Date and DateAndTime behavior should be extracted from Utilities -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 12, 2010