October 2008 - Pharo-dev - lists.pharo.org

Fwd: [Pharo-project] ToolSet

by StÃ©phane Ducasse

Begin forwarded message: > From: Antony Blakey <antony.blakey(a)gmail.com> > Date: October 29, 2008 8:36:49 AM CEST > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] ToolSet > > > On 29/10/2008, at 5:55 PM, StÃ©phane Ducasse wrote: > >> With a registration in a post load phase the tool registers and the >> MENU or whatever does not have to do a >> query over the complete system. > > When I mean discovery, I don't mean that the discovery is performed > every time. Discovery is used on two occasions: > > 1. When re-initializing the system. > 2. When showing the user what methods define commands i.e. a UI for > system exploration. > > Discovery finds the methods, and then you call those methods, which > return a command, which you then 'register'. So really, it's like a > registration system but the framework is declarative rather than > programatic. > > You need the ability to listen for method redefinitions, so that you > can incrementally maintain the registration data, but even that can > be lazily batched i.e. when a method containing a 'pragma' symbol > (or pragma if you want) is redefined, you clear the registration > cache, and the next call recreates it. > > For a full command invocation system such as Commando, there are a > number of optimizations I do, such as maintaining a cache of > accelerators -> applicable commands, and context classes -> > applicable commands. I use Commando in both VW and Squeak, and there > is no delay, because everything is cached. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Human beings, who are almost unique in having the ability to learn > from the experience of others, are also remarkable for their > apparent disinclination to do so. > -- Douglas Adams > > >

Oct. 29, 2008

Re: [Pharo-project] ToolSet

by StÃ©phane Ducasse

I'm still looking for people to help cleaning the PopUpMenu plague. the idea would be to change PopUpMenu -> ToolBuilder but this is not the solution. the PopUpMenu should be converted into a Warning and lot of PopUpMenu should be removed. Now what is the answer to pavel question? On Oct 28, 2008, at 11:23 PM, Michael Rueger wrote: > Igor Stasenko wrote: > >> Sometimes you want to stub out a tools to make them inaccessible. Or >> replace them with different ones. >> For instance, one would like to redirect Transcript output to file, >> or >> suppress debugger / browser / inspector. > > The proposed solution is more a symptom fix than a real solution. > > You want to make the number of access points as small as possible, > so you have e.g. one point where to turn off the debugger. By that I > mean turning off the debugger and not trick the system by stubbing > it out. > > Same for access to Transcript. There shouldn't really be *any* > direct reference to Transcript to begin with, but rather a small but > effective logging API, e.g. Josef's toothpick. > > We Smalltalkers (I just happen to reply to Igor here, I'm including > myself in this remark too ;-) ) tend to use magic tricks just > because we can, but that doesn't mean it is good engineering. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2008

Re: [Pharo-project] ToolSet

by StÃ©phane Ducasse

