- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Epoch returns local offset

by David T. Lewis

(cross posting to squeak-dev) On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote: > > David T. Lewis wrote > > > > So no, it is not a constant. > > > > Let me rephrase: wouldn't it be better if it was a constant, like dos and > unix? Yes it would be better if the Smalltalk epoch was an unambiguously defined value, but unfortunately it is not. That is the reason that the clearly defined Posix epoch would be a more suitable basis for these calculations. <ot> Funny that you should mention DOS. DOS has exactly the same problem as Squeak/Pharo in this regard. It was originally designed as a simple single-user system, where the user was expected to set the clock properly on all of his/her alarm clocks, kitchen appliances, and computers. It has no knowledge of time zones or daylight savings time, and this leads to all sorts of bugs in applications running on MS-DOS that assume that the system time is correct. I was dealing with a real-life bug of this sort last week that had people spending huge amounts of time and energy trying to figure out what was causing clocks to be "reset" in a complex multi-platform application that happened to include some old DOS based computers that were sending time stamped messages. </ot> > I find the current behavior confusing e.g. > > dt := '1/15/2012 0000+00:00' asDateAndTime. > > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation > = 'PDT' ]). > s := dt asSeconds. "3504013200" > > "Now I move to Greenwich" > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation > = 'UTC' ]). > DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!" > Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901" which by definition cannot be correctly implemented. One solution would be to gain agreement among all flavors of Smalltalk as to the proper definition of the Smalltalk epoch. But it seems to me that it would be vastly simpler to just use a definition that is already agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" behind as an interesting historical artifact. Dave

May 17, 2012

Re: [Pharo-project] Pharo is exploding[SEC=UNCLASSIFIED]

by Stephen Taylor

On Wed, 2012-05-16 at 08:31 -0700, Francois Stephany wrote: > > Yes let us create a core-dev private mailing-list. > > > Please don't. > > Just force people to use pharo-users when the question does not fit the > criteria for pharo-project. Agreed. I like to see what's going on, even if I can't currently participate. Steve

May 17, 2012

Re: [Pharo-project] Moving data into new package/image version

by Igor Stasenko

A bit tangent to your problem, Sean. Just want to tell you trick which i use: Rule #1. never make more than 1 reference to any class external to your package in your code. an exception is kernel classes. which means, that you are allowed to do 'Set new' or 'Array new', in any place of your code but never 'SomeFooClass new' more than once. If your code having such dependency, localize it in single method: fooClass ^ FooClass and then use 'self fooClass' everywhere.. Like that, if you will figure out one day, that sand moves under your feets, you'll have to change only single method. :) -- Best regards, Igor Stasenko.

May 16, 2012

