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

[Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)
by StÃ©phane Ducasse Feb. 20, 2011

Feb. 20, 2011

Does anybody have an idea what is the purpose of this function in the vm? Stef sqInt setCompilerInitialized(sqInt newFlag) { register struct foo * foo = &fum; sqInt oldFlag; oldFlag = foo->compilerInitialized; foo->compilerInitialized = newFlag; return oldFlag; }

4 4

[Pharo-project] about FS: a roadmap
by StÃ©phane Ducasse Feb. 20, 2011

Feb. 20, 2011

HI guys I was rambling.... so I looked at other frameworks (RIO, FileMan) and I prefer FS. So I will start to write again comments, continue to reorganize the current structure. I was in contact with colin that told me that he found the improved version that he was doing after ESUG. I asked him to publish it into filesystem I will integrate the fixes of damien. I would like to have - a better help (already there). - Rename workingDirectory as workingDirectoryPath - add workingDirectory returning a FSReference - Every method with an adequate comment. The idea is that the comment should describe what the method does when we do not see its body: let us try to think a bit in JavaDoc or Ruby Yard fashion for once. - Use rename primitives - Have the possibility to create empty file - Clean identification of implementation tests and black box tests - Integrate Gemstone fixes - Stream usage clearly identified to support Gemstone migration) - Onion like structure so that we can have one or two packages that are really the core (yes I still want a minimal kernel). - Check the file API creation: old, new, exist.... - Prepare a migration path for 1.3 - Fix filesystem workingDirectory isWorkingDirectory returns false. - rename fileDoesNotExist: and friends do convey that its goal is mainly to raise en exception raiseFileDoesNotExistsFor: Of course I would like to avoid to throw away all that good energy so I hope to collaborate with colin. We will see what will happen. I can understand that he has another agenda/time frame but we should move on this front. So all my code will be publicly available in the SqueakSource/fs repository. If you think that this is the wrong path, let me know. I will report my changes regularly. Stef

4 8

[Pharo-project] Fwd: Need your point of view on FSPath * and others
by StÃ©phane Ducasse Feb. 20, 2011

Feb. 20, 2011

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Date: February 20, 2011 8:54:54 AM GMT+01:00 > To: Colin Putney <colin(a)wiresong.com> > Subject: Re: Need your point of view on FSPath * and others > > Thanks I will take into that and write better comments. > > I was looking at makeRelative: they look to me as 'private methods' used for double dispatch while > relativeTo: is the public one. I imagine that I'm correct. > >> With that in mind, I added the #/ and #* methods to make the >> filesystem API easier to use. I think binary selectors are >> under-exploited in Smalltalk, and we'd gain a lot in terms of succinct >> and readable code by making better use of them. >> >>> 2- Then I was wondering if it would not be good to have validating creation methods >>> >>> (FSPath * 'parent/child/') isRelative >>> true >>> (FSPath * '/parent/child/') isAbsolute >>> false >>> because the string is not checked >>> FSPath * '/parejhkjhhg %% ^%$%^(%$546547675 nt??child/' >> >> That's not how paths are meant to be used - the string arguments >> should be file- or directory names, not path fragments. #* creates a >> relative path (it's meant to be similar mnemonically to >> ./parent/child, while #/ creates an absolute path. > > > indeed this is cool. > I was trying to find what you tried to express because I was sure that there was something like that > But I was already reading it as star and not dot :) > With dot and slash it makes a lot more sense. > > >> >> (FSPath * 'parent' / 'child') isRelative "true" >> (FSPath / 'parent' / 'child') isAbsolute "true" >> >> >>> I saw that there is >>> readFrom: aStream delimiter: aCharacter >>> >>> so I created an unchecking instance creation category and I added with: and * in it. >> >> It's not a matter of checked and unchecked so much as parsed and >> unparsed. #/ and #* provide a mini-DSL for building up paths, while >> #readFrom:delimiter: parses path strings. >> >>> 3- Then finally the following confuses me >>> >>> (FSPath with: 'parent/child/') isRelative true >> >> That creates to a relative path to a file/directory called >> 'parent/child'. In bash you'd escape the slashes like this: >> >> parent\/child\/ >> >>> (FSPath with: '/parent/child/') isRelative true >> >> That's a relative path to '/parent/child'. In bash: /\parent\/child\/ > > I was not aware of relative path starting with / > Ugly bash. > >> >>> (FSPath with: '') isRelative false >> >> That's an absolute path to the root of the file system. Absolute paths >> have an empty first element. If you consider $/ the a separator, >> '/usr/local/bin' has an empty first element, right? >> >>> Either with: create relative path or isRelative is not consistent. >>> If with: creates relative path then the last one should be true >>> or isRelative should return false on the second one. ? >> >> Ok, it's a bit of an unusual case, but I think it's important to be >> able to represent paths like \/parent\/child. Their perfectly valid as >> far as the filesystem is concerned, and we want to be able to work >> with such oddly-named files. >> >>> 4 - about FSPath root >>> we have >>> >>> root >>> "Return the relative root path" >>> ^ self with: '' >>> >>> FSPath root >>> returns / >>> and I like that >>> >>> Now what about defining root as >>> >>> root >>> ^ self with: '/' >>> >>> It would be more consistent. Now it breaks everything. So I did not do it :) >> >> I suppose that, strictly speaking, the most consistent way to >> represent the root directory is >> >> root >> ^ self withAll: #('' '') >> >> It still ends up being a bit of a special case, though. >> >> Colin >

