May 2011 - Esug-list - lists.esug.org

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Thu, May 26, 2011 at 9:29 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > BTW, the page (http://rmod.lille.inria.fr/web/pier/software/Fuel) > says: > > Gofer new > squeaksource: 'Fuel'; > package: 'ConfigurationOfFuel'; > load. > ((Smalltalk at: #ConfigurationOfFuel) project =latestVersion) load: #(Core > Tests Benchmarks). > > it does not appear to be a valid expression. What is the right > expression? > the = Try: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project latestVersion) load: #(Core Tests Benchmarks). > > -- Yoshiki > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Mariano http://marianopeck.wordpress.com

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

BTW, the page (http://rmod.lille.inria.fr/web/pier/software/Fuel) says: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project =latestVersion) load: #(Core Tests Benchmarks). it does not appear to be a valid expression. What is the right expression? -- Yoshiki

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Thu, 26 May 2011 09:51:00 +0200, Marcus Denker wrote: > > On May 25, 2011, at 7:35 PM, Yoshiki Ohshima wrote: > > > At Wed, 25 May 2011 15:28:00 +0200, > > Mariano Martinez Peck wrote: > >> > >> One of the most important uses we want to do with Fuel (in a future) is to be able to use it for Monticello (to replace mzc). > >> The idea in addition is to be able to boostrap a really small pharo image (hetzel) and be able to load stuff without needing a compiler. > > > > Sounds interesting! Can I learn about "hetzel" somewhere? > > > We are working on how to build minimal Pharo kernels (with the goal of a declarative bootstrap so you can build your own > version of Smalltalk running in the normal Pharo image to experiment with new language features, as one example, or > create a minimal image for deployment). > > There is some information from Nicolas Paez who worked on this when visiting RMOD last year: > > http://www.fast.org.ar/smalltalks2010/videos/Seed+project%3A+The+challenge+… > http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Paez-Seed.pdf > > The status is that we learned a lot and continue to work on it... more to come later ;-) Yay! Declarative bootstrap is good. MicroSqueak is mostly classes and code with a bit of setup, so I thought if the tracer (MicroSqueakImageBuilder) takes somewhat different format but essentially with the same information, you can build an image and then whatever code loader that can load Compiler, you can get to a working state. But as you say, there must be details and I'm all curious to learn also! -- Yoshiki

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Thu, May 26, 2011 at 9:51 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 25, 2011, at 7:35 PM, Yoshiki Ohshima wrote: > > > At Wed, 25 May 2011 15:28:00 +0200, > > Mariano Martinez Peck wrote: > >> > >> One of the most important uses we want to do with Fuel (in a future) is > to be able to use it for Monticello (to replace mzc). > >> The idea in addition is to be able to boostrap a really small pharo > image (hetzel) and be able to load stuff without needing a compiler. > > > > Sounds interesting! Can I learn about "hetzel" somewhere? > > > We are working on how to build minimal Pharo kernels (with the goal of a > declarative bootstrap so you can build your own > version of Smalltalk running in the normal Pharo image to experiment with > new language features, as one example, or > create a minimal image for deployment). > > There is some information from Nicolas Paez who worked on this when > visiting RMOD last year: > > > http://www.fast.org.ar/smalltalks2010/videos/Seed+project%3A+The+challenge+… > http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Paez-Seed.pdf > > The status is that we learned a lot and continue to work on it... more to > come later ;-) > > Ben is now working in the project. He will soon create a website inside RMOD with some more information. He has also some slides and a full report explaing about it :) > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Mariano http://marianopeck.wordpress.com

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Marcus Denker

On May 25, 2011, at 7:35 PM, Yoshiki Ohshima wrote: > At Wed, 25 May 2011 15:28:00 +0200, > Mariano Martinez Peck wrote: >> >> One of the most important uses we want to do with Fuel (in a future) is to be able to use it for Monticello (to replace mzc). >> The idea in addition is to be able to boostrap a really small pharo image (hetzel) and be able to load stuff without needing a compiler. > > Sounds interesting! Can I learn about "hetzel" somewhere? > We are working on how to build minimal Pharo kernels (with the goal of a declarative bootstrap so you can build your own version of Smalltalk running in the normal Pharo image to experiment with new language features, as one example, or create a minimal image for deployment). There is some information from Nicolas Paez who worked on this when visiting RMOD last year: http://www.fast.org.ar/smalltalks2010/videos/Seed+project%3A+The+challenge+… http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Paez-Seed.pdf The status is that we learned a lot and continue to work on it... more to come later ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Martin Dias

Hi On Wed, May 25, 2011 at 10:28 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Philippe. I don't know why but your emails always go to spam in my > account :( > > >> > Actually, the project has already started since several months. Tristan >> > Bourgois and I started with the project while doing an internship with >> RMoD, >> > INRIA. Since a couple of months, Mariano Martinez Peck joined the team, >> and >> > now he is the official mentor in the SummerTalk. >> > >> > ESUG website for SummertTalk: >> > http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 >> > >> > The website with all the necessary information is here: >> > http://rmod.lille.inria.fr/web/pier/software/Fuel >> > It even includes slides explaining the algorithm. In addition, a paper >> is in >> > progress. >> >> Could you make the slides available in some other format than Flash? >> >> > Ok, Martin will do it and upload them directly to the website. > Yes, sorry. I kept the embedded slides but I added links to the pdf "sources". > > > >> > For the moment, Fuel already provides the following features: >> > >> > - Fast pickle format. It is much faster to materialize than to >> serialize. >> >> What has led to the conclusion that materialization is more important >> than serialization? > > > One of the most important uses we want to do with Fuel (in a future) is to > be able to use it for Monticello (to replace mzc). > The idea in addition is to be able to boostrap a really small pharo image > (hetzel) and be able to load stuff without needing a compiler. > I all those cases we assume that you serialize only once or few times and > you materialize much more times. > But of course, that does not apply to all cases, like you said about > session replication. > Actually, despite we have this hypothesis (de-serialization is done much more often than serialization), I often think it is not something really essential to the project. It was an early decision to base on the Parcel's algorithm, which has this feature, but I believe we can eventually implement an alternative strategy that favors serialization performance over deserialization. I think other more essential features (or goals!) are: - any object can be serialized. - binary class load, without compilation. - fast and focused on just one dialect, don't worry about an inter-platform format. - flexibility, for selecting the graph to serialize. > > >> I can image scenarios when there is a one to one >> relationship and scenarios where serialization is more important (e.g. >> session replication). >> >> > - Correctly support class reshape (when the class of serialized objects >> has >> > changed). >> >> So what do you do when an instance variable was added? Set it to nil >> and hope that everything will continue to work? >> > > In that example yes. But what we meant is that right now the inst var names > are bening encoded also. So at materializatio ntime we will be able to deal > with them. > Not all scnearios are developed right now, but the base is there. At some > point, the only solution has to be done by the user. For example, you should > implement > #updateFrom: aVersion to: anotherVersion: anotherVersion object: anObject > or something like that.... > So...we meant that we store the instVar names and we support some type of > changes. > In fact, we have reified FLInstanceVariablesMapping. So maybe we can do > something with that in a future. > I want to let the user configure an initialization block. > > >> >> > - Serialize ANY kind of object. For the moment there is no object to our >> > knowledge that we cannot serialize and materialize. >> >> Really? You serialize Socket, Process, FileStream and something >> meaningful happens? >> > > Of course there are classes whose instances doesn't make sense once to load > them back in the image. Our comment was literally: we can (ok, we should be > able to) serialize them and materialize them without problem. Now....whether > those instances are correct or still valid and meaningful in the current > image is another problem ;) > One of the future features will be to be able to implement > #postMaterializationAction or something like that could be executed after > materialization. > Sockets could try to get a new socket from the OS, Processes could be > restarted and rescheduled? I have no idea. If you have, please let us know. > Yes... maybe I was too much optimistic with this "ANY". I think you can serialize and deserialize instances of these classes but probably they need something to be "meaningful". > > Thanks for the execellent questions :) > > Thanks! Martin > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 26, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Wed, 25 May 2011 15:28:00 +0200, Mariano Martinez Peck wrote: > > One of the most important uses we want to do with Fuel (in a future) is to be able to use it for Monticello (to replace mzc). > The idea in addition is to be able to boostrap a really small pharo image (hetzel) and be able to load stuff without needing a compiler. Sounds interesting! Can I learn about "hetzel" somewhere? -- Yoshiki

May 25, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

> >> > - Correctly support class reshape (when the class of serialized objects >> has >> > changed). >> >> So what do you do when an instance variable was added? Set it to nil >> and hope that everything will continue to work? >> > Of course. One might hope that the developer that added an instance > variable to a system which had existing instanciated objects would provide > suitable lazy initialization as needed. There is no magic. > Exactly. Read the answer I have just send. > > >> >> > - Serialize ANY kind of object. For the moment there is no object to our >> > knowledge that we cannot serialize and materialize. >> >> Really? You serialize Socket, Process, FileStream and something >> meaningful happens? >> > > Again, no magic. One would hope an interface object that became detached > from it's service would know how to reattach. > > > Exactly. Ideally, a class will be able to implement #prepareToBeSerializer and #postMaterializationAction or stuff like that. So, what we want to provide is the infrastructure, the hooks. Then, we shoud identify those base classes that MUST have something like that like the cases pointed out by Philippe For example, the same happes with Set and Dictionaries. They have to be rehashes once they are materialized. > ttfn, Steve > -- > Steve Cline cline(a)acm.org http://www.clines.org > http://www.linkedin.com/in/stevecline > "Do what's right, and try to get along with people, in that order" > - Ezra Taft Benson > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -- Mariano http://marianopeck.wordpress.com

May 25, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

Hi Philippe. I don't know why but your emails always go to spam in my account :( > > Actually, the project has already started since several months. Tristan > > Bourgois and I started with the project while doing an internship with > RMoD, > > INRIA. Since a couple of months, Mariano Martinez Peck joined the team, > and > > now he is the official mentor in the SummerTalk. > > > > ESUG website for SummertTalk: > > http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 > > > > The website with all the necessary information is here: > > http://rmod.lille.inria.fr/web/pier/software/Fuel > > It even includes slides explaining the algorithm. In addition, a paper is > in > > progress. > > Could you make the slides available in some other format than Flash? > > Ok, Martin will do it and upload them directly to the website. > > For the moment, Fuel already provides the following features: > > > > - Fast pickle format. It is much faster to materialize than to serialize. > > What has led to the conclusion that materialization is more important > than serialization? One of the most important uses we want to do with Fuel (in a future) is to be able to use it for Monticello (to replace mzc). The idea in addition is to be able to boostrap a really small pharo image (hetzel) and be able to load stuff without needing a compiler. I all those cases we assume that you serialize only once or few times and you materialize much more times. But of course, that does not apply to all cases, like you said about session replication. > I can image scenarios when there is a one to one > relationship and scenarios where serialization is more important (e.g. > session replication). > > > - Correctly support class reshape (when the class of serialized objects > has > > changed). > > So what do you do when an instance variable was added? Set it to nil > and hope that everything will continue to work? > In that example yes. But what we meant is that right now the inst var names are bening encoded also. So at materializatio ntime we will be able to deal with them. Not all scnearios are developed right now, but the base is there. At some point, the only solution has to be done by the user. For example, you should implement #updateFrom: aVersion to: anotherVersion: anotherVersion object: anObject or something like that.... So...we meant that we store the instVar names and we support some type of changes. In fact, we have reified FLInstanceVariablesMapping. So maybe we can do something with that in a future. > > > - Serialize ANY kind of object. For the moment there is no object to our > > knowledge that we cannot serialize and materialize. > > Really? You serialize Socket, Process, FileStream and something > meaningful happens? > Of course there are classes whose instances doesn't make sense once to load them back in the image. Our comment was literally: we can (ok, we should be able to) serialize them and materialize them without problem. Now....whether those instances are correct or still valid and meaningful in the current image is another problem ;) One of the future features will be to be able to implement #postMaterializationAction or something like that could be executed after materialization. Sockets could try to get a new socket from the OS, Processes could be restarted and rescheduled? I have no idea. If you have, please let us know. Thanks for the execellent questions :) -- Mariano http://marianopeck.wordpress.com

