- Pharo-users - lists.pharo.org

Re: [Pharo-users] Recovering PNG/JPG images that were automatically serialized as FUEL when storing into external database

by Pierce Ng

On Sat, Jul 02, 2016 at 10:01:14PM -0500, Offray Vladimir Luna CÃ¡rdenas wrote: > I can read the blobs from SQLite. The problem is that they're stored > as FUEL inside SQLite and I don't know how to read them back to > recover the png/jpeg image that was serialized that way. UDBCSQLite uses Fuel to serialize/materialize objects that aren't integers, real numbers and strings. Sounds like you've hit a bug, whereby your png/jpg files are serialized but aren't being materialized when read back, so you're getting back raw byte arrays. Can you provide simple schema and code fragment to reproduce the problem please. Pierce

July 5, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Julien Delplanque

Ok, the problem is resolved thanks to Esteban. There was a mistake in the code given in preceding mails so, I am rewriting the 3 steps here: === 1) Declare your class that subclasses FFIOpaqueObject: FFIOpaqueObject subclass: USBDevice etc... 2) Get a pointer to the array: arrayPtr := ExternalAddress new. size := self getDevice: context list: arrayPtr. with: getDevice: ctx list: list ^ self ffiCall: #(size_t libusb_get_device_list (libusb_context *ctx, void **list)) 3) Now that we have the size of the array, we can declare it: array := FFIExternalArray fromHandle: arrayPtr type: USBDevice size: size. === The problem was that I was using #fromPointer:type:size instead of #fromHandle:type:size:. Thanks again Esteban! Julien On 04/07/16 13:15, Julien Delplanque wrote: > > > On 04/07/16 12:18, Ben Coman wrote: >>> On Mon, Jul 4, 2016 at 4:24 PM, Julien Delplanque <julien(a)tamere.eu> >>> wrote: >>>> Hello again Esteban, all others, >>>> >>>> I am still experiencing strange behaviors with the objects in the >>>> external >>>> array. >>>> >>>> I get a lot of NULL pointers and some strange addresses (I guess, I >>>> am not a >>>> C expert) that are close to NULL >>>> (see the screenshot attached). These objects make the VM crash >>>> (segmentation >>>> fault) when I call a function >>>> from the libusb binding (for NULL objects it may be ok but what about >>>> others?). Some other objects (those with >>>> a normal address in the screenshot) work finely with the functions >>>> calls >>>> using UFFI... >>>> >>>> This kind of bug is not reported in libusb discussions I found on the >>>> internet and I tried an example in C, >>>> there is no NULL pointer received from the function (they are not even >>>> considered in official examples). >>>> >>>> So I guess the problem may come from Pharo? >>>> >>>> Do you have any idea of what it could be? >>>> >>>> I will be available on Slack all the day if you want. :) >>>> >>>> Thanks in advance, >>>> >>>> Julien >> >> On Mon, Jul 4, 2016 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> How does it compare with the result you get in pure C? >>> e.g. using this code... >>> http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a… >>> >>> >> Also, what is the return value of calling libusb_init() from Pharo? >> >> cheers -ben > > In pure C, it works. All my device are listed with the code at the > link you gave me (so there is no NULL pointer). > > In Pharo, libusb_init() returns 0 as expected. > > Julien

July 4, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Julien Delplanque

On 04/07/16 12:18, Ben Coman wrote: >> On Mon, Jul 4, 2016 at 4:24 PM, Julien Delplanque <julien(a)tamere.eu> wrote: >>> Hello again Esteban, all others, >>> >>> I am still experiencing strange behaviors with the objects in the external >>> array. >>> >>> I get a lot of NULL pointers and some strange addresses (I guess, I am not a >>> C expert) that are close to NULL >>> (see the screenshot attached). These objects make the VM crash (segmentation >>> fault) when I call a function >>> from the libusb binding (for NULL objects it may be ok but what about >>> others?). Some other objects (those with >>> a normal address in the screenshot) work finely with the functions calls >>> using UFFI... >>> >>> This kind of bug is not reported in libusb discussions I found on the >>> internet and I tried an example in C, >>> there is no NULL pointer received from the function (they are not even >>> considered in official examples). >>> >>> So I guess the problem may come from Pharo? >>> >>> Do you have any idea of what it could be? >>> >>> I will be available on Slack all the day if you want. :) >>> >>> Thanks in advance, >>> >>> Julien > > On Mon, Jul 4, 2016 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >> How does it compare with the result you get in pure C? >> e.g. using this code... >> http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a… >> > Also, what is the return value of calling libusb_init() from Pharo? > > cheers -ben In pure C, it works. All my device are listed with the code at the link you gave me (so there is no NULL pointer). In Pharo, libusb_init() returns 0 as expected. Julien

