- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo scripting -- reborn as "Coral"

by StÃ©phane Ducasse

sound interesting thanks for the pointer On Feb 25, 2009, at 10:09 PM, Michael van der Gulik wrote: > > > On Thu, Feb 26, 2009 at 9:26 AM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > > please > > try it out and let me know what you would expect from a real > Smalltalk > > scripting environment. > > > Something that would really push me in using Coral is an intelligent > prompt. A list of the things the prompt should do: > - crawling into the history of typed commands using up and > down key > arrow > - tab completion (classes and method name) > - colored output > - Ctl-D to quit > - Keybinds: > * Ctlr-A beginning of the line > * Ctrl-E end of the line > * Alt- -> / Alt- <- to jump words > > > I modified REPLServer to do all of the above except for CTRL-d, > colour and Alt-word skipping. I originally made it so that I could > do stuff that breaks Morphic then still be able to use and recover > the image. > > REPLServer uses telnet but can be modified to use other input/output > mechanisms such as stdin/stdout or Display/EventSensor. > > REPLServer is loadable in Squeak 3.9, 3.10 using the Packages > Universe, or http://www.squeaksource.com/SecureSqueak (I should > really put it in its own project at some stage). Its documentation > is available as "online help" from the CLI. > > Gulik. > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 26, 2009

Re: [Pharo-project] Pharo scripting -- reborn as "Coral"

by StÃ©phane Ducasse

because you change the way the file is looked up this way we can now use vm -headless -file ljkljljkl without been forced to provide the full path but may I'm wrong since I\m doing too much stuff On Feb 25, 2009, at 5:19 PM, John M McIntosh wrote: > > On 25-Feb-09, at 4:55 AM, Oscar Nierstrasz wrote: > >> This will load everything that is required and pop up a few Workspace >> windows with further instructions. (You will need John McIntosh's >> latest VM to get this to work -- all is described in the image.) > > Well I'm curious why won't older VM's work? > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] On the toaster again

by StÃ©phane Ducasse

marcus to help hilaire what woul dbe the fall back and deprecated version so that magma works? Stef On Feb 26, 2009, at 10:54 AM, Marcus Denker wrote: > > On 26.02.2009, at 10:37, Hilaire Fernandes wrote: > >> It looks like Association>>isSpecialWriteBinding is gone in Pharo. >> Can >> someone confirm it? >> >> It hurt because it is used by Magma.. >> > > Yes. cleanup of un-used code. > > The story was that: In the SystemDictionary ("Smalltalk") there are > the > classes. Technically, Dictionaries are collections of Associations. > > Now, "Smalltalk" has globals *and* classes. Which means, we can do > > Object := nil. > > And everthing is dead. > > This is especially a problem in an ende-user scripting systems (e.g. > something > more powerful than etoys, but targeted at non-programmers). > > Sometime in the last century, someone started to work on making Squeak > more stable (or > secure for some meaning of secure). > > Now, one can fix the assignment problem in two places: > > A) name analysis of the compiler. The place where all the other > warning are generated. > B) replacing the association in the Smalltalk dictionary by one that > can not be changed. > (here "value:" raises an exception). > > The isSpecialWriteBinding was the test to check if the binging was > read=only or read/write. > Some classes where referenced using a read-only binging (those that > where very old), but > all new classes where referenced using a normal association. > > There was no code in the image that would create > ReadOnlyVariableBindings. It was never used > in this century. And: is that really at the right level, that change? > For controlling assignments, > the compiler's checking phase is much better. > > If one wants to make the structure of the sytem (the "structural > model" in the sense of structural > reflection) read-only, this does not help at all. Remember, this hack > just touches *one* place in the > object graph that starts with "Smalltalk". It does not, for example, > secure the method-dictonary. Nor > changes to the inhertance hierarchy. > > This is actually a very cool topic of research... and we are > incidentally actually working just now > on a paper that shows one cool direction of providing "read only" > views on shared object graphs like > the one that represents the structure of the system. > > Marcus > > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] Have you guys got the refactoring of saveAs:

by StÃ©phane Ducasse

I have to check On Feb 26, 2009, at 7:11 AM, Keith Hodges wrote: > Installer mantis fixBug: '5851 Refactor SmalltalkImage saveAs'. > > I need to know for InstallerScripts-#LevelPlayingFieldPreamblePharo > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

Ok I will try to get some time to integrate that this evening. Thanks mike. Stef On Feb 25, 2009, at 9:53 PM, Michael Rueger wrote: > > OK, here we go... > in the Pharo inbox there is a new version of Network-MIME and > KomHTTPServer. The Kom package should also work on Squeak. > > Seaside would need to change its use of mimeType to contentType in a > handful of places (my guess). > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