Re: [Pharo-project] [Moose-dev] Collection>>difference: behaviour in 1.4 (was Re: Jenkins build is still unstable: moose-latest-dev #972 )

by Alexandre Bergel

Well done Ben!!! Thanks Doru for producing a new version of of the layout. It is now in the version 2.157 of Mondrian. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 16, 2012, at 2:44 PM, Tudor Girba wrote: > Excellent hunting! > > I think this is a conceptual bug in the current Pharo implementation. > > Anyway, I fixed it now (and added a comment): > > MOAbstractGraphLayout>>childrenFor: aNode except: aNodeCollection > > ^(self childrenFor: aNode) > reject: [:each | aNodeCollection includes: each] > > "we are explicitly not using the default Collection>>difference: behavior here because we want to preserve the order of the collection" > > Thanks, > Doru > > > > On 16 May 2012, at 18:22, Ben Coman wrote: > >> This discussion originates from Mondrian on Moose 4.7 where layouts which previously were exactly reproducible now randomly alternate between two arrangements. I have cross-posted since upstream behaviour of Collection>>difference: has changed between Pharo 1.3 and 1.4. >> >> The issue in Mondrian has been isolated so that it can be observed using the attached changeset 'isolate-unstable-972.2.cs' against a fresh Moose 4.7 image downloaded a few moments ago. >> After loading the cs, open a Transcript and then <Generate> the following script in Modrian Easel a dozen times. >> view shape label. >> view nodes: #(1 2 3 4 ). >> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}. >> view treeLayout >> >> At some point you will see a change in the order that nodes are drawn between runs as reflected in lines B2 and A2 shown below... >> ------------------------------RUN 1 >> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3) >> B2>an OrderedCollection(a MONode model: 3 a MONode model: 2) >> A2>a MONode model: 1 >> A2>a MONode model: 3 >> A2>a MONode model: 4 >> A2>a MONode model: 2 >> ------------------------------RUN 2 >> B1>an OrderedCollection(a MONode model: 2 a MONode model: 3) >> B2>an OrderedCollection(a MONode model: 2 a MONode model: 3) >> A2>a MONode model: 1 >> A2>a MONode model: 2 >> A2>a MONode model: 3 >> A2>a MONode model: 4 >> ------------------------------END >> >> >> The cause of this is a change in behaviour of Collection>>#difference: between Pharo 1.3 & 1.4. This can be observed by executing the following in Workspace... >> 20 timesRepeat: >> [ >> one := TextMorph new newContents: '1'. >> two := TextMorph new newContents: '2'. >> collection := (OrderedCollection with: one with: two). >> diff := collection difference: OrderedCollection new. >> Transcript crShow: diff first text, diff second text. >> ] >> >> In Pharo 1.3 the result never deviates from '12'. >> In Pharo 1.4 the result is sometimes '21'. >> >> Pharo 1.3 has... >> Collection>>difference: aCollection >> "Answer the set theoretic difference of two collections." >> ^ self reject: [:each | aCollection includes: each] >> >> Pharo 1.4 has... >> Collection>>difference: aCollection >> "Answer the set theoretic difference of two collections." >> | set| >> set := self asSet. >> aCollection do: [ :each| >> set remove: each ifAbsent: []]. >> ^ self species withAll: set asArray >> >> >> Your thoughts? >> >> cheers -ben >> >> >> Tudor Girba wrote: >>> Could it be a Pharo issue, because I think it happened since we moved to Pharo 1.4. >>> >>> Doru >>> >>> >>> On 15 May 2012, at 21:51, Alexandre Bergel wrote: >>> >>> >>> >>>> Wellâ¦ this happens since the changes in the collection hierarchy a few weeks ago. >>>> The tree layout should indeed preserver the order. I spent some time but I could not see where the problem came from. I should spent some more time on this. >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel >>>> http://www.bergel.eu >>>> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> On May 13, 2012, at 11:21 PM, Tudor Girba wrote: >>>> >>>> >>>> >>>>> Thanks, Alex. >>>>> >>>>> But, it is not good in this case to fix the tests because the rendering should remain the same :(. >>>>> >>>>> For example, in the MetaBrowser I rely on the fact that the tree rendering remains the same to highlight the currently selected property. >>>>> >>>>> We need to investigate this issue closer because it is an important bug. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 14 May 2012, at 04:04, Alexandre Bergel wrote: >>>>> >>>>> >>>>> >>>>>>>> I've seen you committed in the Mondrian rep about the rubber band drag and drop facilities. This is indeed an interesting feature. However, I feel a bit more work is necessary. Here are my suggestions: >>>>>>>> - can you make sure all the Mondrian tests are green. Apparently MORoot>>resetFormCacheResursively disappeared. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Do you mean MONode>>resetFormCacheResursively which was renamed in Mondrian-Core-AlexandreBergel.79 ? >>>>>>> I've searched back a few Mondrian-Core mcz files and not found MORoot>>resetFormCacheResursively. >>>>>>> I fixed a few remaining references to this in Mondrian-Core-BenComan.80 et al. >>>>>>> >>>>>>> >>>>>>> >>>>>> Ok, I've produced a new version of Mondrian that includes your changes. >>>>>> >>>>>> >>>>>> >>>>>>> I fixed MOLayoutTest>>testTreeLayout failure in Mondrian-Tests-BenComan.101. >>>>>>> There is one remaining failure that I can't work out. TestRunner cannot open a debugger on it and after inserting 'self halt' it steps through to the end of the method without a failure. Makes no sense to me. I need to leave this one to others. >>>>>>> >>>>>>> >>>>>>> >>>>>> The tree layout seems to randomly order the nodes. Type the following script in an easel: >>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>>> view shape rectangle withText. >>>>>> view nodes: #(1 2 3 4 ). >>>>>> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}. >>>>>> view treeLayout >>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>>> >>>>>> Times to times it produces: >>>>>> <Screen Shot 2012-05-13 at 10.02.08 PM.png> >>>>>> >>>>>> times to times it produces: >>>>>> <Screen Shot 2012-05-13 at 10.02.16 PM.png> >>>>>> >>>>>> A few weeks ago, it had always produced the same rendering, and tests had been written accordingly. Now it varies, so tests have to be adjusted. I fixed this. >>>>>> The test is now green. >>>>>> >>>>>> >>>>>>>> - add new tests that capture your change of MOCanvas>>mouseUp: , MOCanvas>>mouseOver:, and possibly for MOCanvas>>drawOn:. Those methods are central to Mondrian, they need to be robust. >>>>>>>> >>>>>>>> >>>>>>> I will now start thinking about some tests for these. >>>>>>> >>>>>>> >>>>>>> >>>>>> Cool! >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> >>>>>>>> Let me know how it goes. Currently the tests of Mondrian are yellow. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> >>>>>>>> >>>>>>>> On 8 May 2012, at 16:42, >>>>>>>> >>>>>>>> admin(a)moosetechnology.org >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/972/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> >>>>>>>>> >>>>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> >>>>>>> Moose-dev(a)iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> >>>>> www.tudorgirba.com >>>>> >>>>> >>>>> "Don't give to get. Just give." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>> >>> -- >>> >>> www.tudorgirba.com >>> >>> >>> Innovation comes in least expected form. >>> That is, if it is expected, it already happened. >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> >> >> 'From Pharo1.4 of 18 April 2012 [Latest update: #14438] on 16 May 2012 at 11:15:20 pm'! >> >> !MOAbstractRegularTreeLayout methodsFor: 'hook' stamp: 'BenComan 5/16/2012 23:14'! >> doExecute: node >> | rootNodes btcdebug| >> alreadyLayoutedNodes := OrderedCollection new. >> rootNodes := self rootNodesFor: node nodes. >> nodesByLayer := OrderedCollection new. >> >> self flag: #btcdebug. >> "Regarding moose-dev(a)iam.unibe.ch emails 'Jenkins build is still unstable: moose-latest-dev #972' >> To isolate the issue, open a Transcript then generate the following in Mondrian Easel twenty times >> view shape label. >> view nodes: #(1 2 3 4 ). >> view edgesFromAssociations: { 1 -> 2. 1 ->3 . 3 -> 4}. >> view treeLayout. >> " >> btcdebug := rootNodes first. >> Transcript cr; crShow: '------------------------------'. >> Transcript crShow: 'B1>', (self childrenFor: btcdebug) asString. >> Transcript crShow: 'B2>', (self computeChildrenFor: btcdebug) asString. >> >> self >> layout: rootNodes >> atPoint: self leftGap @ self topGap >> atLayer: 1. >> self isLayered ifTrue: [ >> self rearrangeByLayers: node ]! ! >> >> >> !MOAbstractVerticalTreeLayout methodsFor: 'hook-private' stamp: 'BenComan 5/16/2012 23:02'! >> layout: aNodeCollection atPoint: aPoint atLayer: aNumber >> | treeSize childrenPosition x y middleOfTree | >> aNodeCollection isEmpty ifTrue: [ ^ 0 ]. >> x := aPoint x. >> y := aPoint y. >> alreadyLayoutedNodes addAll: aNodeCollection. >> self atLayer: aNumber add: aNodeCollection. >> aNodeCollection do: [ :each | >> self flag: #btcdebug. Transcript crShow: 'A2>', each asString. >> childrenPosition := y + each height + self verticalGap. >> treeSize := each width >> max: (self layout: (self computeChildrenFor: each) atPoint: x @ childrenPosition atLayer: aNumber + 1). >> middleOfTree := x + (treeSize / 2.0) - (each width / 2.0). >> each translateTo: middleOfTree @ y. >> x := x + treeSize + self horizontalGap ]. >> ^ x - aPoint x - self horizontalGap! ! >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

May 16, 2012

Re: [Pharo-project] Moving data into new package/image version

by Mariano Martinez Peck

On Wed, May 16, 2012 at 10:37 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > Sorry, I don't have ideas of how to solve that. > I ended up using OB to rename the classes in the old image to match the new > class names in the new image, then serialized with ReferenceStream, then > deserialized in the new image. > > Good idea! > > Mariano Martinez Peck wrote > > I can only say > > that Fuel *does* suppor that type of problem > Would Fuel be better than ReferenceStream for persistence? Yes, much better. > I thought the use > case was saving rarely, but loading often; where serialization is balanced > between the two. > Well, even if that's true, that doesn't mean that Fuel serialization is slow. In fact, it is between 5x and 10x faster than ReferenceStream ;) and like 30x when loading. (I should check the paper for the numbers..i don't remember them). Fuel is *much* faster than ReferenceStream while also providing more features (as the one you have just experimented). > > -- > View this message in context: > http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820p… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 16, 2012

Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes

by Tudor Girba

Hi, I do not know if it counts, but here is one about humane assessment with Moose: http://dl.dropbox.com/u/18323746/Humane-assessment/humane-assessment-3-slid… Cheers, Doru On 11 May 2012, at 17:56, StÃ©phane Ducasse wrote: > Hi everybody > > We really want to build a "vitrine" showroom of Pharo and we would you to participate. > We want to build a web page with all these successes and show them to the world. :) > > We would like to get from you a three slides document: > > slide one: > a sexy picture and a teaser / who you are. > > slide two: > what is it how cool is it. > > slide three: > what cool pharo techno you used or developed. > > If you have two successes then do two set of slides. > > So can you please send us these three slides. We would like to present them during the > Pharo conf and after put them on the web. > > Stef and marcus. > > > <sample.pdf>_______________________________________________ > Pharo-consortium mailing list > Pharo-consortium(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by Jimmie Houchin

On 5/16/2012 10:06 AM, StÃ©phane Ducasse wrote: >> I think that some official >> Pharo blog (maybe written by Esteban) would be very helpful. Some kind >> of not very extensive technical information source that will help >> people to stay in touch with Pharo progress. > Ok we will do a private mailing-list. I would prefer not. I am not a core developer. But I like reading this list. I personally do not find the volume all that big a problem. Any reasonable mail program can present you with the a threaded view. Allow you to mark threads as read. Read what you want and mark all the rest as read. Or whatever. No one has to read all the messages. >> That will explain what is >> being changed in Pharo and why. I think that developers than will see >> the changes like positive not as alien ones. > Why people do not register to pharo-users? Possibly what we need to do is have a few people who can move or forward discussions to the pharo-users list and encourage non-development-of-Pharo messages there. But this will require that all the people that we depend upon to answer messages here also subscribe to and respond on pharo-users. If we can do that then over time we will have a culture of the right messages going to the right list. But ultimately, that won't reduce the volume of anything. Neither will using Stack Overflow. Should one be a subscriber to all. Just MHO. Jimmie

