March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Antony Blakey

On 18/03/2009, at 11:43 PM, Schwab,Wilhelm K wrote: > I should raise one flag about the email you forwarded: I smell a > troll. http://linkuistics.com/?page_id=56 http://www.cincomsmalltalk.com/userblogs/antony/blogView > Actually, it might not be a troll so much as someone who has bought > into the idea that external components are a panacea. In my > experience, there are some external libraries that are extremely > helpful, but most are simply trash. The more "cool" the interface > technology, the worse the software. Many C-callable libraries seem > to do what the advertise; most are incomplete junk. I am sad to > report that the vast majority of COM components are buggy non-sense > with all manner of undocumented dependencies between the various > methods. I will also freely admit that Dolphin's ability to dip > into that pool of slime has saved my skin several times. There are many good Java libraries, which is what I was talking about, but in any case you need to see the email that I was responding to. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre

March 18, 2009

Re: [Pharo-project] Condense Changes error

by John Toohey

Thanks, I think I understand it now. Is the limit on the size of the file a limit in the VM or in the images? On Wed, Mar 18, 2009 at 09:18, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Here is a description: http://wiki.squeak.org/squeak/5806 > > If its unclear or you have further questions, please just ask again. > > Adrian > > On Mar 18, 2009, at 14:16 , John Toohey wrote: > >> Will try this to-day with latest Pharo images and the latest Seaside >> build. Can anyone explain Â to me the issue with my source code being >> changes, when I removed the changeset file? I don't understand the >> connection between the source code in the image and the commands in >> the changeset file. >> >> >> On Wed, Mar 18, 2009 at 09:09, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> Hi John, >>> >>> It seems you are already using a future version ;) >>> >>> I took the Pharo core 10248 image that is available online, updated >>> to >>> the most recent version, 10252, and did a condenseChanges. It >>> completed without problems and the sources seem consistent >>> afterwards. >>> >>> You can find out the version you are using from the world menu -> >>> System... -> About. >>> >>> I suggest to store your code with Monticello and start from a fresh >>> image. >>> >>> Cheers, >>> Adrian >>> >>> On Mar 18, 2009, at 09:45 , StÃ©phane Ducasse wrote: >>> >>>> can you try with the latest image since the condenseChanges got >>>> fixed. >>>> >>>> Stef >>>> >>>> On Mar 17, 2009, at 10:00 PM, John Toohey wrote: >>>> >>>>> The name of my image file is Pharo0.1Core-10225.image. Smalltalk >>>>> version gives me Â 'Pharo0.1' >>>>> >>>>> >>>>> >>>>> On Tue, Mar 17, 2009 at 16:47, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> Hi john >>>>>> >>>>>> can you tell us your image update exactly since the latest I'm >>>>>> aware >>>>>> of is 10252. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Mar 17, 2009, at 9:07 PM, John Toohey wrote: >>>>>> >>>>>>> When I run condenseChange on my Phao image (10255), it stops >>>>>>> after >>>>>>> about 95% with a 'syntax error' message. Closing the message does >>>>>>> nothing and the process seems stopped. If I delete the changes >>>>>>> file, >>>>>>> the image is okay, but the parameter names of all my methods has >>>>>>> been >>>>>>> changes to t1, eg, renderContentOn: html becomes renderContentOn: >>>>>>> t1 >>>>>>> etc. >>>>>>> >>>>>>> I can't make any more changes, and need to know how to repair the >>>>>>> changes file, or just get rid of it without it changes my source >>>>>>> code. >>>>>>> -- >>>>>>> -JT >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -JT >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> -JT >> >> _______________________________________________ >> 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 > -- -JT

March 18, 2009

Re: [Pharo-project] Condense Changes error

by Adrian Lienhard

Here is a description: http://wiki.squeak.org/squeak/5806 If its unclear or you have further questions, please just ask again. Adrian On Mar 18, 2009, at 14:16 , John Toohey wrote: > Will try this to-day with latest Pharo images and the latest Seaside > build. Can anyone explain to me the issue with my source code being > changes, when I removed the changeset file? I don't understand the > connection between the source code in the image and the commands in > the changeset file. > > > On Wed, Mar 18, 2009 at 09:09, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Hi John, >> >> It seems you are already using a future version ;) >> >> I took the Pharo core 10248 image that is available online, updated >> to >> the most recent version, 10252, and did a condenseChanges. It >> completed without problems and the sources seem consistent >> afterwards. >> >> You can find out the version you are using from the world menu -> >> System... -> About. >> >> I suggest to store your code with Monticello and start from a fresh >> image. >> >> Cheers, >> Adrian >> >> On Mar 18, 2009, at 09:45 , StÃ©phane Ducasse wrote: >> >>> can you try with the latest image since the condenseChanges got >>> fixed. >>> >>> Stef >>> >>> On Mar 17, 2009, at 10:00 PM, John Toohey wrote: >>> >>>> The name of my image file is Pharo0.1Core-10225.image. Smalltalk >>>> version gives me 'Pharo0.1' >>>> >>>> >>>> >>>> On Tue, Mar 17, 2009 at 16:47, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> Hi john >>>>> >>>>> can you tell us your image update exactly since the latest I'm >>>>> aware >>>>> of is 10252. >>>>> >>>>> Thanks >>>>> >>>>> On Mar 17, 2009, at 9:07 PM, John Toohey wrote: >>>>> >>>>>> When I run condenseChange on my Phao image (10255), it stops >>>>>> after >>>>>> about 95% with a 'syntax error' message. Closing the message does >>>>>> nothing and the process seems stopped. If I delete the changes >>>>>> file, >>>>>> the image is okay, but the parameter names of all my methods has >>>>>> been >>>>>> changes to t1, eg, renderContentOn: html becomes renderContentOn: >>>>>> t1 >>>>>> etc. >>>>>> >>>>>> I can't make any more changes, and need to know how to repair the >>>>>> changes file, or just get rid of it without it changes my source >>>>>> code. >>>>>> -- >>>>>> -JT >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> -JT >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > -JT > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 18, 2009

Re: [Pharo-project] Condense Changes error

by John Toohey

Will try this to-day with latest Pharo images and the latest Seaside build. Can anyone explain to me the issue with my source code being changes, when I removed the changeset file? I don't understand the connection between the source code in the image and the commands in the changeset file. On Wed, Mar 18, 2009 at 09:09, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi John, > > It seems you are already using a future version ;) > > I took the Pharo core 10248 image that is available online, updated to > the most recent version, 10252, and did a condenseChanges. It > completed without problems and the sources seem consistent afterwards. > > You can find out the version you are using from the world menu -> > System... -> About. > > I suggest to store your code with Monticello and start from a fresh > image. > > Cheers, > Adrian > > On Mar 18, 2009, at 09:45 , StÃ©phane Ducasse wrote: > >> can you try with the latest image since the condenseChanges got fixed. >> >> Stef >> >> On Mar 17, 2009, at 10:00 PM, John Toohey wrote: >> >>> The name of my image file is Pharo0.1Core-10225.image. Smalltalk >>> version gives me Â 'Pharo0.1' >>> >>> >>> >>> On Tue, Mar 17, 2009 at 16:47, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Hi john >>>> >>>> can you tell us your image update exactly since the latest I'm aware >>>> of is 10252. >>>> >>>> Thanks >>>> >>>> On Mar 17, 2009, at 9:07 PM, John Toohey wrote: >>>> >>>>> When I run condenseChange on my Phao image (10255), it stops after >>>>> about 95% with a 'syntax error' message. Closing the message does >>>>> nothing and the process seems stopped. If I delete the changes >>>>> file, >>>>> the image is okay, but the parameter names of all my methods has >>>>> been >>>>> changes to t1, eg, renderContentOn: html becomes renderContentOn: >>>>> t1 >>>>> etc. >>>>> >>>>> I can't make any more changes, and need to know how to repair the >>>>> changes file, or just get rid of it without it changes my source >>>>> code. >>>>> -- >>>>> -JT >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> -JT >>> >>> _______________________________________________ >>> 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 > -- -JT

March 18, 2009

Re: [Pharo-project] Pharo Custom Menus

by Adrian Lienhard

Yes, that would be cool. Much more useful than the custom menu editing since you can store your own menu items in code (rather than as objects in the image). Adrian On Mar 18, 2009, at 14:04 , Lukas Renggli wrote: >> I never found custom menu items useful because they can't easily be >> moved between images. Since I often start over from a fresh image >> adding custom entries to the menu makes no sense. If a lot of people >> really need this feature, we can put it back. > > What would be cool is a more convenient menu registration mechanism > that gives control over where, when and how a menu item is displayed. > I guess method annotations would be a nice solution again. > > Like this a tool such as "Seaside 2.9 Control Panel" [1] could appear > slightly more prominent than it does today. The menu item is currently > nested within a sub-sub-menu and that is far from optimal. When people > load this extension package, they very likely would also be able to > open this tool conveniently. > > Furthermore such an approach would solve the problem of Rob and > Mariano cleanly. They could just bundle their scripts in a special > package and register them to appear in a custom sub-menu. > > Cheers, > 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

March 18, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Schwab,Wilhelm K

Stef, First a general note: various people have contacted me about the format of my email messages. I share your irritation at the illeffects of decisions beyond my control. First they foisted Group(Un)wise on us, and now LookOut! has the job. I could use a different account, but that causes problems of its own. Anyway, the length of this lead me to try a suggestion that came my way recently: ditch Word as LookOut!'s editor. I swear I tried that early on and did away with it due to something not working correctly (surely not); we'll see. Back to our regularly scheduled program... Perhaps just my ignorance showing, I see two problematic sides to concurrency. The first is a big deal: getting an image to use multiple processors. The second involves calls to external libraries, where we need to be able to ensure that Pharo is not brought to its knees by a library that blocks for a long time. A final piece of the puzzle is multiple Process instances, but the troublesome aspects of that (I think) fall into the first two categories. In terms of multiple processors/cores, I have no brilliant answers. Andreas floated an idea that made a lot of sense to me. I do not recall the details, but it struck me as being a lot like having multiple system dictionaries to compartmentalize the object memory, simultaneously providing a natural decomposition of the image for the GC. If his idea is nonsense, he fooled me :) External libraries demand an easy way to use OS threads. Dolphin provides "overlapped calls" that block the calling Process but not the entire image. The usual caveats of thread safety apply, but "any" function can be so marked and will be called on separate OS thread. IIRC, they have enhanced the mechanism to lazily choose an OS thread per Process, and to use the thread for all future overlapped calls on that Process. They started out with a thread pool with no memory, but many libraries have thread affinities that can cause problems in the that case. As an example, OpenSSL stores error information in thread local storage, and one obtains it by a separate function call on the same thread. At the time that I wrote my interface for Dolphin, I ended up making a DLL that put a faÃ§ade around the various functions of interest (there were only a few) to make the call and then check for error data as one atomic operation. Then Dolphin could changes threads on me at will, and all was fine. That hack might not be necessary in the current and future versions of Dolphin. I should raise one flag about the email you forwarded: I smell a troll. Actually, it might not be a troll so much as someone who has bought into the idea that external components are a panacea. In my experience, there are some external libraries that are extremely helpful, but most are simply trash. The more "cool" the interface technology, the worse the software. Many C-callable libraries seem to do what the advertise; most are incomplete junk. I am sad to report that the vast majority of COM components are buggy non-sense with all manner of undocumented dependencies between the various methods. I will also freely admit that Dolphin's ability to dip into that pool of slime has saved my skin several times. At a minimum, I think we should provide an answer to Dolphin's overlapped calls. The rest can come as inspiration strikes regarding how to do things properly. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, March 18, 2009 4:17 AM To: Pharo Development Subject: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? Hi all I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great. Stef Begin forwarded message: > From: Antony Blakey <antony.blakey(a)internode.on.net> > Date: March 18, 2009 2:50:47 AM CEST > To: dfinlayson(a)usgs.gov, VWNC NC <vwnc(a)cs.uiuc.edu> > Subject: Re: [vwnc] Would you start a new Smalltalk project today? > > I am a commercial user of VW. > > I've recently replaced my VW/GLORP/Postgresql app with one built in > Ruby/CouchDB. I moved to Ruby because the documentation/learning > material is superior to VW, because of the number of third party > components, which is partly an issue of VW not being Open Source, > because of tools such as Rails, Sinatra and Merb (which I still prefer > over Seaside), and because I needed to focus on sustainable technology > transfer into a market that won't accept VW. Tangentially I wanted to > (subjectively) quantify the productivity improvement due to Smalltalk > relative to another dynamic language (as opposed to Java in Eclipse). > > My experience with Ruby is that the language itself is just too much > of a hack, and this was especially brought home to me when I started > doing Scala and Clojure, and that emphasized for me the beauty of > Smalltalk and Lisp/Scheme. > > I'm going back to Smalltak for new commercial development, partly > because of this, but also because a) the Squeak community is getting a > real injection of energy with Cog and Pharo (which itself pushes > Squeak) and b) I'm getting a good feeling about the way the Cincom > team is changing VW - not only what they're doing, but there seems to > be a much clearer vision and approach that when I first encountered > it. > > I'm also building a commercial application in Scala and Clojure. Both > are great languages, especially for highly concurrent apps, and the > library support is huge because they seamlessly use Java. If this were > the "good old days"(TM) I'm sure someone would be working on decent > concurrency support for Smalltalk. Using multiple images is one > approach, but not one that I like - it seems (IMHO) to be a reaction > to the lack of resources to do something better. Most of the Erlang/ > Scala/Clojure goodness could be layered into Smalltalk if someone had > the will to do so, but I think Cincom would have to do that for it to > get the wide support it would need to have a dependable future. > > One benefit that a JVM language has, as opposed to Smalltalk, is that > both the underlying performance improves, and the available libraries > increase and improve independently of the language. Clojure and Scala > don't need effort per se to improve. Oh for a Smalltalk running on the > JVM in a high performance manner, with JVM object model integration. I > think there is no other way to solve this problem for Smalltalk. > > I really miss programming in an image despite the pain of the Object/ > Subject problem. I don't think it's *always* more productive than > Scala or Clojure (esp for concurrency) but it's more *consistently* > productive. > > Smalltalk's decline has not been terminal, implementations are > improving albeit more slowly than one would like, and as long as it's > the right tool for the job then you should use it. > > On 18/03/2009, at 8:03 AM, David Finlayson wrote: > >> Clojure has some great ideas but you need to know Lisp and Emacs. > > Both Scala and Clojure have good and improving support in (to varying > degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM > required. I use Clojure and Scala in IntelliJ, and I've done so in > Eclipse as well. > >> 2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, >> down the road Pharo may be good, but not today and VW looks like it >> hasn't been updated since the NT days. Although everyone hates Java >> cross-platform desktop apps, it is interesting to compare a VW app >> (say Bottom Feeder) to a Java app of similar design >> (http://www.rssowl.org/overview) In my opinion the Java version fits >> in a lot better than the VW version (particularly on the Mac). > > For VW, my LinkuisticsUI bundle in the public Store improves the > situation somewhat on OSX for VW 7.6. Cincom are also making > improvements to the OSX UI for 7.7. > > Closure and Scala have Swing integration. Scala has very good SWT > bindings. All three IDEs have GUI builders. > > Maybe you should consider a Web UI - checkout tools such as Capuccino > and efforts like bespin. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > A reasonable man adapts himself to suit his environment. An > unreasonable man persists in attempting to adapt his environment to > suit himself. Therefore, all progress depends on the unreasonable man. > -- George Bernard Shaw > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 18, 2009

Re: [Pharo-project] Condense Changes error

by Adrian Lienhard

Hi John, It seems you are already using a future version ;) I took the Pharo core 10248 image that is available online, updated to the most recent version, 10252, and did a condenseChanges. It completed without problems and the sources seem consistent afterwards. You can find out the version you are using from the world menu -> System... -> About. I suggest to store your code with Monticello and start from a fresh image. Cheers, Adrian On Mar 18, 2009, at 09:45 , StÃ©phane Ducasse wrote: > can you try with the latest image since the condenseChanges got fixed. > > Stef > > On Mar 17, 2009, at 10:00 PM, John Toohey wrote: > >> The name of my image file is Pharo0.1Core-10225.image. Smalltalk >> version gives me 'Pharo0.1' >> >> >> >> On Tue, Mar 17, 2009 at 16:47, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi john >>> >>> can you tell us your image update exactly since the latest I'm aware >>> of is 10252. >>> >>> Thanks >>> >>> On Mar 17, 2009, at 9:07 PM, John Toohey wrote: >>> >>>> When I run condenseChange on my Phao image (10255), it stops after >>>> about 95% with a 'syntax error' message. Closing the message does >>>> nothing and the process seems stopped. If I delete the changes >>>> file, >>>> the image is okay, but the parameter names of all my methods has >>>> been >>>> changes to t1, eg, renderContentOn: html becomes renderContentOn: >>>> t1 >>>> etc. >>>> >>>> I can't make any more changes, and need to know how to repair the >>>> changes file, or just get rid of it without it changes my source >>>> code. >>>> -- >>>> -JT >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> -JT >> >> _______________________________________________ >> 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

