- Pharo-dev - lists.pharo.org

[Pharo-project] Strange behaviour in Spec

by Andrei Vasile Chis

Hi, While playing with spec I started to have some quite random and strange behaviour. I'll try to explain what happen, because it might be a nasty/not that nasty bug. I had a ListComposableModel and some very simple code like: aListComposableModel whenListChanged: [ :aList | aListComposableModel setSelectedItem: aList first ]. >From time to time this code seem to randomly fail because the selection wasn't set. I manage to reduce the error to the following equivalent code: aListComposableModel whenListChanged: [ :aList | aList = aListComposableModel listItems ]. What happen was that sometimes the list held by the model was the previous list and not the new list, which was actually correctly passes to the block. This seem to be caused by the way ListComposableModel uses announcers to update its internal state. In ListComposableModel>>registerEvents there is the code: listHolder whenChangedDo: [ self refreshListItems ]. This registers an announcement that should clear the cache: ListComposableModel >>refreshListItems listItemsCache := nil. ^ self changed: #listElementAt: In my code by using 'aListComposableModel whenListChanged:' I also register an event that should be executed when the elements of the list change. So by now the listHolder containing the elements of the list has two registered events. The problem is that in order for this to work correctly they have to execute in the order they were added: first invalidate the cache, then the other events registered by the user. However I do not think that announcers guarantee this. So from time to time they execute in the wrong way. This means that the code in the whenListChanged: block will execute in a state in which internaly aListComposableModel still contains the previous list. Does this make sense? Andrei

Feb. 4, 2013

Re: [Pharo-project] Future "Modules system"

by Denis Kudriashov

Hi 2013/2/4 Martin Dias <tinchodias(a)gmail.com> > I arrived to almost the same problem some weeks ago, when I was > thinking on how to have multiple versions of Fuel at the same time, so > one can, for example, easily migrate her files to a newer version. > > Fuel has lots of extension methods, so we need also multiple versions > of the same extension method. > > Then, I arrived to ClassBoxes paper, from which I would like to > extract and reproduce the experiment in a Pharo2.0 with Opal compiler. > I guess Opal can simplify the implementation. > There is also a paper about a prototype named CoExist, based on > squeak. I didn't try it but apparently they only have a little > performance degradation, because they used a modified vm. > I think It can be implemented with method wrappers and without impact on performance of methods which has not everrided versions. When you load code from package with method extensions you can put this methods in target class with method wrappers which know about classboxies logic. But rest system will continue working as usuall. Do you have links on CoExist? Best regards, Denis > > Martin > > > > On Sun, Feb 3, 2013 at 12:36 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > Have a look at ClassBoxes: > > > > http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf > > > > I think they come pretty close to what you have in mind. > > > > On 2013-02-03, at 12:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > >> Hello. > >> > >> Some days ago I think about how java works with dependencies and how it > can > >> be implemented in smalltalk. > >> > >> For java example libA.jar uses SharedClass.methodA and libB.jar uses > >> SharedClass.methodB. But #methodA exists only in version deployed as > >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. > >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are > >> defined explicitly in their classpathes. So libA.jar knows nothing about > >> libS-b.jar and v.v. And that's why your java programm can works at same > >> time with libA.jar and libB.jar. They will use different versions of > same > >> class. > >> > >> What it means in context of pharo? > >> > >> In pharo we have configurations which manage dependencies of projects. > But > >> you can't use at same time projectA and projectB which depend on > different > >> versions of projectS (when they both use same SharedClass from projectS > >> like in java example). If you load projectA last you will get > SharedClass > >> with only methodA. If you load projectB last you will get SharedClass > with > >> only methodB. So projectA and projectB can't works correctly at same > time. > >> My example very simple. It includes just single class differencies. It > can > >> be more complicated and java world is good example for this. > >> > >> So my global question is how it can be solved in pharo? Do you have some > >> plan for this? > >> > >> I can't remember something similar in pharo vision docs. But maybe what > >> Stephane called "modules system" is exactly about this? I mean what > >> Stephane always opposes in namespaces/environment discussions. And I > think > >> that this problem is ortogonal to namespaces/environments support. Do > you > >> agree? Do you know about such reseach in smalltalk? > >> > >> Little conclusion about such module system (if we can named it such > way?) > >> and what it is required from pharo: > >> > >> - ability to get in image different versions of same package. > >> - separated class (global) dictionaries (multiple Smalltalk's) per > package > >> version. Maybe it can be named Module. So let's think about Module as > >> unique Package+Version pair which contains all globals specific to this > >> version and all dependent other Modules. > >> - each Module knows it dependencies from other Modules, This information > >> can be retreived from configuration. > >> - each method and class should know from which project version (module) > it > >> was loaded. > >> - inside any methods compiler should resolve class names based on Module > >> dependencies information. Compiler should lookup actual class objects > from > >> module dependencies hierarchy. So no global Smalltak for compiler. But > >> Smalltalk can be stay in system as default core Module. > >> - If you want to use class which presents in two loaded versions of same > >> package you should resolve conflict manually. Such action should add > >> dependency to Module of your code. > >> - Module can't have dependencies of two Modules of same package. It > means > >> that code of your project can use only version of some dependant class. > I > >> think it is essential restriction of Modules system. > >> > >> Main thing which Module system can get to us is ability to safelly load > any > >> versions of our projects and use it. It is not matter how old this code. > >> System just loads old version of pharo core for example. Existed pharo > core > >> will continue works correctly. > >> > >> So what you think about it? > >> > >> Best regards, > >> Denis > > > > > >