May 25, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Steve Cline

On Tue, May 24, 2011 at 11:39 PM, Philippe Marschall < philippe.marschall(a)gmail.com> wrote: > Could you make the slides available in some other format than Flash? > I second that. ... > > > - Fast pickle format. It is much faster to materialize than to serialize. > > What has led to the conclusion that materialization is more important > than serialization? I I don't think Martin made a claim about importance, just current implementation behavior. One horse will be faster than another. Currently, the materialization horse is faster than the serialization horse. > > > - Correctly support class reshape (when the class of serialized objects > has > > changed). > > So what do you do when an instance variable was added? Set it to nil > and hope that everything will continue to work? > Of course. One might hope that the developer that added an instance variable to a system which had existing instanciated objects would provide suitable lazy initialization as needed. There is no magic. > > > - Serialize ANY kind of object. For the moment there is no object to our > > knowledge that we cannot serialize and materialize. > > Really? You serialize Socket, Process, FileStream and something > meaningful happens? > Again, no magic. One would hope an interface object that became detached from it's service would know how to reattach. ttfn, Steve -- Steve Cline cline(a)acm.org http://www.clines.org http://www.linkedin.com/in/stevecline "Do what's right, and try to get along with people, in that order" - Ezra Taft Benson

May 25, 2011

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Philippe Marschall