1 0

[Pharo-project] Need your point of view on FSPath * and others
by StÃ©phane Ducasse Feb. 20, 2011

Feb. 20, 2011

Colin I'm continuing adding comments to FS. 1- A question about FSPath class>>* aString ^ self with: aString I would like to deprecated FSPath class>>* and use with: since this is the message and What do you think? I really prefer for static analysis point of view not to pollute numerical behavior with others. Avoiding ad-hoc polymorphism will help us to build static checker in the future. 2- Then I was wondering if it would not be good to have validating creation methods (FSPath * 'parent/child/') isRelative true (FSPath * '/parent/child/') isAbsolute false because the string is not checked FSPath * '/parejhkjhhg %% ^%$%^(%$546547675 nt??child/' I saw that there is readFrom: aStream delimiter: aCharacter so I created an unchecking instance creation category and I added with: and * in it. And added comments 3- Then finally the following confuses me (FSPath with: 'parent/child/') isRelative true (FSPath with: '/parent/child/') isRelative true (FSPath with: '') isRelative false Either with: create relative path or isRelative is not consistent. If with: creates relative path then the last one should be true or isRelative should return false on the second one. ? 4 - about FSPath root we have root "Return the relative root path" ^ self with: '' FSPath root returns / and I like that Now what about defining root as root ^ self with: '/' It would be more consistent. Now it breaks everything. So I did not do it :) May be I'm tired after 4 ours teaching and 6 hours train. Thanks for your time Stef

4 6

Re: [Pharo-project] [Pharo-users] Call for Pharo Support **important**
by StÃ©phane Ducasse Feb. 19, 2011

Feb. 19, 2011

Hi davorin It says that you would consider paying a membership if this one is ok for you but that the membership would have to be clear. So this is just a letter of support. Your are not tying yourself. We will decide together the model because we should like that everybody can contribute. Now for us this is an important tool because we can seize the community to see if we could collect money to pay an engineer like igor full-time, half time.... Stef > I am not expert in legalize, does signing of this letter imply some > financial commitment on part of the signer, or it is just "Pharo is > great and we would like to use it" kind of letter? > > Many thanks! > > Davorin Rusevljan > http://www.cloud208.com/

2 2

Re: [Pharo-project] Hudson builds are cool
by Marcus Denker Feb. 19, 2011

Feb. 19, 2011

On Feb 19, 2011, at 1:03 AM, Miguel CobÃ¡ wrote: > I haven't had time to use Pharo 1.2 from Hudson until now. All I have to > say is: amazing work (or job :) > We need to update the vms used for the build... will do that at some point next week when back home. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 3

[Pharo-project] Hudson builds are cool
by Miguel CobÃ¡ Feb. 19, 2011

Feb. 19, 2011

I haven't had time to use Pharo 1.2 from Hudson until now. All I have to say is: amazing work (or job :) Thanks to all the people involved! -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

1 0

[Pharo-project] saving a monticello working copy
by Tudor Girba Feb. 19, 2011

Feb. 19, 2011

Hi, Does anyone know a simple way to save a Monticello working copy into the package-cache? Cheers, Doru -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

2 3

[Pharo-project] A new GUI visual designer
by nullPointer Feb. 19, 2011

Feb. 19, 2011

https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… It really looks very professional. I made a user interface builder for Polymorph, which I left because I was too complicated for me. I hope that now someone more knowledgeable can really necessary to implement a tool for Squeak / Pharo as a visual designer user interfaces. Regards -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3067111.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

18 69

[Pharo-project] minimalism (formerly case-statement-stuff)
by Craig Latta Feb. 18, 2011

Feb. 18, 2011

Hi-- If you can transfer compiled methods directly, then you can make the entire compiler an optional module... As the Americans are fond of saying, "just sayin'". :) -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

3 4