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

[Pharo-project] Jenkins 502 errors

by Sean P. DeNigris

I found this mailing list post [1] recommending this [2] and this [3] for 502 errors... don't know if it's related to our problem... HTH, Sean [1] http://permalink.gmane.org/gmane.comp.java.hudson.user/39500 [2] http://stackoverflow.com/questions/163603/apache-sockets-not-closing [3] https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache -- View this message in context: http://forum.world.st/Jenkins-502-errors-tp4634147.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 9, 2012

Re: [Pharo-project] [Pharo-users] Fuel FLMethodChanged error

by Mariano Martinez Peck

> >> >> After loading FuelMetaLevel as Martin suggested the above code works to >> serialize and materialize the problematic domain objects just fine. >> > > Ok, just to clarify: when you install the package Fuel only, and in your > graph you have entities like classes or methods, they will be considered > "global", that is, we just store the class name and selector and during > materialization we search it in the Smalltalk globals. If the class/method > is not present, we throw an error. Now...closures are more complicated > because you can even EVALUATE them. If the method surrounding the closure > has changed in the image you are materializing, evaluating the closure > (depending on the change in the method) can even crash your VM. Because of > that, when serializing methods "as globals" we also store a chemsum and we > compare during materialization to see that it hasn't change it. If changed, > we throw the FLMethodChanged. > With the package FuelMetalevel, and by using #newFull the serializer will > consider the method as "full" so it will be fully serialized, and therefore > you don't have the problem of the checksum. > > Anyway, you found a bug because you should not be needing FuelMetalevel > since you are serializing and materializing in the same image. > > Ok...the problem was when you are using the normal (light) serialization with Fuel where methods are always serialized as global. In your case, the method was "not installed" and therefore, was different during materialization. I have just commited Fuel-MarianoMartinezPeck.695. If you know try to serialize again your example, you should get a FLNotInstalledMethod error saying " #XXXSelector can not be serialized as global because it is not installed. You need FuelMetalevel to fully serialize methods. See the documentation. '" And now in http://rmod.lille.inria.fr/web/pier/software/Fuel/Errors I have added that exception and its explanation: * ** FLNotInstalledMethod** By default, Fuel serializes methods as globals. For more details see this page<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/…>. I am an error produced during serialization, signaled when trying to serialize a method that is not installed in any class. It is a prevention, because such method is lekely to be absent during materialization. This case may happen when serializing closures that hold references to not installed methods. If the user wants to fully serialize methods, then it needs to install the package FuelMetalevel (see this page for explanations<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/…>) and create the serializer by using the method #newFull. Example:* * FLSerializer newFull serialize: anObject toFileNamed: 'example'.* Cheers > We will investigate it. > > Thanks > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 9, 2012

[Pharo-project] [update 2.0] #20122

by StÃ©phane Ducasse

20122 ----- - Issue 6044: Nautilus Method Rename. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=6044 - Issue 5487: Deferring the calculation of the failure description string in TestCases. Thanks Stefan Marr. http://code.google.com/p/pharo/issues/detail?id=5487 + cleaning all hardcoded references to TestResult, TestResource and TestSuite. - Issue 6049: Monticello Browser repository List and repositories out of sync when searching. Thanks Dan Uber. http://code.google.com/p/pharo/issues/detail?id=6049

June 9, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Sean P. DeNigris

Guillermo Polito wrote > > Actually, nabble forum is kind of read only. If you post in there, the > messages are not forwarded to the mailing list. The messages will be forwarded if you are subscribed to the underlying list. Join the DBXTalk group at https://groups.google.com/forum/#!forum/dbxtalk and you will be able to post through either google or nabble. Sean -- View this message in context: http://forum.world.st/Re-Pharo-users-loading-order-for-seaside-DBXTalk-Magr… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 9, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Guillermo Polito