2011/5/24 Martin Dias <tinchodias(a)gmail.com>: > Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel > development through the ESUG SummerTalk. I am Martin Dias, a student at > Buenos Aires, Argentina. The idea behind this SummerTalk is to implement > Fuel, a binary, fast and general-purpose object graph serializer in Pharo. > It is based on VisualWorks' Parcels ideas. Please excuse me if this is the wrong forum to discuss things. > Actually, the project has already started since several months. Tristan > Bourgois and I started with the project while doing an internship with RMoD, > INRIA. Since a couple of months, Mariano Martinez Peck joined the team, and > now he is the official mentor in the SummerTalk. > > ESUG website for SummertTalk: > http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 > > The website with all the necessary information is here: > http://rmod.lille.inria.fr/web/pier/software/Fuel > It even includes slides explaining the algorithm. In addition, a paper is in > progress. Could you make the slides available in some other format than Flash? > For the moment, Fuel already provides the following features: > > - Fast pickle format. It is much faster to materialize than to serialize. What has led to the conclusion that materialization is more important than serialization? I can image scenarios when there is a one to one relationship and scenarios where serialization is more important (e.g. session replication). > - Correctly support class reshape (when the class of serialized objects has > changed). So what do you do when an instance variable was added? Set it to nil and hope that everything will continue to work? > - Serialize ANY kind of object. For the moment there is no object to our > knowledge that we cannot serialize and materialize. Really? You serialize Socket, Process, FileStream and something meaningful happens? > - Be able to completely serialize classes and traits (not just a global > name). > - Support cycles and avoid duplicates in the graph. > - Integration to Moose with an extension to export and import their models. > - Detection of globals: for example if you serialize Transcript, it is not > duplicated and instead managed as a global reference. > - Solve common problems like Set rehash. > - Buffered writing: we use a buffered write stream for the serialization > part (thanks Sven!). > - No need of special support from the VM. > - Try to have a good object oriented design. > - Well tested (about 120 tests, for the moment). > - Large set of benchmarks (even benchmarks for Moose extension). > > And of course, there are a lot features for the future. You can see some of > them in the website and some in the issue tracker: > http://code.google.com/p/fuel/issues/list > > We really appreciate all kind of feedback and comments. If you want to try > it, check in the website how to do it. It is extremely easy. > > Once again, I want to thank a lot to ESUG for sponsoring the project. I plan > to create a "news" section in the website with some RSS. I will keep you > informed. Cheers Philippe

