June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

One thing I do not see mentioned, and feel could use some attention, is thread safety. (aka other threads altering the graph you are serializing) > The classic answer would of course be "always run FUEL at highest > priority", but if we ever want to move to true multi-core, that's not > enough. > > Wow. Were you reading our minds?? hehehe. Yes, reading some of the related work papers while writing our own paper, we read about the "atomicy". How to be atomic while analyzing and serializing? Right now, if the graph changes between the first phase (analysis) and the second phase (serializating) you are screw :) I wonder if Eliot fixed that in Parcels? What would be neat is protecting all mutation of objects in the graph with a > Mutex/Monitor whose critical section covers the analysis and serialization, > i.e. blocking all other processes that wants to mutate objects in the graph > untill serialization is complete. > > yes, > Aside from the behaviour when a marked object is encountered, the process > is the same as for immutability, as discussed here: > http://forum.world.st/**immutability-and-become-Was-** > Re-squeak-dev-immutability-**td1597511.html<http://forum.world.st/immutability-and-become-Was-Re-squeak-dev-immutabilit…> > > You could do this image-side as part of the analyze phase, as Eliot's post > suggests, Ok, but in order to do I need the immutable bit in the ObjectHeader, right? > but it's not entirely safe when: > A child -> B > B parent -> A > > 1 . Process1 protects A with Mutex > 2. Process2 calls method on B which does: > a) B parent: C > b) (B's tmpRef to A) child: somethingElse *Wait for Mutex* > 3. Process 1 makes B, C immutable, serializes B with C as parent. > 4. Process2 changes A child. > > It could of course be argued that is a programming/logic error to update B > parent ref before child ref in A, (you'd actually have to do extra work to > get that order), still it's a hard one to debug if it does happen. > (Note to the thread: Following the same logic, I would also say it should > be considered an error to keep a mutable cache as part of an immutable > object :) ) > > In fact, you *could* implement it with immutability, injecting handler > contexts with behaviour as described above into existing/new processes for > any resulting immutability errors. > > wow. Seems a really complicated stuff to deal with :( Immutability is not yet present in default VMs -- Mariano http://marianopeck.wordpress.com

June 20, 2011

Re: [Pharo-project] Zinc Updates

by StÃ©phane Ducasse

Can you start to create an account on gforge.inria.fr (RMOD team) ? And let me know. Stef On Jun 20, 2011, at 2:44 PM, Sven Van Caekenberghe wrote: > > On 20 Jun 2011, at 13:33, StÃ©phane Ducasse wrote: > >> Thanks >> >> we will integrate them. > > OK, great. > >> We should show you how you could do it, if you are interested. > > Yes, but probably best face to face on some future Pharo code sprint, I would not want to mess up everything ;-) > > Sven > >

June 20, 2011

Re: [Pharo-project] About not using full Pharo

by Hilaire Fernandes

Le 19/06/2011 22:38, Damien Cassou a Ã©crit : > Hi, > > I've read that some of you are installing their own set of packages on > top of Pharo-Core and not using Pharo. Why is that so? What don't you > like in Pharo? Why didn't you tell us before? I switch to Pharo core because I use a different version of XML package (an older one). Not a really good reason, but I found easier to take core and install the package I need with a script. Hilaire

June 20, 2011

Re: [Pharo-project] [squeak-dev] Re: [ANN] StOMP - Yet another multi-dialect object serializer

by Mariano Martinez Peck

