[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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi Samir,

great news, thanks for creating this package!

> 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 ?).

Me neither, I am just listed as author, not owner or maintainer. So I  
am unable to change that. Chris can you do it?

> 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.

I will try to install it. I am especially interested into those  
comments. Mind you if I reuse them for Pier?

Thank,
Lukas

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



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> 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.


Samir
the pattern is to have one package with no code and just dependent  
packages.
Each time a package is modified: you version the main one and all the  
dependents
will be versioned too. I would not have internal dependencies between  
the packages
only between the top package and its component (this is a well-know  
approach: if
you hardcode dependencies between the local package then one day you  
will be blocked
because one app will be X-1.22 and the other X-.13 and in VW you  
could not load them
and get stuck). Read the blog of Cess on LineUp this is exactly the  
idea and we got burned
by VW package dependencies. Now we do not use them anymore.

This way you have a kind of specification of what are the packages  
working together.

Stef

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi all,

>> 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 ?).
>
> Me neither, I am just listed as author, not owner or maintainer. So I
> am unable to change that. Chris can you do it?

As I don't know the current state of the package I just made both of you
co-maintainers of it.

By the way ... is there a chance or timeline of some stable-release of
Pier? I have some guys (including me :-) which need some great Content
Management.

Chris


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

"stéphane ducasse" <[hidden email]> writes:

Hi Stef,

This is what I did : smallwiki-stable is a package with no code and
depends from smallwiki-parser which itself depends from
smallwiki-kernel. But I don't know why, I miss this point :

> you version the main one and all the  
> dependents
> will be versioned too.

Anyway, it works now : thanks !

Samir


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Lukas Renggli <[hidden email]> writes:

No problem for me !

As you've noticed, there was a lot of changes between the 0.9.23 and
0.9.53 and I'm trying to understand the changes and how to incorporate
gradually those changes into smallwiki-stable... Not easy !

Cheers,
Samir

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

>
> Hi Stef,
>
> This is what I did : smallwiki-stable is a package with no code and
> depends from smallwiki-parser which itself depends from
> smallwiki-kernel. But I don't know why, I miss this point :

The point is not to have for example smallwiki parser depends on  
smallwiki-kernel.
In VW we ended with situation where we could not load two  
applications together
since one was internally depending on the version 2 of a component  
while the other
was depending on another version. We could not fix that since we  
could not load the
packages. So we stopped having internal dependency and use instead  
lineUp

http://www.cincomsmalltalk.com/userblogs/travis/blogView?
showComments=true&entry=3265388740

Stef


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> By the way ... is there a chance or timeline of some stable-release  
> of Pier? I have some guys (including me :-) which need some great  
> Content Management.

It is already on SqueakMap, for quite some time now ;-)

I recently heard an interesting presentation of Gilad Bracha titled  
"Objects as Software Services: Toward a World without Releases".

For me the thing without the releases was nothing new: I never really  
released "SmallWiki 1", and this will be probably the same for Pier  
and Magritte. At some point in time, people just started to use it,  
because it fits their needs. Some people wait a bit longer, because  
they require a particular feature, others are just happy with what  
they get. Some people never update their code after they have what  
they initially wanted, others always want to stay up-to-date at the  
bleeding edge. Some people write extensions, fork the system, modify  
it while merging my changes, etc.

And at the same time I am slowly, but continuously developing it  
further, enhancing the running system, fixing bugs, integrating  
changes of other people, etc.

Btw, I am using Pier for my own web-site now ;-)

Lukas

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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

"stéphane ducasse" <[hidden email]> writes:

>>
>> Hi Stef,
>>
>> This is what I did : smallwiki-stable is a package with no code and
>> depends from smallwiki-parser which itself depends from
>> smallwiki-kernel. But I don't know why, I miss this point :
>
> The point is not to have for example smallwiki parser depends on  
> smallwiki-kernel.

I must admit that I don't understand at all : so you say that A does
not depend on B anymore, but I don't understand how do you tackle the
dependencies issues with current tools available for squeak
(Monticello I mean ??). And after reading the link you gave me, Avi
seems to say that he follows the same approach than the one reported
on the blog... I would like to understand the problem.

I've just posted on squeak-dev about that, maybe it could interesting
for the list to dialogue around that...

Samir


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

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


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

Me too



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki