[squeak-dev] SqueakMap revival

Ho folks!

Just wanted to mention that I sat down last night and ended up hacking
on SqueakMap. I started by fixing a few silly UI issues (not deployed
yet) when editing releases - funny that so few have noticed them.

... and then I ended up a refactoring/integration of Michal Starke's
work called Kabungu. For those of you who weren't around in 2005 when
Michal wrote Kabungu - it is a dependency resolver and universe
implementation for SqueakMap with support for explicit conflicts and
virtual dependencies (depend on "web server" for example) etc etc.

So... my goal is to get Kabungu fully integrated for OOPSLA this year
(October). If anyone is interested in helping me with this - just mail
me privately.

ciao, Göran

PS. Yep, about time right? :)

Oooh,

Sake/Packages does virtual dependencies, but not conflicts, I hadn't
thought of that...!

A problem S/P has with SM and Universes is going in the reverse
direction Sake/Packages (subscribers can edit) to SM/Uni (only package
publisher can edit).

Any ideas? Could SM hold two lots of metadata, and users pick either
"author blessed" latest or "subscriber says is ok" latest.

Sake/Packages has several levels

Packages beta  "for the absolute latest package, if published"
Packages current "for the subscriber says is ok"
Packages universe "for the author published to the universe package"
Packages squeakmap "for the squeakmap published package"

How about a feedback facility in SM for users to report their experiences?

One problem we may have is that the list of "loaded packages" is managed
several times over and they get out of sync. MCWorkingCopy,
PackagesOrganizer, and in Sake/Packages class Packages>>#provided all
have a list. I am also anticipating that MC2 will have another similar
scheme.

So in the very latest alpha MC1.5 (not yet in LPF) I have moved towards
a scheme whereby it expects PackagesOrganizer to hold the master list of
"loaded packages", and PackageInfo instances are willing to hold
meta-data on behalf of other client tools.

regards

Keith

Hi!

Keith Hodges wrote:
> Oooh,
>
> Sake/Packages does virtual dependencies, but not conflicts, I hadn't
> thought of that...!

Yes, darnit - forgot about your work. Haven't looked at it yet, sorry to
say. And last night I honestly forgot about it :)

> A problem S/P has with SM and Universes is going in the reverse
> direction Sake/Packages (subscribers can edit) to SM/Uni (only package
> publisher can edit).
>
> Any ideas? Could SM hold two lots of metadata, and users pick either
> "author blessed" latest or "subscriber says is ok" latest.

Kabungu has a hinting mechanism (not sure yet, code is not entirely
clear) and I think "users" can add hints to package release.

> Sake/Packages has several levels
>
> Packages beta  "for the absolute latest package, if published"
> Packages current "for the subscriber says is ok"
> Packages universe "for the author published to the universe package"
> Packages squeakmap "for the squeakmap published package"
>
> How about a feedback facility in SM for users to report their experiences?

Right. :) Current SM code also has a mechanism (not used though, except
by the old Kabungu code) for attaching arbitrary "resources" (meta data)
to packages/releases. I was actually thinking of skipping that though
and integrating Kabungu fully instead.

> One problem we may have is that the list of "loaded packages" is managed
> several times over and they get out of sync. MCWorkingCopy,
> PackagesOrganizer, and in Sake/Packages class Packages>>#provided all
> have a list. I am also anticipating that MC2 will have another similar
> scheme.

And SM has its own too :)

> So in the very latest alpha MC1.5 (not yet in LPF) I have moved towards
> a scheme whereby it expects PackagesOrganizer to hold the master list of
> "loaded packages", and PackageInfo instances are willing to hold
> meta-data on behalf of other client tools.

Yeah, we need a plan. :) I am all ears. And I want all of our work to
"mesh together" as best we can. I need to learn more about Sake/Packages
to understand how it fits (or not) with Kabungu.

regards, Göran

Hi all!

Mini report:

Sat up last night and continued integrating Kabungu. After some time I
realized that the latest snapshot in the Kabungu SS-repo (13) is quite
"broken" compared to the released snapshot on SM (12).

So... I think I will back down to Kabungu.12 as soon as I can sit down
again. We also moved development over to
http://source.squeakfoundation.org/SqueakMap - everyone can read/write
there so if you want to help, consider that to be an "open inbox" for SM
code.

I also threw an email to Michal Starke but no reply so far.

Furthermore, Ken started looking at building the server image using
Keith's LPF and a script, and probably upgrading the server image from
the current 3.8 to 3.10. Great to have someone helping out!

The Plan:

- Integrate Kabungu more or less as it stands on the domain code side.
- Simplify the SM domain code. In some areas it is definitely a bit
overengineered.
- Look at how this fits with Sake/Packages.
- Add web UI bits so that Kabungu can be used.

There are tons of other nice things we should/could do like:

- Move away from ImageSegments as distribution model.
- Move towards a distributed model.
- Add support for "sucking up" packages and releases from other sources
like for example SqueakSource. This would improve SM as the "catalog for
all code there is"
- ...
... but "first things first".

regards, Göran