May 25, 2011

ESUG SummerTalk - Fuel, binary object serializer

by Martin Dias

Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in Pharo<http://www.pharo-project.org/>. It is based on VisualWorks' Parcels ideas. Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with RMoD, INRIA <http://rmod.lille.inria.fr/web/pier>. Since a couple of months, Mariano Martinez Peck <http://marianopeck.wordpress.com/> joined the team, and now he is the official mentor in the SummerTalk. ESUG website for SummertTalk: http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 The website with all the necessary information is here: http://rmod.lille.inria.fr/web/pier/software/Fuel It even includes slides explaining the algorithm. In addition, a paper is in progress. For the moment, Fuel already provides the following features: - Fast pickle format. It is much faster to materialize than to serialize. - Correctly support class reshape (when the class of serialized objects has changed). - Serialize ANY kind of object. For the moment there is no object to our knowledge that we cannot serialize and materialize. - Be able to completely serialize classes and traits (not just a global name). - Support cycles and avoid duplicates in the graph. - Integration to Moose <http://www.moosetechnology.org/> with an extension to export and import their models. - Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference. - Solve common problems like Set rehash. - Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!). - No need of special support from the VM. - Try to have a good object oriented design. - Well tested (about 120 tests, for the moment). - Large set of benchmarks (even benchmarks for Moose extension). And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: http://code.google.com/p/fuel/issues/list We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed. Best regards, Martin

