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

Re: [Pharo-project] Synchronizing system time

by Denis Kudriashov

I think, you dont understand me. Getting current date and time not reflects system time changes. Just start pharo then change your windows system time and execute "DateAndTime now". It will return wrong datetime. So question: how to reinitialize DateAndTime in such situation to get right system date and time? 2012/7/13 Camillo Bruni <camillobruni(a)gmail.com> > > On 2012-07-13, at 08:45, Denis Kudriashov wrote: > > > Hello, > > > > I try to implement system time synchronization with some server. > > And I found that when system OS time changed running pharo instance don't > > see that. > > I execute DateAndTime>>initializeOffsets but it not helps. > > > > Is it bug somewhere? > > Is it possible to reinitialize OS date and time from running pharo? > > Instances of DateAndTime directly store the seconds / nanoseconds for they > time. > If the underlying system time changes this is not reflected in the > existing instances... > > If you can get somehow the offset by which the time changed you can > manually loop > over all DateAndTime objects and replace the internal representations... > > DateAndTime allInstances do: [ :each| > each instVarNamed: #seconds put: each seconds + systemTimeChange ]. > > > I use WindowsXP > > > > Best regards, > > Denis > > >

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Mariano Martinez Peck

On Sat, Jul 14, 2012 at 9:31 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Yes, a set of layered compatibility packages is a solution, but a lot of > work to maintain. I guess. > >From my little experience with Fuel, it was the *easiest* way we found. We just put the overrides in the compatibility packages. No need to think how to be compatible. You can also do a lot of dirty hacks, like registering stuff in Smalltalk globals (for classes that were removed) or to create subclasses from the originals with the names you need, etc....What I mean is that I don't care how "beautiful" these compatibility packages are (as said, they are usually dirty). All I care is that they work and that they let me have the real beautiful code in trunk. > I was trying to avoid that. With FileSystem there was no way around it. > You mean the class renames? > > Thanks for the pointer. > > Sven > > On 14 Jul 2012, at 00:05, Mariano Martinez Peck wrote: > > > On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > > > On 13 Jul 2012, at 15:44, Marcus Denker wrote: > > > > > Issue 6356: some cleanups related to methods moved away from > SmalltalkImage (vm and os related) > > > http://code.google.com/p/pharo/issues/detail?id=6356 > > > > OK. but how can a poor library developer trying to write code that has > to remain compatible with 1.3 and 1.4 deal with this ? > > > > > > Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have > "Compatibility packages" which are usually some overrides in a few methods. > Fuel's "trunk" is CLEAN, as good as possible (no need of any backward > compatibility) and expected to work in latest Pharo while all the rest is > fixed in those overrides for those compatibility packages. For example, see > ConfigurationOfFuel: > > > > spec > > package: 'FuelCompatibilityForSqueak' with: [ spec > requires: #( 'FuelCompatibilityBeforePharo12' ) ]; > > package: 'FuelCompatibilityBeforePharo12' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; > > package: 'FuelCompatibilityBeforePharo13' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; > > package: 'FuelCompatibilityBeforePharo14' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; > > package: 'FuelCompatibilityBeforePharo20' with: [ > spec requires: #( 'Fuel' ) ]. > > > > > > The browse any of those packages to see what I mean. > > > > Maybe something like this can help you. > > > > Cheers > > > > Have a look at > > > > ZnUserAgentSettings class>>#platformDetails > > ^ self platform platformName, ' ', self platform > platformSubtype, ' ', self platform osVersion > > > > Now, this is a deprecated class in Zn as well, but rewriting > > > > self platform osVersion > > > > to > > > > self platform os version > > > > does not seem to give the same result in 1.4 > > > > Any suggestions ? > > > > Thx, > > > > Sven > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

July 14, 2012

Re: [Pharo-project] Squeaksource moved

by Fabrizio Perin

Investigating the problem. Let you know soon. Fabrizio 2012/7/13 Sean P. DeNigris <sean(a)clipperadams.com> > > Fabrizio Perin-3 wrote > > > > Today at 14 we moved squeaksource on a new machine > > http://www.squeaksource.com/phexample/Phexample-NikoSchwarz.57.mcz > The package is listed in the versions, but trying to download -> 404 error > > Related to the move? > > -- > View this message in context: > http://forum.world.st/Squeaksource-moved-tp4639837p4639853.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Sven Van Caekenberghe

On 14 Jul 2012, at 00:08, Marcus Denker wrote: > We could just add a good version of #version to SystemPlatform in 1.4. > Because what is called on 1.4 is #version of ClassDescription which is related to a > concept of class versions which seems to be some arcane stuff in need of cleanup. > > version > "Return the version number string of the platform we're running on" > "OSPlatform version" > > ^(Smalltalk vm getSystemAttribute: 1002) asString I'll have another look, it is not that important in the scope of Zinc (and it is used in a Zinc deprecated class anyway). Sven

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Sven Van Caekenberghe

Yes, a set of layered compatibility packages is a solution, but a lot of work to maintain. I guess. I was trying to avoid that. With FileSystem there was no way around it. Thanks for the pointer. Sven On 14 Jul 2012, at 00:05, Mariano Martinez Peck wrote: > On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 13 Jul 2012, at 15:44, Marcus Denker wrote: > > > Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) > > http://code.google.com/p/pharo/issues/detail?id=6356 > > OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ? > > > Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have "Compatibility packages" which are usually some overrides in a few methods. Fuel's "trunk" is CLEAN, as good as possible (no need of any backward compatibility) and expected to work in latest Pharo while all the rest is fixed in those overrides for those compatibility packages. For example, see ConfigurationOfFuel: > > spec > package: 'FuelCompatibilityForSqueak' with: [ spec requires: #( 'FuelCompatibilityBeforePharo12' ) ]; > package: 'FuelCompatibilityBeforePharo12' with: [ spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; > package: 'FuelCompatibilityBeforePharo13' with: [ spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; > package: 'FuelCompatibilityBeforePharo14' with: [ spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; > package: 'FuelCompatibilityBeforePharo20' with: [ spec requires: #( 'Fuel' ) ]. > > > The browse any of those packages to see what I mean. > > Maybe something like this can help you. > > Cheers > > Have a look at > > ZnUserAgentSettings class>>#platformDetails > ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion > > Now, this is a deprecated class in Zn as well, but rewriting > > self platform osVersion > > to > > self platform os version > > does not seem to give the same result in 1.4 > > Any suggestions ? > > Thx, > > Sven > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 14, 2012

