[ANN] SmallWiki-stable release

Hi,

I've just posted on squeakmap a stable release of smallwiki for Squeak
3.6 only, which is basically the same one used for
www.squeak.org. This release is a "one-click" install - "ready for
contribution" release both for users and developers, which means that
you don't need to bother about dependencies. The unstable one - called
Smallwiki - is for Squeak 3.7 and 3.8. This unstable one should
probably be renamed Smallwiki-unstable (sorry, don't have the
login/pass to do it - Lukas ?).

Users : just install this version and follows the instruction in the
smallwiki readme.

Developers : install this version, you will see on monticello all
packages from which smallwiki depends (NamedServices, KomHttp and so
one). The repository is in global read/write access, so you don't need
to ask for permission to contribute to smallwiki. So please consider
that this is a great responsability : you should read carefully the
"how to contribute" proposal (www.squeaksource.com/smallwiki1). Please
post to the smallwiki list for any comments. The current
smallwiki-stable release is based on the Chris port version 0.9.23-6
whereas the unstable one is based on 0.9.53.

Developers - bis :

How to keep the "one-click" installation both for developers and users
?  Answer: When releasing a new SW version, we should for the moment
update the modified package plus its dependent packages - maybe there
is a way to automate (TODO) that through MCConfiguration but I don't
know how to do that. For instance, a modification of SmallWiki-Kernel
implies a dependency update of SmallWiki-Parser + SmallWiki-Stable.

Thanks !
Samir

I'm a bit new...I see that SmallWiki is still SmallWiki but the new
SmallWiki 2 is called Pier.

Is their doc someplace that shows the difference between SmallWiki and
Pier? Or are they really two different animals?
( I did look here: http://kilana.unibe.ch:9090/SmallWiki

Hi Brad,

> Is their doc someplace that shows the difference between SmallWiki and
> Pier? Or are they really two different animals?
> ( I did look here: http://kilana.unibe.ch:9090/SmallWiki

Pier (formerly known as SmallWiki 2) is what I started to work on
after SmallWiki 1. They certainly share some code and are similar in
some parts, but after all Pier has been rewritten from scratch. While
SmallWiki 1 was designed to be used as a well tested and extensible
Wiki implementation in Smalltalk, people started to use it as a CMS
(Content Management System), e.g., <http://www.squeak.org/> and
<http://www.esug.org>. In my opinion there is not much differencen
between a CMS and a Wiki, for the CMS this are mostly a few additional
tools and that you don't grant the edit permission to everybody in a
CMS. Pier has been designed with the CMS in mind -- and it turned out
to be even more: it can also be seen as an application development
framework on top of Seaside ...

So what is the difference to Pier then?

* The code-base of Pier is much cleaner than one of SmallWiki 1. There
is strict separation between the model and its views, they are all in
different packages and can be loaded independently. There are
currently two views available, the default one working with Seaside
and one using OmniBrowser and Morphic Squeak.

* Pier is based on the Magritte meta-model, what makes it very easy to
extend and query the system. E.g., imagine that you want to store a
small comment for all the edit operations, the only thing you need to
do is to add a string-description to the edit command and immediately
all parts of Pier will be aware of this new feature: all the edit
views for Seaside and Morphic display a new input field, the history
displays the additional field, the query engine and the persistency
will consider the new field, etc.

* Pier has got 5 times more tests than SmallWiki, not counting the
1500 of Magritte.

* Pier uses a similar document representation as SmallWiki, the wiki
syntax for both is similar to the one of SWiki. Again there is a SmaCC
parser that builds an AST of the document that can be easily visited
and transformed to HTML (Seaside), Latex (Documentation), morphic
text, plain text, etc.

* Pier uses a prevalence based history and snapshot mechanism. This
part is not quite finished/proved, serialization is quite tricky after
all, especially if the objects change during development. There was
someone that reported he stored the model in OmniBase. For me I am
currently just saving the image ;-)

* Pier uses Seaside as default view, as opposed to the stateless
approach with Swazoo in SmallWiki. This makes it very easy to plug any
Seaside application into pier, or to plug Pier into any of your
Seaside applications. Navigation tree that remember open nodes are
just a breeze. Ajax is cool with Pier. All links in are bookmark-able,
of course ...

There are certainly more differences, but I guess I wrote down the
most important ones ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Hello,

I've just discovered something with MC I didn't understand the first
time, so it could be interesting for others to understand that...

Let's start with this convention: A depends on B

A (version)
|_B (version)

A* : modified package.

Here is a use case:

A (1)
|_B (1)

A (1)
|_B * (1) (B modified)

With MC, we have to save A first to handle correctly the
dependencies. The first time, I saved B thinking that A will update
itself correctly. Here is an explanation from Avi:

> [Avi Bryant] June 22, 2004 21:08:09 EDT

> Neat. That's precisely the solution I came up with for Monticello as
> well. But if you'll forgive my ignorance of Store: how do prereqs
> between packages work? Does a package have another package as a
> prereq, or a version another version, or a version another package,
> or... ? So, for example: package A depends on B. I save version 1 of
> A, when I have version 1 of B loaded. Later I save a version 2 of
> B. If someone else tries to load version 1 of A, which B do they get?

> In Monticello dependencies are currently very strict
> (version->version, so you would get B version 1 in the above
> case).

> This is good in some cases but really annoying in others, so
> I'm curious how "lineups" deal with it.

>From a ref given by stéphane about LineUp:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265388740


Cheers,
Samir

In visualWorks
        if A.1 depends on B.23
       
        and
        Z.2 depends on B.24

you cannot load A and Z since B.23 and B.24 cannot load together.

So what you do is

        W
                A.1
                B.23

        K
                Z.2
                B.24

If you want to load
        A.1 and Z.2
        you can
        because you load first B.23 or B.24
        because you analyzed

But you did not had to change A.1 or Z.2 for that.
You only created a new lineUp
       
        R
                A.1
                B.23
                Z.2

Since other components may want to still load W or A.1 with another B  
version

I let you imagine how this can be the mess with packages depending on  
packages depending on package.....
Stef

Worth reading....
Cool cees!
http://www.cincomsmalltalk.com/userblogs/travis/blogView?
showComments=true&entry=3265388740


On 20 févr. 06, at 17:39, Samir Saidani wrote: