January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo on a Raspbian

by Igor Stasenko

Btw, to reduce the pain, i propose to introduce: NativeBoost isAvailable protocol. The implementation is simple, since primitiveIsEnabled fails only if it not exists (else it returns true or false), do a following: isAvailable ^ self primIsAvailable notNil primIsAvailable "Answer flag indicating whether running a native code enabled by plugin" <primitive: #primitiveIsEnabled module: #NativeBoostPlugin> ^ nil Then you can easily implement a fallback mechanisms, if NB is not avail. On 17 January 2014 23:07, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 17 January 2014 22:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Who is JB ? >> >> > Jean Baptiste Arnaud. The invaluable asset in any team :) > The hacker who without any help configuring & compiling VM on raspberry. > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Jan. 17, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Igor Stasenko

On 17 January 2014 22:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Who is JB ? > > Jean Baptiste Arnaud. The invaluable asset in any team :) The hacker who without any help configuring & compiling VM on raspberry. -- Best regards, Igor Stasenko.

Jan. 17, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Sven Van Caekenberghe

Who is JB ? On 17 Jan 2014, at 21:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Here is a working vm for RaspberryPi on Raspbian: > https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Com… Well, I tried this download: https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Com… and we're soo close (I think) to running 3.0 (headless at least): pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval '1+2' Error: Can't find the requested origin UnixResolver(PlatformResolver)>>cantFindOriginError UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in Block: [ self cantFindOriginError ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: NativeBoost class(Object)>>primitiveFailed: NativeBoost class(Object)>>primitiveFailed NativeBoost class>>isEnabled NativeBoost class>>forCurrentPlatform NativeBoost class>>CLibrary NixEnvironment(OSEnvironment)>>getEnv: NixEnvironment(OSEnvironment)>>at:ifAbsent: NixEnvironment(OSEnvironment)>>at: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ Smalltalk os environment at: aString ] BlockClosure>>on:do: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: UnixResolver>>home UnixResolver>>preferences in Block: [ self home / '.config' ] UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in Block: [ ^ aBlock value ] BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: ;-)

Jan. 17, 2014

Re: [Pharo-dev] IncompatibleLayoutConflict with NativeBoost in recent #30700

by Igor Stasenko

On 17 January 2014 21:22, Torsten Bergmann <astares(a)gmx.de> wrote: > Thanks Igor! :) > > After trying in in a fresh Pharo3.0 Latest update: #30703 I loaded slice > 12674 the > test for NB are green and > > (NBExternalTypeValue ofType: 'NBInt64'). > > now finally works. With this now "PUnQLite" package can be loaded again in > Pharo 3.0 > without errors: > > Gofer new > url: 'http://smalltalkhub.com/mc/MasashiUmezawa/PunQLite/main'; > package: 'ConfigurationOfPunQLite'; > load. > (Smalltalk at: #ConfigurationOfPunQLite) load > > The examples from https://github.com/mumez/PunQLite work, EXCEPT one: > > "Import from files" > db := PqDatabase open: 'mczCache.db'. > (FileSystem workingDirectory / 'package-cache') files do: [:each | > (db importAt: each basename fromFile: each pathString) > ifTrue: [db commitTransaction]. > ]. > db keys inspect. > db close. > > which first gives an "PqCursor" error and when run for a second time leads > to > a hard VM CRASH (on Windows 8). Anyone able to reproduce? > > Note that one requires UnQLite library to reproduce which is prebuilt here: > > https://github.com/mumez/PunQLite/tree/master/binary > > I guess it is somewhere in #importAt:fromFile: which uses memory mapped > files... > > If you will stuck for real, feel free to send me a .zip file containing everything prepared vm+image+dll+doit in workspace to reproduce it, so i can take a look. No guarantees i will be able to find anything, however ;) > Bye > T. > > > > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.

Jan. 17, 2014

subscriptOutOfBounds: 1 in NECInstVarTypeGuesser in Pharo 30677

by Pharo4Stef

No idea how to reproduce it. computeVarType | info tempNames name | types ifEmpty: [ ^ nil ]. info := types first. (hasSend and: [ info isDefinedByMessageSend not ]) ifTrue: [ info type: nil. ^ info ]. info isDefinedByTemporary ifFalse: [ ^ info ]. tempNames := (receiverClass compiler parse: currentMethod sourceCode) tempNames. ^^^^^^^^^^^^ #() so the rest breaks. name := tempNames at: info temporaryOffset + 1. info type: (self class getClassFromTypeSuggestingName: name). ^ info

Jan. 17, 2014

Re: [Pharo-dev] Displaying labels with Athens on Linux?

by Igor Stasenko

On 17 January 2014 21:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > For normal humans you do not convey the pain behind â¦. > here is the answer I got from the two amigos igor and ronie that looked at > the problem > > about the pain behind.. Stef, i'm not sure, maybe for those who not familiar with low-level debugging, the procedures look very scary and traumatizing, but for not for me nor Ronie.. i don't remember but i think it took us less than an hour to determine what's wrong there. And to fix that, it took few seconds. So, it was done very quickly, alas... then i faced integration wall.. and it took me much more time & effort to verify & wait till it reverify things in many places.. because for some strange reason integration validation says there's failing test.. which is not if you run things by yourself. All this pain, of course, doesn't means, that i am against validation. It really helps, but sure thing it is hard to cover all aspects to make sure things run under same conditions as in reality.. and it always be like that. (and speaking about conveying the pain behind... imagine the amount of pain setting up & automating validation procedure and integration, so that it works and we can use it.. ) > > We debugged in both machines at the same time. Installed > some debug symbols, looking at the libpixman source code. Disassembling and > looking some instructions. > > When I saw the use of intrinsics in the source code, I > started to suspect a bit of the alignment of some stuff and when Igor, > found the segmentation fault causing instruction movdqa > (Move double-quadword aligned), it was clear that it was a > stack alignment issue. Checking the Intel manual confirmed this and I asked > about whose responsible for aligning the > stack, suspecting it was a problem with the library not > conforming to the ABI. Then, Igor remembered how to change the stack > alignment in native boost and it worked. > > This is why having people with such knowledge around is key to let us (the > smart cosy smalltalkers) having fun with our cool language. > > Stef > > > > > Fix integrated. > > > > in 3.0 704 > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Jan. 17, 2014

Re: [Pharo-dev] Displaying labels with Athens on Linux?

by Alexandre Bergel

I suspected a big pain, but not that much. Thanks guys! Alexandre On Jan 17, 2014, at 5:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > For normal humans you do not convey the pain behind â¦. > here is the answer I got from the two amigos igor and ronie that looked at the problem > > > We debugged in both machines at the same time. Installed some debug symbols, looking at the libpixman source code. Disassembling and looking some instructions. > > When I saw the use of intrinsics in the source code, I started to suspect a bit of the alignment of some stuff and when Igor, found the segmentation fault causing instruction movdqa > (Move double-quadword aligned), it was clear that it was a stack alignment issue. Checking the Intel manual confirmed this and I asked about whose responsible for aligning the > stack, suspecting it was a problem with the library not conforming to the ABI. Then, Igor remembered how to change the stack alignment in native boost and it worked. > > This is why having people with such knowledge around is key to let us (the smart cosy smalltalkers) having fun with our cool language. > > Stef > > > >> Fix integrated. >> >> in 3.0 704 >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 17, 2014

Re: [Pharo-dev] different execution result debugger vs. 'normal run'

by Marcus Denker

On 17 Jan 2014, at 18:43, Johan Brichau <johan(a)inceptive.be> wrote: > Hi Marcus, > > I was hoping for that ;-) > An NDA will not be necessary, just that I don't need to send our code to the list and your guarantee to eat the image afterwards ;-) > > Will put it on a shared Dropbox link and email you, is that fine? > ok! > Johan > > Sent from my iPad > >> On 17 Jan 2014, at 13:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> This could be a compiler bugâ¦ I check that with you offline of the list (and sign any NDA needed ;-) >> >> Marcus >> >>> On 17 Jan 2014, at 13:27, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> Hi there, >>> >>> In the process of porting our work to Pharo3, I encounter a bug where the execution in the debugger works correctly but not outside of it. >>> It consistently occurs in a testcase of our code, across different images running Pharo 30700 and latest stable vm om mac (26 dec) as well as an older vm (6 sep). >>> >>> Since it's difficult to create a separate public test for this to recreate the problem, how do we go about this? >>> >>> cheers, >>> Johan >> >> >