May 16, 2012

Re: [Pharo-project] About process startups

by Guillermo Polito

On Wed, May 16, 2012 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I do not really like the class idea. > why not? Maybe it does not apply for every process, but for some of them. Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S > May be having a convention + a pragma for the methods is good. > > Stef > > On May 16, 2012, at 3:27 PM, Guillermo Polito wrote: > > > I'm playing with the process initialization for the bootstrap, and some > things come to my mind. > > > > There are some classes that startup processes on the class side > initialize, like > > > > WeakArray -> Finalization process > > Delay -> Timer event loop > > > > What it is not clear to me is if those processes should be installed > when the class is initialized, or when it is startupped for the first time. > Also, I can't stop thinking that the processes in the image are all spread > and not clear. If I want to know where the processes are defined, it's > kind of a mess. > > > > Is having specialized objects for our processes undesired by some reason > I can't see? I'd like to have objects like > > > > MorphicUIProcess > > FinalizationProcess > > TimeEventProcess > > ... > > and so on > > > > Guille > > >

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by Sean P. DeNigris

David T. Lewis wrote > > So no, it is not a constant. > Let me rephrase: wouldn't it be better if it was a constant, like dos and unix? I find the current behavior confusing e.g. dt := '1/15/2012 0000+00:00' asDateAndTime. DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'PDT' ]). s := dt asSeconds. "3504013200" "Now I move to Greenwich" DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'UTC' ]). DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!" -- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630564.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] Moving data into new package/image version

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Sorry, I don't have ideas of how to solve that. I ended up using OB to rename the classes in the old image to match the new class names in the new image, then serialized with ReferenceStream, then deserialized in the new image. Mariano Martinez Peck wrote > I can only say > that Fuel *does* suppor that type of problem Would Fuel be better than ReferenceStream for persistence? I thought the use case was saving rarely, but loading often; where serialization is balanced between the two. -- View this message in context: http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012