March 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 'Bad argument for external function' with UFFI... no clue

by Mariano Martinez Peck

OK, thank you guys. We chatted internally with Esteban and he proposed me a working solution :) Best, On Thu, Mar 31, 2016 at 11:35 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Mariano, > > You should be able to find the function information you need in > $GEMSTONE/include/gci.hf... > > Dale > > > On 3/31/16 6:27 AM, Mariano Martinez Peck wrote: > > > > On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano < > <estebanlm(a)gmail.com>estebanlm(a)gmail.com> wrote: > >> how does your function call looks like? >> >> > > The function call is: > > ^ self ffiCall: #( GsGciOopType GciExecuteStrFromContextDbg_(String > source, int64 sourceSize, GsGciOopType sourceClassOopType, GsGciOopType > contextObjectOopType, GsGciOopType symbolListOopType, int flags, ushort > environmentId) ) > > > And the C function SHOULD BE (I say SHOULD because I don't have access to > the C source nor header): > > EXTERN_GCI_DEC(OopType) > GciExecuteStrFromContextDbg_( > const char source[], int64 sourceSize, OopType sourceClass, > OopType contextObject, OopType symbolList, > int flags, ushort environmentId ); > > > I am not sure which is the error because other times I did get an error > that is was clear that it couldn't marshal the arguments. But that "bad > arguments" doesn't tell me much :( > > > > > On 31 Mar 2016, at 04:55, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> Hi guys, >> >> Could someone help me understand what could be the exact reason of a 'Bad >> argument for external function' in an FFI call? Of course, I double checked >> all the arguments definitions in the #ffiCall: and the real objects I >> receive as arguments at the moment of the callout. And they all seem >> correct. >> >> And even better...how can I get more info about it? >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

March 31, 2016

Re: [Pharo-dev] [Moose-dev] Spotter Survey

by Tudor Girba

Hi, In case you did not do it yet, please consider spending 5 minutes to fill in this survey. It helps us advertise this work to the outside world, and get a better picture of where to move next. Cheers, Doru > On Mar 29, 2016, at 10:17 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hello everybody, > > We are conducting a small survey about Spotter. > It would help us if you would complete the survey at: http://spotter.limequery.com/index.php/216683/lang-en > > We will use the data from this survey both in a research tasks and to help us to further improve Spotter. > The survey should take you less than 5 minutes to complete. > > Thanks for your help! > > Cheers, > Andrei > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

March 31, 2016

Re: [Pharo-dev] [ANN] OS-Linux-CentOS

by Sven Van Caekenberghe

> On 31 Mar 2016, at 18:35, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Torsten, > > This is a very cool piece of work! Thanks. +10 > Cheers, > Doru > > >> On Mar 31, 2016, at 6:31 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi, >> >> the OS-xxx series with (so far) >> >> - OS-Windows >> - OS-Linux-Ubuntu >> - OS-Unix >> - OS-Raspbian >> >> now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized >> pendant to "OS-Linux-Ubuntu". >> >> Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS >> >> Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" >> into the Spotter search tool. >> >> Enjoy the video: >> >> https://www.youtube.com/watch?v=nAwtVeoll_k >> >> Bye >> T. >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > >

March 31, 2016

Re: [Pharo-dev] [ANN] OS-Linux-CentOS

by Tudor Girba

Hi Torsten, This is a very cool piece of work! Thanks. Cheers, Doru > On Mar 31, 2016, at 6:31 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > the OS-xxx series with (so far) > > - OS-Windows > - OS-Linux-Ubuntu > - OS-Unix > - OS-Raspbian > > now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized > pendant to "OS-Linux-Ubuntu". > > Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS > > Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" > into the Spotter search tool. > > Enjoy the video: > > https://www.youtube.com/watch?v=nAwtVeoll_k > > Bye > T. > > -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

March 31, 2016

[ANN] OS-Linux-CentOS

by Torsten Bergmann

Hi, the OS-xxx series with (so far) - OS-Windows - OS-Linux-Ubuntu - OS-Unix - OS-Raspbian now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized pendant to "OS-Linux-Ubuntu". Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" into the Spotter search tool. Enjoy the video: https://www.youtube.com/watch?v=nAwtVeoll_k Bye T.

March 31, 2016

[ANN] OS-Windows 2.1 project updated for Pharo 5 (NB to UFFI transition)

by Torsten Bergmann