Yes I was thinking about that too for building a Preference class that would not be called by the tools during their execution but that would query the pragma to get contents. Now the registration has the advantage that you load the tools and it is registered. Stef On Oct 28, 2008, at 11:42 PM, Antony Blakey wrote: > IMO discovery is a preferable model to registration, using either > pragmas or pragma-like constructs. In Commando I do this: > > createCommands > LSDCommando thisMethodReturnsAListOfCommands. > .... > > and > > commandStructureTransformers > LSDCommando thisMethodReturnsAListOfCommandTransformers. > ... > > where the thisMethod... methods are empty. To collect all the > methods that generate commands I do a senders-of-XXX-in-descendents- > of-Class-that-have-an-LSDYYY-reference search. You could do more > sophisticated filter after the search by bytecode analysis. > > One benefit of discovery is that (IMO) reuse is conceptually easier > because (in the case you are talking about in this thread) the > concept of 'being-a-command' is separated from 'in-the-world-menu'. > > Squeak has pragmas now, which people might prefer to traditional > reflection. Personally I don't. > > On 29/10/2008, at 8:49 AM, StÃ©phane Ducasse wrote: > >> I like the idea. >> What I learned curving etoy is that we need a Menu Registration for >> the world menu too. >> >> Stef >> >> On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote: >> >>> 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> Hi, >>>> >>>> we should decide how we will manipulate with tools. A lot of tools >>>> classes are referenced directly - that is wrong because you cannot >>>> then use different set of tools (for example a dummy toolset for no >>>> tools at all). >>>> In the KernelImage I added a registration mechanism for tools so >>>> they >>>> were called for example ToolSet default browser. There were no >>>> ToolSet >>>> subclasses and there was only a test if the default ToolSet is not >>>> nil. That was not optimal solution. >>>> >>>> The current philosophy of ToolSet class supposess that you will >>>> send >>>> messages directly to ToolSet class and you will not get real tools >>>> classes at all. However the set of this messages would be very long >>>> and Squeak wants sometimes directly the class (for comparison etc.) >>>> >>> >>> I think, it would be nicer, instead of use a predefined methods, >>> use a >>> dictionary in a form 'tool name'->class and DNU pattern which >>> then can respond with proper class when you send message like: >>> >>> Smalltalk tools browser >>> >>> here , a 'Smalltalk tools' should return a registry , and then >>> registry in #doesNotUnderstand: should lookup a dictionary by >>> #browser key. >>> >>> Also, if you want to add new, or replace old tool you just write: >>> >>> Smalltalk tools register: Workspace name: #workspace >>> Smalltalk tools register: Transcript name: #transcriptWindow >>> ...etc... >>> >>> as well as remove: >>> Smalltalk tools remove: #workspace >>> >>> With this approach, the number/kinds of tools is arbitrary. They can >>> be freely replaced at any moment without subclassing or writing >>> methods. >>> In vanilla image, we need only a single method, which can populate a >>> default tool set. >>> Also note, i'm not using a ToolSet class, i think 'Smalltalk >>> tools' or >>> 'SmalltalkImage tools' is much more elegant. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Some defeats are instalments to victory. > -- Jacob Riis > > >

Oct. 29, 2008

[Pharo-project] ToolSet -> ToolRegistry

by Igor Stasenko

I'm implemented a new ToolRegistry class, which can work as replacement of ToolSet. It would require a 'bit' refactoring, to replace all references to 'ToolSet' with 'Smalltalk tools'. What i discovered during implementation, if we migrate to new class, a lot of stuff can be cleaned up. For instance, Smalltalk tools inspectorTypes holds a dictionary of Class name -> inspector class name so, one could simply register own inspector by including a line: Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector in package/class initialization method, instead of overriding #inspect method. Also, during copying a StandartToolSet convenience methods implementation i discovered a lot of tools which support different protocols. It would be nice to at least make them all respond to same message, like #open. Because currently, if you take a look at different #openXXXXX methods in ToolRegistry, its using many different/weird selectors to do the simplest possible thing - open a new window! In attachments you can find the actual class, and a small changeset which is required to make magic 'Smalltalk tools' working. I decided to put default tools/inspectors types in Preferences class. See Preferences class>>registerPreferredTools method in changeset. -- Best regards, Igor Stasenko AKA sig.

Oct. 29, 2008

[Pharo-project] Squeak Carbon OS-X VM 3.8.19beta1U ships

by John M McIntosh

This VM has a number of fundamental changes and can be found via ftp or my idisk at http://www.smalltalkconsulting.com/squeak.html (a) I have changed how image files are read. Users should verify the VM still will load and work with their current images on their current systems. I have tested with macintel on 10.5.x and powerpc on 10.4.x but have NOT tested on a 10.3.x powerpc system, if some 10.3.x user could do that it would be appreciated. (b) I no longer cwd (change working directory) at startup time to the VM directory, and I added a change so if the image name is for example Squeak.image we attempt to find that in the VM directory. This change *should* enable the ablility to launch a VM and image and startup file from a command line using relative file paths, versus having to give absolute paths. Users are welcome to test and confirm this feature works as expected with relative and absolute paths for the image and startup file. Memory allocation background: In the past we have read the image file into a pre-allocated chunk of memory allocated via mmap, now I have changed to a more complicated but faster method of reading which then allows us to someday depending on your VM to avoid re-swizzling pointers for an image that is launched on a unix, windows, or iPhone since all oops should start on the 500MB boundary. What happens is we mmap the image file with copy on write mmap into a segment of memory starting at a real address of 500MB (500*1024*1024), the next virtual memory page follow the size of the file then is anonymously mmap upto the maximum memory size choosen for the implmentation. In this case we allocate 512MB of memory which is a settable option in the info.plist. Because of mmap differences between operating systems, and versions of operating systems I cannot say if this will work on your favourite device, but it does seem to work on os-x 10.4 & 10.5 for powerpc and macintel, plus on iPhone 2.x. Post loading we check to see if the memory start location is the same as the memory start location when the image was saved. If not then we adjust all oops pointers by the difference in addresses. If the saved image was at the 500MB boundary then we do not need to walk all the oops to swizzle pointers, this saves some CPU cycle and becomes important on slow devices like the iPhone, or when we want to use Squeak as a scripting engine and expect really fast startup. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 29, 2008

[Pharo-project] Re: [squeak-dev] iPhone 1.07

by John M McIntosh

I'm not sure this is accurate if I do open Squeak.app Squeakx.image Then with the carbon VM I get the VM launched which then asks me for an image via the file selection navigation services, AND I get a copy of the VM launched which opens the Squeakx.image. This is because the Squeak.app runs, then the Squeakx.image sends an open document request to the VM which then looks at the *.image and invokes some applescript to launch a copy of the VM with the *.image. This logic was developed a few years back to solve the problem of double-clicking on the a image file and it would open file browser in the running squeak.image which wasn't exactly what a person wanted. I note that saying open -a Squeak.app Squeakx.image does the right thing since it asks to open Squeakx.image with the application Squeak.app Now if I do open -a Squeak\ VM\ Opt.app Squeakx.image test.st then that starts the application, opens the image, and then opens the test.st in a file edit browser, well not what we want either. In looking at the issue for historical reasons I've done a cwd to the VM path when the app starts. If I remove that ./Development/Squeak.app/Contents/MacOS/Squeak\ VM\ Opt ./Development/ Squeakx.image test.st Well that works as desired, now I wonder about side-effects... Ok well it won't open the Squeak.image that is found in the same directory as the Squeak.app if you launch from the Dock because the cwd isn't done and I'd guess cwd points to '/' So let me add a change to check for no '.' or '/' on the image name means look in VM directory, so the default Squeak.image turns into a search for /Application/ Squeak.image if Squeak.app is in /Application/ Yes that works. Ok I'll push out a 3.8.19beta1U for testing On Oct 28, 2008, at 10:08 AM, Eliot Miranda wrote: > > > On Tue, Oct 28, 2008 at 12:10 AM, stephane ducasse <stephane.ducasse(a)free.fr > > wrote: > Thanks john > > BTW I have a request for the mac VM > > Since I would like to use Squeak as a scripting language I would > really like to be able to do > squeak image file > right now I have to pass the full pathname of image and file. > Would it be possible to get that? > > I think the answer for the VM application is no because Mac OS X > opens applications in /. > So the VM cannot find the image unless given a full pathname and > cannot find file unless given a full pathname either since the image > won't be in the same directory as the image file. > > But it is trivial to write a shell script to wrapper the VM that > supplies the full pathnames, e.g. > > ----8<---squeak---8<--- > #!/bin/sh > open /Applications/SqueakFoo.app /Applications/SqueakFoo.app/ > Resources/Scripting.image "`pwd`/$1" > ----8<---squeak---8<--- > > and then have Scripting.image change its working directory to that > of the file argument, not the image. > > > I currently run from the command line using the attached > CommandLineLauncher via e.g. > > ../stackvm/macbuild/Qwaq\ VM.app/Contents/MacOS/Qwaq\ VM ~/Qwaq/Cog/ > Benchmarks/stck-1.2.21.image -doit "UnixProcess stdOut nextPutAll: > 'Hello world!'; nl" > Hello world! > > > > > Thanks > > Stef > > > On Oct 28, 2008, at 1:08 AM, John M McIntosh wrote: > > I've push out an iPhone 1.07 VM. http://www.smalltalkconsulting.com/squeak.html > > This VM uses the latest core Pharo image. > > The VM has a number of changes to enable C data structure support > and code examples for > putting up a UITextEdit and UITextView for single and multiple line > textual input, along with > the ability to execute objective-c methods on the main thread versus > the squeak thread. > There is of course a new ObjectiveCPlugin for os-x users. > > For developers the key to getting a UITextEdit field to work is that > you *must* create the UITextEdit > thread on the main thread, otherwise if you create the object on the > squeak thread, then attempt to > use it for textual input on the main thread as per recommendations > it deadlocks on a semaphore when it > decides that the two process threads are different. > > Still to do is finishing the Keyboard entry logic, (oh I'm sure just > a few minutes should do it...). Then > I'll see if I can get a Menu control example working > > I've not included the VNC logic since I don't know if anyone uses > it, or if it can be integrated into the > Pharo image at this time, however I suspect someone will let me know. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > > > > <CommandLineLauncher.st> -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Antony Blakey

