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

Re: [Pharo-project] Pharo 1.2 virtual sprint

by laurent laffont

Guillermo, please subscribe on doodle: http://www.doodle.com/byvynpkmm87hc3x8 so we know when to join over IRC. Laurent On Sat, Feb 19, 2011 at 1:10 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Next week? I can join a llittle :). > > > On Sat, Feb 19, 2011 at 5:46 AM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> No one seems to be motivated to have a virtual sprint to release Pharo 1.2 >> ? >> >> >> On Wed, Feb 16, 2011 at 1:28 PM, laurent laffont >> <laurent.laffont(a)gmail.com> wrote: >> > >> > On Wed, Feb 16, 2011 at 3:28 AM, Serge Stinckwich >> > <serge.stinckwich(a)gmail.com> wrote: >> >> >> >> Launch a doodle for a day long virtual sprint all over the world ;-) >> > >> > >> > http://www.doodle.com/byvynpkmm87hc3x8 >> > Laurent. >> > >> >> >> >> On Wed, Feb 16, 2011 at 4:54 AM, laurent laffont >> >> <laurent.laffont(a)gmail.com> wrote: >> >> > Which day you prefer ? >> >> > Laurent >> >> > On Tue, Feb 15, 2011 at 10:00 AM, StÃ©phane Ducasse >> >> > <Stephane.Ducasse(a)inria.fr> wrote: >> >> >> >> >> >> If there is internet connection where I will be hacking with alain >> we >> >> >> can >> >> >> participate :). >> >> >> >> >> >> Stef >> >> >> >> >> >> On Feb 14, 2011, at 10:01 PM, laurent laffont wrote: >> >> >> >> >> >> > Could we organize a Pharo 1.2 virtual sprint over IRC to resolve, >> >> >> > kill, >> >> >> > eleminate, eradicate, destroy remaining issues ? and learn >> together >> >> >> > too. >> >> >> > >> >> >> > I can do this next week from monday to wednesday evening (France >> time >> >> >> > zone). >> >> >> > >> >> >> > Laurent >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Serge Stinckwich >> >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> >> Every DSL ends up being Smalltalk >> >> http://doesnotunderstand.org/ >> >> >> > >> > >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> >

Feb. 20, 2011

Re: [Pharo-project] about GLMOrangeUITheme [WAS] Re: [update 1.2] #12302

by Richard Durr

Why not create a chat client that automatically connects to a central lobby whenever you open an image, so that everybody can chat ^^ On Sat, Jan 15, 2011 at 9:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Improve the infrastructure so that we can get rid of most of the > subclasses. > Now the best way to make sure that this will happen is that some people see > it right in front of their nose. > > Did you notice for example that we were just some to attend the irc? > So how can we really communicate? > > > Stef > > > > > > > On Thu, Jan 13, 2011 at 9:15 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > 12302 > > ----- > > > > - GLMOrangeUITheme. Thanks Igor Stasenko > > > > I don't agree with this kind of changes. > > Tomorrow I want Watery2BlackTheme and GLMYellowUITHeme and what? we are > going to integrate it also? > > > > I don't understand. The change should be to create a setting to set the > color and then igor runs a script in his own image that set it to orange. Me > to yellow. And you to pink. > > > > > > - Issue 3538: Add a "Browse test" in the TestRunner failed/error list. > Thanks Benjamin van Ryseghem > > > > Stef > > > > >

Feb. 20, 2011

Re: [Pharo-project] Is there a http server that understands PUT?

by Nikolay Suslov

Hello, 2011/1/17 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > > > Swazoo certainly supports PUT, because it is used in Aida WebDAV support. > > > Is there any available source code for WebDav support to try out? Thanks, Nikolay

Feb. 20, 2011

Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)

by Schwab,Wilhelm K

Sig, You mean it doesn't work that way already?? :) It sounds good. Does the name lookup proceed by dlsym()/GetProcAddress()/etc.? The alternative would be to have a map inside the vm that would require maintenance :( The other question is how often does the lookup occur? It's probably not a concern, but it deserves at least a quick thought. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Sunday, February 20, 2011 11:42 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag) On 20 February 2011 08:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Tx > >> Hi StÃ©f, >> >> it is an initializer for the old jitter VM. > > which one? > The one that marcus worked on with Ian in 2001? > >> It is not used and simply set to zero in the Cog VMs. It is still included in sqVirtualMachine.c because that's the way that interface works (that VirtualMachine is a struct of function pointers). > > I did not get it. > the virtual machine public interface is a list of function pointers in specific order. You can't remove something from list, otherwise it will become non-compatible with older versions. Therefore you can only add new function pointers to the end of list. The problem is that plugin assuming that if VM has greater version than it was compiled once, its API is backwards compatible. I think we should move away from this binding, and use name lookup mechanism, which i implemented in Hydra. Plugin just asks VM for providing a function with given name. If there is no such function, plugin will fail to initialize and refuse to work. So, this means that pluign don't needs to be bound to VM version anymore. -- Best regards, Igor Stasenko AKA sig.