Hi, the "OS-Windows" package [1] from my "OS-xxx" Pharo goodies series [2] is providing better access to native Windows APIs and wraps Windows functionality for easier access/coding in Pharo (browser, console, processes, shell, window, GDI, ...). Some of you may know or use this package already. Up to the last provided stable version for Pharo 4 all my code and bindings were based on "old" NativeBoost (NB). With the transition away from NB over to new UniversalFFI (UFFI) within Pharo 5 it was necessary to port/migrate the code over to UFFI for all the OS-xxx projects. Work of the Windows port started when UFFI was still shaky (December) and in a separate repo [3]. It was not easy in the beginning, some headbanging against the wall and feeling like a crash test dummy was involved - basing the port on early UFFI code and without much documentation. Several UFFI issues had to be discussed with Esteban Lorenzano in private conversations on #slack: often leading to some updated UFFI versions afterwards and an updated worklog of Esteban [4]. In the Pharo spirit "step by step" all of this got analyzed, fixed, renamed, improved and integrated into latest Pharo 5 in the last months. Esteban was VERY VERY supportive and adopted UFFI for all the needs! ONCE AGAIN: A BIG THANK YOU, ESTEBAN!!! Long story short: I can now release "OS-Windows" again into the wild for Pharo 5: fully compatible, again with cleaner code, some more functionality and even more tests (from 77 to now 81) As ever it is easy to access: open spotter in Pharo 5 and load "OSWindows". Full docu is on the project page [1], the new version is fully compatible to the Pharo 4 version so there was no need to change a single line in the tutorial. ;) Have fun T. [1] http://www.smalltalkhub.com/#!/~OS/OS-Windows [2] http://www.smalltalkhub.com/#!/~OS [3] http://www.smalltalkhub.com/#!/~TorstenBergmann/NOS [4] http://log.smallworks.eu/

March 31, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Gabriel Cotelli

Handling Error will be an improvement. But we don't know the rationale for handling Exception in the first place, if it's for ignoring some Warnings and Errors then changing the handler to Error would break things. I was trying to propose the less risky change, but I'm with you. The right solution is not to make the handler too broad, even handling Error is a bad smell. On Thu, Mar 31, 2016 at 11:22 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > On the meantime at least change the handler to ignore the halts. > > ... on: Exception - Halt > > Should do the trick > > Can someone say why > ... on: Error > will not improve things? > > Exception - Halt is just /wrong/, less wrong than Exception but still very > wrong. > > _,,,^..^,,,_ (phone) > > On Mar 31, 2016 06:57, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > >> >> On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Do anyone really use GLM-Morphic-Brick? >> >> Because it is there just for spotter and will be deleted ASAP. >> >> We know that it is bad. Normal fix requires too many changes... >> >> but catching Exception is bad because it will catch all, even Warnings >> and Halts. >> It would be less bad if it catches Error (not Exception). Still bad, but >> less bad :) >> >> Esteban >> >> On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: >> >>> Please don't do this: >>> >>> updateHeight >>> "no need to care about height, when it's logic is not customized" >>> self layout isHeightCustom ifFalse: [ ^ self ]. >>> [ self bounds: (self brickBounds withHeight: self customHeight) ] >>> on: Exception >>> do: [ "just skip and do nothing" ] >>> >>> This makes debugging GLM/Brick ui/layout code with "self haltOnce" >>> impossible. >>> see >>> GLMBrickGeometryTrait>>#updateHeight >>> GLMBrickGeometryTrait>>#updateWidth >>> >>> And if you log out the raised exception, you see some calls to >>> not initialized fonts and a ZeroDevide and some more errors. >>> The above catch, catches and hides wrong / to late initialized objects. >>> >> >>

March 31, 2016

Re: [Pharo-dev] 'Bad argument for external function' with UFFI... no clue

by Dale Henrichs

Mariano, You should be able to find the function information you need in $GEMSTONE/include/gci.hf... Dale On 3/31/16 6:27 AM, Mariano Martinez Peck wrote: > > > On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > how does your function call looks like? > > > > The function call is: > > ^ self ffiCall: #( GsGciOopType GciExecuteStrFromContextDbg_(String > source, int64 sourceSize, GsGciOopType sourceClassOopType, > GsGciOopType contextObjectOopType, GsGciOopType symbolListOopType, int > flags, ushort environmentId) ) > > > And the C function SHOULD BE (I say SHOULD because I don't have access > to the C source nor header): > > EXTERN_GCI_DEC(OopType) > GciExecuteStrFromContextDbg_( > const char source[], int64 sourceSize, OopType sourceClass, > OopType contextObject, OopType symbolList, > int flags, ushort environmentId ); > > > I am not sure which is the error because other times I did get an > error that is was clear that it couldn't marshal the arguments. But > that "bad arguments" doesn't tell me much :( > > > > >> On 31 Mar 2016, at 04:55, Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Hi guys, >> >> Could someone help me understand what could be the exact reason >> of a 'Bad argument for external function' in an FFI call? Of >> course, I double checked all the arguments definitions in the >> #ffiCall: and the real objects I receive as arguments at the >> moment of the callout. And they all seem correct. >> >> And even better...how can I get more info about it? >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > > -- > Mariano > http://marianopeck.wordpress.com

