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

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

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

by Esteban Lorenzano

> 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 <mailto:nicolaihess@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] Catching Exceptions without any notice

by Nicolai Hess

2016-03-31 10:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Nicolai, > > Thank you for the feedback. Just, please letâs adopt a different tone. > > Cheers, > Doru > > > I am not sure what is wrong with my tone. I did not choose a random external library and starting to criticize it. This is a core component. And "Because it is there just for spotter and will be deleted ASAP. We know that it is bad. Normal fix requires too many changes." is not an excuse for badly debuggable code. I don't like to have quick-dirty-throwaway-hacks in the core. There is a real demand for debugging this code. The attached screenshot shows a common issue with inspector panes. The available space would suffice for all tabs (secodn window) but the default size shnrinks nearly all tabs (first window). The normal way to understand and trying to fix this issue, is to put some "self halt" at some point for the layout processing.But this does not work here because *all* exceptions are catched. And changing the code to actually execute the exception won't work either, becuase this will throw all other (previously cachted) exceptions (what is wrong with initializing the font property properly or checking for ZeroDivide?) And this is frustrating. And I hope no one sees and adopts this code, just because it is the way our own core tools are built. BTW, your LazyTabGroupMorph class is another bad example. It subclasses TabGroupMorph, it calls super initialize, removes all created and added morphs from its super class and recreates and replaces them with its own. nicolai

March 31, 2016

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

by Tudor Girba

Hi Nicolai, Thank you for the feedback. Just, please letâs adopt a different tone. Cheers, Doru > On Mar 31, 2016, at 8:37 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-03-30 19:54 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Do anyone really use GLM-Morphic-Brick? > > We all "use" it, our tools are build with this. (inspector/debugger/playground/spotter). > > Because it is there just for spotter and will be deleted ASAP. > > > Not only for spotter. And if our tools are build with this, people may try to use this > for their own tools. This is the core image, and the core tools. What should we > say? > Please don't use it, but our core tools are built on this? > > > We know that it is bad. Normal fix requires too many changes... > > > No excuse. > > > 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. > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

March 31, 2016