- Pharo-dev - lists.pharo.org

[Pharo-project] About using toolbuilder

by stephane ducasse

I tried to use toolbuilder to open tools like the changeSorter and I always got a rather small window. So I checked in Squeak and the buildPluggableWindow method is different Should we integrate this changes? http://code.google.com/p/pharo/issues/detail?id=1963 buildPluggableWindow: aSpec | widget children label | aSpec layout == #proportional ifFalse:[ "This needs to be implemented - probably by adding a single pane and then the rest" ^self error: 'Not implemented'. ]. widget := PluggableStandardWindow new. self register: widget id: aSpec name. widget model: aSpec model. (label := aSpec label) ifNotNil:[ label isSymbol ifTrue:[widget getLabelSelector: label] ifFalse:[widget setLabel: label]]. children := aSpec children. children isSymbol ifTrue:[ widget getChildrenSelector: children. widget update: children. children := #(). ]. widget closeWindowSelector: aSpec closeAction. panes := OrderedCollection new. self buildAll: children in: widget. - aSpec extent ifNotNil:[widget extent: aSpec extent]. + self buildHelpFor: widget spec: aSpec. + widget bounds: (RealEstateAgent + initialFrameFor: widget + initialExtent: (aSpec extent ifNil:[widget initialExtent]) + world: self currentWorld). widget setUpdatablePanesFrom: panes. ^widget A related question is do we get rid of the method creation that do not rely on toolbuilder? I think that it would make sense. Stef

Feb. 14, 2010

Re: [Pharo-project] FileSystem

by Lukas Renggli

> Do we really reference the file-system or just a file ? > > asFileReference or asFilename (VW) would be just fine to my own taste. It can be a directory or filename. It does not have to exist (yet). I agree that the name is long and that there are probably better ones. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2010

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