March 31, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Eliot Miranda

> On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > On the meantime at least change the handler to ignore the halts. > > ... on: Exception - Halt > > Should do the trick > Can someone say why ... on: Error will not improve things? Exception - Halt is just /wrong/, less wrong than Exception but still very wrong. _,,,^..^,,,_ (phone) >> On Mar 31, 2016 06:57, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >> >>> On 30 Mar 2016, at 19:54, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> >>> Do anyone really use GLM-Morphic-Brick? >>> >>> Because it is there just for spotter and will be deleted ASAP. >>> >>> We know that it is bad. Normal fix requires too many changes... >>> >> but catching Exception is bad because it will catch all, even Warnings and Halts. >> It would be less bad if it catches Error (not Exception). Still bad, but less bad :) >> >> Esteban >> >>>> On Mar 30, 2016 1:34 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: >>>> Please don't do this: >>>> >>>> updateHeight >>>> "no need to care about height, when it's logic is not customized" >>>> self layout isHeightCustom ifFalse: [ ^ self ]. >>>> [ self bounds: (self brickBounds withHeight: self customHeight) ] >>>> on: Exception >>>> do: [ "just skip and do nothing" ] >>>> >>>> This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible. >>>> see >>>> GLMBrickGeometryTrait>>#updateHeight >>>> GLMBrickGeometryTrait>>#updateWidth >>>> >>>> And if you log out the raised exception, you see some calls to >>>> not initialized fonts and a ZeroDevide and some more errors. >>>> The above catch, catches and hides wrong / to late initialized objects.

March 31, 2016

Re: [Pharo-dev] 'Bad argument for external function' with UFFI... no clue

by Mariano Martinez Peck

One more addition is that the exact definition of OopType is this: typedef uint64_t OopType; On Thu, Mar 31, 2016 at 10:51 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > OK...I have some more info...please read the end if you have little time. > > I have the same error for even a simpler function: > > GCI_ALIGN_STACK EXTERN_GCI_DEC(OopType) > GciFetchClass(OopType theObject); > > which I call this way: > > apiGciFetchClass: theObject > > ^ self ffiCall: #( GsGciOopType GciFetchClass(GsGciOopType theObject) ) > > The arguments I receive at runtime (theObject) prints to something > like "GsOopType(200635137)" so...at least it looks like a valid object > with a valid handle. > > I suspect there might be something wrong with the GsGciOopType (subclass > of FFIExternalStructure). > *In the original C specification it says that OopType should be an > unsigned 64-bit integer.* > > *The way this was mapped BEFORE (with old FFI) was like this:* > > *fields* > "self compileFields" > "self byteSize" > * ^ #(nil 'ulonglong')* > > *BTW... i don't understand that nil there. * > > And...with the OLD FFI, GsGciOopType (originally subclass of > ExternalStructure) was managed like an integer directly. For example, above > GciFetchClass would directly answer the integer (the ulonglong field). > > With the new approach I am doing: > > fieldsDesc > > ^ #( > ulonglong oop; > ) > > But now... for example above GciFetchClass would answer an instance of > GsGciOopType to which I must send #asInteger to get the integer value. > > > So...I suspect the same problem might be in the marshaling of the > GsGciOopType instances I pass as argument. Maybe previously arrived already > as integer to C while now it's different. > > Any pointer is appreciated. > > > > > > On Thu, Mar 31, 2016 at 10:27 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Thu, Mar 31, 2016 at 12:44 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> how does your function call looks like? >>> >>> >> >> The function call is: >> >> ^ self ffiCall: #( GsGciOopType GciExecuteStrFromContextDbg_(String >> source, int64 sourceSize, GsGciOopType sourceClassOopType, GsGciOopType >> contextObjectOopType, GsGciOopType symbolListOopType, int flags, ushort >> environmentId) ) >> >> >> And the C function SHOULD BE (I say SHOULD because I don't have access to >> the C source nor header): >> >> EXTERN_GCI_DEC(OopType) >> GciExecuteStrFromContextDbg_( >> const char source[], int64 sourceSize, OopType sourceClass, >> OopType contextObject, OopType symbolList, >> int flags, ushort environmentId ); >> >> >> I am not sure which is the error because other times I did get an error >> that is was clear that it couldn't marshal the arguments. But that "bad >> arguments" doesn't tell me much :( >> >> >> >> >> On 31 Mar 2016, at 04:55, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>> Hi guys, >>> >>> Could someone help me understand what could be the exact reason of >>> a 'Bad argument for external function' in an FFI call? Of course, I double >>> checked all the arguments definitions in the #ffiCall: and the real objects >>> I receive as arguments at the moment of the callout. And they all seem >>> correct. >>> >>> And even better...how can I get more info about it? >>> >>> Thanks in advance, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

March 31, 2016