May 24, 2011

[[ UK Smalltalk User Group ]] UK Smalltalk User Group Meeting - Monday, May 23rd

by gcorriga

The next meeting of the UK Smalltalk User Group will be on Monday, May 23rd. Tim Mackinnon has recently started looking at JTalk - and how it translates Smalltalk to JavaScript as well as providing the familiar Smalltalk browsers in your web page. It's still a new project, but how does this approach compare to staying native? Come and join us for some interesting smalltalk on this topic. In addition to this, Niall Ross will briefly update us on the upcoming ESUG conference 2011, in Edimburgh. Don't forget that the early registration is now open! We'll meet in our usual venue - the Counting House, close to Bank Station, from 18:30 onwards. -- Posted By gcorriga to [ UK Smalltalk User Group ] on 5/21/2011 10:06:00 AM

May 21, 2011

Postdoc position in software engineering at University of Chile in cooperation with INRIA

by Alexandre Bergel

Hi! Some of you may be interesting in the following call: -=-=-=-=-=-=-=-=-=-=-=-= Postdoc position in software engineering at University of Chile in cooperation with INRIA A post-doctoral research position is available with the Pleiad Lab (University of Chile) and the RMoD Group (INRIA Lille Nord Europe). The position is scheduled to start in September 2011, but earlier dates are possible. The position is targeted for research on software maintenance and software visualization. Validation of research hypotheses will be carried out using the Pharo programming language. Experience with it, or any other Smalltalk dialect, is a plus (but not necessary). The postdoctoral researcher will be expected to develop independent research initiatives within the scope of the position, design and contribute to the research experiments conducted by Pleiad and RMoD. There is no teaching duty associated with this position. Both Pleiad and RMoD offer a creative, productive and multicultural staff and students, with many collaboration opportunities. Pleiad and RMoD have an extensive expertise and an advanced infrastructure related to software analysis, data mining, testing, meta-modeling and language semantics. The position is funded by INRIA for a period of 12 or 18 months. In order to foster the collaboration between France and Chili, the candidate will have to share his time between Lille, France and Santiago, Chile. The candidate must hold a PhD in computer science. Contact Persons: Alexandre Bergel and Stéphane Ducasse http://pleiad.dcc.uchile.cl http://rmod.lille.inria.fr http://www.pharo-project.org http://www.moosetechnology.org -=-=-=-=-=-=-=-=-=-=-=-= See you in August! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2011

Re: [Esug-list] ESUG 2011 registration is live !

by Juraj Kubelka

Dear Niall, may I ask you how long will be the registration available for the early-bird price? Thank you in advance, Juraj On Wed, May 18, 2011 at 7:56 PM, Niall Ross <nfr(a)bigwig.net> wrote: > The title says it all. > > £315 buys you the all-included early-bird registration: all 5 conference > days, 2 Camp Smalltalk days and the full social event. > > The link at the top of website main page > http://www.esug.org/Conferences/2011 > takes you to the registration app link (and the registration FAQ if needed > - if anything is not made clear in app or FAQ, by all means let me know). > > > Accommodation > =========== > The registration list and the conference accommodation room lists are > separate, because those who live in Edinburgh, and a few others, will > register but not need a room, while others will want to stay on for the > festival. (However it makes sense for you to use the same email and > password when you sign into both lists: the same email speeds our checking > that everyone registered has somewhere to stay, and the same password is one > less thing for you to remember.) > > Room reservations are confirmed if you > > - are registered, or reserve then register > > - enter specific arrival and departure dates in the room list (or, for > those who are leaving later than the conference, if you specified a definite > date in the text box). > > If you do not give specific dates for arrival and departure, your room > reservation remains provisional after you register until you update your > room-list entry. (If you don't do that reasonably soon after registering, > expect a nagging email. :-) ) > > FYI, the website accommodation page (and some others) have been rewritten > to have more pictures and info. > > See you in Edinburgh > Niall Ross > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email___________________________________________… > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

May 19, 2011

Re: [Esug-list] Sponsoring visit of ESUG 2011 for smalltalkers from Russia

by Dennis Schetinin

