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

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

by StÃ©phane Ducasse

Yes Alien is the way to go. Stef On Feb 14, 2010, at 10:28 AM, Lukas Renggli wrote: >> sad sad. May be eliot was not aware of your work. >> may be we should ressurect what you did and now we do not care about the FFI maintainer :) >> We can have PharoFFI if needed. > > I don't have a problem with that. I am just saying that we've been > there and we've done that :-) > > I don't care about FFI. According to Fernando Alien seems the way to > go nowadays anyway. As far as I know it does not even depend on the > compiler. What is way better than anything else. > > 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] GoferApiTest failing (WinXP)

by StÃ©phane Ducasse

> > 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. This is the idea. Now lukas I would like to see the interface of FileSystem a bit more user friendly see the reply to our answers. I would love to use FileSystem for Coral so the api is really important for scripting.

Feb. 14, 2010

Re: [Pharo-project] FileSystem question

by StÃ©phane Ducasse

Of course I read them :) this is the first thing I do. >> Are there some examples (not tests)? > > Mason and Monticello 2 use it, as far as I know. sure Now I mean little examples in the sense of a little tutorial (see below the rio one). I will probably start to write something like that for me. >> 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. Ok so FSPath is a kind of internal representation of /usr/bin/ > >> For example how can I print in the Transcript all the files in my current dir? > > FSDiskFilesystem current working children > Instantiating and Building Paths The most concise method for creating a Rio is via: 1.below, the following are equivalent: â¢ 'myFile.txt' asRio â¢ Cwd / 'myFile.txt' â¢ Rio / 'myFile.txt' â¢ Rio new:'myFile.txt' - the verbose form Rio's may be constucted using the #/ and #, operators like so. Cwd / 'package-cache' / 'Rio-Core' , '-kph.20' , '.mcz'. Deconstructing the Rio Path and File Name Given myFile := Cwd / 'myFile.3.txt'. â¢ myFile full => '/media/hda1/squeak/myFile.3.txt' â¢ myFile fileName => 'myFile.3.txt' â¢ myFile parent => '/media/hda1/squeak' â¢ myFile base => 'myFile' â¢ myFile version => 3 â¢ myFile ext => 'txt' â¢ myFile path => ''. â¢ myFile full split => #('/' 'media' 'hda1' 'squeak' 'myFile.3.txt') Adjusting the Rio Path and File Name Given myFile := Cwd / 'myFile.3.txt'. (#parent: and #full: will set the path relative to the default directory). â¢ myFile fileName: 'another.txt' => (Rio new:'another.txt'). â¢ myFile base: 'temp' => (Rio new: 'temp.3.txt'). â¢ myFile version: 4 => (Rio new: 'myFile.4.txt'). â¢ myFile ext: 'html' => (Rio new: 'myFile.3.html'). â¢ myFile parent: 'temp' => (Rio new: 'temp/myFile.3.txt') â¢ myFile full: '/media/hda1/squeak/temp/myFile.3.txt' => (Rio new: 'temp/myFile.3.txt') File Versions Helpers If there exists a file, Cwd / 'temp.4.txt'. Then there are some utilities for obtaining the latest and next version file rio's. â¢ 'temp.txt' asRio latestVersion => (Rio new: 'temp.4.txt'). â¢ 'temp.txt' asRio nextVersion => (Rio new: 'temp.5.txt'). A Word About Style Rio may be used in two distinct styles. In addition to the traditional smalltalk cascading messages style, Rio supports a sentence like 'sequential' style. Whenever an example below uses the 'sequential' style for conciseness, suffice to say there is a traditional equivalent. sequential: 'myFile.zip' asRio zip addAll: '/tmp/files' asRio all files cascading: (Rio new: 'myFile) setModeToZip; addAll: ((Rio new:'/tmp/files') setModeToRecursive; yourself) files; yourself. Introducing Modes - 'Renaming' Mode When a Rio is #setModeToRenaming, all of the above fileName and path manipulations are simultaneously actualized on disk. Below is an example using Rio's 'sequential' style for configuring modes: â¢ myFile rename base: 'temp'. <= is equivalent to => 'myFile.3.txt' asRio renameTo: 'temp.3.txt'. When a mode is set using 'cascading' style, (e.g. #setModeToRenaming) the mode flag is set on the given instance as you would expect. In contrast, when a mode is set in sequential style, a new instance is created, making the mode setting temporary for the remainer of that 'sequential sentence'. This convention applies to all modes. e.g. â¢ cascading: (myFile setModeToRenaming; yourself) base:'temp'. â the renamng mode flag of myFile is set. â¢ sequential: myFile rename base: 'temp'. â myFile itself is untouched, the renaming mode flag is set in the myFile copy that performs #base: File Stat All of the typical stat information about files and directories is directly obtainable from a Rio. â¢ myFile fileSize â¢ myFile modificationTime returns a DateAndTime â¢ myFile creationTime returns a DateAndTime â¢ myFile isFile â¢ myFile exists â¢ myFile isDirectory Directory Queries #select:ing Internally the operating system provides the above stat data on entries of the parent directory. Rio implements many of its features by using one single function #select:. When #select: is performed upon a directory it traverses all of the directory entries collecting stat data. We can make use of this to perform a wide variety of directory queries. Given myDir := Cwd / 'package-cache': â¢ myDir files => is implemented by: myDir select: [ :stat | stat isFile ] â¢ myDir directories => is implemented by: myDir select: [ :stat | stat isDirectory ] â¢ myDir entries => is implemented by: myDir select: [ :stat | true ] â¢ Roll your own: files modified in 2007 â¢ myDir select: [ :stat | stat isFile & (stat modificationTime > '1-1-2007' asDate) ] â¢ And the rather useful: myDir filesMatching: #('*.image' '*.changes') Directory Queries On Steroids aka. 'Recursive' Mode Having explained how the world of directories, their entries and stats revolves around #select:, now is the time to announce one other little feature of #select: - it can perform its search recursively. All of the above queries become full tree searches with the addition of one little word: #recursively or #all (they are equivalent). â¢ myDir all files â¢ myDir all directories â¢ myDir all entries â¢ Rolling your own: files modified in 2007 â¢ myDir recursively select:[ :stat | stat isFile & (stat modificationTime > '1-1-2007' asDate) ] â¢ And the even more useful: myDir all filesMatching: #('*.image' '*.changes') Essential Directory Operations â¢ myDir mkdir - make a directory, raise an error if it already exists. â¢ myDir rmdir - remove a directory if it exists and is empty, otherwise raise an error. â¢ myDir ifAbsent mkdir - assure the existence of a directory â¢ myDir ifAbsent mkpath - assure the existence of a directory and its parents. â¢ myDir all delete mkpath - delete the old contents and make me a fresh temporary directory.(useful for temp directories) Reading and Writing Files - No Forcing Obtaining a stream for reading and writing files without forcing a new file is as simple as this: â¢ To Obtain a readStream: readStream := 'myFile.txt' asRio reader. â¢ To Obtain a writeStream: writeStream := 'myFile.txt. asRio writer. â¢ Lazy method for obtaining file contents: 'myFile.txt' asRio reader contents. â¢ Methods/usage idiom, which ensures that streams are correctly closed â¢ for writing: 'myFile.txt' asRio writer out: [ :writeStream | ... ]. â¢ for writing: 'myFile.txt' asRio writer: [ :writeStream | ... ]. - abbreviated form â¢ for reading: 'myFile.dat' asRio binary reader in: [ :readStream | ... ]. â¢ for reading: 'myFile.dat' asRio binary reader: [ :readStream | ... ]. - abbreviated form â¢ Convenience method for creating an empty file - 'empty' asRio touch. Reading and Writing - With Force. One small modification to the above provides the equivalent of all of the #forceNewFileNamed: calls of old. (#assureNewFile is a synonym for #delete, but communicates different intent) â¢ To 'forcefully' obtain a writeStream on a new file: 'myFile.txt' asRio assureNewFile writer â¢ 'Forcefully' writing: 'myFile.txt' asRio assureNewFile writer: [ :writeStream | ... ] Copying Files - Introducing 'Binary' Mode The basic file copying feature is implemented by a generic stream to stream copying function aPositionableStream-#copyTo:. The aim here being to eliminate many places where this, "copy from one stream to another stream via a buffer", code is duplicated. (e.g. GZReadStream-#saveContents:, GZWriteStream-compressFile: etc.) aPositionableStream-#copyTo: honours the setting of #binary mode on the input stream being copied. To make use of this Rio itself has a 'binary' mode of its own which is passed on to the streams that it uses for reading, writing and copying files. â¢ 'myFile.txt' asRio copyTo: 'yourFile.txt' â¢ 'myFile.gz' asRio binary copyTo: 'yourFile.txt.gz' Copying Files with Compression - Introducing Adaptors and 'GZip' Mode 'GZip' mode introduces a new Rio concept, Adaptors. An adaptor is an additional protocol which is added to Rio as needed for a given mode. 'GZip' mode adds an adaptor that wraps the standard file readStream, and writeStreams with GZipReadStream, and GZipWriteStream respectively. Readers and writers can now be created directly onto compressed streams via the same API (note the binary setting is also honoured by compressed streams). This has additional benefits since, with the generic #copyTo: scheme (described above) in place, the act of (de)compressing files now becomes: â¢ compressing a file: myFile binary copyTo: (MyFile + '.gz') gzip. â¢ decompressing a file: (myFile + '.gz') binary gzip copyTo: myFile â¢ reading a gzip file: 'myFile.txt.gz' asRio gzip reader contents The GZip adaptor also adds some convenience methods to Rio as part of its protocol enabling the following: â¢ compressing a file: 'myFile.dat' asRio gzip compress => 'myFile.dat.gz' â¢ decompressing a file: 'myFile.dat.gz' asRio gzip decompress => 'myFile.dat' Adding Files to an Existing Directory - The 'Dir' Adaptor The 'Dir' Adaptor adds facilities for adding files, collections of files, or whole directory trees, into an existing directory. â¢ copy a single file into a directory: myDirRio add: myFile. â¢ copy a collection of files into a directory (flat): â¢ myDirRio addAll: (myImagesDir all filesMatching: #('*.image' '*.changes')) â¢ copy a whole directory tree into a directory: myDirRio addTree: yourDirRio. â¢ copy selected files from a directory tree into a directory preserving the heirarchy â¢ myDirRio addAll: (myImagesDir all filesMatching: #('*.image' '*.changes')) fromBase: myImagesDir. Adding Files to Archives - The 'Archive' Adaptor. The 'Archive' Adaptor is a specialisation of the 'Dir' adaptor, providing the exact same interface for copying files, selections of files, and directory trees into an archive file. Selecting #zip mode, sets the 'Archive' adaptor to generate a zip archive file. The zip file is not actually written until explicitly requested via a call to #commit, or the block form #commit: â¢ copy a single file into a zip archive: 'my.zip' asRio zip add: myFile; commit. â¢ copy a collection of files into a zip archive, without preserving heirarchy, i.e. flat.: â¢ 'my.zip' asRio zip commit: [ :zip | zip addAll: (myImagesDir all filesMatching: #('*.image' '*.changes')) ] â¢ copy a whole directory tree into an archive: 'my.zip' asRio zip addTree: yourDirRio; commit. â¢ copy selected files from a directory tree into a zip archive preserving the heirarchy â¢ 'my.zip' asRio zip commit: [ :zip | zip addAll: (myImagesDir all filesMatching: #('*.image' '*.changes')) fromBase: myImagesDir ] Rio at Large Rio's may be compared for equality with other Rio's, or directly with Strings. Rios may be used in many situations where you would use Strings. For example, a Rio may be included directly in a String concatentation. Rio's may be passed into, and obtained from the #name attribute of a StandardFileStream. To help with legacy integration, Rio's may also be passed in to many of FileDirectory's standard public methods.

Feb. 14, 2010

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

by Danny Chan

Am Samstag, 13. Februar 2010 22:13:27 schrieb Torsten Bergmann: > >I have implemented some authoring capabilities in ProfStefBrowser > >to create new tutorials > > Yes, authoring capabilities would be cool to have. But first > we have to find out what the content really should be and how > it should be represented (simple text, markup, active morphs, ...) > > >Some kind of simple markup language to have for example links to other > > pages or books, or to execute code snippets with a single mouse click > > Do you know the Squeak welcome workspace? It provided something like this - > a Text could define "runs" to change style, color of text or even have > clickable links with Smalltalk code behind - dont know if this is still > possible in Pharo since parts of Morphic are removed. > On the other hand it was Squeak only - hard to create from tyical > documentation formats (text, HTML, ...) > > Maybe we could reactive code from "Scamper" (the Squeak web browser) > for simple HTML like text styling. Using a subset of HTML as description > would also allow us to publish the help contents on webpages later. > > I also remember a full webbrowser written in Smalltalk (VW). Meanwhile > it is open source (MIT), see [1] ... so lets just reactivate it ;) > > We all have many ideas (like yours with the debugger) - but first > I would like to see a minimal version for a help system: > > - provide help contents as simple ascii text (as it is now) > - ability to jump from a tool to a specific page (like F1-help on Windows) > we can use a simple unique key which is defined in HelpTopic already. > - ability to define order of pages together with order of (sub)books > > With a minimal help tool (included in the dev-image) we > can provide help to beginners and start documenting Pharo. > > As a second step we can work on better markup, authoring, active content I fully agree with this plan. So let's get the definition of the structure of help contents right, so people can start using and especially writing content quickly without having to fear that they need to restructure their content with the next release. All the presentation stuff of the actual content can be done later and does not decrease the value of the documents already written. > ... > > However - the repo is open for any contribution... Let's coordinate, I have little time and do this for fun, but I would love to help. Maybe add a document to HelpSystem with a basic vision and all the ideas for the future? > > >Now....It is not clear for me the differences between HelpSystem and > >ProfStef. > > "HelpSystem" is like a normal help system you know from Eclipse, KDE, > Windows, ... > It is more a reference/documentation kind of thing. > > "ProfStef" is an interactive tutorial usefull to teach things step by > step. I think that HelpSystem with little work can provide a superset in functionality of ProfStef. As I perceive it, the goals are different. ProfStef is to be simple, fun and small. And to accomplish this it is basically full featured and finished. HelpSystem is to be comprehensive and needs a lot of work. I was excited when I found out that the debugger is so well integrated in the work flow that debugging isn't something that distracts from coding. I would love to have something that somehow makes the experience of documentation similar to that. And that's why it is a good idea to decouple these two projects. > > >Help system is new ? > > Yes, developed yesterday. > > >should they be merged? > > Hey, we just decoupled ... why merge again ;) > Read [2] > > >when we should use one and when the other ? > > ProfStef is for an introduction (5min course) on Pharo or tools, > an interactive tutorial to introduce Smalltalk or basic concepts. > It is more "workspace" oriented. See Laurents comments. > > HelpSystem is more a general help system with a "browser" that > should be available as a base framework so tools can provide > help texts/contents to users. > > Bye > T. > > [1] > http://www.cincomsmalltalk.com/userblogs/rowanb/blogView?showComments=true > &printTitle=Im_back..._but_SWS_isnt&entry=3364012145 > > [2] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/021782. > html >