On Sat, Jun 9, 2012 at 11:05 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <camsanders(a)aol.com>wrote: > >> >> >> On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders < >> csanders(a)debrispublishing.com> wrote: >> >>> I keep having problems with configurations. The documentation for each >>> particular tool looks so simple, and seems to work all by itself, but for >>> some reason, I keep failing at having one 1.4 (or 1.3) image where >>> everything works (e.g. Glorp AND seaside AND DBXTalk); though I do have 3 >>> different images where 2-out of three work, so by revolving my dev process >>> through the images, >>> >> > what is *exactly* what does not work? otherwise we cannot guess. > > > >> I can make headway... but there must be a better way. Especially given >>> that those images contain different versions of the tools and core image. >>> >>> > I don't use Seaside. Why don't you provide the whole gofer script you use > to install those 3 tools so that someone can reproduce it? > > >> Is there someone who has all three tools (Glorp, DBXTalk & Magritte, and >>> Seaside) coexisting and playing well together in a 1.4 (or 1.3) image? >>> Could you please drop me an email? >>> >>> > I attach the Pharo development mailing list. > > > >> I also want to use Fuel for some things. >>> >>> How much money would I need to donate to Pharo per year, so that the >>> recipients would make available an image meeting my (see above) specs with >>> the recommended patterns working? With updates available every 3 months, >>> for example. >>> >> >> [if i pay for something, deducting the money from my taxable income is no >> problem.] >> >>> >>> I am sure there are a few common configurations that people would like. >>> Part of the problem of course is the explosion of tools! Nice work >>> everybody!! >>> - >>> >>> Who would be the DBXTalk expert? >>> >> > Me, Guillermo Polito, Esteban Lorenzano and many others. > > >> For some reason I am unable to post on the nabble forum -- oddly, a >>> private thread of emails I shared with Pamela ended up there, but I cannot >>> seem to post directly. I keep trying to join, but nabble never lets me in. >>> [I must be making another stupid mistake...] >>> >>> > We didn't receive any email from you. Yuo should register in this google > group: http://groups.google.com/group/dbxtalk/?pli=1 > Actually, nabble forum is kind of read only. If you post in there, the messages are not forwarded to the mailing list. Here are other links of interesting resources: http://dbxtalk.smallworks.com.ar/Support/?_s=sl3ptC0z84u54Hyk&_k=y49B2OsTLC… > > >> I have a few fixes for DBXTalk: the Magritte descriptions generation (I >>> switched Array output code-generation to the {...} format instead of #( >>> ...) which was not allowing #conditions: to be properly formatted, which >>> may be a problem for other smalltalk environments), and other trivial fixes. >>> >> > Excellent!!! :) Thanks. Can you send us the changes or directly commit? > > >> - >>> Any help or guidance you can provide is most welcome! >>> >>> -Cam Sanders >>> 603-412-2134 >>> PS: any pharo smalltalkers right here in New Hampshire, USA? >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com > >

June 9, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Mariano Martinez Peck

On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <camsanders(a)aol.com> wrote: > > > On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders < > csanders(a)debrispublishing.com> wrote: > >> I keep having problems with configurations. The documentation for each >> particular tool looks so simple, and seems to work all by itself, but for >> some reason, I keep failing at having one 1.4 (or 1.3) image where >> everything works (e.g. Glorp AND seaside AND DBXTalk); though I do have 3 >> different images where 2-out of three work, so by revolving my dev process >> through the images, >> > what is *exactly* what does not work? otherwise we cannot guess. > I can make headway... but there must be a better way. Especially given >> that those images contain different versions of the tools and core image. >> >> I don't use Seaside. Why don't you provide the whole gofer script you use to install those 3 tools so that someone can reproduce it? > Is there someone who has all three tools (Glorp, DBXTalk & Magritte, and >> Seaside) coexisting and playing well together in a 1.4 (or 1.3) image? >> Could you please drop me an email? >> >> I attach the Pharo development mailing list. > I also want to use Fuel for some things. >> >> How much money would I need to donate to Pharo per year, so that the >> recipients would make available an image meeting my (see above) specs with >> the recommended patterns working? With updates available every 3 months, >> for example. >> > > [if i pay for something, deducting the money from my taxable income is no > problem.] > >> >> I am sure there are a few common configurations that people would like. >> Part of the problem of course is the explosion of tools! Nice work >> everybody!! >> - >> >> Who would be the DBXTalk expert? >> > Me, Guillermo Polito, Esteban Lorenzano and many others. > For some reason I am unable to post on the nabble forum -- oddly, a >> private thread of emails I shared with Pamela ended up there, but I cannot >> seem to post directly. I keep trying to join, but nabble never lets me in. >> [I must be making another stupid mistake...] >> >> We didn't receive any email from you. Yuo should register in this google group: http://groups.google.com/group/dbxtalk/?pli=1 > I have a few fixes for DBXTalk: the Magritte descriptions generation (I >> switched Array output code-generation to the {...} format instead of #( >> ...) which was not allowing #conditions: to be properly formatted, which >> may be a problem for other smalltalk environments), and other trivial fixes. >> > Excellent!!! :) Thanks. Can you send us the changes or directly commit? > - >> Any help or guidance you can provide is most welcome! >> >> -Cam Sanders >> 603-412-2134 >> PS: any pharo smalltalkers right here in New Hampshire, USA? >> >> -- Mariano http://marianopeck.wordpress.com

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Mariano Martinez Peck

On Sat, Jun 9, 2012 at 8:05 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Not used as offset in DateAndTime, Durations can be anything, both > negative as well as positive, like in > > '2010-01-02' asDate - '2012-06-08' asDate > > '2010-01-02' asDate - DateAndTime now > > Ok, thanks Sven. > On 09 Jun 2012, at 19:53, Mariano Martinez Peck wrote: > > > > > > > On Sat, Jun 9, 2012 at 2:53 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > > > On 09 Jun 2012, at 14:24, Mariano Martinez Peck wrote: > > > > > The seconds/nanoseconds are always positive when normalized. > > > > > > Are you sure? > > > I have just changed (for testing) to this: > > > > > > DateAndTime localTimeZone: (TimeZone timeZones detect: [:tz | tz > abbreviation = 'EST']). > > > > > > And now if I do: > > > > > > DateAndTime now offset asSeconds ----> -18000 > > > > The seconds/nanoseconds in DateAndTime itself are like that, > > the TZ offset can be positive and negative: > > > > http://en.wikipedia.org/wiki/Timezone > > > > <<Most of the 40 time zones on land are offset from Coordinated > Universal Time (UTC) by a whole number of hours (UTC-12 to UTC+14), but a > few are offset by 30 or 45 minutes.>> > > > > > > > > Ok, perfect. And what about durations outside DateAndTime. Say if I do: > "-123 seconds" is that valid? I mean, should we accept normal durations > (not the instVar offset of a DateAndTime) with negative seconds/nanoseconds? > > > > thanks > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