How can one apply to a free slot access for ESUG 2011? 2011/4/27 Stéphane Ducasse <stephane.ducasse(a)inria.fr>: > Hi Dennis > > ESUG has two programs to help people participating: > - some free slot access: you can get the conference for free. > - one day pass for the complete week-end like that you contribute to the conference > this is around 170 Euros. > > Stef > > > On Apr 26, 2011, at 7:53 PM, Dennis Schetinin wrote: > >> Hello! >> >> Can ESUG help a couple of Russian smalltalkers to visit the conference >> this year? If this is possible I'll provide more information. TIA >> >> -- >> Dennis Schetinin >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -- Dennis Schetinin

May 19, 2011

ESUG 2011 registration is live !

by Niall Ross

The title says it all. £315 buys you the all-included early-bird registration: all 5 conference days, 2 Camp Smalltalk days and the full social event. The link at the top of website main page http://www.esug.org/Conferences/2011 takes you to the registration app link (and the registration FAQ if needed - if anything is not made clear in app or FAQ, by all means let me know). Accommodation =========== The registration list and the conference accommodation room lists are separate, because those who live in Edinburgh, and a few others, will register but not need a room, while others will want to stay on for the festival. (However it makes sense for you to use the same email and password when you sign into both lists: the same email speeds our checking that everyone registered has somewhere to stay, and the same password is one less thing for you to remember.) Room reservations are confirmed if you - are registered, or reserve then register - enter specific arrival and departure dates in the room list (or, for those who are leaving later than the conference, if you specified a definite date in the text box). If you do not give specific dates for arrival and departure, your room reservation remains provisional after you register until you update your room-list entry. (If you don't do that reasonably soon after registering, expect a nagging email. :-) ) FYI, the website accommodation page (and some others) have been rewritten to have more pictures and info. See you in Edinburgh Niall Ross ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

May 18, 2011

Re: [Esug-list] [Seaside-dev] Re: [ANN] SmallHarbour project

by Dale Henrichs

On May 18, 2011, at 4:02 AM, Nick Ager wrote: Hi, We are in the process of adding support for deploying GLASS applications into the Cloud Foundry, but I wouldn't mind helping folks who are interested in adding support for other Smalltalks into the Cloud Foundry ... The Cloud Foundry is written largely in ruby, so you'll need to be wearing your ruby dancing shoes:) There certainly a lot of (justified) buzz around CloudFoundry at the moment. Building CloudFoundry infrastructure for Smalltalk deployment would appear to be a great approach - married with a hosting service that provides that infrastructure as a service. Nick <ATT00001..txt> Nick, VMware will/is providing a hosting service based on cloud foundry, but there is an open source variant of cloud foundry that can be used by others to provide hosting services ... Dale

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by Sean Allen

> 11) We currently require infrastructure support for https eg stunnel or > reverse proxy through a webserver eg > http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seas… > actually that link is... http://www.monkeysnatchbanana.com/posts/2010/06/22/faking-a-https-client-fo… just for posterity.

May 18, 2011

Re: [Esug-list] [Seaside-dev] Re: [ANN] SmallHarbour project

by Nick Ager

Hi, We are in the process of adding support for deploying GLASS applications > into the Cloud Foundry, but I wouldn't mind helping folks who are interested > in adding support for other Smalltalks into the Cloud Foundry ... The Cloud > Foundry is written largely in ruby, so you'll need to be wearing your ruby > dancing shoes:) > There certainly a lot of (justified) buzz around CloudFoundry at the moment. Building CloudFoundry infrastructure for Smalltalk deployment would appear to be a great approach - married with a hosting service that provides that infrastructure as a service. Nick

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by Davorin Rusevljan

On Wed, May 18, 2011 at 12:08 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > So what would be better? > > I think a collection of cookbooks would. Maybe defining layers of a web app, > starting from the Browser through all layers of functionality to the data > backend, and collecting material for each of them would be much better. If > I'm interested in a load-balanced, https-aware installation of a Squeak > Image that persists data in Magma, I can choose appropriate documentation > for each layer. Some layers may not be deeply related to Smalltalk at all, > then we could add links to relevant information (like how do I configure > Apache as a load balancer with Sticky sessions?), while others might be > deeply related to Smalltalk. yes, cookbooks would be nice. We also need simple, reliable, no investigation, no fuss, low effort way to deploy most common forms of smalltalk web app or pier blog. If you want fancy stuff you go for recipes or forge one for yourself. But for most common cases it would be great if it would be smooth and reliable. We need distilled, reliable and maintained most common cases, and it seems that this is also one of the goals of SmallHarbour. It is like Linux and its distributions. Linux can be anything, which is great, but distribution makes it much more usable in some domain. just my 2 lipas, Davorin Rusevljan http://www.cloud208.com/

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by Joachim Tuchel

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by laurent laffont