July 4, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Esteban Lorenzano

> On 04 Jul 2016, at 12:15, Ben Coman <btc(a)openinworld.com> wrote: > > How does it compare with the result you get in pure C? > e.g. using this code... > http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a… <http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a…> yes, this is a good approach since I cannot know what is happeningâ¦ and basically arrays just take the pointer and do âaddress+offsetâ to give you another pointer. but of course, it can failâ¦ if somewhere there is a problem in function translationâ¦ Esteban > > On Mon, Jul 4, 2016 at 4:24 PM, Julien Delplanque <julien(a)tamere.eu> wrote: >> Hello again Esteban, all others, >> >> I am still experiencing strange behaviors with the objects in the external >> array. >> >> I get a lot of NULL pointers and some strange addresses (I guess, I am not a >> C expert) that are close to NULL >> (see the screenshot attached). These objects make the VM crash (segmentation >> fault) when I call a function >> from the libusb binding (for NULL objects it may be ok but what about >> others?). Some other objects (those with >> a normal address in the screenshot) work finely with the functions calls >> using UFFI... >> >> This kind of bug is not reported in libusb discussions I found on the >> internet and I tried an example in C, >> there is no NULL pointer received from the function (they are not even >> considered in official examples). >> >> So I guess the problem may come from Pharo? >> >> Do you have any idea of what it could be? >> >> I will be available on Slack all the day if you want. :) >> >> Thanks in advance, >> >> Julien >> >> On 01/07/16 14:03, Esteban Lorenzano wrote: >>> >>> ok, can you reload development version and try again? >>> >>> ps: this is easier on slack ;) >>> >>>> On 01 Jul 2016, at 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> yes, I made a mistakeâ¦ the problem of not being capable of test here :( >>>> >>>> 1 minute. >>>> >>>> Esteban >>>> >>>>> On 01 Jul 2016, at 13:56, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>> >>>>> Ok, now I get a different exception! :-) >>>>> >>>>> "MessageNotUnderstood: LUDevice class>>fromHandle:" >>>>> >>>>> when executing: "array first." >>>>> >>>>> Where LUDevice is defined like this: >>>>> >>>>> FFIOpaqueObject subclass: #LUDevice >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> package: 'LibUsb-Kernel' >>>>> >>>>> Julien >>>>> >>>>> >>>>> On 01/07/16 13:51, Esteban Lorenzano wrote: >>>>>> >>>>>> I need you to test :) >>>>>> >>>>>> can you execute this: >>>>>> >>>>>> (ConfigurationOfUnifiedFFI project version: #development) load. >>>>>> >>>>>> and then retry your example? >>>>>> >>>>>> thanks, >>>>>> Esteban >>>>>> >>>>>> ps: this became pharo-dev, but wellâ¦ still here :) >>>>>> >>>>>>> On 01 Jul 2016, at 13:48, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>>>> >>>>>>> Oh, ok :p >>>>>>> >>>>>>> Can you notify me know when the bug will be resolved? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Julien >>>>>>> >>>>>>> >>>>>>> On 01/07/16 13:36, Esteban Lorenzano wrote: >>>>>>>> >>>>>>>> â¦ and now you hit a bug. >>>>>>>> bah, an ânon implemented featureâ :P >>>>>>>> >>>>>>>> I never tested arrays with complex types. >>>>>>>> it should not be hardâ¦ I will provide a fix. >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>>> On 01 Jul 2016, at 13:30, Julien Delplanque <julien(a)tamere.eu> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Ok, the ffi call is done without problem with your method thanks. :) >>>>>>>>> >>>>>>>>> But now that I have the array, when I try to access the first >>>>>>>>> element using: >>>>>>>>> >>>>>>>>> array first. >>>>>>>>> >>>>>>>>> I get a exception saying I need to override a method: >>>>>>>>> >>>>>>>>> "SubclassResponsibility: FFIOpaqueObjectType had the subclass >>>>>>>>> responsibility to implement #basicHandle:at:" >>>>>>>>> >>>>>>>>> I looked at others implementors but I am not sure of how I should >>>>>>>>> override it, nor if I should. >>>>>>>>> >>>>>>>>> Thanks for the time your taking to answer me. :-) >>>>>>>>> >>>>>>>>> Julien >>>>>>>>> >>>>>>>>> On 01/07/16 12:29, Esteban Lorenzano wrote: >>>>>>>>>>> >>>>>>>>>>> On 01 Jul 2016, at 12:27, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> hi, >>>>>>>>>>> >>>>>>>>>>> this is because you want to get an array with opaque objects. Do >>>>>>>>>>> not let the *** confuses youâ¦ cwhat you actually want, conceptually is >>>>>>>>>>> something like this: >>>>>>>>>>> >>>>>>>>>>> *((FFIOpaqueObject*)[]) >>>>>>>>>>> >>>>>>>>>>> means: you pass the address of an array of opaque types (who are >>>>>>>>>>> always pointers). >>>>>>>>>>> >>>>>>>>>>> So, what you need to pass is the address of an arrayâ¦ you will >>>>>>>>>>> need to work a bit here, since translation is not automatic. >>>>>>>>>>> >>>>>>>>>>> 1) you need to declare your type. Letâ say it will be: >>>>>>>>>>> >>>>>>>>>>> FFIOpaqueObject subclass: USBDevice. >>>>>>>>>>> >>>>>>>>>>> 2) then you need to get the pointer to this array. You need to >>>>>>>>>>> rewrite you code as this: >>>>>>>>>>> >>>>>>>>>>> arrayPtr := ExternalAddress new. >>>>>>>>>>> size := self getDevice: ctx list: arrayPtr. >>>>>>>>>>> >>>>>>>>>>> getDevice: ctx list: list >>>>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list >>>>>>>>>>> (libusb_context *ctx, void **list)) >>>>>>>>>>> >>>>>>>>>>> NOTE that we change the type to "void **â. This is because this is >>>>>>>>>>> what you actually want: the array of devices >>>>>>>>>>> >>>>>>>>>>> 3) now you will have size and arrayPtr. Then you declare the >>>>>>>>>>> array: >>>>>>>>>>> >>>>>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice >>>>>>>>>> >>>>>>>>>> sorry, this expression (while possible) does not stops in âsizeââ¦ >>>>>>>>>> it has to be like this, instead: >>>>>>>>>> >>>>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice >>>>>>>>>> size: size. âyou already has the size for the result" >>>>>>>>>> >>>>>>>>>>> â¦ and you should be able to iterate this array normally :) >>>>>>>>>>> >>>>>>>>>>> let me know if this works for youâ¦ Iâm âcoding in mail clientâ, so >>>>>>>>>>> it can fail :P >>>>>>>>>>> >>>>>>>>>>> cheers, >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 01 Jul 2016, at 12:02, Julien Delplanque <julien(a)tamere.eu> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Thanks, it works I get an instance of FFIOpaqueObject. >>>>>>>>>>>> >>>>>>>>>>>> But how do I get a specific libusb_device object from the list? >>>>>>>>>>>> >>>>>>>>>>>> Thanks again for you quick answer :-). >>>>>>>>>>>> >>>>>>>>>>>> Julien >>>>>>>>>>>> >>>>>>>>>>>> On 01/07/16 11:44, Esteban Lorenzano wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> an opaque structure is not an FFIExternalObject but an >>>>>>>>>>>>> FFIOpaqueObject. >>>>>>>>>>>>> in that case, something like (simplified): >>>>>>>>>>>>> >>>>>>>>>>>>> ctx := (your context). >>>>>>>>>>>>> list := FFIOpaqueObject new. >>>>>>>>>>>>> size := self getDevice: ctx list: list. >>>>>>>>>>>>> >>>>>>>>>>>>> getDevice: ctx list: list >>>>>>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list >>>>>>>>>>>>> (libusb_context *ctx, FFIOpaqueObject ***list)) >>>>>>>>>>>>> >>>>>>>>>>>>> should work (note that of course you can make libusb_device an >>>>>>>>>>>>> alias for your typeâ¦ that does not matters much, this is just a >>>>>>>>>>>>> simplification). >>>>>>>>>>>>> >>>>>>>>>>>>> if this does not works, if you can provide me code to reproduce >>>>>>>>>>>>> it, I can give it a shot and see what happens :) >>>>>>>>>>>>> >>>>>>>>>>>>> Esteban >>>>>>>>>>>>> >>>>>>>>>>>>>> On 01 Jul 2016, at 11:19, Julien Delplanque <julien(a)tamere.eu> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have a question about the UFFI API. I have the following >>>>>>>>>>>>>> function: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ssize_t libusb_get_device_list (libusb_context *ctx, >>>>>>>>>>>>>> libusb_device ***list) >>>>>>>>>>>>>> >>>>>>>>>>>>>> where libusb_device is an opaque structure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I made a type mapping "ssize_t" -> "int" and an object >>>>>>>>>>>>>> inheriting >>>>>>>>>>>>>> from FFIExternalObject for the "libusb_context" (others methods >>>>>>>>>>>>>> using it are working). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can not find how to get an array filled with libusb_device >>>>>>>>>>>>>> using UFFI from Pharo. :-( >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks in advance, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Julien >>>>>>>>>>>>>> >>>>> >>> >> >