Feb. 4, 2013

Re: [Pharo-project] Nanosecond-precision DateAndTime?

by Igor Stasenko

On 4 February 2013 16:56, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 February 2013 16:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Yes, I just can't understand all this code ;-) >> >> The nanoseconds seemed overly ambitious to me. >> >> That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations). >> >> If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight. >> >> 60 * 60 * 24 * 1000 < SmallInteger maxVal >> >> Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed. >> > > i am not against having highly precise storage format (which would > allow storing at arbitrary precision).. > what i don't understand is why having so much logic in order to > emulate such precision: > to my opinion, if OS/VM don't provides such precision, so be it.. use > what is given, > because doing so "neat" hacks with millisecond clock is just waste of > code as to me, > because it is really belongs to primitive (so you don't have chance to > be interrupted, nor you need to wait till "new second" will happen :) > ). > clarification: i meant, related to system time, like DateAndTime>>now , or TimeStamp>>now.. those two is by their nature is system-dependent.. and so, if underlying system does not supports higher than 1 ***second precision, there is no way how you will get it. For synthesizing dates and stamps (like reading from file) .. it is another story (the logic in the methods i presented is related only to system *current* time). -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] Future "Modules system"

by Martin Dias

On Mon, Feb 4, 2013 at 4:15 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Then, I arrived to ClassBoxes paper, from which I would like to Hmmm, I misread. Actually the paper I was talking about is the ChangeBoxes one. So I wanted to play with that but without tracking the changes as they do...

Feb. 4, 2013

Re: [Pharo-project] Nanosecond-precision DateAndTime?

by Igor Stasenko

On 4 February 2013 16:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I just can't understand all this code ;-) > > The nanoseconds seemed overly ambitious to me. > > That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations). > > If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight. > > 60 * 60 * 24 * 1000 < SmallInteger maxVal > > Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed. > i am not against having highly precise storage format (which would allow storing at arbitrary precision).. what i don't understand is why having so much logic in order to emulate such precision: to my opinion, if OS/VM don't provides such precision, so be it.. use what is given, because doing so "neat" hacks with millisecond clock is just waste of code as to me, because it is really belongs to primitive (so you don't have chance to be interrupted, nor you need to wait till "new second" will happen :) ). -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Igor Stasenko

On 31 January 2013 22:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Igor can you also update the ci? > > https://ci.inria.fr/rmod/job/NativeBoost/configure > it looks already up to date. why do we need this job btw? who uses it? (i'd like to mention that you should not expect from me that i will feel responsible for updating/syncing something which i was not created nor aware of) -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] Nanosecond-precision DateAndTime?

by Sven Van Caekenberghe