Feb. 20, 2011

Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)

by Igor Stasenko

On 20 February 2011 08:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Tx > >> Hi StÃ©f, >> >> Â Â it is an initializer for the old jitter VM. > > which one? > The one that marcus worked on with Ian in 2001? > >> Â It is not used and simply set to zero in the Cog VMs. Â It is still included in sqVirtualMachine.c because that's the way that interface works (that VirtualMachine is a struct of function pointers). > > I did not get it. > the virtual machine public interface is a list of function pointers in specific order. You can't remove something from list, otherwise it will become non-compatible with older versions. Therefore you can only add new function pointers to the end of list. The problem is that plugin assuming that if VM has greater version than it was compiled once, its API is backwards compatible. I think we should move away from this binding, and use name lookup mechanism, which i implemented in Hydra. Plugin just asks VM for providing a function with given name. If there is no such function, plugin will fail to initialize and refuse to work. So, this means that pluign don't needs to be bound to VM version anymore. -- Best regards, Igor Stasenko AKA sig.

Feb. 20, 2011

Re: [Pharo-project] about FS: a roadmap

by StÃ©phane Ducasse

> <stephane.ducasse(a)inria.fr> wrote: >> - renamed workingDirectory into workingDirectoryPath >> - added FSDiskFileSystem class>>workingDirectory >> >> - renamed working into workingDirectory. >> - deprecate working > > I think isWorkingDirectory should be renamed to isEmpty. It's only > used in this meaning anyway. > > A real isWorkingDirectory should resolve paths and check equality or > something like that, so that it works even if you give it a fully > expanded path rather than just ./ commit and merge :) Damien better commit into squeaksource/fs dans pharotaksForces. Ok now heading towards the month saint michel and before the breakfast :) > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Feb. 20, 2011

Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)

by StÃ©phane Ducasse

Tx > Hi StÃ©f, > > it is an initializer for the old jitter VM. which one? The one that marcus worked on with Ian in 2001? > It is not used and simply set to zero in the Cog VMs. It is still included in sqVirtualMachine.c because that's the way that interface works (that VirtualMachine is a struct of function pointers). I did not get it. > > On Fri, Feb 18, 2011 at 12:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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; > } > >

Feb. 20, 2011

[Pharo-project] Fwd: Need your point of view on FSPath * and others

by StÃ©phane Ducasse

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 >

Feb. 20, 2011

Re: [Pharo-project] Need your point of view on FSPath * and others

by StÃ©phane Ducasse

Here is a forward of colin's answer which I like. On Fri, Feb 18, 2011 at 2:40 PM, StÃ©phane Ducasse <stephane. ducasse(a)inria.fr> wrote: > 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. I think that in an ideal world, each selector would have a single "meaning" and all methods with the same selector would be polymorphic to each other. But we're very, very far from that world, and in practice, I don't think there's anyway a static analysis tool can rely on two methods with the same selector being polymorphic. 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. (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\/ > (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

Feb. 20, 2011

Re: [Pharo-project] Need your point of view on FSPath * and others

by StÃ©phane Ducasse

Thanks damien On Feb 20, 2011, at 12:53 AM, Damien Pollet wrote: > On Fri, Feb 18, 2011 at 23:40, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I would like to deprecated FSPath class>>* and use with: since this is the message > > Yes but what about / both class and instance side? > >> 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 > > I think those should raise exceptions in this case. FSPath is for > building paths step by step, so the argument should not contain > separators (or, it means you want a path with only one element with > separators in its name, which will probably cause problems with the > OS. But see below. > >> I saw that there is >> readFrom: aStream delimiter: aCharacter > > And this one is called by FSFilesystem >> #pathFromString: > The problem here is that only the filesystem knows which separator > makes sense. FSPath alone does not know how to parse a string, which > explains why the above methods do not check: it's not their > responsibility. So probably FSPath should know for which kind of > filesystem it's meant, or there should be platform-specific subclasses > of it. > >> (FSPath with: 'parent/child/') isRelative true >> (FSPath with: '/parent/child/') isRelative true >> (FSPath with: '') isRelative false > > Same as above and what Max said, those always create relative paths > with one step named by the string you pass, unparsed. Now we can > discuss using the empty string as a convention for the root, or a > proper null objectâ¦ > >> Now what about defining root as >> >> root >> ^ self with: '/' >> >> It would be more consistent. Now it breaks everything. So I did not do it :) > > Not really consistent, because / is a separator. Using it as the name > for the first element of a path does not make sense. FSPath root / > 'plop is not //plop :) > >> May be I'm tired after 4 ours teaching > > teaching bears, that's a concept :) > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Feb. 20, 2011