On Sat, Sep 24, 2011 at 10:53 PM, Guillermo Polito < [email protected]> wrote:
> Hmmm, I don't think that Fuel has to be related with Monticello. They have > different intentions :). > > But having binary packaging is great! :) > > What comes next is a way of organize the binary distributions :P. > > Well, in fact that was one of the ideas behind Fuel Package Loader. For those who knows Java, the idea is to provide a kind of Jar, that is, the code already compiled. With of course, the possibility to attach sources as well. Then for example you have your applicatio XXX that uses Seaside, then you can just build an image with seaside.fuel and that's all. No need of sources, no need of version history, etc... So...I think that for deploying purposes, it is also an interesting idea :) > Guille > > > On Sat, Sep 24, 2011 at 5:30 PM, Mariano Martinez Peck < > [email protected]> wrote: > >> >> >> On Sat, Sep 24, 2011 at 10:22 PM, Frank Shearar >> <[email protected]>wrote: >> >>> On 24 September 2011 20:51, Mariano Martinez Peck <[email protected]> >>> wrote: >>> > >>> > >>> > On Sat, Sep 24, 2011 at 9:47 PM, Frank Shearar < >>> [email protected]> >>> > wrote: >>> >> >>> >> On 24 September 2011 20:40, Mariano Martinez Peck < >>> [email protected]> >>> >> wrote: >>> >> > >>> >> > >>> >> > On Sat, Sep 24, 2011 at 9:34 PM, Frank Shearar < >>> [email protected]> >>> >> > wrote: >>> >> >> >>> >> >> On 24 September 2011 20:01, Mariano Martinez Peck >>> >> >> <[email protected]> >>> >> >> wrote: >>> >> >> > Well...Martin and I have been working a little bit this week and >>> here >>> >> >> > is >>> >> >> > a >>> >> >> > post explaining it: >>> >> >> > >>> >> >> > >>> >> >> > >>> http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-packages-with-fuel/ >>> >> >> >>> >> >> Cool! >>> >> >> >>> >> >> If I understand correctly, Fuel and Monticello (1; I don't know >>> >> >> anything about 2 other than noone seems to use it but it's much >>> >> >> better) accomplish two different things though: Fuel's a mechanism >>> to >>> >> >> quickly load a bunch of stuff, while Monticello's much more >>> >> >> introspective: mainly, a bunch of definitions of things, with a >>> >> >> history pointing to previous versions of the package. >>> >> >> >>> >> > >>> >> > Yes. >>> >> > >>> >> >> >>> >> >> I don't see how Fuel could replace Monticello, >>> >> > >>> >> > No, Fuel won't replace Monticello at all. They are different things. >>> >> >>> >> Ah, OK. That means I misinterpreted "As you may imagine the idea is >>> >> that maybe in the future we can replace Monticello’ mcz with Fuel >>> >> packages." You meant in the sense of an mcz being something you load >>> >> in your image, not somehow extending Fuel to a version control system >>> >> (which would ... not make sense :) ). >>> >> >>> > >>> > Exactly. Maybe the comment was not clear. What I mean is to change >>> > Monticello in the way that instead of serializing code into a mzc that >>> > contains the sources and the use the compiler, use Fuel to directly >>> > store/load the code in a binary way. >>> > Is that better explained? >>> >>> I think it's just my careless reading. The rest of the article's quite >>> clear - "As you may know, Fuel is a plain object graph serializer. No >>> more than that." - and so on. >>> >>> >> :) >> >> >>> I can't wait: a super fast package loader makes it cheap and easy to >>> build up images from recipes. Nice! >>> >>> >> Yes, me too. Problem is that neither Martin or I know very much about >> Monticello. Even more, we prefer to focus in Fuel itself. We consider Fuel >> Package Loader as a proof of concept for a real project. Hopefully, someone >> can join and take care of it. Otherwise, we will try to make progres, but >> slowly :( >> >> >> >> >>> frank >>> >>> >> >> then, except in the >>> >> >> sense of "here's a chunk of stuff you can load into your image" - >>> >> >> which makes me think that one could simply replace the snapshot.bin >>> >> >> with a snapshot.fuel (or simply put it in the same directory, for a >>> >> >> loss in space but a gain in compatibility) and you'd have a much >>> >> >> faster loading mcz, right? >>> >> > >>> >> > Exactly. With Monticello right now you have to compile the >>> sources.st, >>> >> > which >>> >> > may be slow and even more you need the compiler. The idea is to >>> >> > experiment a >>> >> > way of using Monticello to directly store binary/already compiled >>> code. >>> >> > This way, it may be faster for exporting/importing the code. >>> >> > So....in summary, we will try to experiment to replace only a small >>> part >>> >> > of >>> >> > Monticello ;) >>> >> >>> >> Ah, excellent! I can't wait! >>> >> >>> >> >> frank >>> >> >> >>> >> >> > Cheers >>> >> >> > >>> >> >> > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe >>> >> >> > <[email protected]> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >>> >> >> >> >>> >> >> >> > Cool Martin. Now I could do it as well. I have exported the >>> groups >>> >> >> >> > 'Core', 'Tests' and 'Zinc-Seaside'. >>> >> >> >> > Then I materialize it a clean image and all tests (1567) are >>> >> >> >> > green. >>> >> >> >> > And >>> >> >> >> > it only takes 7 seconds :) >>> >> >> >> >>> >> >> >> Great ! >>> >> >> >> >>> >> >> >> I want to try this myself soon. >>> >> >> >> >>> >> >> >> Sven >>> >> >> >> >>> >> >> >> _______________________________________________ >>> >> >> >> seaside mailing list >>> >> >> >> [email protected] >>> >> >> >> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Mariano >>> >> >> > http://marianopeck.wordpress.com >>> >> >> > >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Mariano >>> >> > http://marianopeck.wordpress.com >>> >> > >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> > >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com