IMO discovery is a preferable model to registration, using either pragmas or pragma-like constructs. In Commando I do this: createCommands LSDCommando thisMethodReturnsAListOfCommands. .... and commandStructureTransformers LSDCommando thisMethodReturnsAListOfCommandTransformers. ... where the thisMethod... methods are empty. To collect all the methods that generate commands I do a senders-of-XXX-in-descendents-of-Class- that-have-an-LSDYYY-reference search. You could do more sophisticated filter after the search by bytecode analysis. One benefit of discovery is that (IMO) reuse is conceptually easier because (in the case you are talking about in this thread) the concept of 'being-a-command' is separated from 'in-the-world-menu'. Squeak has pragmas now, which people might prefer to traditional reflection. Personally I don't. On 29/10/2008, at 8:49 AM, StÃ©phane Ducasse wrote: > I like the idea. > What I learned curving etoy is that we need a Menu Registration for > the world menu too. > > Stef > > On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote: > >> 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Hi, >>> >>> we should decide how we will manipulate with tools. A lot of tools >>> classes are referenced directly - that is wrong because you cannot >>> then use different set of tools (for example a dummy toolset for no >>> tools at all). >>> In the KernelImage I added a registration mechanism for tools so >>> they >>> were called for example ToolSet default browser. There were no >>> ToolSet >>> subclasses and there was only a test if the default ToolSet is not >>> nil. That was not optimal solution. >>> >>> The current philosophy of ToolSet class supposess that you will send >>> messages directly to ToolSet class and you will not get real tools >>> classes at all. However the set of this messages would be very long >>> and Squeak wants sometimes directly the class (for comparison etc.) >>> >> >> I think, it would be nicer, instead of use a predefined methods, >> use a >> dictionary in a form 'tool name'->class and DNU pattern which >> then can respond with proper class when you send message like: >> >> Smalltalk tools browser >> >> here , a 'Smalltalk tools' should return a registry , and then >> registry in #doesNotUnderstand: should lookup a dictionary by >> #browser key. >> >> Also, if you want to add new, or replace old tool you just write: >> >> Smalltalk tools register: Workspace name: #workspace >> Smalltalk tools register: Transcript name: #transcriptWindow >> ...etc... >> >> as well as remove: >> Smalltalk tools remove: #workspace >> >> With this approach, the number/kinds of tools is arbitrary. They can >> be freely replaced at any moment without subclassing or writing >> methods. >> In vanilla image, we need only a single method, which can populate a >> default tool set. >> Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' >> or >> 'SmalltalkImage tools' is much more elegant. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by Michael Rueger