March 18, 2009

Re: [Pharo-project] Condense Changes error

by Damien Cassou

On Wed, Mar 18, 2009 at 2:04 PM, John Toohey <johnptoohey(a)gmail.com> wrote: > I had other issues getting Seaside 2.9 working with the latest images, > the 10225 was the last one that worked for me. Is there anything else > that I can do to turn of the change file or create a new one? Seaside should now work on all recent images. -- Damien Cassou http://damiencassou.seasidehosting.st

March 18, 2009

Re: [Pharo-project] Pharo Custom Menus

by Lukas Renggli

And here is the missing reference of the famous but lost in a deep menu tree "Seaside Control Panel": [1] http://blog.fitzell.ca/2009/03/seaside-server-adaptors.html On Wed, Mar 18, 2009 at 2:04 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> I never found custom menu items useful because they can't easily be >> moved between images. Since I often start over from a fresh image >> adding custom entries to the menu makes no sense. If a lot of people >> really need this feature, we can put it back. > > What would be cool is a more convenient menu registration mechanism > that gives control over where, when and how a menu item is displayed. > I guess method annotations would be a nice solution again. > > Like this a tool such as "Seaside 2.9 Control Panel" [1] could appear > slightly more prominent than it does today. The menu item is currently > nested within a sub-sub-menu and that is far from optimal. When people > load this extension package, they very likely would also be able to > open this tool conveniently. > > Furthermore such an approach would solve the problem of Rob and > Mariano cleanly. They could just bundle their scripts in a special > package and register them to appear in a custom sub-menu. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

March 18, 2009

Re: [Pharo-project] Pharo Custom Menus

by Lukas Renggli

> I never found custom menu items useful because they can't easily be > moved between images. Since I often start over from a fresh image > adding custom entries to the menu makes no sense. If a lot of people > really need this feature, we can put it back. What would be cool is a more convenient menu registration mechanism that gives control over where, when and how a menu item is displayed. I guess method annotations would be a nice solution again. Like this a tool such as "Seaside 2.9 Control Panel" [1] could appear slightly more prominent than it does today. The menu item is currently nested within a sub-sub-menu and that is far from optimal. When people load this extension package, they very likely would also be able to open this tool conveniently. Furthermore such an approach would solve the problem of Rob and Mariano cleanly. They could just bundle their scripts in a special package and register them to appear in a custom sub-menu. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 18, 2009