Gardening/ScriptManager

See below for Josephs answer regarding Ginsu.



-------- Original-Nachricht --------
Datum: Tue, 26 Jan 2010 11:39:19 +0100
Von: Joseph Pelrine <...>
An: Torsten Bergmann <...>
CC: ..., ...
Betreff: Re: Gardening/ScriptManager

Hi Torsten,

Torsten Bergmann wrote:
> Below a reply from Joseph. Thanks, I changed the ScriptManager project http://www.squeaksource.com/ScriptManager.html to MIT license.
> I think the mail is enough since Joseph already signed the agreement
> for Pharo (according to the ListOfOkCommitters on the wiki)!
>
> Maybe Metacello development can profit from Ginsu, dont know. Had no time
> to follow all the details at http://code.google.com/p/metacello.
I wouldn't be surprised, since Dale also worked for Digitalk, and heard
the same ideas about modularity etc. that I did.
>
> Squeak-dev is currently also discussing the need of a package management system
>  (Sake/Bob, Metacello, maybe Ginsu). Time will tell. Would be nice if there
> would be only one sharable across Squeak, Cuis and Pharo (and other Smalltalks).
I had taken Ginsu much further, and had it running over multiple
dialects with multiple back-end possibilities (I couldn't give up on
ENVY for Squeak :-)
>
> I cant remember all the details of Ginsu beside that it was working (and
> dont have a World tour image here) - it had a declarative model similar
> to Metacello. If I remember correctly Joseph used XML (simílar to Maven) instead
> of a code spec as Metacello does.
I had used code specs in Smalltalk, similar to the specs Alan Knight and
I describe in the ENVY book. Saves you needing an XML parser in the base
image. IIRC, John implemented an XML version for SWT.
>
> Joseph, regarding Ginsu it would be nice to have an MIT release too so others
> can have a look. Maybe someone can publish the last world tour image too. Thanks!
Since I haven't worked on it for a while now, I'll have to see what the
latest version I have looks like, and what I'd want to put out publicly.

Cheers
Joseph

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: ...
Web:   http://www.metaprog.com

When circumstances change, I change my views. What do you do?
- John Maynard Keynes

--
Nur noch bis 31.01.2010: DSL-Komplettpaket für 16,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl02

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Torsten, btw I did chat with Joseph a bit about helping here, so I'll devote a few hours/days to see
if we can get it off the ground again.

On 2010-01-26, at 3:59 AM, Torsten Bergmann wrote:
>> Joseph, regarding Ginsu it would be nice to have an MIT release too so others
>> can have a look. Maybe someone can publish the last world tour image too. Thanks!
> Since I haven't worked on it for a while now, I'll have to see what the
> latest version I have looks like, and what I'd want to put out publicly.
>
> Cheers
> Joseph
>



--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Two questions:

        but what will be the point to have Ginsu?
        We have the smalltalk metamodel + MC + PseudoClass and do we want one more?
        I know well Ginsu I have it on my harddisc and read it when MC was not even created and I wrote FAMIX which is a Ginsu for JavaC++Smalltalk.


For me I dream about the following:

- having ONE code metamodel (ginsu or MC) that can be used to do version management = MC versioning
but has the same static interface than the Smalltalk runtime so that he can be browsed using the SAME code browser.

To be clearer:
        why do we need two code browsers or three (pseudoClass) just browsing badly class (not talking about packages)
        can we have one browser that uses a structural API (for static class structure navigation)
        and that
                we have two kinds of objects
                        runtime class = having Structural Api + runtime API
                        offclass (MCDefinition/Ginsu Definition) = having just a Structural Api

this way we remove
        MC/Ginsu/pseudoClass => GinsuPLUS

We remove crappy browsers
        PseudoCode
        MCDefinition crappy browsers   => One browser to rule them all
        Class/SystemBrowser

So may be I'm a bit blind so tell me the vision you have, because if you need I have one or more

Stef


On Jan 26, 2010, at 8:54 PM, John M McIntosh wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

if somebody wants a version and joseph release it.
I have it.
I was always a big fan of SWT (squeak World Tour) miniimage, professional dev, clean code... does it ring the bell :)

Stef

On Jan 26, 2010, at 8:54 PM, John M McIntosh wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

Are you describing something that allows different versions to coexist in one image?  Unless that's the idea (and I'm not sure I'd want to do that??), there seems to be a role for something that can browse what an external package would do to the image.

