- Pharo-dev - lists.pharo.org

[Pharo-project] Squeaksource.com down

by Miguel CobÃ¡

SqueakSource Down SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource. At -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 17, 2011

Re: [Pharo-project] [Vm-dev] Socket Plugin primitives

by jannik.laval

On Mar 16, 2011, at 21:52 , Levente Uzonyi wrote: > On Wed, 16 Mar 2011, jannik.laval wrote: > >> >> Hi all, >> >> I am analyzing SocketPluggin for Ocean development. And I have some remarks/questions. >> >> First, to be sure, can you confirm my vision: >> - the vm 4.x is the old one. Is it maintained ? >> - vm 5.7.x is the normal vm (without JIT) >> - vm 5.8.x is the Cog VM with normal pluggin >> - vm Cog is Cog VM with less primitives than vm 5.8 (modified pluggins). >> >> Based on that, we can see that Cog has only 38 primitives related to SocketPluggin where normal pluggin provides 61 primitives. >> Could anyone explain to me why some primitives disappear ? > > Cog was forked from an old version of the VM sources that didn't have the IPv6 primitives, so those are missing. Ok, now I understand. > There may be other differences, so someone has to merge the code of the two (Cog's and the interpreter VM's) plugins. Which kind of difference ?You want to say in the source code ? Jannik > > > Levente > >> I do not yet analyze which primitives disappear but maybe someone could help me to understand this difference between the two pluggins. >> >> Thanks in advance for your help, >> --- >> Jannik Laval >> >>

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