Thanks a lot Nick for your feedback, it is helpful. Laurent. On Wed, May 18, 2011 at 9:46 AM, Nick Ager <nick.ager(a)gmail.com> wrote: > Hi Romain, Laurent, > > >> Having Amazon ec2 image is also a very good idea, and some >>>> Smalltalkers have already made first important steps like: >>>> >>>> >>>> http://www.nickager.com/blog/Create-a-free-Gemstone-server-in-the-cloud-in-… >>>> >>> > After having shared the above Amazon AMI (Amazon machine image), and > experimented with EC2 hosting, I realised there are some undesirable > properties of AMIs: > > 1) It's an image; with all the benefits and problems that entails; namely > either you like the whole thing or not. It's not composable; it's difficult > to know precisely what has been configured and how, and difficult to choose > the bits you like and replace the bits you don't like. > 2) You can't (currently for Linux), create an AMI locally and upload it, > meaning everything has to be performed remotely and operating remotely in > the IDE over X11 forwarding can be slow. > 3) It's difficult to share across regions. Amazon's data centres operate > autonomously. I created the image in EU-WEST and copying it to US-WEST or > US-EAST is non-trivial. > 4) It's another configuration that I need to keep up to date and I don't. > 5) Not everyone wants to use EC2; other cloud services are available eg > slicehost, linode, cloud-foudry etc > 6) I configured the AMI using Amazon Linux, people might prefer Ubuntu, > RHEL, Suse, Windows!#*? etc > 7) I configured the AMI using Nginx as a front-end server with added > modules (http://nickager.com/blog/compiling-nginx-to-add-extra-modules/) > others might require other modules or other different server eg Apache, > Cherokee etc. Even with the same server the configuration required can vary > (url redirection, static file serving etc). > 8) Everyone has a different way of performing backups, monitoring the > health of the server. > 9) I configured the AMI using Gemstone, others might prefer image based > persistence or MySQL, Postgres etc. > 10) Ideally the configuration would allow you to specify the number of > images (or Gems for Gemstone) you'd like to respond to request, behind a > load balancer. > 11) We currently require infrastructure support for https eg stunnel or > reverse proxy through a webserver eg > http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seas… > > Quite a list... The main issue is that I'd like to be able to build server > infrastructure from composable pieces and share configuration knowledge with > others. This led me to Chef (http://opscode.com/chef/) where people create > configuration "recipes" and a specific configuration is composed from these > recipes. The benefit of using something like Chef is that there are > already recipes for the standard parts of the server configuration eg > installing and configuring Apache, Nginx, MySql, Postgres etc have already > been taken care of. Chef abstracts the OS, and the cloud (eg EC2, slicehost > etc). > > The task is then to create recipes for Seaside specific parts. There are a > couple of Gemstone recipes already ( > https://github.com/timfel/gemstone-cookbooks, > https://github.com/johnnyt/gemstone-cookbooks) A few of us (myself > Norbert Hartl, Stephen Eggermont) plan to investigate coding our > configurations is Chef - though it's still early days and it may prove that > it's more complex than we need. > > Our basic requirements are to be able to rapidly deploy production, > staging, backup, Jenkins continuous integration and development VMs. > > Do others have experience with Chef or something similar? > > Ideally ESUG or someone else would provide http://www.heroku.com/ for > Seaside - but it would require formalising more of our stack and providing a > flexible solution to https. > > Hope this helps, > > Nick >

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by Nick Ager

Hi Romain, Laurent, > Having Amazon ec2 image is also a very good idea, and some >>> Smalltalkers have already made first important steps like: >>> >>> >>> http://www.nickager.com/blog/Create-a-free-Gemstone-server-in-the-cloud-in-… >>> >> After having shared the above Amazon AMI (Amazon machine image), and experimented with EC2 hosting, I realised there are some undesirable properties of AMIs: 1) It's an image; with all the benefits and problems that entails; namely either you like the whole thing or not. It's not composable; it's difficult to know precisely what has been configured and how, and difficult to choose the bits you like and replace the bits you don't like. 2) You can't (currently for Linux), create an AMI locally and upload it, meaning everything has to be performed remotely and operating remotely in the IDE over X11 forwarding can be slow. 3) It's difficult to share across regions. Amazon's data centres operate autonomously. I created the image in EU-WEST and copying it to US-WEST or US-EAST is non-trivial. 4) It's another configuration that I need to keep up to date and I don't. 5) Not everyone wants to use EC2; other cloud services are available eg slicehost, linode, cloud-foudry etc 6) I configured the AMI using Amazon Linux, people might prefer Ubuntu, RHEL, Suse, Windows!#*? etc 7) I configured the AMI using Nginx as a front-end server with added modules (http://nickager.com/blog/compiling-nginx-to-add-extra-modules/) others might require other modules or other different server eg Apache, Cherokee etc. Even with the same server the configuration required can vary (url redirection, static file serving etc). 8) Everyone has a different way of performing backups, monitoring the health of the server. 9) I configured the AMI using Gemstone, others might prefer image based persistence or MySQL, Postgres etc. 10) Ideally the configuration would allow you to specify the number of images (or Gems for Gemstone) you'd like to respond to request, behind a load balancer. 11) We currently require infrastructure support for https eg stunnel or reverse proxy through a webserver eg http://www.monkeysnatchbanana.com/posts/2010/06/23/reverse-proxying-to-seas… Quite a list... The main issue is that I'd like to be able to build server infrastructure from composable pieces and share configuration knowledge with others. This led me to Chef (http://opscode.com/chef/) where people create configuration "recipes" and a specific configuration is composed from these recipes. The benefit of using something like Chef is that there are already recipes for the standard parts of the server configuration eg installing and configuring Apache, Nginx, MySql, Postgres etc have already been taken care of. Chef abstracts the OS, and the cloud (eg EC2, slicehost etc). The task is then to create recipes for Seaside specific parts. There are a couple of Gemstone recipes already ( https://github.com/timfel/gemstone-cookbooks, https://github.com/johnnyt/gemstone-cookbooks) A few of us (myself Norbert Hartl, Stephen Eggermont) plan to investigate coding our configurations is Chef - though it's still early days and it may prove that it's more complex than we need. Our basic requirements are to be able to rapidly deploy production, staging, backup, Jenkins continuous integration and development VMs. Do others have experience with Chef or something similar? Ideally ESUG or someone else would provide http://www.heroku.com/ for Seaside - but it would require formalising more of our stack and providing a flexible solution to https. Hope this helps, Nick

May 18, 2011

Re: [Esug-list] [ANN] SmallHarbour project

by laurent laffont

On Tue, May 17, 2011 at 10:48 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > On 05/17/2011 12:37 PM, Davorin Rusevljan wrote: > >> On Tue, May 17, 2011 at 9:19 PM, laurent laffont >> <laurent.laffont(a)gmail.com> wrote: >> >>> Actually we have several visions (nothing is final here, ideas welcome) >>> >> .. >> >> Having Amazon ec2 image is also a very good idea, and some >> Smalltalkers have already made first important steps like: >> >> >> http://www.nickager.com/blog/Create-a-free-Gemstone-server-in-the-cloud-in-… >> >> You probably already have enough on your plate, but I mentioned >> CloudFoundry for following reasons: >> - it has a promise that one would be able to deploy SmallHarbour to >> different cloud providers >> - CloudFoundry currently provides support for Java, Ruby and >> Javascript, adding Smalltalk would be nice for visibility, and could >> be used for other Smalltalk services not only SmallHarbour. >> >> As I said you probably have enough to do in the first place, but if >> you just happen to have some student lurking that has some ruby >> knowledge to hack the interface for Smalltalk to Cloudfoundry it would >> be very nice to have :) >> >> As for your other goals - great! >> >> Davorin Rusevljan >> http://www.cloud208.com/ >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > > Laurent/Davorin, > > We are in the process of adding support for deploying GLASS applications > into the Cloud Foundry, but I wouldn't mind helping folks who are interested > in adding support for other Smalltalks into the Cloud Foundry ... The Cloud > Foundry is written largely in ruby, so you'll need to be wearing your ruby > dancing shoes:) > Thanks Dale, just need to wax my shoes first, haven't worn them for a long time :) Laurent. > > Dale >

May 18, 2011