2011/6/20 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi Masashi, > > Now we have a competition, Fuel vs. StOMP :) Big advantage of StOMP is > that it is portable and already ported to VW. Which are other > advantages? Disadvantages? > > Also question for Fuel developers, do you plan to port it to other > Smalltalks too? Portability is namelly something which is very high on > checking list for a serializer to use in portable projects, like most of > web ones are. > Hi Janko. I think "portability" is to wide to just talk without details. For me, portability in this case means two things: a) In a dialect XXX be able to materialize a stream which was serialized in a dialect YYY: b) that the code of the serializer can also work in another dialect (not necessary including a) ). Fuel will not support a) for sure. At least, we will not do extra effort to support that. Regarding b), it is not Fuel first feature to be portable to other dialects. But let me explain it: - We want to be able to serialize ANY kind of object, that includes BlockClosure, CompiledMethod, MethodContext, Class, Trait, etc.... Finding a abstract and portable representation for those objects across dialects is complicated. - We want to be as fast as possible. That means that if we find a way to be faster which only works in Pharo, we don't care. We will go ahead with that. That being said, I have to say that Fuel OO design, from my point of view, is quite nice, easy to understand, and not difficult to port. As an example, Eliot Miranda easily not even port Fuel to another dialect but to Newspeak. And even more, he needed special management for Newspeak data, and he was able to easily adapt Fuel for his needs. So....from in this case Fuel was portable (in the sense of b) and flexible. Another difference is that we try to be a little faster in materialization than in serialization (which is not the case of StOMP). So in summary, the differences I can see are: 1) StOMP is focus in portability across dialects and also be able to materialize the same stream in different dialects. Fuel is not focus on portability even if it could be portable in the sense of the code. 2) StOMP is faster in serializing small/medium graphs. Fuel is faster in large graphs. 3) StOMP is faster in serializing while Fuel in materializing. 4) StOMP can serialize some objects (cannot right now BlockClosures or things like that), Fuel can (or should) be able to serialize all. That's all I can see for the moment. But don't worry, there is no fight. We have been sending each other several mails this and the previous week and tried to shared knowledge between :) Cheers > > Best regards > Janko > > S, Masashi UMEZAWA piÅ¡e: > > Hello all, > > > > I have recently developed a new serialization library called > > StOMP(Smalltalk Objects on MessagePack). > > http://stomp.smalltalk-users.jp/ > > > > StOMP is a binary serializer for major Smalltalk dialects. For those > > who know SIXX, StOMP can be seen as a binary SIXX. While SIXX > > represents object data as XML, StOMP uses MessagePack. By combining > > the flexibility of SIXX with the compactness of MessagePack, StOMP > > aims to be a unique, next-generation portable serializer for > > Smalltalk. > > > > Features: > > - Implementation is compact and portable > > - Shared/circular references support > > - "Class shape changes" support > > - Data is interchangable between Smalltalk dialects > > - Good performance for small sized object graph > > > > StOMP is now available for Squeak, Pharo, and VisualWorks. > > > > There is ConfigurationOfStOMP, so the installation is easy. > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfStOMP'; > > load. > > (Smalltalk at: #ConfigurationOfStOMP) perform: #load. > > > > Enjoy! > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > -- Mariano http://marianopeck.wordpress.com

June 20, 2011

Re: [Pharo-project] Zinc Updates

by Sven Van Caekenberghe

On 20 Jun 2011, at 13:33, StÃ©phane Ducasse wrote: > Thanks > > we will integrate them. OK, great. > We should show you how you could do it, if you are interested. Yes, but probably best face to face on some future Pharo code sprint, I would not want to mess up everything ;-) Sven

June 20, 2011

Re: [Pharo-project] ZnServer - Swazoo - Comanche

by Janko MivÅ¡ek

