[Glass] Metacello ... is there something easy with it ?

Fri Jun 6 10:23:11 PDT 2014

Did you use Squeak or Pharo - which version? I mentioned the GemTools image
specifically because I am pretty certain that the infrastructure hasn't
changed out from under the original tutorial.

The tutorial that I expected you to use is browser based and you select the
lesson1 method and perform doits ... there are Metacello tests that are
supposed to ensure that the expressions in the lessons will run without
errors ... I guess I neglected to add a test for "copy class" to my
tutorial ... I also built a tutorial based on the Pharo Help Browser ... to
my knowledge noone has ever used it and in the more recent versions of
Pharo, I'm not even certain it works anymore ...

Frankly, the arc of my major open source smalltalk projects: Metacello,
FileTree, git, github, tODE are all aimed at trying to address these types
of issues ...

Before Metacello it was not possible to load a project without sending
email to the developer and asking them in what order the packages should be
loaded and which other projects the packages depended upon, followed by
another email to another developer on another mailing list...

Before FileTree it was not possible to store/share smalltalk code on disk.

Once you can store/share smalltalk on disk you can use git. When you use
git, you can store other artifacts like documentation, scripts, images,
etc.

When you store code and documentation together, the code and documentation
can be updated together.

When you use git you can use github where you can easily share your code
with other users and it is PRACTICAL for large numbers of developers to
contribute to the project ...

When you use git, the job of Metacello is greatly simplified. I equate
Monticello packages to RCS (where you can only manage the versions for a
single file). I equate Metacello (without git) to CVS, where you manage
collections of files using an external database ... your ConfiguratioOf...
is a data base of versions where the specific package versions are
associated together in a single version... with git it no longer becomes
necessary to manage the collection of files from within Metacello ... git
does that for you as well as a lot more ...

With git you only need to define a Metacello baseline: specification of
package and project dependencies only...a much simpler job and much simpler
to document.

When you use git, you have to have git integrated into the development
environment ...

Before tODE you had to do all of your git manipulation from a separate
shell window ...

So until I can get tODE out the door, I can't ask people to use git for
their new projects. When tODE goes out the door, I can focus my efforts on
shoring up the other pieces of the infrastructure ... WHICH WILL BE BUILT
ON GIT AND GITHUB...

I released Metacello in 2009 so I've been on a 5 year crusade ... so at the
end of the day, I would say that I felt your anger and frustration 5 years
ago and have been working hard to solve the problems as they come up ...

I've just create the ServiceVM project on github[1]...it is still very raw
as I have simply cobbled together the pieces of the project and brought
them together in one spot:

  1. documentation from google[2] into the ServiceVM project readme[3].
  2. scripts from here[4] and here[5] into the ServiceVM bin directory[6].
  3. copied 4 monticello packages ([7], [8], [9], [10]) from two different
      monticello repositories into the project repository[11]
  4. pulled in the tODE scripts that I've been using to work with the
      servicevm into the tode directory[12].
  5. if you look at the end of adaptors script[13] you will see that there
is
      a man page included in the script documenting the script api. There
      will be a couple more scripts before I am done ...
  6. this is only the start ... I expect to include an install shell script
that
      will put the shell scripts in the right spot...and that install
script
      will be initiated from within the tODE environment...

So here's a very simple project that was spread out over 3 different web
sites that should have been located in one location with all of the
artifacts and supporting scripts avaialalbe in a single versioned
location...

I'm close ... We're close ...

Dale

[1] https://github.com/glassdb/ServiceVM
[2] https://code.google.com/p/glassdb/wiki/ServiceVMExample
[3] https://github.com/glassdb/ServiceVM#servicevm
[4]
https://code.google.com/p/glassdb/wiki/ServiceVMExampleRunSeasideGems30Script
[5]
https://code.google.com/p/glassdb/wiki/ServiceVMExampleStartServiceVM30Script
[6] https://github.com/glassdb/ServiceVM/tree/master/bin

[7]
http://seaside.gemtalksystems.com/ss/Seaside30/Seaside-GemStone-ServiceExamples-DaleHenrichs.10.mcz
[8]
http://seaside.gemtalksystems.com/ss/Seaside30/Seaside-GemStone-ServiceTask-NickAger.20.mcz
[9] http://www.squeaksource.com/Futures/Pharo-Future-NickAger.3.mcz
[10]
http://www.squeaksource.com/Futures/Future-Seaside-Examples-NickAger.9.mcz
[11] https://github.com/glassdb/ServiceVM/tree/master/repository
[12] https://github.com/glassdb/ServiceVM/tree/master/tode
[13] https://github.com/glassdb/ServiceVM/blob/master/tode/adaptors.ston

On Fri, Jun 6, 2014 at 8:56 AM, itlists at schrievkrom.de <
itlists at schrievkrom.de> wrote:

> Am 06.06.2014 16:00, schrieb Dale Henrichs:
> > There is a tutorial that you can run in a Pharo image (your GemTools
> > image should work).  It should give you enough information to be
> dangerous:)
> >
>
> Downloaded it, tried it - but -- well it does not work.
>
> Hmm, I actually I did not expect it to work out of the box - that's the
> reality of the squeak world (Hello Joachim :-))).
>
> That's all a very unstable (and serious bad) situation.
>
> We have GemTools, we have Jade - that the state of today. We have 3.2.0
> and we should have a software base working on these platforms (actually
> we have that - the original delivered extend). When leaving this base it
> becomes an adventure.
>
> In one of the tuturials it is said: do a copy of the MetacelloTemplate
> class - even this simple sentence becomes a problem, if the tools do not
> support creating a copy of a class and if there is not a class with the
> same name as mentioned in the tutorial.
>
> That means for me: I stay away from all public repositories and
> keep/maintain my own packages (Zinc and Neo-JSON). I just use Monticello
> packages from my own http sources and write my own loading stuff -
> that's of course a disaster in terms of software reuse.
>
>
> A pretty angry,
>
>
> Marten Feldtmann
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140606/1d024059/attachment.html>