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

Re: [Pharo-project] FileSystem

by Nicolas Cellier

2010/2/14 Lukas Renggli <renggli(a)gmail.com>: >> hi Colin > > I guess he missed that, so let me answer. > >> 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 > > First of all you should not hardcode the unix platform. Instead let > the system resolve the platform for you: > > Â (FSDiskFilesystem current / 'griffle') writeStream > > At the moment there is no shortcut for this on String. I think it > would make sense to add a method #asFilesystemReference that would try > to guess the right filesystem and answer a reference. So then one > could write: > > Â 'griffle' asFilesystemReference writeStream > Â 'http://www.lukas-renggli.ch' asFilesystemReference readStream > Â ... > Do we really reference the file-system or just a file ? asFileReference or asFilename (VW) would be just fine to my own taste. Nicolas >> currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] > > Â currentFolder allChildren do: [ :each | > >> Do I have to use an FSPreOrderGuide? >> Are there some behavior like doWithAllFiles already defined? > > Yes, in the enumeration protocol of FSReference. There are only a few > algorithms there, but that will probably grow over time. The > FSPreOrderGuide is an internal implementation artifact, it should not > be used directly. > > 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. 14, 2010

Re: [Pharo-project] FileSystem question

by Lukas Renggli

> Are there some examples (not tests)? Mason and Monticello 2 use it, as far as I know. > What is the difference between FSReference and FSPath? Did you read the class comments? FSPath: I an abstract filesystem path, independent of the string representation used to describe paths on a specific filesystem. I provide methods for navigating the filesystem hierarchy and working with absolute and relative paths. I only refer to a concrete file or directory with regard to a specific filesystem. FSReference: I combine a filesystem and path, which is sufficient to refer to a concrete file or directory. I provide methods for navigating my filesystem, performing filesystem operations and opening and closing files. I am the primary mechanism for working with files and directories. So most likely you are only interested in FSReference. FSPath is only used for relative paths independent of the filesystem, or path that cross or are independent of filesystem boundaries. > For example how can I print in the Transcript all the files in my current dir? FSDiskFilesystem current working children Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

Re: [Pharo-project] FileSystem

by Lukas Renggli

> hi Colin I guess he missed that, so let me answer. > 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 First of all you should not hardcode the unix platform. Instead let the system resolve the platform for you: (FSDiskFilesystem current / 'griffle') writeStream At the moment there is no shortcut for this on String. I think it would make sense to add a method #asFilesystemReference that would try to guess the right filesystem and answer a reference. So then one could write: 'griffle' asFilesystemReference writeStream 'http://www.lukas-renggli.ch' asFilesystemReference readStream ... > currentFolder doWithAllFiles: [:each | Transcript show: each name ; show: each size ; cr] currentFolder allChildren do: [ :each | > Do I have to use an FSPreOrderGuide? > Are there some behavior like doWithAllFiles already defined? Yes, in the enumeration protocol of FSReference. There are only a few algorithms there, but that will probably grow over time. The FSPreOrderGuide is an internal implementation artifact, it should not be used directly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

Re: [Pharo-project] GoferApiTest failing (WinXP)

by Lukas Renggli

On 14 February 2010 09:26, Ch Lamprecht <ch.l.ngre(a)online.de> wrote: > Lukas Renggli schrieb: >>> running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see >>> GoferApiTest>>#testSubDirectoryRepository failing. >> >> Are you sure that you use the latest Gofer code, because I think I >> fixed that a while back. >> > I just ran the tests that come with > > PharoCore-1.0-10508 > PharoCore-1.1-11196 > > using the image as it is. > > I updated to Gofer-Tests lr.115 and now I see, that #testSubDirectoryRepository > has been removed in that version... > >>> It could be fixed by changing >>> >>> MCSubDirectoryRepository>>#description >>> >>> + Â Â Â ^ directory pathName, FileDirectory slash , '*' >>> - Â Â Â ^ directory pathName, '/*' >>> >>> The current implementation works because '/' and '\' both are valid path >>> separators on windows. Assuming '/' as path delimiter would cause trouble with >>> MacFileDirectory - but that might be obsolete anyway. >>> So may be the test is too strict? >> >> I bet that breaks the tests on all platforms other than Windows. > > Why do you think so? Is 'FileDirectory slash' broken on platforms other than > Windows? All code that uses FileDirectory is full of these kind of bugs. Working with paths and file-names on the bases of strings is never really platform independent. Pharo should move on and adopt Filesystem. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