I find MC to be surprisingly weak on support tools (help me package my code so I don't lose work, make it very easy to save many packages at one time, load a large number of packages with minimal effort), but otherwise, it does a pretty good job of showing me the code in a particular package.

What am I missing?

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Tuesday, January 26, 2010 3:28 PM
To: [hidden email]; [hidden email]
Subject: Re: [Pharo-project] Gardening/ScriptManager

Two questions:

        but what will be the point to have Ginsu?
        We have the smalltalk metamodel + MC + PseudoClass and do we want one more?
        I know well Ginsu I have it on my harddisc and read it when MC was not even created and I wrote FAMIX which is a Ginsu for JavaC++Smalltalk.


For me I dream about the following:

- having ONE code metamodel (ginsu or MC) that can be used to do version management = MC versioning but has the same static interface than the Smalltalk runtime so that he can be browsed using the SAME code browser.

To be clearer:
        why do we need two code browsers or three (pseudoClass) just browsing badly class (not talking about packages)
        can we have one browser that uses a structural API (for static class structure navigation)
        and that
                we have two kinds of objects
                        runtime class = having Structural Api + runtime API
                        offclass (MCDefinition/Ginsu Definition) = having just a Structural Api

this way we remove
        MC/Ginsu/pseudoClass => GinsuPLUS

We remove crappy browsers
        PseudoCode
        MCDefinition crappy browsers   => One browser to rule them all
        Class/SystemBrowser

So may be I'm a bit blind so tell me the vision you have, because if you need I have one or more

Stef


On Jan 26, 2010, at 8:54 PM, John M McIntosh wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jan 26, 2010, at 10:30 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> Are you describing something that allows different versions to coexist in one image?  Unless that's the idea (and I'm not sure I'd want to do that??)

Yes! At least I want that... we once described it like this:

Backward compatibility is the enemy of forward evolvability. Nevertheless, we cannot live in a world where the old is ignored.
An often overlooked property of software is that new systems can simulate the old, and the recent trends in hardware virtualization
have shown that simulation of the old is far easier than for the new to stay compatible. A snapshot of an old Windows machine can
run on a virtual machine forever, whereas keeping an operating system compatible forever is bound to fail. Programming languages
for evolving systems should provide backwards compatibility in the same way: we need a first class description of the history of all code
of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back
in time easily. The system should provide complete, runnable snapshots of itself at any point in the past.
Our work on changeboxes forms one first step towards this goal....

Oscar Nierstrasz, Marcus Denker, Tudor Gîrba, Adrian Lienhard and David Röthlisberger: “Change-Enabled Software Systems,”
Challenges for Software-Intensive Systems and New Computing Paradigms, Martin Wirsing, Jean-Pierre Banâtre and Matthias Hölzl (Eds.),
pp. 64-79, Springer-Verlag, 2008.

http://scg.unibe.ch/archive/papers/Nier08bChangeEnabledSoftware.pdf

The ChangeBoxes work is here: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Not so fast, all you have to do is sprinkle some .net dust on the computer and everything will be fixed until the next time MS changes their mind, right?

Sorry, couldn't resist.  Ironically, I find that software written to MS specs breaks readily; things written with anything up through contempt for them seems to work just fine.  I stop short of seeing a vm as allowing one to run Windows in perpetuity, but that is another debate.

I frequently want things both ways. I want the rest of the world to stand still (except when I want something fixed<g>) so I can get on with my work, and I generally expect that my code will evolve such that the most recent version is the best I know how to make.

It is unlikely that I would be brave enough to run old versions of my code in the same image with new stuff, but if you can make that work to serve all of us, have at it :)

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marcus Denker
Sent: Tuesday, January 26, 2010 4:49 PM
To: [hidden email]
Subject: Re: [Pharo-project] Gardening/ScriptManager


On Jan 26, 2010, at 10:30 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> Are you describing something that allows different versions to coexist
> in one image?  Unless that's the idea (and I'm not sure I'd want to do
> that??)

Yes! At least I want that... we once described it like this:

Backward compatibility is the enemy of forward evolvability. Nevertheless, we cannot live in a world where the old is ignored.
An often overlooked property of software is that new systems can simulate the old, and the recent trends in hardware virtualization have shown that simulation of the old is far easier than for the new to stay compatible. A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever is bound to fail. Programming languages for evolving systems should provide backwards compatibility in the same way: we need a first class description of the history of all code of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back in time easily. The system should provide complete, runnable snapshots of itself at any point in the past.
Our work on changeboxes forms one first step towards this goal....

Oscar Nierstrasz, Marcus Denker, Tudor Gîrba, Adrian Lienhard and David Röthlisberger: "Change-Enabled Software Systems,"
Challenges for Software-Intensive Systems and New Computing Paradigms, Martin Wirsing, Jean-Pierre Banâtre and Matthias Hölzl (Eds.), pp. 64-79, Springer-Verlag, 2008.

http://scg.unibe.ch/archive/papers/Nier08bChangeEnabledSoftware.pdf

The ChangeBoxes work is here: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jan 26, 2010, at 10:59 PM, Schwab,Wilhelm K wrote:

> Not so fast, all you have to do is sprinkle some .net dust on the computer and everything will be fixed until the next time MS changes their mind, right?
>
> Sorry, couldn't resist.  Ironically, I find that software written to MS specs breaks readily; things written with anything up through contempt for them seems to work just fine.  I stop short of seeing a vm as allowing one to run Windows in perpetuity, but that is another debate.
>
>

This was not about Microsoft or Windows, nor about virtualization in particular.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

With respect, please re-read your post, with emphasis on "A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever is bound to fail."  I do not agree that virtualization is fix-all goodness, and I have concerns about trying to have various versions of important classes in the image.  

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marcus Denker
Sent: Tuesday, January 26, 2010 5:10 PM
To: [hidden email]
Subject: Re: [Pharo-project] Gardening/ScriptManager


On Jan 26, 2010, at 10:59 PM, Schwab,Wilhelm K wrote:

> Not so fast, all you have to do is sprinkle some .net dust on the computer and everything will be fixed until the next time MS changes their mind, right?
>
> Sorry, couldn't resist.  Ironically, I find that software written to MS specs breaks readily; things written with anything up through contempt for them seems to work just fine.  I stop short of seeing a vm as allowing one to run Windows in perpetuity, but that is another debate.
>
>

This was not about Microsoft or Windows, nor about virtualization in particular.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef at this point I'm going to poke it with a stick and see if it lives.

Then we can dream, or at least I'll see about your dreaming.

On 2010-01-26, at 12:28 PM, Stéphane Ducasse wrote:

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

My question was also sent to torsten or other.
What is the point? and I gave one possible interpretation of future.

Stef


On Jan 27, 2010, at 1:25 AM, John M McIntosh wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes marcus
my approach was less research oriented :) and I imagine that just paying attention of interface (API) solves
my little vision.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project