[Pharo-project] [squeak-dev] Personalized systems with Treated

Miguel Cobá miguel.coba at gmail.com
Thu May 5 20:23:04 CEST 2011

El jue, 05-05-2011 a las 13:02 -0500, Chris Muller escribió:
> Well, I'm 0-2 so far from the replies understanding the point of my
> story..  Oh well.
> > The problem with those other repositories is that they are for specific
> > uses, as Stef said in other post, the Treated repository is for packages
> > integrated in current Pharo. So, of course you could post some package
> > there but it wont belongs to there really.
> I don't see getting more use out of something than for what it was
> originally intended as a "problem".  I was just getting the work done
> to quell the complaining for Magma coming from that side..
> > This workaround it could be better implemented if the package with
> > specific changes will be pushed to some dedicated compatibility
> > repository where everyone can push every package and use it in their
> > install procedures. That would be better.
> Sure, that could be an incremental step but I wasn't in a position at
> the time to go lobbying to the Pharo group for a new repository; I
> just needed to get Magma done for Pharo'ites.
> Question:  When is anything in "Treated" ever "consumed"?  If it's not
> ever consumed, it's wasting space, so why not delete it?

For the same reason that the Treated repository from Squeak isn't
deleted, for historical references. That doesn't means that we should
put there what one wants. (well, not that rude, just that as is so easy
to create our own repo, isn't well seen if we put packages in others'

> > Now, lets remember that for Pharo at lease, backwards compatibility is a
> > "great to have" feature not a "must have at all means" feature. So if
> Actually that describes Squeak's philosophy; they just do it in a
> slower, more-incremental nature.
> > Other thing, we really don't like changesets or gofer scripts for
> > installing anything on Pharo (even if we really like gofer). Why?
> > Because they aren't a package management system.
> Exactly; philosophical instead of practical..

More than philosophical I think. A script can reflect over itself A
metacello configuration class can. Text vs class. Unless you put a
parser to work, that is extra work.

> >The end result could be the same: the packages are installed in the system, that is granted, but
> > the capability of Metacello of declaring which other configurations it
> > depends on and the one of querying the configuration to see the full
> > list of packages to be installed is something that no gofer script,
> > installer script or SqueakMap feature can handle right now without
> > downloading everything to check.
> Not true.  SqueakMap load scripts specify which other prerequisite
> configurations are required and merges them, as needed, from SqueakMap
> itself.  See Magma or Maui as an example.  Those prerequisite configs
> can be browsed before loading, if desired.

Yes, I saw the scripts for Magma and I see check for specific classes to
test if they exist in the image (if they are installed):

[Smalltalk at: #MagmaTestCase] ifFalse: [ "install other mcz" ]

> I'm more interested to know the answers to these questions:
>   - How does one deploy an application on Pharo that requires a
> one-line change to a core system method that is not acceptable to the
> Pharo gods?

The same tha squeak for changes that aren't accepted/belongs to/are too
specific to an application. You include them as an *mypackage extension
in some package of yours and then when the mcz is installed, the
extension is installed too. That is just monticello as always.

>   - How does one deploy an application on Pharo that loads code from
> external web-sites?

Using doIts if necessary. Or specifying some other repo to fetch mcz
things from. A metacello configuration can have any nnumber of origin
repositories to fetch mcz from and then install them in the image. For
resources like images and so, the doIts can have HTTPClient to download
and serialize to the image as needed. Smalltalk at the point of your

>   - How does one deploy an application on Pharo that requires external
> graphics, videos, XML or other resources?


>   - How does one deploy an application on Pharo that requires an
> object-graph to be loaded internally into the image that was pre-built
> using another tool (e.g., NOT generated via code)?

Don't understand the example
But for loading external data that is in a suitable form to load you can
use a postLoad doit to open (or download the data) and then bring it
into the image, creating objects on the fly. You can load binary data if
you want (SIXX, whatever) or text data (XML,JSON,etc) at the end is
smalltalk in a doIt doing the work.

> These questions are much more important to me than "it isn't a package
> management system".  If Metacello could do all of these things, I
> might be interested..

I think it does those things, maybe a second look at the existings
configurations can clear a lot of doubts.

I have a doubt. the metacello configuration can have groups that install
specific mcz of the full list of mcz that Seaside have to install just
what you need. How will that be made with scripts and SqueakMap?

> Regards,
>   Chris

Miguel Cobá

More information about the Pharo-project mailing list