Re: [Pharo-project] GoferApiTest failing (WinXP)

by Ch Lamprecht

Lukas Renggli schrieb: >> running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see >> GoferApiTest>>#testSubDirectoryRepository failing. > > Are you sure that you use the latest Gofer code, because I think I > fixed that a while back. > I just ran the tests that come with PharoCore-1.0-10508 PharoCore-1.1-11196 using the image as it is. I updated to Gofer-Tests lr.115 and now I see, that #testSubDirectoryRepository has been removed in that version... >> It could be fixed by changing >> >> MCSubDirectoryRepository>>#description >> >> + ^ directory pathName, FileDirectory slash , '*' >> - ^ directory pathName, '/*' >> >> The current implementation works because '/' and '\' both are valid path >> separators on windows. Assuming '/' as path delimiter would cause trouble with >> MacFileDirectory - but that might be obsolete anyway. >> So may be the test is too strict? > > I bet that breaks the tests on all platforms other than Windows. Why do you think so? Is 'FileDirectory slash' broken on platforms other than Windows? Cheers, Christoph

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Marcus Denker

On Feb 14, 2010, at 6:37 AM, Igor Stasenko wrote: > On 12 February 2010 15:09, 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. >> > > I'd like to discuss, what changes to compiler we may introduce to allow FFI > to handle pragmas in non-intrusive manner. > Very simple: FFI just needs to use the pragmas as introduces in 3.9, than remove all knowledge about FFI from the Compiler. Problem solved. Isn't that beautiful? < cdecl: void 'InvalRect' ( MacRect ) module: 'InterfaceLib'> of that would be changed so that the stuff inside the <> would be a standard Smalltalk Message expression, problem solved. to illustrate... using the SMaCC grammar of the NewCompiler (a bit simplified) as extendend for Pragmas, Primitives and FFI by Mathiue Suen. A method in Squeak has Pragmas: Method: | MethodPattern Temporaries Pragmas Statements {#methodTempsPragma:}; So they are difined like this (we can have multiple ones): Pragmas: "<" PragmaMessage ">" {#pragma:} | Pragmas "<" PragmaMessage ">" {#pragmas:} So it's quite simple: there is one message expression inside... simple. But there is FFI. Primitives are there, too, but that's not really a problem: they fit in the Pragmas. primitive: 15 is a valid message in Smalltalk. (Math did the gramar for primitives to have nice error messages, but that's not needed) PragmaMessage: Apicall {#messagePragma:} | Primitive {#messagePragma:} | MessagePragma {#messagePragma:}; How Primitive and MessagePragma are done is not important. But we need Gramar rules just to be able to parse FFI: Apicall: TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> {#externalCall:} | TypeCall ExternalType IndexName "(" ParameterApicall <rightParentheses> "module:" <string> {#externalModuleCall:}; IndexName: <string> {#externalFunction:} | <number> {#externalIndex:}; TypeCall: "apicall:" {#callConvention:} | "cdecl:" {#callConvention:}; ParameterApicall: ExternalType {#parameterExtCall:} | ParameterApicall ExternalType {#parametersExtCall:}; ExternalType: <name> {#externalType:} | <name> "*" {#externalTypePointer:}; And this is *always* in the Grammar. Even when FFI is not loaded! (a nice example where our simple notion of modularity brakes down completely). No the solution here is simple: a small trivial modification to FFI to use the Evil Pragmas as introduced by the Dumb People (tm) in 3.9: < cdecl: 'void InvalRect ( MacRect )' module: 'InterfaceLib'> or *whatever*. just something that is a valid Smalltalk message expression... can't be hard, can it? Ah. And and about "notion of modularity"... of course the problem "how can I extend the language from my package without having to spread code over the parser, compiler, debugger, browser..." is intellectually an interesting one. And, oh, we are payed for finding these kind of Problems and especially solving these Problems in a way that goes beyond of just doing a pragmatic and simple solution (aka what I described here). (They call it "Academic Research". Involves mostly a programming language called TeX and can be very boring at times but it's complementary to the practical world... in a very interesting way). And int his context the result is, of course, tataaa....: Lukas' Helvetia: http://scg.unibe.ch/research/helvetia/languageboxes See? So *everything* fits together... research and non-research, problems and solutions (on multiple levels), progress in the small and the large! Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 14, 2010

Re: [Pharo-project] Pharo changing the game

by Igor Stasenko

On 13 February 2010 03:12, Eagle Offshore <eagleoffshore(a)mac.com> wrote: > I think the really tragic thing is that nothing in Smalltalk remains stable. > Hehe.. and i love smalltalk exactly because of that! Let's not forget that it is hardware, which called 'an early frozen software'. Smalltalk evolves, because IT CAN. ;) But sure, its not hard to find a stable things nowadays - see java with its 'final' stuff :) > It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. > > By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2010

Re: [Pharo-project] GoferApiTest failing (WinXP)

by Lukas Renggli

> running the tests in latest images PharoCore-1.1 and 1.0 on WinXP I see > GoferApiTest>>#testSubDirectoryRepository failing. Are you sure that you use the latest Gofer code, because I think I fixed that a while back. > It could be fixed by changing > > MCSubDirectoryRepository>>#description > > + Â Â Â ^ directory pathName, FileDirectory slash , '*' > - Â Â Â ^ directory pathName, '/*' > > The current implementation works because '/' and '\' both are valid path > separators on windows. Assuming '/' as path delimiter would cause trouble with > MacFileDirectory - but that might be obsolete anyway. > So may be the test is too strict? I bet that breaks the tests on all platforms other than Windows. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

Re: [Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Lukas Renggli

>>> 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. >> > > I'd like to discuss, what changes to compiler we may introduce to allow FFI > to handle pragmas in non-intrusive manner. > I suppose something, like registration mechanism for compiler, where > any external package can > register and provide own handler(s) for pragmas. > Then, of course, an Encoder should have a public API, which would > allow such handlers to add/change literals > and method header. > > We already having at least another use of pragmas - preferences. It's > also could use same mechanism which can > be used to notify a preferences system about appearance of new or > removal existing preferences as a result of method compilation. In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks. The idea was that you could add methods with a specific pragma to one of the compiler classes (I don't remember which one). There was also one such method for each of the Smalltalk primitives currently supported (#primitive:, 3primitive:module:, ...). When encountering a pragma in the source code the compiler would check if this was a compiler-pragma with the same name defined and perform that method. In the case of the primitive the compiler would change the compile method to use the configured primitive. A very strait forward use of pragmas. However the functionality that made compiler pragmas and primitives extensible is gone today even in Pharo. For reasons unknown to me Eliot removed all the code when he added the closure support. Back to hacking and patching the compiler. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

[Pharo-project] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Igor Stasenko

On 12 February 2010 15:09, 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. > I'd like to discuss, what changes to compiler we may introduce to allow FFI to handle pragmas in non-intrusive manner. I suppose something, like registration mechanism for compiler, where any external package can register and provide own handler(s) for pragmas. Then, of course, an Encoder should have a public API, which would allow such handlers to add/change literals and method header. We already having at least another use of pragmas - preferences. It's also could use same mechanism which can be used to notify a preferences system about appearance of new or removal existing preferences as a result of method compilation. > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2010