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

Re: [Pharo-dev] subscriptOutOfBounds: 1 in NECInstVarTypeGuesser in Pharo 30677

by Marcus Denker

What we need is a a statistics gatherer for issues like this: -> every time a walk bak happens, the system allow people to submit a stack track -> this is gatererd in a database -> then we visualise the system to show where all the problems are ==> we will soon know all unable and buggy parts of the system. On 17 Jan 2014, at 22:49, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > 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. 18, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by StÃ©phane Ducasse

One of the problem we are thinking about now is the FFI on ARM (alien or not alien)â¦. >> 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. > > Good to know. > > Thanks Jean-Baptiste ! >

Jan. 18, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by StÃ©phane Ducasse

+1 On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. 18, 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 > > 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. You forgot the afternoon before where you were clueless. :) And Iâm talking for a guy that is not a friend with gbd, assembly. Most of us can fix bugs in the image now how many can fix bugs that are related with Stack alignement? one? two? This is the kind of waranty that the consortium should give us. Remember in 11 months you are not payed anymore. Stef > 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. 18, 2014

Re: [Pharo-dev] ConfigurationOfGetText broken?

by Johan Brichau

I agree. The Seaside packages should be moved to the Seaside configuration and make that one dependent on ConfigurationOfGettext. Also, the Seaside30Addons repository was moved to smalltalkhub. Johan On 17 Jan 2014, at 17:17, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Le 17/01/2014 11:42, Usman Bhatti a Ã©crit : >> >> It seems that some recent changes in the ConfigurationOfText have broken >> the loading in the Pharo 3.0. >> > > > I only know basic of ConfigurationOf..., but it looks odd to me to see > Seaside dependencies in the Gettext configuration. Should it not belong > to this configuration? Imagine if each package depending on Gettext to > add itself in the gettext configuration? > > Hilaire > > -- > Dr. Geo http://drgeo.eu > >

Jan. 18, 2014

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

by Johan Brichau

And I will answer my own question, having found the thread on the subject [1]. short answer: "DateAndTime now" got faster ;-) Good job guys! Our test was flawed because it relied (unknowingly) on the delay in DateAndTime creation. thx! Johan [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-April/07756… On 18 Jan 2014, at 05:35, Johan Brichau <johan(a)inceptive.be> wrote: > I figured it out and it's because of this: > > DateAndTime now = DateAndTime now > > is true in Pharo 3 > is false in Pharo 2.0 > is false in Pharo 1.4 > > Did Pharo3 become so fast or did the clock precision decrease? > > Johan > > On 17 Jan 2014, at 22:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> 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. 18, 2014

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

by Johan Brichau

I figured it out and it's because of this: DateAndTime now = DateAndTime now is true in Pharo 3 is false in Pharo 2.0 is false in Pharo 1.4 Did Pharo3 become so fast or did the clock precision decrease? Johan On 17 Jan 2014, at 22:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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. 18, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Igor Stasenko

On 17 January 2014 23:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There is already NativeBoost class>>#isEnabledOrNil > > oh.. right.. > On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > 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 > > so this could become > > ^ self isEnabledOrNil 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. > > But we would still have to write the fallback code, right ;-) > > > 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. > > > -- Best regards, Igor Stasenko.

Jan. 17, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Sven Van Caekenberghe

On 17 Jan 2014, at 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. Good to know. Thanks Jean-Baptiste !

Jan. 17, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Sven Van Caekenberghe

There is already NativeBoost class>>#isEnabledOrNil On 17 Jan 2014, at 23:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 so this could become ^ self isEnabledOrNil 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. But we would still have to write the fallback code, right ;-) > 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