July 4, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Ben Coman

> On Mon, Jul 4, 2016 at 4:24 PM, Julien Delplanque <julien(a)tamere.eu> wrote: >> Hello again Esteban, all others, >> >> I am still experiencing strange behaviors with the objects in the external >> array. >> >> I get a lot of NULL pointers and some strange addresses (I guess, I am not a >> C expert) that are close to NULL >> (see the screenshot attached). These objects make the VM crash (segmentation >> fault) when I call a function >> from the libusb binding (for NULL objects it may be ok but what about >> others?). Some other objects (those with >> a normal address in the screenshot) work finely with the functions calls >> using UFFI... >> >> This kind of bug is not reported in libusb discussions I found on the >> internet and I tried an example in C, >> there is no NULL pointer received from the function (they are not even >> considered in official examples). >> >> So I guess the problem may come from Pharo? >> >> Do you have any idea of what it could be? >> >> I will be available on Slack all the day if you want. :) >> >> Thanks in advance, >> >> Julien On Mon, Jul 4, 2016 at 6:15 PM, Ben Coman <btc(a)openinworld.com> wrote: > How does it compare with the result you get in pure C? > e.g. using this code... > http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a… > Also, what is the return value of calling libusb_init() from Pharo? cheers -ben

July 4, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Ben Coman