Yes, I just can't understand all this code ;-) The nanoseconds seemed overly ambitious to me. That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations). If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight. 60 * 60 * 24 * 1000 < SmallInteger maxVal Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed. On 04 Feb 2013, at 16:18, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, i am maybe completely ignorant, > but can someone tell me where such precision is used? > > In order to achieve this (or well, get close to), > a current implementation goes into very long circles to squeeze > accuracy from underlying OS & primitives.. > just take a look at this code and tell me what you think: > > secondsWhenClockTicks > > "waits for the moment when a new second begins" > > | lastSecond delay | > > delay := Delay forMilliseconds: 1. > lastSecond := self primSecondsClock. > [ lastSecond = self primSecondsClock ] whileTrue: [ delay wait ]. > > ^ lastSecond + 1 > > > initializeOffsets > | durationSinceEpoch secondsSinceMidnight nowSecs | > LastTick := 0. > nowSecs := self clock secondsWhenClockTicks. > LastMilliSeconds := self millisecondClockValue. > durationSinceEpoch := Duration > days: SqueakEpoch > hours: 0 > minutes: 0 > seconds: nowSecs. > DaysSinceEpoch := durationSinceEpoch days. > secondsSinceMidnight := (durationSinceEpoch - > (Duration > days: DaysSinceEpoch > hours: 0 > minutes: 0 > seconds: 0)) asSeconds. > MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds > > what amuses me is then the way how TimeStamp class dealing with it to > actually throw away > extra precision: > > TimeStamp >> current "called by #now" > > | ts ticks | > ts := super now. > > ticks := ts ticks. > ticks at: 3 put: 0. > ts ticks: ticks offset: ts offset. > > ^ ts > > DateAndTime>>ticks > "Private - answer an array with our instance variables. Assumed to be UTC " > > ^ Array with: julianDayNumber with: seconds with: nanos. > > > if it is not obvious for someone, the right way to reset the > nanoseconds field in timestamp > is not sending a message to existing timestamp, say #resetNanoseconds, NO! > you should call a private method, which answers you an Array and then > you do "at:3 put: 0", > and then pass it again to same object as two arguments. > > > -- > Best regards, > Igor Stasenko. >

Feb. 4, 2013

Re: [Pharo-project] Nanosecond-precision DateAndTime?

by Igor Stasenko

The more, the interesting, consider: DateAndTime class>>now " [ 10000 timesRepeat: [ self now. ] ] timeToRun / 10000.0 . If calls to DateAndTime-c-#now are within a single millisecond the semaphore code to ensure that (self now <= self now) slows things down considerably by a factor of about 20. The actual speed of a single call to DateAndTime-now in milliseconds is demonstrated by the unguarded method below. [ 100000 timesRepeat: [ self todayAtMilliSeconds: (self milliSecondsSinceMidnight) ] ] timeToRun / 100000.0 . 0.00494 0.00481 0.00492 0.00495 " | nanoTicks msm | nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. (LastTick < nanoTicks) ifTrue: [ LastTick := nanoTicks. ^ self todayAtMilliSeconds: msm]. LastTickSemaphore critical: [ LastTick := LastTick + 1. ^ self todayAtNanoSeconds: LastTick] okay, since we multiply value by 1000000 we get a nanosecond precision. Right? :) Most funny is DateAndTime class comment (see how it is coherent with TimeStamp implementation): ------------ I represent a point in UTC time as defined by ISO 8601. I have zero duration. My implementation uses three SmallIntegers and a Duration: jdn - julian day number. seconds - number of seconds since midnight. nanos - the number of nanoseconds since the second. offset - duration from UTC. The nanosecond attribute is almost always zero but it defined for full ISO compliance and is suitable for timestamping. -------------- so i really wonder if it worth having so much for so nothing? :) -- Best regards, Igor Stasenko.

Feb. 4, 2013

[Pharo-project] Nanosecond-precision DateAndTime?

by Igor Stasenko

