- Pharo-dev - lists.pharo.org

[Pharo-project] 2.0 is really nice

by Sean P. DeNigris

I just ported a project from 20531 to 20597... not too far in calendar time, but a world of difference in usability :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/2-0-is-really-nice-tp4681279.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 13, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Levente Uzonyi

On Sat, 13 Apr 2013, Igor Stasenko wrote: > > Both #timeToRun and secondsWhenClockTicks (via Delay) using same primitive > - #millisecondClockValue. > Sure thing, precision of this primitive should be it is 1 millisecond > or smaller.. > But it has nothing to do with precision of primSecondsClock and you > cannot increase precision of > it using #millisecondClockValue. The only thing I wanted to point out is that the value of #primSecondsClock changes when the actual second changes (the difference is less than 1ms). So while its resolution is just 1 second, it's accuracy is better than 1ms. Here's another example using the microsecond clock: (1 to: 10) collect: [ :e | | start | Time secondsWhenClockTicks. start := Time primUTCMicrosecondClock. Time secondsWhenClockTicks. Time primUTCMicrosecondClock - start ]. "==> #(1000136 999914 999961 999926 1000029 999988 999991 999985 998089 1000034)" > > Because this code: > > [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay > forMilliseconds: 1) wait ]. > > actually means: > > [ lastSecond = self primSecondsClock ] whileTrue: [ block not less than 1 ms ]. > > but not: > > [ lastSecond = self primSecondsClock ] whileTrue: [ block exactly 1 ms ]. > > the upper bound of "(Delay forMilliseconds: 1) wait" is undefined.. > and you know it well. Of course Delays are not ideal here, but there was nothing better to use when the code was written. As you can see in the above example, in 1 out of 10 cases the difference was less than 999 ms. Levente > >> >> About DateAndTime: having it nanosecond resolution is a future proof idea. >> It will take a while till software can create better accuracy timestamps. >> Reducing the resolution to milliseconds is a very bad idea. The VM and >> external software can give you a microsecond or smaller resolution timestamp >> which you want to represent as DateAndTime (or whatever class you use to >> create a timestamp) in the image. >> >> > Yes i know. My problem is the amount of code which does something > "userful" with nanoseconds > while everybody knows that we have no such resolution.. and won't have > in 10 years or so. > >> Levente > > > -- > Best regards, > Igor Stasenko. > >

April 13, 2013

Re: [Pharo-project] Zinc/Zodiac error while doing a get in Windows

by Esteban Lorenzano

just that... all the other tests are fine On Apr 13, 2013, at 8:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 April 2013 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> On 13 Apr 2013, at 17:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> yes... it still happen with your fix. >>> It ss weird that it works for you because I tested in two different windows (XP and W7) and in two different networks (work and here). >>> tbh, I don't really need it working, the small program I'm doing will not run in windows anyway (it was just by chance that I tested there)... but since I catched the probable bug, I want to solve it (or demonstrate it is not a bug) :) >> >> I meant that it worked on my Mac. And I just tried and indeed it does fail on Windows (8), while all other Zinc/Zodicac tests pass. >> >> The problem is inside the initial TLS/SSL connect handshake, which is really low level. >> >> I think it is worth to make an issue out of this, but I have no clue as to a solution. >> > > does that means one cannot use SSL on windoze at all? > or it breaks only in some special cases (like with given url)? > > -- > Best regards, > Igor Stasenko. >

April 13, 2013

Re: [Pharo-project] Zinc/Zodiac error while doing a get in Windows

by Igor Stasenko

On 13 April 2013 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 13 Apr 2013, at 17:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> yes... it still happen with your fix. >> It ss weird that it works for you because I tested in two different windows (XP and W7) and in two different networks (work and here). >> tbh, I don't really need it working, the small program I'm doing will not run in windows anyway (it was just by chance that I tested there)... but since I catched the probable bug, I want to solve it (or demonstrate it is not a bug) :) > > I meant that it worked on my Mac. And I just tried and indeed it does fail on Windows (8), while all other Zinc/Zodicac tests pass. > > The problem is inside the initial TLS/SSL connect handshake, which is really low level. > > I think it is worth to make an issue out of this, but I have no clue as to a solution. > does that means one cannot use SSL on windoze at all? or it breaks only in some special cases (like with given url)? -- Best regards, Igor Stasenko.

April 13, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

Levente, i slightly modified your example to simulate interrupt between two primitive invocations: | sema quit result secondsWhenTick | sema := Semaphore new. quit := false. [ [ quit ] whileFalse: [ sema wait. (Delay forSeconds: 2) wait. sema signal ]. ] forkAt: Processor activePriority - 1. secondsWhenTick := [ | lastSecond | lastSecond := Time primSecondsClock. [ lastSecond = Time primSecondsClock ] whileTrue: [ sema signal. sema wait. (Delay forMilliseconds: 1) wait ]]. result := (1 to: 10) collect: [:i | secondsWhenTick value. [ secondsWhenTick value ] timeToRun ]. quit := true. result #(2002 2002 2004 2003 2004 2004 2003 2003 2004 2004) You know that interrupt can happen at any moment. Even if it is not VM, it can be hardware interrupt, OS interrupt and god knows what else. Like that we can only state: well, there is some >0 probability that error of measurement using #secondsWhenTick will be within ~1 msec interval.. but it is never == 1. Which at the end means that expression: DateAndTime now nanoSecond and: 1000000000 atRandom can be used more or less interchangeably, because both has nothing to do with measurement of current system time. -- Best regards, Igor Stasenko.

