- Pharo-dev - lists.pharo.org

[Pharo-project] Squeaksource down?
by Nicolas Petton Sept. 24, 2012

Sept. 24, 2012

http://www.downforeveryoneorjustme.com/http://squeaksource.com/ Nico -- Nicolas Petton http://nicolas-petton.fr

1 0

[Pharo-project] [update 2.0] #20302
by Esteban Lorenzano Sept. 24, 2012

Sept. 24, 2012

2.0.20302 --------- The following changes have been integrated: Issue 6709: MNU MethodRepackaged>>oldProtocol http://code.google.com/p/pharo/issues/detail?id=6709 Issue 6685: Nautilus should select Code after creating a new Protocol http://code.google.com/p/pharo/issues/detail?id=6685

1 0

[Pharo-project] [update 2.0] #20301
by Esteban Lorenzano Sept. 24, 2012

Sept. 24, 2012

2.0.20301 --------- The following changes have been integrated: Issue 6728: infinite recursion on startup preferences. http://code.google.com/p/pharo/issues/detail?id=6728 Issue 6723: Improve Collection Streaming http://code.google.com/p/pharo/issues/detail?id=6723 Issue 6715: RPackageSet is not backwards compatible http://code.google.com/p/pharo/issues/detail?id=6715

1 0

[Pharo-project] Changes in MongoTalk
by Francois Stephany Sept. 24, 2012

Sept. 24, 2012

I've introduced the notion of limit to the MongoTalk driver (see the MongoTalk repo). If someone (Nico, Esteban?) could have a look at the changes it would be great. The test case is overly simplistic but it should illustrate the point. Next on my list: numberToSkip[1]. With "limit" and "numberToSkip", we should be able to have something like pagination easily. Please stop me if none of these changes makes sense ;) [1] http://www.mongodb.org/display/DOCS/Mongo+Wire+Protocol#MongoWireProtocol-O…

3 3

[Pharo-project] [update 2.0] #20301
by Marcus Denker Sept. 24, 2012

Sept. 24, 2012

20301 ----- Issue 6697: Zn+Zdc Update 2012-09-19 http://code.google.com/p/pharo/issues/detail?id=6697 Issue 6699: Share binding of metaclass methods http://code.google.com/p/pharo/issues/detail?id=6699 -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] headless CogVM on Windows
by Pavel Krivanek Sept. 24, 2012

Sept. 24, 2012

Hi, it seems that the headless mode in CogVM on Windows is not working well. It always opens a window and the only difference from the normal start is that it uses minimalization to systray. As far as I know the older windows VMs always used systray (bad) but without the initial window opening. -- Pavel

3 4

[Pharo-project] I found this highly relevant to Pharo :)
by Igor Stasenko Sept. 23, 2012

Sept. 23, 2012

http://www.infoq.com/presentations/Ugly-Code -- Best regards, Igor Stasenko.

2 1

[Pharo-project] Pharo 1.4 -- debugger initialExtent is too wide, centered
by Martin McClure Sept. 23, 2012

Sept. 23, 2012

In Pharo 1.4, if your Display is not tiny, the initial extent of the debugger is 2/3 the width and 4/5 the height of Display. For large screens, this is just too big, especially too wide. My current Display is 2396x1741x32, and I have to immediately resize any debugger smaller in order to make it usable. I've experimented with leaving the height as is and limiting the width to 900 in Debugger>>initialExtent; this produces a much more usable result. ((w - (w // 3)) min: 900) @ (h - (h // 5)) The debugger also always centers its window in Display. Since my Display is spread across two monitors, this means it always must be moved to be readable. If I comment out the line window center: Display center. in MorphicUIManager>>openDebugger:fullMorphicLabel:, I'm much happier. I'd think these changes might be desirable for everyone -- comments? Regards, -Martin

4 4

[Pharo-project] headless CogVM on Windows
by Torsten Bergmann Sept. 22, 2012

Sept. 22, 2012

>yeah... we need a real headless mode (no systry, nothing... just a deamon >running) The regulary Squeak VM for Windows is able to do just that. It runs Smalltalk as an NT service by using the option "-service" See http://wiki.squeak.org/squeak/105 Dont know if this also works on Cog/Pharo standard VM. Bye T.