June 9, 2012

Re: [Pharo-project] recompiling class

by Eliot Miranda

On Sat, Jun 9, 2012 at 5:10 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jun 9, 2012, at 8:26 AM, S Krish wrote: > > > > > > > Can we do this in Pharo: > > > > "in Java, the computation of numeric o ffsets for instance elds in > memory is done by > > the run-time system. This permits updating a class with new instance > elds or methods without > > aff ecting existing code. In other words, it is possible to run an > existing bytecode fi le for a subclass > > after updating and recompiling the class, but without recompiling the > subclass." > > Hello, > > In Smalltalk, not only *new* instances get the changed > class layout, but *all* existing ones are migrated. > > There is always just one version of a class in the system, all instances > are of that version. > > Thus, if you add a instvar in a superclass, the iVar offsets of the > subclasses have to be > fixed. Right now this is done by recompiling the all subclasses, but you > could be much > more intelligent: filter for those methods that actually reference ivars > and then don't recompile > but just change the offset. > > This "just" is more difficult than it seems: changing an offset can mean > that the bytecode > needed is larger (2 instead of 1), and that then means jump offsets need > to be changed. > Which in turn can mean that the larger jump needs more bytecode, too.. > > So in practice, the best is to decompile to an Intermediate Representation > that is at the > level of bytecode, yet abtracts away jumps and the decision of which > bytecode exactly it used. > > For the backend of Opal, I did some crude benchmark for Martin this week: > Decompiling to IR and re-generating of all methods in Morph that access > iVars takes 0.8 seconds... > and how long does recompiling all Morph methods take? Marcus, I'm eager to port your code to Squeak. Would that be OK? > > We will add the IR backend to 2.0 soon and the new ClassBuilder will use > it. > > But in general, it would be nice to late-bind the offsets and just use > names in the representation > that a method is saved in. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Sven Van Caekenberghe

Not used as offset in DateAndTime, Durations can be anything, both negative as well as positive, like in '2010-01-02' asDate - '2012-06-08' asDate '2010-01-02' asDate - DateAndTime now On 09 Jun 2012, at 19:53, Mariano Martinez Peck wrote: > > > On Sat, Jun 9, 2012 at 2:53 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 09 Jun 2012, at 14:24, Mariano Martinez Peck wrote: > > > The seconds/nanoseconds are always positive when normalized. > > > > Are you sure? > > I have just changed (for testing) to this: > > > > DateAndTime localTimeZone: (TimeZone timeZones detect: [:tz | tz abbreviation = 'EST']). > > > > And now if I do: > > > > DateAndTime now offset asSeconds ----> -18000 > > The seconds/nanoseconds in DateAndTime itself are like that, > the TZ offset can be positive and negative: > > http://en.wikipedia.org/wiki/Timezone > > <<Most of the 40 time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours (UTCâ12 to UTC+14), but a few are offset by 30 or 45 minutes.>> > > > > Ok, perfect. And what about durations outside DateAndTime. Say if I do: "-123 seconds" is that valid? I mean, should we accept normal durations (not the instVar offset of a DateAndTime) with negative seconds/nanoseconds? > > thanks > > > -- > Mariano > http://marianopeck.wordpress.com >

June 9, 2012

Re: [Pharo-project] What can be negative regarding timezones with date-related objects?

by Mariano Martinez Peck

On Sat, Jun 9, 2012 at 2:53 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 09 Jun 2012, at 14:24, Mariano Martinez Peck wrote: > > > The seconds/nanoseconds are always positive when normalized. > > > > Are you sure? > > I have just changed (for testing) to this: > > > > DateAndTime localTimeZone: (TimeZone timeZones detect: [:tz | tz > abbreviation = 'EST']). > > > > And now if I do: > > > > DateAndTime now offset asSeconds ----> -18000 > > The seconds/nanoseconds in DateAndTime itself are like that, > the TZ offset can be positive and negative: > > http://en.wikipedia.org/wiki/Timezone > > <<Most of the 40 time zones on land are offset from Coordinated Universal > Time (UTC) by a whole number of hours (UTC-12 to UTC+14), but a few are > offset by 30 or 45 minutes.>> > > > Ok, perfect. And what about durations outside DateAndTime. Say if I do: "-123 seconds" is that valid? I mean, should we accept normal durations (not the instVar offset of a DateAndTime) with negative seconds/nanoseconds? thanks -- Mariano http://marianopeck.wordpress.com

June 9, 2012