Feb. 14, 2010

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

by StÃ©phane Ducasse

Ok thanks for the historical refresh. Some people may now understand why we finally decided to do Pharo. Now let us stop ranting and think about the blue sky of the new horizon. What do we do in Pharo 1.1? :) I'm full ears open. Stef >>>> 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. > > > _______________________________________________ > 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] Making FFI non-intrusive (Was: Re: Pharo changing the game)

by Lukas Renggli

> sad sad. May be eliot was not aware of your work. > may be we should ressurect what you did and now we do not care about the FFI maintainer :) > We can have PharoFFI if needed. I don't have a problem with that. I am just saying that we've been there and we've done that :-) I don't care about FFI. According to Fernando Alien seems the way to go nowadays anyway. As far as I know it does not even depend on the compiler. What is way better than anything else. 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 StÃ©phane Ducasse

Lukas sad sad. May be eliot was not aware of your work. may be we should ressurect what you did and now we do not care about the FFI maintainer :) We can have PharoFFI if needed. Stef >> 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 > > _______________________________________________ > 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] Pharo changing the game

by StÃ©phane Ducasse

> It is not a code problem. It is a social/political problem. Right now yes: 16rff now is working in pharo as well as Squeak. The question is how much do we put on the table to make what we believe important done. In addition do you prefer an old greyish smalltalk or a new one showing interest and trying to build new stuff? I chose my camp and backward compatibility will not keep pharo in a closet or in a can http://en.wikipedia.org/wiki/Nothing_Safe:_Best_of_the_Box Now people can use VW, Dolphin or VA if they want. I would have prefer that non open source smalltalk show the way (they did partly (parcel, pragma) but I cannot run dolphin on mac or linux, VW nearly missed Seaside....). Now the question is what people do for their dreams. Pharo is not my daily work. I have to do a lot more and other tasks. I work on it every time I can and my goal is to make it cool: first class instance variable, well designed, modular.... Stef

Feb. 14, 2010

[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