4 5

[Pharo-project] [NB] NativeBoost meets JIT
by Igor Stasenko Sept. 21, 2012

Sept. 21, 2012

Hello there, so, we're entered a new area, where native code, generated from image side can be run directly by JIT. This feature was one of the first things which i wanted to try, once Eliot released Cog :) The way how we do that, is when VM decides to JIT a specific method, we copying the native code (from method trailer) directly into the method's code. All you need to do is to use special primitive for that 220 ( #primitiveVoltage) So, a first question, which we wanted to be answered is how faster to run native code by JIT, comparing to running native code via NativeBoost primitive , which is #primitiveNativeCall.. For here are methods, which just answer 42: This one using #primitiveNativeCall nbFoo2 <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ NBNativeCodeGen methodAssembly: [:gen :proxy :asm | asm noStackFrame. asm mov: (42 << 1) + 1 to: asm EAX; ret. ] And this one uses JIT: nbFoo <primitive: 220 error: errorCode> [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self nbFoo ]. ^ NBNativeCodeGen jitMethodAssembly: [:gen :proxy :asm | asm noStackFrame. asm mov: (42 << 1) + 1 to: asm EDX; ret: 4 asUImm. ] And this one is code which JIT can do: nbFoo42 ^ 42 So, here the numbers: Time to run via #primitiveNativeCall : [100000000 timesRepeat: [ MyClass nbFoo2 ] ] timeToRun 6995 Time to run via JIT: [100000000 timesRepeat: [ MyClass nbFoo ] ] timeToRun 897 Time to run JITed method: [100000000 timesRepeat: [ MyClass nbFoo42 ] ] timeToRun 899 so, as you can see, the JITed method and our custom generated code is on par (which is logical ;). Time to run an empty loop: [100000000 timesRepeat: [ ] ] timeToRun 679 So, here the result, if we extract the loop overhead, we can see the difference in calling our native code when it uses JIT vs using #primitiveNativeCall : (6995 - 679 ) / (897- 679) asFloat 28.972477064220183 28 times faster!!!! So, with this new feature, we now can make our generated code to run with unmatched speed, without overhead related to #primitiveNativeCall. This is especially useful for implementing primives which involving heavy numeric crunching. I would release this code to public, but there's one little discrepancy i need to deal with first: (one little problem, which i hope Eliot can help to solve) it looks like primitivePerform: never enters the JIT mode, but always executing the method via interpreter. This is why you see this code: [ errorCode = ErrRunningViaInterpreter ] whileTrue: [ ^ self nbFoo ]. because if i do it inside of NBNativeCodeGen>>jitMethodAssembly:, which checks for same error and retries the send using perform primitive, it never enters the JIT mode, resulting in endless loop :( This is despite the fact that method is JITed, because we enforce the JITing of that method during error handling: lastError = ErrRunningViaInterpreter ifTrue: [ "a method contains native code, but executed by interpreter " method forceJIT ifFalse: [ self error: 'Failed to JIT the compiled method. Try reducing it''s size ' ]. ^ self retrySend: aContext ]. The #forceJit is the primitive which i implemented like following: primitiveForceJIT <export: true > | val result | val := self stackTop. (self isIntegerObject: val) ifTrue: [ ^ self primitiveFail ]. (self isCompiledMethod: val) ifFalse: [ ^ self primitiveFail ]. (self methodHasCogMethod: val) ifFalse: [ cogit cog: val selector: objectMemory nilObject ]. result := (self methodHasCogMethod: val ) ifTrue: [ objectMemory trueObject ] ifFalse: [ objectMemory falseObject ]. ^ self pop: 1 thenPush: result. As you can see from its usage, if VM, for some reason will fail to jit the method, the primitive will answer false, and we will stop with an error.. Which apparently never happens. Still, a #primitivePerform seems like ignoring that the method contains machine code an always runs it interpreted :( I do not like the idea, that users will be forced to manually put such loops in every method they will write.. any ideas/suggestions how to overcome that? -- Best regards, Igor Stasenko.

2 1