- Pharo-dev - lists.pharo.org

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

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

by Mariano Martinez Peck

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

March 31, 2016

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

by Mariano Martinez Peck

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

March 31, 2016

[pharo-project/pharo-core] 7f477d: 50672

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7f477d73603beebc109ea6cd31f277a1f4f89309 https://github.com/pharo-project/pharo-core/commit/7f477d73603beebc109ea6cd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-03-31 (Thu, 31 Mar 2016) Changed paths: R Morphic-Widgets-Basic.package/PluggableToggleButtonMorph.class/instance/accessing/getModelState.st M SUnit-Core.package/TAssertable.class/instance/asserting/assert_description_resumable_.st M SUnit-Core.package/TestCase.class/instance/events/announce_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50671.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50672.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50671.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50672.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/Slot.class/instance/class building/changingIn_.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/build.st Log Message: ----------- 50672 16775 Class Button is in the wrong state sometimes https://pharo.fogbugz.com/f/cases/16775 17871 Slots need to be notified when they changed https://pharo.fogbugz.com/f/cases/17871 16373 Methods called but not implemented in SUnit https://pharo.fogbugz.com/f/cases/16373 http://files.pharo.org/image/50/50672.zip

March 31, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50672 Home: https://github.com/pharo-project/pharo-core

March 31, 2016

[ANN] Search and open Unix man pages in Pharo (using OSUnix project)

by Torsten Bergmann

I added the possibility to search and open Unix man pages (commands, functions and header files) directly from Pharo Spotter. You will find it in the updated version of my OSUnix support package in catalog (Pharo 5) https://www.youtube.com/watch?v=81eehVO14KU Have fun T.

March 31, 2016

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

by Gabriel Cotelli

On the meantime at least change the handler to ignore the halts. ... on: Exception - Halt Should do the trick 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

CBD now for Pharo

by stepharo

Hi guys just a little announce. Four students in our lecture released a Pharo implementation for CDB. We published a configuration in the Pharo40 Catalog Code is here: MCHttpRepository location: 'http://smalltalkhub.com/mc/TheProfessionals/CDBFormat/main' user: '' password: '' Stef

March 31, 2016