April 13, 2013

Re: [Pharo-project] Open window out of my pharo environment

by stephane ducasse

On Apr 13, 2013, at 2:14 PM, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: > > > > 2013/4/13 stephane ducasse <stephane.ducasse(a)free.fr> > tristan > > I do not think that without help we will be able to get multiwindowing working within the time of your intern. > > I can give some of my freetime to help on this! But I don't think I can spend my work time because of I'm under ThalÃ¨s licence for the moment (I will ask to my tutor). On the other side nothing forbid me to make an alternative at work! to me it looks like some people want the butter and the money for the butterâ¦. > > Now if one guy at your place wants to help it can really change. > > Stef > > >> >> >> >> 2013/4/12 S Krish <krishnamachari.sudhakar(a)gmail.com> >> >> From immediate perspective, why not hook up with NativeBoost to a C DLL one can easily parametrize to serve as viable alternative / proof of concept till Igor / Esteban's work becomes core to Pharo. >> >> Can you explain me fastly how to do that? (Sorry but I'm a terribly newbie on low-level programming) >> >> Is this Windows / Mac / Linux or multi OS..? For Pharo, they will have to ensure it multi OS compatible so may take time stabilizing. >> >> >> I develop on Windows but we have to be compatible with Linux. (The demo to the client are on Linux machine). >> >> >> On Fri, Apr 12, 2013 at 1:19 PM, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: >> Hi! >> >> all my question is in the object ^^ >> >> Does exist the possibility to open a window out of my pharo environment? (Or someone know the way to do that?) >> >> I'm working on a graphic framework and at my work they need a multi screen support. It's needed to validate Pharo as the smalltalk they will use! >> >> Thanks! >> >> Tristan >> >> > >

April 13, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 13 April 2013 09:13, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 13 Apr 2013, Igor Stasenko wrote: > >> On 12 April 2013 23:47, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>> Am 12.04.2013 um 23:23 schrieb Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> On 12 April 2013 23:14, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>> >>>>> +1. No clue either. But discovered the terminate process shortcut to >>>>> kill >>>>> them faster... >>>>> >>>>> Coping over solving ... >>>>> >>>> >>>> One of the "solutions" i proposed is to rewrite the code and get rid >>>> of "nano-second" """"synchronization""" of date and time with system >>>> clock >>>> because >>>> a) there is no real users of it (to my knowledge) >>>> b) you cannot have precision higher than precision of system primitive >>>> we're using, >>>> which is in millisecond range.. >>>> >>> Where do you see a nanosecond synchronization? It is still millisecond >>> clock as far as I can see. Only the instVar is called nanos. >> >> >> Ah, sorry.. i mistaken by some orders of magnitude. ;) >> >> The offending code starts from here: >> >> 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 >> >> (notice that 1000 multiplier, which gives us "nanosecond" precision) >> >> But that's fine.. now look at >> >> secondsWhenClockTicks >> >> "waits for the moment when a new second begins" >> >> | lastSecond | >> >> lastSecond := self primSecondsClock. >> [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay >> forMilliseconds: 1) wait ]. >> >> ^ lastSecond + 1 >> >> that is complete nonsense. Sorry. >> >> This code relying on primSecondsClock resolution, which is..... (drum >> roll..... ) >> 1 second.. > > >> >> then it is combined with millisecondClockValue , as you see later to get >> system time with millisecond precision.. >> >> I am not genius in math and physics.. but even i understand that if >> you measurement has error X >> you cannot get more precision than X, even if you combine it with >> another measurement with higher precision. >> >> (But i can be wrong with that.. if so, please explain why) > > > (1 to: 10) collect: [ :e | > Time secondsWhenClockTicks. [ Time secondsWhenClockTicks ] timeToRun > ]. "==> #(1000 1000 1000 1000 1000 1000 1000 1000 1000 1000)" > > It seems like the resolution is 1 seconds, but the accuracy is 1 millisecond > or smaller. Which means that the code will give you a millisecond resolution > timestamp. > Both #timeToRun and secondsWhenClockTicks (via Delay) using same primitive - #millisecondClockValue. Sure thing, precision of this primitive should be it is 1 millisecond or smaller.. But it has nothing to do with precision of primSecondsClock and you cannot increase precision of it using #millisecondClockValue. Because this code: [ lastSecond = self primSecondsClock ] whileTrue: [ (Delay forMilliseconds: 1) wait ]. actually means: [ lastSecond = self primSecondsClock ] whileTrue: [ block not less than 1 ms ]. but not: [ lastSecond = self primSecondsClock ] whileTrue: [ block exactly 1 ms ]. the upper bound of "(Delay forMilliseconds: 1) wait" is undefined.. and you know it well. > > About DateAndTime: having it nanosecond resolution is a future proof idea. > It will take a while till software can create better accuracy timestamps. > Reducing the resolution to milliseconds is a very bad idea. The VM and > external software can give you a microsecond or smaller resolution timestamp > which you want to represent as DateAndTime (or whatever class you use to > create a timestamp) in the image. > > Yes i know. My problem is the amount of code which does something "userful" with nanoseconds while everybody knows that we have no such resolution.. and won't have in 10 years or so. > Levente -- Best regards, Igor Stasenko.