Hi, i am maybe completely ignorant, but can someone tell me where such precision is used? In order to achieve this (or well, get close to), a current implementation goes into very long circles to squeeze accuracy from underlying OS & primitives.. just take a look at this code and tell me what you think: secondsWhenClockTicks "waits for the moment when a new second begins" | lastSecond delay | delay := Delay forMilliseconds: 1. lastSecond := self primSecondsClock. [ lastSecond = self primSecondsClock ] whileTrue: [ delay wait ]. ^ lastSecond + 1 initializeOffsets | durationSinceEpoch secondsSinceMidnight nowSecs | LastTick := 0. nowSecs := self clock secondsWhenClockTicks. LastMilliSeconds := self millisecondClockValue. durationSinceEpoch := Duration days: SqueakEpoch hours: 0 minutes: 0 seconds: nowSecs. DaysSinceEpoch := durationSinceEpoch days. secondsSinceMidnight := (durationSinceEpoch - (Duration days: DaysSinceEpoch hours: 0 minutes: 0 seconds: 0)) asSeconds. MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds what amuses me is then the way how TimeStamp class dealing with it to actually throw away extra precision: TimeStamp >> current "called by #now" | ts ticks | ts := super now. ticks := ts ticks. ticks at: 3 put: 0. ts ticks: ticks offset: ts offset. ^ ts DateAndTime>>ticks "Private - answer an array with our instance variables. Assumed to be UTC " ^ Array with: julianDayNumber with: seconds with: nanos. if it is not obvious for someone, the right way to reset the nanoseconds field in timestamp is not sending a message to existing timestamp, say #resetNanoseconds, NO! you should call a private method, which answers you an Array and then you do "at:3 put: 0", and then pass it again to same object as two arguments. -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] Future "Modules system"

by Martin Dias

I arrived to almost the same problem some weeks ago, when I was thinking on how to have multiple versions of Fuel at the same time, so one can, for example, easily migrate her files to a newer version. Fuel has lots of extension methods, so we need also multiple versions of the same extension method. Then, I arrived to ClassBoxes paper, from which I would like to extract and reproduce the experiment in a Pharo2.0 with Opal compiler. I guess Opal can simplify the implementation. There is also a paper about a prototype named CoExist, based on squeak. I didn't try it but apparently they only have a little performance degradation, because they used a modified vm. Martin On Sun, Feb 3, 2013 at 12:36 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Have a look at ClassBoxes: > > http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf > > I think they come pretty close to what you have in mind. > > On 2013-02-03, at 12:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> Some days ago I think about how java works with dependencies and how it can >> be implemented in smalltalk. >> >> For java example libA.jar uses SharedClass.methodA and libB.jar uses >> SharedClass.methodB. But #methodA exists only in version deployed as >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are >> defined explicitly in their classpathes. So libA.jar knows nothing about >> libS-b.jar and v.v. And that's why your java programm can works at same >> time with libA.jar and libB.jar. They will use different versions of same >> class. >> >> What it means in context of pharo? >> >> In pharo we have configurations which manage dependencies of projects. But >> you can't use at same time projectA and projectB which depend on different >> versions of projectS (when they both use same SharedClass from projectS >> like in java example). If you load projectA last you will get SharedClass >> with only methodA. If you load projectB last you will get SharedClass with >> only methodB. So projectA and projectB can't works correctly at same time. >> My example very simple. It includes just single class differencies. It can >> be more complicated and java world is good example for this. >> >> So my global question is how it can be solved in pharo? Do you have some >> plan for this? >> >> I can't remember something similar in pharo vision docs. But maybe what >> Stephane called "modules system" is exactly about this? I mean what >> Stephane always opposes in namespaces/environment discussions. And I think >> that this problem is ortogonal to namespaces/environments support. Do you >> agree? Do you know about such reseach in smalltalk? >> >> Little conclusion about such module system (if we can named it such way?) >> and what it is required from pharo: >> >> - ability to get in image different versions of same package. >> - separated class (global) dictionaries (multiple Smalltalk's) per package >> version. Maybe it can be named Module. So let's think about Module as >> unique Package+Version pair which contains all globals specific to this >> version and all dependent other Modules. >> - each Module knows it dependencies from other Modules, This information >> can be retreived from configuration. >> - each method and class should know from which project version (module) it >> was loaded. >> - inside any methods compiler should resolve class names based on Module >> dependencies information. Compiler should lookup actual class objects from >> module dependencies hierarchy. So no global Smalltak for compiler. But >> Smalltalk can be stay in system as default core Module. >> - If you want to use class which presents in two loaded versions of same >> package you should resolve conflict manually. Such action should add >> dependency to Module of your code. >> - Module can't have dependencies of two Modules of same package. It means >> that code of your project can use only version of some dependant class. I >> think it is essential restriction of Modules system. >> >> Main thing which Module system can get to us is ability to safelly load any >> versions of our projects and use it. It is not matter how old this code. >> System just loads old version of pharo core for example. Existed pharo core >> will continue works correctly. >> >> So what you think about it? >> >> Best regards, >> Denis > >

Feb. 4, 2013