SqueakMap is supported

I just want to state for the larger Squeak community, **SqueakMap is
supported** and it will continue to document the current locations of
projects now and into the future.  I can say this with confidence
because this does not require the participation of the original
authors, anyone can document any project.  *I*, myself, intend to
document my own projects as well as ones written by others which I
find interesting enough to want to capture how to load them at some
point in the future for myself.

Since it is just a database of Smalltalk code snippets (in some cases,
a SAR file) SqueakMap will remain generically useful all while
SCM-tool-wars rage for decades.  It does not compete in that arena.  I
know there are several other folks in the community besides myself who
also understand SqueakMap's place and purpose in the Squeak ecosystem
and they, too, will document projects in SqueakMap.

So, bottom line -- at least *some* projects will always be documented
in SqueakMap and, to the extent the guidelines[1] established last
year are followed by the documenter, they will always work.

[1] - http://wiki.squeak.org/squeak/6182

Hi!

On 12/21/2012 03:54 AM, Chris Muller wrote:
> I just want to state for the larger Squeak community, **SqueakMap is
> supported** and it will continue to document the current locations of
> projects now and into the future.

I really like what you are writing of course - SM is and will always be
close to my heart for obvious reasons. I didn't mean to "hammer" on it,
I was just trying to be constructive and foresee what is coming.

On the other hand, if the community decides to keep SM going as it was
*meant* (a generic catalog) then I might be persuaded into improving on
it :)

If I let my mind wander in this direction I would probably:

- Add good support for Metacello.
- Add some kind of auto-indexing, SM could actually pick up projects
from SS, SS3, Smalltalkhub, and make them available.
- Make sure the in-image tools are good.


regards, Göran

Thank you for Göran for your willingness to help maintaining SqueakMap.


http://map.squeak.org/recentnew

shows Frank Shearar's Zipper package.

It does not load as documented here
   http://bugs.squeak.org/view.php?id=7708

Maybe this is something easy for you to solve within a few minutes.....  ??

--Hannes

On 12/21/12, Göran Krampe <[hidden email]> wrote:

Göran,

Another probably small thing.

Would it be possible to extend the view

   http://map.squeak.org/recentnew

from 30 to 60 days?

--Hannes

On 12/21/12, H. Hirzel <[hidden email]> wrote:

On 12/21/2012 12:07 PM, H. Hirzel wrote:
I can take a look later tonight, and also extend to 60 days or even add
"show more" or something similar.

Further, a little known feature that you ALL should be aware of:

I wanted to take a look at Kats the other day:

        http://map.squeak.org/packagebyname/kats

...it has a release:

        http://map.squeak.org/packagebyname/kats/autoversion/1

But the file is long gone. Now, here is a trick:

        http://map.squeak.org/packagebyname/kats/autoversion/1/cache

It will download the file directly from the cache on map.squeak.org -
but the name will be "cache". But just rename it, and there it is.

regards, Göran

I am delighted by these developments and I have to admit that until
the recent threads, I hadn't noticed that SM got a new UI, and
excellent new docs on the swiki.

It might me just be my lack of experience, as I have only written
small Smalltalk programs. However my first impression is that
SqueakMap documentation could do with a little more editing. I feel
that if I was to write or adopt a program suitable for SM, as I would
like to do, that I would have to invest some time and trial and error
following the hyperlinks to reconcile different threads of
documentation. I would also be afraid of making mistakes and _adding_
to the bit rot problem. Here are my naive suggestions which I regret I
am unable to write myself. In order of usefulness IMHO.

(1) Merge the significant content from the following 3 pages such that
a new publisher would have a step by step guide:
http://wiki.squeak.org/squeak/6181 "How to create a new SqueakMap Release"
http://wiki.squeak.org/squeak/6182 "SqueakMap Publishing Guidelines"
http://wiki.squeak.org/squeak/779 "FAQ: Squeak Packages"

(2) Choose a canonical example of a real supported project and include
step by step code snippets and screenshots throughout.

(3) Add a page with a suggestion or two for scripting the load of
non-source-code resources, such as image segments (.pr files) (For
large binaries like videos or WAVs, that might be handier than
ASCII-fying them and putting them in Monticello sources.)

(4) A suggestion or two for publishing a project whose canonical
sources (or the sources of a dependency) are outside the traditional
Squeak infrastructure and are found instead in Filetree / Github /
Google Code / Smalltalkhub etc.

(5) Links to good tutorials on scripting with Configurations etc.

I have always loved SqueakMap as an end user. Until now I considered
the link rot and bit rot to be inevitable consequence of the highly
creativity yet small size of the community, so I am hopeful about the
recent steps to tackle bit rot.

Hope that helps. David

p.s. Would it be right to say that SqueakMap is to Monticello as BSD
Ports is to Subversion ?

p.p.s. re. Goran. SqueakMap has a source code cache? Wow, that is
fantastic, and it works! That needs a UI soon (if it doesn't have one
already!)

On 21 December 2012 12:44, David Corking <[hidden email]> wrote:
Yes, that would be exactly right.

frank

> p.p.s. re. Goran. SqueakMap has a source code cache? Wow, that is
> fantastic, and it works! That needs a UI soon (if it doesn't have one
> already!)

> On the other hand, if the community decides to keep SM going as it was
> *meant* (a generic catalog) then I might be persuaded into improving on it
> :)

You made a gorgeous domain model, the SM model, but the server code
cannot compile on closure images because some of the methods are too
long.  More than anything, SqueakMap needs a rewrite of the web-server
IMO.

> If I let my mind wander in this direction I would probably:
>
> - Add good support for Metacello.
> - Add some kind of auto-indexing, SM could actually pick up projects from
> SS, SS3, Smalltalkhub, and make them available.
> - Make sure the in-image tools are good.

Yes, the in-image tools are clunky and a bit fragile.  I hope myself
or someone will have time in 2013 to clean these things up and make
them rock-solid.