How does it compare with the result you get in pure C? e.g. using this code... http://libusb.org/browser/libusb/examples/lsusb.c?rev=efc29733ad31f81883a7a… On Mon, Jul 4, 2016 at 4:24 PM, Julien Delplanque <julien(a)tamere.eu> wrote: > Hello again Esteban, all others, > > I am still experiencing strange behaviors with the objects in the external > array. > > I get a lot of NULL pointers and some strange addresses (I guess, I am not a > C expert) that are close to NULL > (see the screenshot attached). These objects make the VM crash (segmentation > fault) when I call a function > from the libusb binding (for NULL objects it may be ok but what about > others?). Some other objects (those with > a normal address in the screenshot) work finely with the functions calls > using UFFI... > > This kind of bug is not reported in libusb discussions I found on the > internet and I tried an example in C, > there is no NULL pointer received from the function (they are not even > considered in official examples). > > So I guess the problem may come from Pharo? > > Do you have any idea of what it could be? > > I will be available on Slack all the day if you want. :) > > Thanks in advance, > > Julien > > On 01/07/16 14:03, Esteban Lorenzano wrote: >> >> ok, can you reload development version and try again? >> >> ps: this is easier on slack ;) >> >>> On 01 Jul 2016, at 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> yes, I made a mistakeâ¦ the problem of not being capable of test here :( >>> >>> 1 minute. >>> >>> Esteban >>> >>>> On 01 Jul 2016, at 13:56, Julien Delplanque <julien(a)tamere.eu> wrote: >>>> >>>> Ok, now I get a different exception! :-) >>>> >>>> "MessageNotUnderstood: LUDevice class>>fromHandle:" >>>> >>>> when executing: "array first." >>>> >>>> Where LUDevice is defined like this: >>>> >>>> FFIOpaqueObject subclass: #LUDevice >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> package: 'LibUsb-Kernel' >>>> >>>> Julien >>>> >>>> >>>> On 01/07/16 13:51, Esteban Lorenzano wrote: >>>>> >>>>> I need you to test :) >>>>> >>>>> can you execute this: >>>>> >>>>> (ConfigurationOfUnifiedFFI project version: #development) load. >>>>> >>>>> and then retry your example? >>>>> >>>>> thanks, >>>>> Esteban >>>>> >>>>> ps: this became pharo-dev, but wellâ¦ still here :) >>>>> >>>>>> On 01 Jul 2016, at 13:48, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>>> >>>>>> Oh, ok :p >>>>>> >>>>>> Can you notify me know when the bug will be resolved? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Julien >>>>>> >>>>>> >>>>>> On 01/07/16 13:36, Esteban Lorenzano wrote: >>>>>>> >>>>>>> â¦ and now you hit a bug. >>>>>>> bah, an ânon implemented featureâ :P >>>>>>> >>>>>>> I never tested arrays with complex types. >>>>>>> it should not be hardâ¦ I will provide a fix. >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>>> On 01 Jul 2016, at 13:30, Julien Delplanque <julien(a)tamere.eu> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Ok, the ffi call is done without problem with your method thanks. :) >>>>>>>> >>>>>>>> But now that I have the array, when I try to access the first >>>>>>>> element using: >>>>>>>> >>>>>>>> array first. >>>>>>>> >>>>>>>> I get a exception saying I need to override a method: >>>>>>>> >>>>>>>> "SubclassResponsibility: FFIOpaqueObjectType had the subclass >>>>>>>> responsibility to implement #basicHandle:at:" >>>>>>>> >>>>>>>> I looked at others implementors but I am not sure of how I should >>>>>>>> override it, nor if I should. >>>>>>>> >>>>>>>> Thanks for the time your taking to answer me. :-) >>>>>>>> >>>>>>>> Julien >>>>>>>> >>>>>>>> On 01/07/16 12:29, Esteban Lorenzano wrote: >>>>>>>>>> >>>>>>>>>> On 01 Jul 2016, at 12:27, Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> hi, >>>>>>>>>> >>>>>>>>>> this is because you want to get an array with opaque objects. Do >>>>>>>>>> not let the *** confuses youâ¦ cwhat you actually want, conceptually is >>>>>>>>>> something like this: >>>>>>>>>> >>>>>>>>>> *((FFIOpaqueObject*)[]) >>>>>>>>>> >>>>>>>>>> means: you pass the address of an array of opaque types (who are >>>>>>>>>> always pointers). >>>>>>>>>> >>>>>>>>>> So, what you need to pass is the address of an arrayâ¦ you will >>>>>>>>>> need to work a bit here, since translation is not automatic. >>>>>>>>>> >>>>>>>>>> 1) you need to declare your type. Letâ say it will be: >>>>>>>>>> >>>>>>>>>> FFIOpaqueObject subclass: USBDevice. >>>>>>>>>> >>>>>>>>>> 2) then you need to get the pointer to this array. You need to >>>>>>>>>> rewrite you code as this: >>>>>>>>>> >>>>>>>>>> arrayPtr := ExternalAddress new. >>>>>>>>>> size := self getDevice: ctx list: arrayPtr. >>>>>>>>>> >>>>>>>>>> getDevice: ctx list: list >>>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list >>>>>>>>>> (libusb_context *ctx, void **list)) >>>>>>>>>> >>>>>>>>>> NOTE that we change the type to "void **â. This is because this is >>>>>>>>>> what you actually want: the array of devices >>>>>>>>>> >>>>>>>>>> 3) now you will have size and arrayPtr. Then you declare the >>>>>>>>>> array: >>>>>>>>>> >>>>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice >>>>>>>>> >>>>>>>>> sorry, this expression (while possible) does not stops in âsizeââ¦ >>>>>>>>> it has to be like this, instead: >>>>>>>>> >>>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice >>>>>>>>> size: size. âyou already has the size for the result" >>>>>>>>> >>>>>>>>>> â¦ and you should be able to iterate this array normally :) >>>>>>>>>> >>>>>>>>>> let me know if this works for youâ¦ Iâm âcoding in mail clientâ, so >>>>>>>>>> it can fail :P >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 01 Jul 2016, at 12:02, Julien Delplanque <julien(a)tamere.eu> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Thanks, it works I get an instance of FFIOpaqueObject. >>>>>>>>>>> >>>>>>>>>>> But how do I get a specific libusb_device object from the list? >>>>>>>>>>> >>>>>>>>>>> Thanks again for you quick answer :-). >>>>>>>>>>> >>>>>>>>>>> Julien >>>>>>>>>>> >>>>>>>>>>> On 01/07/16 11:44, Esteban Lorenzano wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> an opaque structure is not an FFIExternalObject but an >>>>>>>>>>>> FFIOpaqueObject. >>>>>>>>>>>> in that case, something like (simplified): >>>>>>>>>>>> >>>>>>>>>>>> ctx := (your context). >>>>>>>>>>>> list := FFIOpaqueObject new. >>>>>>>>>>>> size := self getDevice: ctx list: list. >>>>>>>>>>>> >>>>>>>>>>>> getDevice: ctx list: list >>>>>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list >>>>>>>>>>>> (libusb_context *ctx, FFIOpaqueObject ***list)) >>>>>>>>>>>> >>>>>>>>>>>> should work (note that of course you can make libusb_device an >>>>>>>>>>>> alias for your typeâ¦ that does not matters much, this is just a >>>>>>>>>>>> simplification). >>>>>>>>>>>> >>>>>>>>>>>> if this does not works, if you can provide me code to reproduce >>>>>>>>>>>> it, I can give it a shot and see what happens :) >>>>>>>>>>>> >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>>> On 01 Jul 2016, at 11:19, Julien Delplanque <julien(a)tamere.eu> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> I have a question about the UFFI API. I have the following >>>>>>>>>>>>> function: >>>>>>>>>>>>> >>>>>>>>>>>>> ssize_t libusb_get_device_list (libusb_context *ctx, >>>>>>>>>>>>> libusb_device ***list) >>>>>>>>>>>>> >>>>>>>>>>>>> where libusb_device is an opaque structure. >>>>>>>>>>>>> >>>>>>>>>>>>> I made a type mapping "ssize_t" -> "int" and an object >>>>>>>>>>>>> inheriting >>>>>>>>>>>>> from FFIExternalObject for the "libusb_context" (others methods >>>>>>>>>>>>> using it are working). >>>>>>>>>>>>> >>>>>>>>>>>>> I can not find how to get an array filled with libusb_device >>>>>>>>>>>>> using UFFI from Pharo. :-( >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks in advance, >>>>>>>>>>>>> >>>>>>>>>>>>> Julien >>>>>>>>>>>>> >>>> >> >