On Feb 25, 2009, at 5:59 PM, Michael Rueger wrote: > Lukas Renggli wrote: >>> what seasiders think? >>> I would be in favor to get a KOM pharo version >> >> Having two incompatible versions of Kom makes distribution even more >> painful as it is today. I would prefer to have compatible versions if >> this is possible. > > As I said, we are at or at least close to the point where we have to > make the decision which version to support. If you want to have Pharo > stay compatible with Squeak, we can just as well abandon Pharo now. > It's as simple as that. No else we would not have done pharo. The point is more how can we help people migrating to pharo. Probably having a specific Kom version. Stef > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

[Pharo-project] Guys please sign the license agreement so that

by StÃ©phane Ducasse

we do not have problem in the future... http://pharo.gforge.inria.fr/licenseDocuments/ Thanks

Feb. 26, 2009

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by StÃ©phane Ducasse

Ok dale this is probably related to the problems I see too during the lab. if you have fix open an issue in the bugtracker and post here so that we get aware of it. Stef On Feb 25, 2009, at 3:46 PM, Dale Henrichs wrote: > Okay, > > I've been able to reproduce the spurious bug that Igor was seeing > ('aContext not in process chain' error). > > It seems to be related to the fact that the OTDebugger uses an > OBFixedButtonPanel and the buttons are not getting updated correctly > (or at all), so the buttons are operating on stale contexts. The > menu items for the debugger appear to work okay - although the short > cut keys may not work - I'll look into this one:). You'll hit the > 'aContext not in process chain' as soon as you step out of the > original method context. > > The problem was introduced with pharo0.1-10243dev09.02.3 > (pharo0.1-10236dev09.02.2 doesn't have the sticky button problem). > > I also have fixes for the extra junk on the stack (for create method > and for halts/errors), but until the OBFixedButtonPanel issue gets > fixed you might want to revert to the non-ob debugger. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 26, 2009

Re: [Pharo-project] Announcements for Pharo?

by Tudor Girba

We have just ported an application that uses Announcements from VW to Pharo, and it worked out of the box (well, a minor renaming was necessary, but it is now committed) with the implementation of Lukas. Cheers, Doru On 26 Feb 2009, at 11:20, Janko MivÅ¡ek wrote: > I found Vassili's Announcements a really cool way to implement any > publish/subscribe event mechanism, because it is generally useful for > many things from events in GUI apps to those on web apps and they > can be > extended even in a distributed way (think Hydra). > > Announcements in Pharo are therefore very welcome, I'd just be careful > that they are API compatible with VisualWorks, to ease porting. > > Best regards > Janko > > Rob Rothwell pravi: >> +1 >> >> Even as a beginner, it made sense to me! >> >> Rob >> >> On Wed, Feb 25, 2009 at 8:40 PM, Miguel Enrique CobÃ¡ MartÃnez >> <m.coba.m(a)gmail.com <mailto:m.coba.m@gmail.com>> wrote: >> >> Tudor Girba wrote: >>> That would be cool, actually. I have used the implementation of >>> Lukas >>> and it works just fine. >>> >> >> + 1 >> >> I also use the Lukas' version. >> That is the version that we should use and standarize to. >> >> Miguel CobÃ¡ >> >>> Lukas pointed out that the VW Announcements code is under Cincom >>> copyright. The nice thing about his implementation is that he did >>> not >>> look at the code. He only implemented the idea as he read it from >>> the >>> blog :). >>> >>> Cheers, >>> Doru >>> >>> >>> On 26 Feb 2009, at 01:28, Michael Rueger wrote: >>> >>>> Hi all, >>>> >>>> should we add Announcements as part of the core image? >>>> And if so, which of the existing implementations? >>>> >>>> Michael > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

Feb. 26, 2009

Re: [Pharo-project] smalltalk as an interactive shell language (was Pharo scripting -- reborn as "Coral")

by Oscar Nierstrasz

Hi Alex, I am interested in using Smalltalk as a scripting language for routine tasks (to replace sh, perl, python, ruby etc.). It seems that you want to use it as an interactive shell language (to replace sh, bash, tcsh etc.). These are somewhat different goals. I am not sure if they are compatible, but it is interesting to explore. Does anyone know of any previous attempts to use Smalltalk or Smalltalk-like syntax for an interactive shell? David Lewis mentioned ExternalCommandShell as an example. Is that the state-of-the-art? - on On Feb 25, 2009, at 22:14, Alexandre Bergel wrote: > My dream is to completely get rid of bash and other awful shells. > > I remember to have seen a talk on a OO shell, where each command like > 'cat', 'ls', 'cd' where actually message sent to an instance of a > class Shell. The receiver would then be implicit. > Imagine a prompt like: > shell. > > Each command will then be a message sent to the object referenced by > the variable 'shell'. > > entering 'ls' will then invoke 'shell.ls'... > > Cheers, > Alexandre

Feb. 26, 2009