April 13, 2013

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Igor Stasenko

On 13 April 2013 09:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 13, 2013, at 7:10 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> Igor >> >> I have the impression that this is happening for us because we always download the image from jenkins. >> Did we experience the same once the processes are cleaned? and we do not get an image from another os/system? > > Yes, every time the image is saved on Jenkins we get one more. > > There is some other strange problem with saving images from the CommandLine: some things are deferred until > the GUI is available, which is when you open it after downloading from jenkins. > > As for 2.0: we cleaned it by handâ¦ (the release image). > yes.. and it still popping new ones. so problem is still there. > Marcus -- Best regards, Igor Stasenko.

April 13, 2013

Re: [Pharo-project] Zinc/Zodiac error while doing a get in Windows

by Sven Van Caekenberghe

On 13 Apr 2013, at 17:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > yes... it still happen with your fix. > It ss weird that it works for you because I tested in two different windows (XP and W7) and in two different networks (work and here). > tbh, I don't really need it working, the small program I'm doing will not run in windows anyway (it was just by chance that I tested there)... but since I catched the probable bug, I want to solve it (or demonstrate it is not a bug) :) I meant that it worked on my Mac. And I just tried and indeed it does fail on Windows (8), while all other Zinc/Zodicac tests pass. The problem is inside the initial TLS/SSL connect handshake, which is really low level. I think it is worth to make an issue out of this, but I have no clue as to a solution. > Anyway, here a fuelised stack: > > <Debugger-Stack-Socket-2013-04-13-11578.zip> > > Esteban > > On Apr 13, 2013, at 4:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Esteban, >> >> On 13 Apr 2013, at 15:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm having an error while trying to execute (latest 2.0 image & vm, downloaded with zeroconf): >>> >>> ZnClient new get: 'https://api.eveonline.com/eve/CharacterInfo.xml.aspx?characterID=90628525' >>> >>> in a Windows machine (both XP and W7) >>> >>> the error is "connection closed". >>> >>> Is weird because all Zodiac tests pass, and also the same request works in Mac and Linux. >>> >>> cheers, >>> Esteban >> >> That is weird indeed, works for me as well, it is a pretty simple request, chunked response with connection close. >> I will try myself of windows when my kids get off their computer. >> >> Can you give a stack trace ? >> >> You might try to patch SocketStream>>#next: >> >> 'From Pharo2.0 of 7 March 2013 [Latest update: #20593] on 13 April 2013 at 4:11:25 pm'! >> >> !SocketStream methodsFor: 'stream in' stamp: 'SvenVanCaekenberghe 3/22/2013 16:09'! >> next: anInteger >> "Read count elements and return them in a collection. >> If the receiver is #atEnd before count elements were read, >> return a smaller collection and don't signal ConnectionClosed." >> >> ^ self nextInto: (self streamBuffer: anInteger)! ! >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >

April 13, 2013

Re: [Pharo-project] Zinc/Zodiac error while doing a get in Windows

by Esteban Lorenzano

Hi, yes... it still happen with your fix. It ss weird that it works for you because I tested in two different windows (XP and W7) and in two different networks (work and here). tbh, I don't really need it working, the small program I'm doing will not run in windows anyway (it was just by chance that I tested there)... but since I catched the probable bug, I want to solve it (or demonstrate it is not a bug) :) Anyway, here a fuelised stack: Esteban On Apr 13, 2013, at 4:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Esteban, > > On 13 Apr 2013, at 15:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> I'm having an error while trying to execute (latest 2.0 image & vm, downloaded with zeroconf): >> >> ZnClient new get: 'https://api.eveonline.com/eve/CharacterInfo.xml.aspx?characterID=90628525' >> >> in a Windows machine (both XP and W7) >> >> the error is "connection closed". >> >> Is weird because all Zodiac tests pass, and also the same request works in Mac and Linux. >> >> cheers, >> Esteban > > That is weird indeed, works for me as well, it is a pretty simple request, chunked response with connection close. > I will try myself of windows when my kids get off their computer. > > Can you give a stack trace ? > > You might try to patch SocketStream>>#next: > > 'From Pharo2.0 of 7 March 2013 [Latest update: #20593] on 13 April 2013 at 4:11:25 pm'! > > !SocketStream methodsFor: 'stream in' stamp: 'SvenVanCaekenberghe 3/22/2013 16:09'! > next: anInteger > "Read count elements and return them in a collection. > If the receiver is #atEnd before count elements were read, > return a smaller collection and don't signal ConnectionClosed." > > ^ self nextInto: (self streamBuffer: anInteger)! ! > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

April 13, 2013