Jan. 17, 2014

Re: [Pharo-dev] IncompatibleLayoutConflict with NativeBoost in recent #30700

by Torsten Bergmann

Thanks Igor! :) After trying inÂ in a freshÂ Pharo3.0Â Latest update: #30703 I loaded slice 12674 the test for NB are green and (NBExternalTypeValue ofType: 'NBInt64'). now finally works. With this now "PUnQLite" package can be loaded again in Pharo 3.0 without errors: Â Â Gofer new url: 'http://smalltalkhub.com/mc/MasashiUmezawa/PunQLite/main'; package: 'ConfigurationOfPunQLite'; load. (Smalltalk at: #ConfigurationOfPunQLite) load The examples from https://github.com/mumez/PunQLite work, EXCEPT one: "Import from files" db := PqDatabase open: 'mczCache.db'. (FileSystem workingDirectory / 'package-cache') files do: [:each | (db importAt: each basename fromFile: each pathString) ifTrue: [db commitTransaction]. ]. db keys inspect. db close. which first gives an "PqCursor" error and when run for a second time leads to a hard VM CRASH (on Windows 8). Anyone able to reproduce? Note that one requires UnQLite library to reproduce which is prebuilt here: https://github.com/mumez/PunQLite/tree/master/binary I guess it is somewhere in #importAt:fromFile: which uses memory mapped files... Bye T. Â Gesendet:Â Freitag, 17. Januar 2014 um 20:55 Uhr Von:Â "Igor Stasenko" <siguctua(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] IncompatibleLayoutConflict with NativeBoost in recent #30700 Â Â On 17 January 2014 20:13, Torsten Bergmann <astares(a)gmx.de> wrote: Camille wrote: >It works and it's commited.Â Â Thanks! Still there is a problem: Â (NBExternalTypeValue ofType: 'NBInt64'). in a Pharo3.0 Latest update: #30703 (with the fix integrated) throws now an #DNU because the new anonymous subclass of NBExternalTypeValue class does not understand #rebuildFieldAccessors NBExternalTypeValue(class)>>valueType: sends #rebuildFieldAccessors but there is no such method in this hierarchy. But there is NBExternalStructure>>rebuildFieldAccessors and NBExternalTypeValue(class)>>installAccessors. Maybe a leftover from refactoring? Â Â fix in inbox https://pharo.fogbugz.com/f/cases/12674/Fix-NBExternalTypeValue-initializat… Â Thx Torsten Â -- Best regards, Igor Stasenko.

Jan. 17, 2014

Re: [Pharo-dev] Displaying labels with Athens on Linux?

by StÃ©phane Ducasse

For normal humans you do not convey the pain behind â¦. here is the answer I got from the two amigos igor and ronie that looked at the problem We debugged in both machines at the same time. Installed some debug symbols, looking at the libpixman source code. Disassembling and looking some instructions. When I saw the use of intrinsics in the source code, I started to suspect a bit of the alignment of some stuff and when Igor, found the segmentation fault causing instruction movdqa (Move double-quadword aligned), it was clear that it was a stack alignment issue. Checking the Intel manual confirmed this and I asked about whose responsible for aligning the stack, suspecting it was a problem with the library not conforming to the ABI. Then, Igor remembered how to change the stack alignment in native boost and it worked. This is why having people with such knowledge around is key to let us (the smart cosy smalltalkers) having fun with our cool language. Stef > Fix integrated. > > in 3.0 704 > > > > -- > Best regards, > Igor Stasenko.

Jan. 17, 2014