Hi guys, For Swazoo it would be fine to merge its HTTP framework with something else and here I see two possibilities, one from WebClient and another from Zinc. That way we can achieve the same HTTP library for both Swazoo and Zinc or WebClient tools. And later for web frameworks too, no need to transform requests and responses from/to framework specific ones as it is a case now. Main goal of Swazoo is to serve one or more virtual websites directly to the public Internet as optimal and reliable as possible, next goal is wide cross-dialect portability. Swazoo is doing that job reliably for 11 years now, so it will certainly stay there to continue. Just that it would be nice to improve it from time to time and having now Zinc and WebClient on hand it is a just nice opportunity for thinking about such a merge. Best regards Janko S, Sven Van Caekenberghe piÅ¡e: > Hello GermÃ¡n, > > On 19 Jun 2011, at 16:14, GermÃ¡n Arduino wrote: > >> Hi Sven, People: >> >> I want to ask about ZnServer, is focused in have at some point all the >> features of Swazoo or Comanche and being itself a complete web server? >> >> Or the goal is only to be a default implementation, as the comment says? >> >> Thanks. >> GermÃ¡n. > > From my point of view, the goal of Zn is to be a framework implementing the HTTP protocol and a library on top of that offering client and server functionality based mainly on RFC 2616. > > The server part is kept relatively simple: the server does multithreading, connection handling, request parsing and response writing and then asks its delegate to do the work, using #handleRequest: which is given a ZnRequest as argument and is expected to return a ZnResponse. > > The code doing the #handleRequest can be simple, like in the examples that are included, but could become arbitrarily complex, like Apache. > > Anyone is free to build on top of Zn whatever they think makes sense, most of this will probably be more application specific and hence out of the scope of Zn. > > The Seaside adaptor is a good example: it is an add-on. Seaside expects very little from its servers and Zn is offering slightly more than needed. Still, the Seaside experience is quite rich to say the least. > > I don't consider Swazoo or Comanche competition, they offer more features but also specific API's. > > Another goal of Zn is understandability: I would like the Zn code to be readable by anyone interested in HTTP. > > Sven > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

June 20, 2011

Re: [Pharo-project] pharo/linux/alien

by Alexandre Bergel

Ok. Thanks for sharing your experience Alexandre Le 20 juin 2011 Ã 04:49, danil osipchuk <danil.osipchuk(a)gmail.com> a Ã©crit : > Argh, just noticed recent email from Eliot about new vm (I've been in a digest mode). > printf examples work there(qsort prim fails but that's probably not a vm issue) > > 2011/6/20 danil osipchuk <danil.osipchuk(a)gmail.com> > Hello, all > > Is there a combination of Pharo image, linux vm and alien packages which is known to be working? > > I've tried one-click 1.2.1 Pharo releases with following: > > Gofer it > squeaksource:'MetacelloRepository' ; > package: 'ConfigurationOfAlien'; > load. > > ConfigurationOfAlien loadCore. > ConfigurationOfAlien loadTests. > ConfigurationOfAlien loadLibC. > > > Both cog and plain-vm releases load the above fine. However the plain vm doesn't have IA32ABI in >>Smalltalk listBuiltinModules (neither does have external plugin) and cog vm segfaults on every example i tried. Any clues? > > regards, > Danil > > Segmentation fault Mon Jun 20 12:24:14 2011 > > > C stack backtrace: > ./Contents/Linux/squeakvm[0x805ad7a] > ./Contents/Linux/squeakvm[0x805b0ef] > [0xb77cd40c] > /lib/i686/cmov/libc.so.6(_IO_vfprintf+0x133)[0xb7638773] > /lib/i686/cmov/libc.so.6(vsprintf+0x8c)[0xb765a34c] > /lib/i686/cmov/libc.so.6(sprintf+0x2b)[0xb764255b] > ./Contents/Linux/squeakvm(callIA32IntegralReturn+0x2bd)[0x80fbdf9] > ./Contents/Linux/squeakvm[0x80fba1c] > ./Contents/Linux/squeakvm[0x806bcf5] > ./Contents/Linux/squeakvm[0x8086a84] > ./Contents/Linux/squeakvm(interpret+0x5ea5)[0x8063d15] > ./Contents/Linux/squeakvm[0x8072e1d] > ./Contents/Linux/squeakvm[0x8078c9d] > ./Contents/Linux/squeakvm(interpret+0x18)[0x805de88] > ./Contents/Linux/squeakvm(main+0x266)[0x805cf37] > /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb760f455] > ./Contents/Linux/squeakvm[0x8059fd1] > > > Smalltalk stack dump: > 0xbfb33bdc I LibCLibrary>sprintfWithArguments: 2027450576: a(n) LibCLibrary > 0xbfb33c0c I AlienExamples>exampleSprintf 2027449520: a(n) AlienExamples > 0xbfb33c24 M AlienExamples class>? 2022153212: a(n) AlienExamples class > .... cut > basicNew: > sizeFieldPut: > addressFieldPut: > primFFICallResult:withArguments: > Aborted > > >

June 20, 2011

Re: [Pharo-project] Zinc Updates

by StÃ©phane Ducasse

Thanks we will integrate them. We should show you how you could do it, if you are interested. Stef On Jun 20, 2011, at 1:24 PM, Sven Van Caekenberghe wrote: > Marcus, > > On 20 Jun 2011, at 10:39, pharo(a)googlecode.com wrote: > >> I have to admit I am confused what what to load. >> >> Can someone put the version(s) in the inbox? > > I worked on the following issues lately: > > Zinc does not honour network proxy configuration.... > > http://code.google.com/p/pharo/issues/detail?id=4417 > > Connection timeout problem > > http://code.google.com/p/pharo/issues/detail?id=4326 > > New mechanism for Zinc servers' start/stop handling after system startUp/shutDown > > http://code.google.com/p/pharo/issues/detail?id=4428 > > Loading the lastest version of Zn should include all of these, > there are seperate commits for each. > > HTH, > > Sven >

June 20, 2011

Re: [Pharo-project] About not using full Pharo

by StÃ©phane Ducasse

>> The point is that we should be able to have good tools inside the default system so that we can get faster. >> We are fedup to do refactoring of core manually. > > You have a build server that builds PharoCore and Pharo images > immediately and all the time. So, why are you not improving the system > in Pharo and immediately let your servers build experimental PharoCore > and Pharo images right after you commit? If tests pass the files get > propagated and generate the official builds. The point is that when I work with core right now we do not have RB loaded. So a pain ;) Now if we work on Pharo (RB loaded) and change RB (we will have to do that for RPackage for example). How do I publish, reload everything? I want to close the loop because it should be possible and that jenkins does all the job for me. Right now scriptLoader does not deal with external packages and dependencies So we could do it but we will lose all the effort in making these external packages loadable outside of the "pharo" image. So this is why I proposed. > seed + MetacelloSpec + modification => seed' + MetacelloSpec' > > and that we are able to build hudson that takes > aSeed + a spec > => run all the tests + run all the quality check > > Right now we have > seed + list of package + modification => seed' + list of package' > > and we get in trouble when we modify seed parts that influence external package This way: pharo hardcore like us can work with the tools at full speed. And other people can make sure that they can load the tools we use and modified in the different version of the images using Metacello and the dependencies management (the scary part of packages for me). > As long as Pharo packages are clean without any overrides there should > be no problem (this is the case with my builds). Yes more or less because dependencies between versions will be evil and kill us if we do not pay attention. > If you remember, we did together some refactorings while I was visiting you in Lille last year. Yes but I got stuck :( I should invest throwing away scriptLoader :) Mariano, Guillermo I would love to have a Metacello conf for Pharo (old pharo-core). And that the system generate it for me. Ok I will invest in that.... Argh. Now I spent 1/3 of my time in meetings (as lab representent reagrh....). Stef (I will survive). > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

June 20, 2011

Re: [Pharo-project] Zinc Updates

by Sven Van Caekenberghe

Marcus, On 20 Jun 2011, at 10:39, pharo(a)googlecode.com wrote: > I have to admit I am confused what what to load. > > Can someone put the version(s) in the inbox? I worked on the following issues lately: Zinc does not honour network proxy configuration.... http://code.google.com/p/pharo/issues/detail?id=4417 Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 New mechanism for Zinc servers' start/stop handling after system startUp/shutDown http://code.google.com/p/pharo/issues/detail?id=4428 Loading the lastest version of Zn should include all of these, there are seperate commits for each. HTH, Sven

June 20, 2011