July 4, 2016

Re: [Pharo-users] [UFFI] Getting an array of opaque structures filled

by Julien Delplanque

Hello again Esteban, all others, I am still experiencing strange behaviors with the objects in the external array. I get a lot of NULL pointers and some strange addresses (I guess, I am not a C expert) that are close to NULL (see the screenshot attached). These objects make the VM crash (segmentation fault) when I call a function from the libusb binding (for NULL objects it may be ok but what about others?). Some other objects (those with a normal address in the screenshot) work finely with the functions calls using UFFI... This kind of bug is not reported in libusb discussions I found on the internet and I tried an example in C, there is no NULL pointer received from the function (they are not even considered in official examples). So I guess the problem may come from Pharo? Do you have any idea of what it could be? I will be available on Slack all the day if you want. :) Thanks in advance, Julien On 01/07/16 14:03, Esteban Lorenzano wrote: > ok, can you reload development version and try again? > > ps: this is easier on slack ;) > >> On 01 Jul 2016, at 14:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> yes, I made a mistakeâ¦ the problem of not being capable of test here :( >> >> 1 minute. >> >> Esteban >> >>> On 01 Jul 2016, at 13:56, Julien Delplanque <julien(a)tamere.eu> wrote: >>> >>> Ok, now I get a different exception! :-) >>> >>> "MessageNotUnderstood: LUDevice class>>fromHandle:" >>> >>> when executing: "array first." >>> >>> Where LUDevice is defined like this: >>> >>> FFIOpaqueObject subclass: #LUDevice >>> instanceVariableNames: '' >>> classVariableNames: '' >>> package: 'LibUsb-Kernel' >>> >>> Julien >>> >>> >>> On 01/07/16 13:51, Esteban Lorenzano wrote: >>>> I need you to test :) >>>> >>>> can you execute this: >>>> >>>> (ConfigurationOfUnifiedFFI project version: #development) load. >>>> >>>> and then retry your example? >>>> >>>> thanks, >>>> Esteban >>>> >>>> ps: this became pharo-dev, but wellâ¦ still here :) >>>> >>>>> On 01 Jul 2016, at 13:48, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>> >>>>> Oh, ok :p >>>>> >>>>> Can you notify me know when the bug will be resolved? >>>>> >>>>> Thanks, >>>>> >>>>> Julien >>>>> >>>>> >>>>> On 01/07/16 13:36, Esteban Lorenzano wrote: >>>>>> â¦ and now you hit a bug. >>>>>> bah, an ânon implemented featureâ :P >>>>>> >>>>>> I never tested arrays with complex types. >>>>>> it should not be hardâ¦ I will provide a fix. >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>>> On 01 Jul 2016, at 13:30, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>>>> >>>>>>> Ok, the ffi call is done without problem with your method thanks. :) >>>>>>> >>>>>>> But now that I have the array, when I try to access the first element using: >>>>>>> >>>>>>> array first. >>>>>>> >>>>>>> I get a exception saying I need to override a method: >>>>>>> >>>>>>> "SubclassResponsibility: FFIOpaqueObjectType had the subclass responsibility to implement #basicHandle:at:" >>>>>>> >>>>>>> I looked at others implementors but I am not sure of how I should override it, nor if I should. >>>>>>> >>>>>>> Thanks for the time your taking to answer me. :-) >>>>>>> >>>>>>> Julien >>>>>>> >>>>>>> On 01/07/16 12:29, Esteban Lorenzano wrote: >>>>>>>>> On 01 Jul 2016, at 12:27, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> hi, >>>>>>>>> >>>>>>>>> this is because you want to get an array with opaque objects. Do not let the *** confuses youâ¦ cwhat you actually want, conceptually is something like this: >>>>>>>>> >>>>>>>>> *((FFIOpaqueObject*)[]) >>>>>>>>> >>>>>>>>> means: you pass the address of an array of opaque types (who are always pointers). >>>>>>>>> >>>>>>>>> So, what you need to pass is the address of an arrayâ¦ you will need to work a bit here, since translation is not automatic. >>>>>>>>> >>>>>>>>> 1) you need to declare your type. Letâ say it will be: >>>>>>>>> >>>>>>>>> FFIOpaqueObject subclass: USBDevice. >>>>>>>>> >>>>>>>>> 2) then you need to get the pointer to this array. You need to rewrite you code as this: >>>>>>>>> >>>>>>>>> arrayPtr := ExternalAddress new. >>>>>>>>> size := self getDevice: ctx list: arrayPtr. >>>>>>>>> >>>>>>>>> getDevice: ctx list: list >>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list (libusb_context *ctx, void **list)) >>>>>>>>> >>>>>>>>> NOTE that we change the type to "void **â. This is because this is what you actually want: the array of devices >>>>>>>>> >>>>>>>>> 3) now you will have size and arrayPtr. Then you declare the array: >>>>>>>>> >>>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice >>>>>>>> sorry, this expression (while possible) does not stops in âsizeââ¦ it has to be like this, instead: >>>>>>>> >>>>>>>> array := FFIExternalArray fromPointer: arrayPtr type: USBDevice size: size. âyou already has the size for the result" >>>>>>>> >>>>>>>>> â¦ and you should be able to iterate this array normally :) >>>>>>>>> >>>>>>>>> let me know if this works for youâ¦ Iâm âcoding in mail clientâ, so it can fail :P >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> Esteban >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 01 Jul 2016, at 12:02, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>>>>>>> >>>>>>>>>> Thanks, it works I get an instance of FFIOpaqueObject. >>>>>>>>>> >>>>>>>>>> But how do I get a specific libusb_device object from the list? >>>>>>>>>> >>>>>>>>>> Thanks again for you quick answer :-). >>>>>>>>>> >>>>>>>>>> Julien >>>>>>>>>> >>>>>>>>>> On 01/07/16 11:44, Esteban Lorenzano wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> an opaque structure is not an FFIExternalObject but an FFIOpaqueObject. >>>>>>>>>>> in that case, something like (simplified): >>>>>>>>>>> >>>>>>>>>>> ctx := (your context). >>>>>>>>>>> list := FFIOpaqueObject new. >>>>>>>>>>> size := self getDevice: ctx list: list. >>>>>>>>>>> >>>>>>>>>>> getDevice: ctx list: list >>>>>>>>>>> ^ self ffiCall: #(size_t libusb_get_device_list (libusb_context *ctx, FFIOpaqueObject ***list)) >>>>>>>>>>> >>>>>>>>>>> should work (note that of course you can make libusb_device an alias for your typeâ¦ that does not matters much, this is just a simplification). >>>>>>>>>>> >>>>>>>>>>> if this does not works, if you can provide me code to reproduce it, I can give it a shot and see what happens :) >>>>>>>>>>> >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>>> On 01 Jul 2016, at 11:19, Julien Delplanque <julien(a)tamere.eu> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello everyone, >>>>>>>>>>>> >>>>>>>>>>>> I have a question about the UFFI API. I have the following function: >>>>>>>>>>>> >>>>>>>>>>>> ssize_t libusb_get_device_list (libusb_context *ctx, libusb_device ***list) >>>>>>>>>>>> >>>>>>>>>>>> where libusb_device is an opaque structure. >>>>>>>>>>>> >>>>>>>>>>>> I made a type mapping "ssize_t" -> "int" and an object inheriting >>>>>>>>>>>> from FFIExternalObject for the "libusb_context" (others methods >>>>>>>>>>>> using it are working). >>>>>>>>>>>> >>>>>>>>>>>> I can not find how to get an array filled with libusb_device using UFFI from Pharo. :-( >>>>>>>>>>>> >>>>>>>>>>>> Thanks in advance, >>>>>>>>>>>> >>>>>>>>>>>> Julien >>>>>>>>>>>> >>> >

