Monticello 2

Hi. I saw on Lukas's Esug presentation that Monticello 2 is
recommended for Seaside development because it is supported on
all of the Smalltalks that Seaside is available on. I was not
aware of this; I thought Monticello 2 was still in the alpha
phase, didn't yet support remote repositories, and only worked
on Squeak. I must have missed something. Where can I find out
more about Monticello 2?

Here is what I am referring to:

Slide 58:
http://www.lukas-renggli.ch/blog/seaside-presentation-esug2008

Minutes 28-31 of the talk:
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Lukas_talks_Seaside_at_ESUG_2008&entry=3401865449

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Hi. I saw on Lukas's Esug presentation that Monticello 2 is
> recommended for Seaside development because it is supported on
> all of the Smalltalks that Seaside is available on. I was not
> aware of this; I thought Monticello 2 was still in the alpha
> phase, didn't yet support remote repositories, and only worked
> on Squeak. I must have missed something. Where can I find out
> more about Monticello 2?

No, I did not say that we use Monticello 2 or that it is supported on
any platform. I said, that it is the future and that we would like all
the Smalltalk platforms to port and support it, so that we can easily
merge and load extensions and patches coming from anywhere.

Right now this it is nearly impossible (and in practice it maybe
happened once) to get back extensions or fixes from VisualWorks,
Dolphin and GST. It happens on an almost daily bases with GemStone,
because they have a full port of Monticello 1.

Then I added, that I do not suggest to port Monticello 1 now, because
Monticello 1 was not designed with portability in mind and probably
very hard to integrate into different platforms. Monticello 2 is
designed to support different platforms.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Thu, Oct 30, 2008 at 10:45 AM, Matthew Fulmer <[hidden email]> wrote:

> I thought Monticello 2 was still in the alpha
> phase, didn't yet support remote repositories, and only worked
> on Squeak.

I would say it's at least in beta at this point, and there is finally
a reasonable scheme for remote repositories: MC2's "directory
repository" type with a DropBox shared folder (http://getdropbox.com)
does nearly everything I would want a for remote development.  (Though
not for distribution or deployment: there's no way to grant read-only
access, and I don't know how to set it up on a headless linux server).

It does only work on Squeak so far, though.

Avi
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Thu, Oct 30, 2008 at 07:01:49PM +0100, Lukas Renggli wrote:
> Then I added, that I do not suggest to port Monticello 1 now, because
> Monticello 1 was not designed with portability in mind and probably
> very hard to integrate into different platforms. Monticello 2 is
> designed to support different platforms.

I don't know why you say this, so let's examine what is required
to port Monticello 1, and compare it to Monticello 2.

Reading a package:
- Monticello 1:
  - Reading a zip: probably available
  - Reading the snapshot.st file: Contained within Monticello;
    portable
  - Reading the snapshot.bin file: Requires a port of
    DataStream.  Not so easy
  - Reading the other files: contained within Monticello;
    portable
- Monticello 2:
  - ?

Loading a package:
- Monticello 1:
  - Provide a loader for each MCDefinition type
- Monticello 2:
  - Provide a loader for each MDVersion type

Snapshotting a package:
- Monticello 1:
  - Create a PackageInfo that can scan this system
- Monticello 2:
  - Create a Slice that can scan this system

Saving a package:
- Same portability status as Reading a package

Other portability issues, shared by MC 1 and 2:
- Traits are specific to Squeak
- Namespaces are specific to VisualWorks


All in all, I don't see a huge difference between the
theoretical portability of MC1 and 2. I'd need to know more
about the format of MC2 packages though

I'm curious why you say this. Please explain.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 30-Oct-08, at 2:11 PM, Matthew Fulmer wrote:

> All in all, I don't see a huge difference between the
> theoretical portability of MC1 and 2. I'd need to know more
> about the format of MC2 packages though
>
> I'm curious why you say this. Please explain.

I think that what Lukas was getting at was that MC2 has been developed  
with portability in mind to a greater extent than was MC1.

For example, a snapshot in MC2 stores program state in property  
dictionaries rather than instances of an MCDefinition subclass, and it  
ignores but preserves any properties it doesn't understand. This means  
that a VW or Gemstone port of MC2 could store dialect-specific  
information in custom properties, and the Squeak version would not  
have to be updated to handle them.

Another example is that the MC2 user interface is based on  
OmniBrowser, which is itself portable, and now runs on 3 Smalltalk  
dialects.

Finally, I've tried to organize the code in MC2 for better  
portability. Some packages are meant to be portable, and others are  
meant to be Squeak-specific. I've tried to keep platform-specific code  
as isolated as possible, largely by following the techniques that  
Lukas and the rest of the Seaside developers have figured out in  
managing Seaside across several dialects.

All this is not to say that MC1 can't be ported - it runs on Gemstone  
after all. But with MC2, portability has been an explicit goal, which  
it never was for MC1.

Colin
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

We just did a podcast with Colin Putney about Monticello and  
Monticello2 recently:

http://www.cincomsmalltalk.com/audio/2008/industry_misinterpretations107.mp3


We intend to have interop with Monticello 2, for the reasons that  
Lukas lays out below - it will make code submissions (and porting on  
our end) simpler.


James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library




On Oct 30, 2008, at 2:01 PM, Lukas Renggli wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside