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

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

by Lawson English

embedding assembler in Pharo method using NativeBoost Hooray! L test code: fr1 := GMPfrWrapper new. "create new GNU mpfr floating point number" fr1 prim_mpfr_prec_roundWithPrecision:4096 withRounding: 0. "set to 4096 digits of precision" fr1 set_d: 1. "set it to 1.0" "perform 10,000,000 4096-digit additions fr1 := fr1 + fr1 in a loop" [fr1 test:10000000.] timeToRun =>1971 ms GMPfrWrapper>>test:cnt "function prototype: mpfr_add (mpzf_t gmpf, mpf_t op1, mpf_t op2)" <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout cdecl: #( void (mpfr_t gmpfr, ulong cnt)) emitCall: [:gen | | asm proxy smpfr scnt| asm := gen asm. proxy := gen proxy. "reserve temps for parameters passed in from Smalltalk" smpfr := gen reserveTemp. scnt := gen reserveTemp. "move parameters into temps" asm mov: asm ESP ptr to: asm EAX; mov: asm EAX to: smpfr; "gmpfr -> smpfr" mov: asm ESP ptr + 4 to: asm EAX; mov: asm EAX to: scnt. "cnt -> scnt" "setup loop compare and jmp or push ECX and pass through to function call" asm mov: scnt to: asm ECX; label: #top; cmp: asm ECX with: 0; jz: #bottom; push: asm ECX. "call function" asm cdeclCall: [:call | | gmpfrAddFcnPtr | "handles stack alignment" "push function arguments (note, cdecl push order is from right to left ) " asm push: smpfr; push: smpfr; push: smpfr. "get a function address" gmpfrAddFcnPtr := self nbGetSymbolAddress: 'mpfr_add' module:self nbLibraryNameOrHandle. "put a function address into EAX, and call function " asm mov: gmpfrAddFcnPtr asUImm to: asm EAX. asm call: asm EAX. ] alignment: gen stackAlignment . "restore ECX and jump to top for test" asm pop: asm ECX; dec: asm ECX; jmp: #top. asm label: #bottom. ] -- 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

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

by Marcus Denker

On Jul 13, 2012, at 11:01 PM, Marcus Denker wrote: > > On Jul 13, 2012, at 10:48 PM, Sven Van Caekenberghe 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 ? >> >> 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 ? 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 -- Marcus Denker -- http://marcusdenker.de

July 13, 2012

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

by Mariano Martinez Peck

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 13, 2012

Re: [Pharo-project] Zinc intermittently returning nil

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > This will be hard to debug... Thanks for digging in and finding that bug! http://code.google.com/p/pharo/issues/detail?id=6364 seems to fix it. The following returned the correct result through the whole loop (1 to: 100) do: [ :e | Transcript show: e asString, ': '; show: (ZnEasy get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x…') contents; cr ]. -- View this message in context: http://forum.world.st/Zinc-intermittently-returning-nil-tp4636820p4639938.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 13, 2012

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

by Marcus Denker

On Jul 13, 2012, at 10:48 PM, Sven Van Caekenberghe 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 ? > > 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 ? maybe we need to concept of pre-deprecation? Then we can pre-deprecate a method, and a version later deprecate it, and then remove it... In general: staying compatible forever means no change. That is possible, too. Marcus -- Marcus Denker -- http://marcusdenker.de

July 13, 2012

Re: [Pharo-project] [ENH]: Zinc - Streaming Download Progress

by Frank Shearar

On 13 July 2012 21:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe wrote >> >> Uhh, HTTPProgress was already there. I believe all progress is done that >> way, no ? >> > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. > My first cut at cleaning up the SystemProgressMorph was in preparation to > re-implement using announcements instead. Well, using Exceptions for non-exceptional conditions is a hack. But these aren't, they're Notifications, which are entirely different! Seriously though, resumable exceptions are at the core of how Squeak/Pharo work. They're really useful. frank > Sven Van Caekenberghe wrote >> >> With Announcements the problem is that you have to specify an Announcer, >> Notifications are just thrown in the air ;-) >> > How about an announcer per client that also forwards to one for the whole > Zinc library? > > -- > View this message in context: http://forum.world.st/ENH-Zinc-Streaming-Download-Progress-tp4639686p463993… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 13, 2012

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

by Sven Van Caekenberghe

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 ? 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

July 13, 2012

Re: [Pharo-project] [ENH]: Zinc - Streaming Download Progress

by Sven Van Caekenberghe

Sean, On 13 Jul 2012, at 22:23, Sean P. DeNigris wrote: > Sven Van Caekenberghe wrote >> >> Uhh, HTTPProgress was already there. I believe all progress is done that way, no ? > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. > My first cut at cleaning up the SystemProgressMorph was in preparation to > re-implement using announcements instead. Yes, it seems like a hack. > Sven Van Caekenberghe wrote >> >> With Announcements the problem is that you have to specify an Announcer, >> Notifications are just thrown in the air ;-) > How about an announcer per client that also forwards to one for the whole Zinc library? I think I understand what you are trying to achieve, yes it makes sense. But this feels like a architectural decision - I don't feel qualified to decide. Anybody else care to comment ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 13, 2012

Re: [Pharo-project] [ENH]: Zinc - Streaming Download Progress

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > Uhh, HTTPProgress was already there. I believe all progress is done that > way, no ? > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. My first cut at cleaning up the SystemProgressMorph was in preparation to re-implement using announcements instead. Sven Van Caekenberghe wrote > > With Announcements the problem is that you have to specify an Announcer, > Notifications are just thrown in the air ;-) > How about an announcer per client that also forwards to one for the whole Zinc library? -- View this message in context: http://forum.world.st/ENH-Zinc-Streaming-Download-Progress-tp4639686p463993… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 13, 2012

Re: [Pharo-project] DateAndTime

by Sven Van Caekenberghe

Great work. let's hope it stands the test of time, so to speak. On 13 Jul 2012, at 21:20, Camillo Bruni wrote: > ben+2:00 > cami+2:00 I bet you would rather be ben+0:00 and cami+0:00 or even benZ and camiZ ;-)

July 13, 2012