Igor Stasenko wrote: > Sometimes you want to stub out a tools to make them inaccessible. Or > replace them with different ones. > For instance, one would like to redirect Transcript output to file, or > suppress debugger / browser / inspector. The proposed solution is more a symptom fix than a real solution. You want to make the number of access points as small as possible, so you have e.g. one point where to turn off the debugger. By that I mean turning off the debugger and not trick the system by stubbing it out. Same for access to Transcript. There shouldn't really be *any* direct reference to Transcript to begin with, but rather a small but effective logging API, e.g. Josef's toothpick. We Smalltalkers (I just happen to reply to Igor here, I'm including myself in this remark too ;-) ) tend to use magic tricks just because we can, but that doesn't mean it is good engineering. Michael

Oct. 28, 2008

Re: [Pharo-project] ToolSet

by StÃ©phane Ducasse

I like the idea. What I learned curving etoy is that we need a Menu Registration for the world menu too. Stef On Oct 28, 2008, at 8:26 PM, Igor Stasenko wrote: > 2008/10/28 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Hi, >> >> we should decide how we will manipulate with tools. A lot of tools >> classes are referenced directly - that is wrong because you cannot >> then use different set of tools (for example a dummy toolset for no >> tools at all). >> In the KernelImage I added a registration mechanism for tools so they >> were called for example ToolSet default browser. There were no >> ToolSet >> subclasses and there was only a test if the default ToolSet is not >> nil. That was not optimal solution. >> >> The current philosophy of ToolSet class supposess that you will send >> messages directly to ToolSet class and you will not get real tools >> classes at all. However the set of this messages would be very long >> and Squeak wants sometimes directly the class (for comparison etc.) >> > > I think, it would be nicer, instead of use a predefined methods, use a > dictionary in a form 'tool name'->class and DNU pattern which > then can respond with proper class when you send message like: > > Smalltalk tools browser > > here , a 'Smalltalk tools' should return a registry , and then > registry in #doesNotUnderstand: should lookup a dictionary by > #browser key. > > Also, if you want to add new, or replace old tool you just write: > > Smalltalk tools register: Workspace name: #workspace > Smalltalk tools register: Transcript name: #transcriptWindow > ...etc... > > as well as remove: > Smalltalk tools remove: #workspace > > With this approach, the number/kinds of tools is arbitrary. They can > be freely replaced at any moment without subclassing or writing > methods. > In vanilla image, we need only a single method, which can populate a > default tool set. > Also note, i'm not using a ToolSet class, i think 'Smalltalk tools' or > 'SmalltalkImage tools' is much more elegant. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2008

Re: [Pharo-project] problem with update 10120 ?

by Adrian Lienhard

thanks, it works. Adrian On Oct 28, 2008, at 22:10 , StÃ©phane Ducasse wrote: > I redid an update > > Stef > > >> Thanks. >> We got some problems with the network and I could not check. >> I removed the problem for the moment. >> Lukas the Type removal does not work :) >> I will commit the etoy removal I did. >> >> Stef >> >> On Oct 28, 2008, at 8:48 PM, Damien Pollet wrote: >> >>> I'm getting this when I update from 10118: >>> This package depends on the following classes: >>> AnObsoleteSymbolListType >>> AnObsoleteDataType >>> You must resolve these dependencies before you will be able to load >>> these definitions: >>> FullVocabulary >>> PlayerType >>> ScriptNameType >>> UserCustomEventNameType >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 28, 2008