Done, now it's dying while running the tests. I'll try to make it work again tomorrow night (only if we finally get to release a new version of SqueakNOS, I promise). Here is the stack trace in case it's a known problem: Smalltalk stack dump: 0xbf78b038 M NBFFICallout class(NBNativeCodeGen class)>generateCode:andRetry: 2032660172: a(n) NBFFICallout class 0xbf78b9a8 I NativeBoostLinux32>getGlobalSymbolPointer: 2039879072: a(n) NativeBoostLinux32 0xbf78b9d0 I [] in NBUnixExternalHeapManager>mmapLength:prot:flags:into: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78b9f4 I NBFFICallout>generate: 2041155916: a(n) NBFFICallout 0xbf78ba28 I [] in NBFFICallout class>cdecl:emitCall:options: 2032660172: a(n) NBFFICallout class 0xbf78ba64 I NBFFICallout class(NBNativeCodeGen class)>generateCode:andRetry: 2032660172: a(n) NBFFICallout class 0xbf78ba90 I NBFFICallout class(NBNativeCodeGen class)>handleFailureIn:nativeCode: 2032660172: a(n) NBFFICallout class 0xbf78babc I NBFFICallout class>cdecl:emitCall:options: 2032660172: a(n) NBFFICallout class 0xbf78bae8 I NBUnixExternalHeapManager>mmapLength:prot:flags:into: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bb20 I NBUnixExternalHeapManager>primAllocatePage: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bb50 I NBUnixExternalHeapManager(NBExternalHeapManager)>allocatePage: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bb74 M [] in NBUnixExternalHeapManager(NBExternalHeapManager)>allocate: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bb8c M IdentitySet(Collection)>detect:ifNone: 2041154916: a(n) IdentitySet 0xbf78bbc0 I [] in NBUnixExternalHeapManager(NBExternalHeapManager)>allocate: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bbe0 M [] in Semaphore>critical: 2041154856: a(n) Semaphore 0xbf78bc00 M BlockClosure>ensure: 2041155208: a(n) BlockClosure 0xbf78bc20 M Semaphore>critical: 2041154856: a(n) Semaphore 0xbf78bc44 I NBUnixExternalHeapManager(NBExternalHeapManager)>allocate: 2041154832: a(n) NBUnixExternalHeapManager 0xbf78bc6c I NativeBoostLinux32>basicAllocate: 2039879072: a(n) NativeBoostLinux32 0xbf78bc94 I NativeBoostLinux32(NativeBoost)>allocate: 2039879072: a(n) NativeBoostLinux32 0xbf78bcb8 I NativeBoostLinux32(NativeBoost)>initialize 2039879072: a(n) NativeBoostLinux32 0xbf78bcd0 M NativeBoostLinux32 class(Behavior)>new 2032913612: a(n) NativeBoostLinux32 class 0xbf78bcf4 I [] in NativeBoost class>discoverPlatformId 2032664204: a(n) NativeBoost class 0xbf78bd1c I [] in NativeBoost class(Behavior)>allSubclassesDo: 2032664204: a(n) NativeBoost class 0xbf78bd40 M Array(SequenceableCollection)>do: 2032915888: a(n) Array 0xbf78bd64 I NativeBoost class(Class)>subclassesDo: 2032664204: a(n) NativeBoost class 0xbf78bd88 I NativeBoost class(Behavior)>allSubclassesDo: 2032664204: a(n) NativeBoost class 0xbf78bdb0 I NativeBoost class>discoverPlatformId 2032664204: a(n) NativeBoost class 0xbf78bdd0 I NativeBoost class>forCurrentPlatform 2032664204: a(n) NativeBoost class 0xbf78bdf0 I NativeBoost class>allocate: 2032664204: a(n) NativeBoost class 0xbf78be10 M NBExternalAddressTests>testMemoryAccess 2039875280: a(n) NBExternalAddressTests 0xbf78be30 I NBExternalAddressTests(TestCase)>performTest 2039875280: a(n) NBExternalAddressTests 0xbf78be50 I [] in NBExternalAddressTests(TestCase)>runCase 2039875280: a(n) NBExternalAddressTests 0xbf78be70 M BlockClosure>ensure: 2039878812: a(n) BlockClosure 0xbf78be94 I NBExternalAddressTests(TestCase)>runCase 2039875280: a(n) NBExternalAddressTests On Wed, Mar 16, 2011 at 11:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 March 2011 03:20, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > I'm also seeing that NBCoInterpreter and NBCoObjectMemory only have small > > modifications compared to the non NB ones. Maybe it is possible to merge > > them directly into cog with an enable/disable flag, so that building NB > is > > the same as building Cog with NB enabled. > > > > Yes, the changes are very small, but i wanted to keep them separate, > so its easy to see them. > > So if you can't wait, you can just patch the original classes > and then generate VM sources using usual command. > But don't forget to include NativeBoostPlugin as internal one. > > If you using CMakeVMMaker, you do it like following: > > | config | > config := CogUnixConfig new. > config internalPlugins: (cog internalPlugins copyWith: #NativeBoostPlugin). > > config generateSourceFiles. > config generate. > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Igor Stasenko

On 17 March 2011 03:27, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Maybe it is too much to ask, but having aÂ NBCogUnixDebugConfig would be > pretty useful in this context! > Not much.. just creating extra class + adding 1 extra method :) -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Igor Stasenko

On 17 March 2011 03:20, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > I'm also seeing that NBCoInterpreter and NBCoObjectMemory onlyÂ haveÂ small > modifications compared to the non NB ones. Maybe it is possible to merge > them directly into cog with an enable/disable flag, so that building NB is > the same as building Cog with NB enabled. > Yes, the changes are very small, but i wanted to keep them separate, so its easy to see them. So if you can't wait, you can just patch the original classes and then generate VM sources using usual command. But don't forget to include NativeBoostPlugin as internal one. If you using CMakeVMMaker, you do it like following: | config | config := CogUnixConfig new. config internalPlugins: (cog internalPlugins copyWith: #NativeBoostPlugin). config generateSourceFiles. config generate. -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

Maybe it is too much to ask, but having a NBCogUnixDebugConfig would be pretty useful in this context! On Wed, Mar 16, 2011 at 11:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 March 2011 03:10, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > > Hi! I'm following the steps on the wiki to generate the NativeBoost > plugin. > > First of all I'd like to know if these steps are up to date (there has > been > > some activity since december when they were written). Then, I > successfully > > generated sources but don't know what to do next. Is it possible to > generate > > a CMakeFile, or how do I build everything? > > Piece of cake... I will create a separate CMakeVMMaker config for it.. > so you will do something like: > > NBCogUnixConfig generateWithSources > > and then in command line do as usual: > cmake . > make > > :) > > > Thanks! > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Igor Stasenko

On 17 March 2011 03:10, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: > Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. > First of all I'd like to know if these steps are up to date (there has been > some activity since december when they were written). Then, I successfully > generated sources but don't know what to do next. Is it possible to generate > a CMakeFile, or how do I build everything? Piece of cake... I will create a separate CMakeVMMaker config for it.. so you will do something like: NBCogUnixConfig generateWithSources and then in command line do as usual: cmake . make :) > Thanks! > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Best regards, Igor Stasenko AKA sig.

March 17, 2011

Re: [Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

I'm also seeing that NBCoInterpreter and NBCoObjectMemory only have small modifications compared to the non NB ones. Maybe it is possible to merge them directly into cog with an enable/disable flag, so that building NB is the same as building Cog with NB enabled. On Wed, Mar 16, 2011 at 11:10 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. > First of all I'd like to know if these steps are up to date (there has been > some activity since december when they were written). Then, I successfully > generated sources but don't know what to do next. Is it possible to generate > a CMakeFile, or how do I build everything? > > Thanks! > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

[Pharo-project] Building NativeBoost plugin (on linux)

by Javier PimÃ¡s

Hi! I'm following the steps on the wiki to generate the NativeBoost plugin. First of all I'd like to know if these steps are up to date (there has been some activity since december when they were written). Then, I successfully generated sources but don't know what to do next. Is it possible to generate a CMakeFile, or how do I build everything? Thanks! -- Javier PimÃ¡s Ciudad de Buenos Aires

March 17, 2011

Re: [Pharo-project] Cog/FFI Return Values

by Eliot Miranda

On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken(a)miriamtech.com> wrote: > On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote: > > > I expect that if the standard FFI plugin answers an instance of OopType64 > then you've found a bug in the ReentrantFFIPlugin. If you're brave you'll > have a look at both plugins and try and verify that that's the case. But I > have to say that the FFI plugins are not simple. > > Brave, yes. Smart, no. Here's what it looks like to my untrained eye: > > 1. When the ExternalFunction is compiled, the return argType is not flagged > as a structure. So the primitives, old and new, see this as a regular > non-struct callout, but with return class = OopType64. So far, so good. > > 2. The old plugin had this one-slot "wrapping" capability at the bottom of > #ffiCreateReturn: (which is called only for non-pointer, non-structure > functions): > > ffiRetClass := interpreterProxy popRemappableOop. > ffiRetClass == interpreterProxy nilObject ifTrue:[ > "Just return oop" > ^interpreterProxy push: retOop]. > "Otherwise create an instance of external structure and store the > return oop" > interpreterProxy pushRemappableOop: retOop. > retOop := interpreterProxy instantiateClass: ffiRetClass > indexableSize: 0. > oop := interpreterProxy popRemappableOop. > interpreterProxy storePointer: 0 ofObject: retOop withValue: oop. > ^interpreterProxy push: retOop. > > 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and > ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is > a memcpy(). > > Am I on the right track? If so, how would you like to see the code > structured to get this feature restored? We could add a new > wrap-if-necessary return method, or we could try to reuse > #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for > FFIFlagStructure. > If you're happy producing a fix I'll take whatever works, a test case and the I can always muck it up if I disapprove :) > > Or maybe there's a cleaner solution that's beyond my hazy view at the > moment. > I think you're on the right track. I probably misread when I wrote my first cut. Apologies. best Eliot > > -- > Ken Treis > Miriam Technologies, Inc. > >

March 16, 2011