July 4, 2016

SIGPLAN Programming Languages Mentoring Workshop @ SPLASH'16

by Tijs van der Storm

SIGPLAN Programming Languages Mentoring Workshop @ SPLASH'16 Amsterdam, The Netherlands (part of SPLASH 2016) Tuesday, November 1st, 2016 http://2016.splashcon.org/track/splash-2016-plmw We are pleased to invite students interested in programming languages to the Programming Languages Mentoring Workshop (PLMW) at SPLASH. The goal of this workshop is to introduce senior undergraduate and early graduate students to research topics in programming languages as well as provide career mentoring advice. We have recruited leaders from the programming languages community to provide overviews of current research topics and give students valuable advice about how to thrive in graduate school, search for a job, and cultivate habits and skills that will help them in research careers. This workshop is part of the activities surrounding SPLASH, and takes place the day before the main conference. A key goal of the workshop is to make SPLASH more accessible to newcomers. Through the generous donation of our sponsors, we are able to provide travel scholarships to fund student participation. These travel scholarships will cover reasonable travel expenses (airfare and hotel) for attendance at both the workshop and the following main three days of SPLASH. The workshop is open to all. Students with alternative sources of funding for their travel and registration fees are welcome. In particular, many student attendance programs provide full or partial travel funding for students to attend SPLASH 2016. More information about student attendance programs at SPLASH is available here: http://2016.splashcon.org/attending/students Application for Travel Support: The travel funding application is available from the PLMW webpage. The deadline for full consideration of funding is August 15th, 2016. Selected participants will be notified by September 1st. Organizers: Sandrine Blazy, University of Rennes 1 Ulrik Pagh Schultz, University of Southern Denmark