[Pharo-project] pharo-2.0-tests Â» 32,mac - Build # 221 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 14, 2012

[Pharo-project] pharo-2.0-tests Â» 32,linux - Build # 221 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 14, 2012

[Pharo-project] pharo-2.0-tests Â» 32,win - Build # 221 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 14, 2012

[Pharo-project] [update 2.0] #20212

by Marcus Denker

20212 ----- Issue 6369: clean menu entries #openSingleMessageBrowser http://code.google.com/p/pharo/issues/detail?id=6369 Issue 6368: Some small cleanups related to TTC font cleanup http://code.google.com/p/pharo/issues/detail?id=6368 Issue 6367: Remove FormSetFont http://code.google.com/p/pharo/issues/detail?id=6367 Issue 6364: Zodiac.Tests.ZdcSecureSocketStreamTests.testIsNativeSSLPluginPresent http://code.google.com/p/pharo/issues/detail?id=6364 Issue 6344: Failing test testDownloadSmallHTML http://code.google.com/p/pharo/issues/detail?id=6344 -- Marcus Denker -- http://marcusdenker.de

July 14, 2012

Re: [Pharo-project] NativeBoost: perform 10, 000, 000 4096-digit additions fr1 := fr1 + fr1 in a loop in 1971 ms

by Lawson English

On 7/13/12 11:36 PM, Lawson English wrote: > > > "function prototype: mpfr_add (mpzf_t gmpf, mpf_t op1, mpf_t op2)" > the prototype is actually mpfr_add (mpfr_t gmpfr, mpfr_t op1, mpfr_t op2, ulong rnd) http://www.mpfr.org/mpfr-current/mpfr.html#Basic-Arithmetic-Functions I'm using rnd := 0. MPFR_RNDN: round to nearest -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

July 14, 2012