July 4, 2016

Re: [Pharo-users] GTSpotter froze my image again

by stepharo

tx for the report. I'm working often in presence of no network :) so the catalog bites me often especially when I try to demo pharo :). Stef Le 3/7/16 Ã 16:55, Bernardo Ezequiel Contreras a Ã©crit : > here's another report > > https://pharo.fogbugz.com/f/cases/18659/Image-freeze > > with the image to reproduce it. > > Sent from a cheap desktop computer in South America.

July 3, 2016

Re: [Pharo-users] problem starting Grafoscopio

by Offray Vladimir Luna CÃ¡rdenas

Hi Ben, Thanks a lot for testing and reporting such errors. Grafoscopio is now being migrated to the last Pharo / Moose stable versions and will be using Johan's Spec/GT-Tools bridge. I will try to improve the code in other regards. You can see the new interface (which is in GrafoscopioNotebook class) by executing 'OffshoreLeaksDB openIntroNotebook ' from your update Grafoscopio installation. To update it run: Gofer new smalltalkhubUser: 'Offray' project: 'Grafoscopio'; package: 'Grafoscopio'; load. self updateUI. I'll be finishing the Pharo MOOC before July 16 and after that I will be focused on Grafoscopio, but don't hesitate to report any issue you have. I will reply slowly meanwhile, but surely. Thanks again, Offray On 03/07/16 10:47, Ben Coman wrote: > Hi Offray, > > After loading Grafiscopio from the Catalog in a fresh Pharo-50760 > image, selecting Launch>New notebook... > ==> MNU GrafoscopioGUI class>>open > > Finder shows #open is only understood by GrafoscopioBrowser > but GrafoscopioBrowser open > ==> MNU: receiver of "/" is nil > in #openDefault at... > workingFile := draftsLocation / 'draft.ston'. > where draftsLocation is nil, > and searching all references show no method sets that variable. > > In the comments is... > GrafoscopioBrowser configureSettings > but that ==> MNU. > > Trying a rough guess to force... > draftsLocation := '/home/ben/grafosocpio' asFileRefence > lets the GrafoscopioBrowser open. > > cheers -ben >

July 3, 2016