March 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] USB in Pharo?

by Luc Fabresse

Nice, thanks a lot! Luc 2015-03-25 11:47 GMT+01:00 Udo Schneider <udo.schneider(a)homeaddress.de>: > Hi Luc, > > Yepp will do. Time to write a blog entry again :-) > > CU, > > Udo > > > On 25/03/15 11:42, Luc Fabresse wrote: > >> Hi Udo, >> >> Thanks to report your experience on TalkFFI. >> Can you also post a small step by step tutorial of what you did to >> generate the NB bindings ? >> >> Thanks, >> >> #Luc >> >> 2015-03-25 11:37 GMT+01:00 Udo Schneider >> <udo.schneider(a)homeaddress.de >> <mailto:udo.schneider@homeaddress.de>>: >> >> I found the offending code. The original code is something like: >> >> struct libusb_bos_dev_capability___descriptor >> *dev_capability >> #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) >> [] /* valid C99 code */ >> #else >> [0] /* non-standard, but usually working code */ >> #endif >> ; >> >> This doesn't work with clang/TalkFFI. I assume based on the #defines >> it uses the C99 notation which doesn't work. "Hardcoding" it to the >> non-standard notation does work. E.g.: >> >> struct libusb_bos_dev_capability___descriptor >> *dev_capability >> //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) >> // [] /* valid C99 code */ >> //#else >> [0] /* non-standard, but usually working code */ >> //#endif >> ; >> >> It seems that this was the only showstopper as TalkFFI just >> generated a binding for the whole library w/o any problem. >> >> I'll start experimenting now ... >> >> CU, >> >> Udo >> >> >> On 24/03/15 17:33, kilon alios wrote: >> >> If the library is big you can use TalkFFI (you will find it in >> smalltalkhub) that automates the wrapping with nativeboost. >> >> On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider >> <Udo.Schneider(a)homeaddress.de >> <mailto:Udo.Schneider@homeaddress.de> >> <mailto:Udo.Schneider@__homeaddress.de >> <mailto:Udo.Schneider@homeaddress.de>>> >> wrote: >> >> I guess not :-) >> >> I'll try to wrap libUSB then. >> >> I assume the future-proof way to use "a" FFI framework is >> to use the >> NB notation? Do I remember correctly that the NB notation is >> supposed to remain the same although the backend will change >> to >> something more like traditional FFI? >> So using NB notation w/o relying on the code generation is >> safe, >> correct? >> >> CU, >> >> Udo >> >> >> >> On 23.03.2015 16:15, Udo Schneider wrote: >> >> All, >> >> does anybody have some code or plugin to access USB >> ports with >> Pharo? >> Maybe something using libUSB or OpenUSB? >> >> Thanks, >> >> Udo >> >> >> >> >> >> >> >> >> >> >> >> > > >

March 25, 2015

Re: [Pharo-users] USB in Pharo?

by Udo Schneider

Hi Luc, Yepp will do. Time to write a blog entry again :-) CU, Udo On 25/03/15 11:42, Luc Fabresse wrote: > Hi Udo, > > Thanks to report your experience on TalkFFI. > Can you also post a small step by step tutorial of what you did to > generate the NB bindings ? > > Thanks, > > #Luc > > 2015-03-25 11:37 GMT+01:00 Udo Schneider > <udo.schneider(a)homeaddress.de > <mailto:udo.schneider@homeaddress.de>>: > > I found the offending code. The original code is something like: > > struct libusb_bos_dev_capability___descriptor *dev_capability > #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) > [] /* valid C99 code */ > #else > [0] /* non-standard, but usually working code */ > #endif > ; > > This doesn't work with clang/TalkFFI. I assume based on the #defines > it uses the C99 notation which doesn't work. "Hardcoding" it to the > non-standard notation does work. E.g.: > > struct libusb_bos_dev_capability___descriptor *dev_capability > //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) > // [] /* valid C99 code */ > //#else > [0] /* non-standard, but usually working code */ > //#endif > ; > > It seems that this was the only showstopper as TalkFFI just > generated a binding for the whole library w/o any problem. > > I'll start experimenting now ... > > CU, > > Udo > > > On 24/03/15 17:33, kilon alios wrote: > > If the library is big you can use TalkFFI (you will find it in > smalltalkhub) that automates the wrapping with nativeboost. > > On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider > <Udo.Schneider(a)homeaddress.de > <mailto:Udo.Schneider@homeaddress.de> > <mailto:Udo.Schneider@__homeaddress.de > <mailto:Udo.Schneider@homeaddress.de>>> > wrote: > > I guess not :-) > > I'll try to wrap libUSB then. > > I assume the future-proof way to use "a" FFI framework is > to use the > NB notation? Do I remember correctly that the NB notation is > supposed to remain the same although the backend will change to > something more like traditional FFI? > So using NB notation w/o relying on the code generation is > safe, > correct? > > CU, > > Udo > > > > On 23.03.2015 16:15, Udo Schneider wrote: > > All, > > does anybody have some code or plugin to access USB > ports with > Pharo? > Maybe something using libUSB or OpenUSB? > > Thanks, > > Udo > > > > > > > > > > >

March 25, 2015

Re: [Pharo-users] USB in Pharo?

by Luc Fabresse

Hi Udo, Thanks to report your experience on TalkFFI. Can you also post a small step by step tutorial of what you did to generate the NB bindings ? Thanks, #Luc 2015-03-25 11:37 GMT+01:00 Udo Schneider <udo.schneider(a)homeaddress.de>: > I found the offending code. The original code is something like: > > struct libusb_bos_dev_capability_descriptor *dev_capability > #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) > [] /* valid C99 code */ > #else > [0] /* non-standard, but usually working code */ > #endif > ; > > This doesn't work with clang/TalkFFI. I assume based on the #defines it > uses the C99 notation which doesn't work. "Hardcoding" it to the > non-standard notation does work. E.g.: > > struct libusb_bos_dev_capability_descriptor *dev_capability > //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) > // [] /* valid C99 code */ > //#else > [0] /* non-standard, but usually working code */ > //#endif > ; > > It seems that this was the only showstopper as TalkFFI just generated a > binding for the whole library w/o any problem. > > I'll start experimenting now ... > > CU, > > Udo > > > On 24/03/15 17:33, kilon alios wrote: > >> If the library is big you can use TalkFFI (you will find it in >> smalltalkhub) that automates the wrapping with nativeboost. >> >> On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider >> <Udo.Schneider(a)homeaddress.de >> <mailto:Udo.Schneider@homeaddress.de>> wrote: >> >> I guess not :-) >> >> I'll try to wrap libUSB then. >> >> I assume the future-proof way to use "a" FFI framework is to use the >> NB notation? Do I remember correctly that the NB notation is >> supposed to remain the same although the backend will change to >> something more like traditional FFI? >> So using NB notation w/o relying on the code generation is safe, >> correct? >> >> CU, >> >> Udo >> >> >> >> On 23.03.2015 16:15, Udo Schneider wrote: >> >> All, >> >> does anybody have some code or plugin to access USB ports with >> Pharo? >> Maybe something using libUSB or OpenUSB? >> >> Thanks, >> >> Udo >> >> >> >> >> >> >> >> > > >

March 25, 2015

Re: [Pharo-users] USB in Pharo?

by Udo Schneider

I found the offending code. The original code is something like: struct libusb_bos_dev_capability_descriptor *dev_capability #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) [] /* valid C99 code */ #else [0] /* non-standard, but usually working code */ #endif ; This doesn't work with clang/TalkFFI. I assume based on the #defines it uses the C99 notation which doesn't work. "Hardcoding" it to the non-standard notation does work. E.g.: struct libusb_bos_dev_capability_descriptor *dev_capability //#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) // [] /* valid C99 code */ //#else [0] /* non-standard, but usually working code */ //#endif ; It seems that this was the only showstopper as TalkFFI just generated a binding for the whole library w/o any problem. I'll start experimenting now ... CU, Udo On 24/03/15 17:33, kilon alios wrote: > If the library is big you can use TalkFFI (you will find it in > smalltalkhub) that automates the wrapping with nativeboost. > > On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider > <Udo.Schneider(a)homeaddress.de > <mailto:Udo.Schneider@homeaddress.de>> wrote: > > I guess not :-) > > I'll try to wrap libUSB then. > > I assume the future-proof way to use "a" FFI framework is to use the > NB notation? Do I remember correctly that the NB notation is > supposed to remain the same although the backend will change to > something more like traditional FFI? > So using NB notation w/o relying on the code generation is safe, > correct? > > CU, > > Udo > > > > On 23.03.2015 16:15, Udo Schneider wrote: > > All, > > does anybody have some code or plugin to access USB ports with > Pharo? > Maybe something using libUSB or OpenUSB? > > Thanks, > > Udo > > > > > > >

March 25, 2015

Re: [Pharo-users] USB in Pharo?

by Udo Schneider

Just had a quick start with TalkFFI ... and after getting 32bit libs on Mac OS X it finally worked. However running TalkFFI results in a wallback because (I assume) a type can't be infered. Is there any way to debug TalkFFI to get the C name of the offending type/function? All I'm seeing are their addresses :-( CU, Udo On 24/03/15 17:33, kilon alios wrote: > If the library is big you can use TalkFFI (you will find it in > smalltalkhub) that automates the wrapping with nativeboost. > > On Tue, Mar 24, 2015 at 4:58 PM, Udo Schneider > <Udo.Schneider(a)homeaddress.de > <mailto:Udo.Schneider@homeaddress.de>> wrote: > > I guess not :-) > > I'll try to wrap libUSB then. > > I assume the future-proof way to use "a" FFI framework is to use the > NB notation? Do I remember correctly that the NB notation is > supposed to remain the same although the backend will change to > something more like traditional FFI? > So using NB notation w/o relying on the code generation is safe, > correct? > > CU, > > Udo > > > > On 23.03.2015 16:15, Udo Schneider wrote: > > All, > > does anybody have some code or plugin to access USB ports with > Pharo? > Maybe something using libUSB or OpenUSB? > > Thanks, > > Udo > > > > > > >

March 25, 2015

Re: [Pharo-users] Starting with Pharo Issue Tracker

by Jigyasa Grover

Exactly my question. Thanks for the help :) -- View this message in context: http://forum.world.st/Starting-with-Pharo-Issue-Tracker-tp4814883p4815016.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 25, 2015

Re: [Pharo-users] Git overriding repo load from different source

by Jan B.

Hello I was able to get by those warnings automatically by adding onLock: [ :ex | ex disallow ]; in addition to onConflict Metacello new baseline: '...' repository: 'gitfiletree:///.../repository' onConflict: [ :ex | ex allow ]; onLock: [ :ex | ex disallow ]; load I'm not sure whether it couldn't cause any problems, but it seems to be working. Jan Peter UhnÃ¡k wrote >> If so then the trick is to use the Metacello `lock` ... Do the following >> BEFORE loading the project that depends upon you sample project: >> > Combined with onConflict: mentioned by Thierry this works like a charm, > thanks a lot. :) > > >> (a Warning is dumped to the transcript) ... >> > I got a warning prompt which I had confirm ("proceed") couple of times, > but > that's just a detail. > > Thanks a lot! > > Peter -- View this message in context: http://forum.world.st/Git-overriding-repo-load-from-different-source-tp4813… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 25, 2015

Re: [Pharo-users] Collection with memory?

by Sven Van Caekenberghe

OK, I get your point now, #read and #read: are a better combination than #get and #read: About #++ and friends, yes I think they are so uncommon that they do not warrant a special selector, what is the point ? > On 25 Mar 2015, at 09:12, stepharo <stepharo(a)free.fr> wrote: > >> Stef, >> >> Like Denis said, there is no #next: in Xtreams, AFIACT. > > Yes but this is the same > we should get read and read: and not get and read: > This is my point. >> >> There are >> >> XTReadStream>>#get >> "Read an object from self. >> If there aren't any elements left in the stream, the Incomplete exception is raised." >> >> and >> >> XTReadStream>>#read: anInteger >> "Read anInteger's worth of elements from self and return them in a collection. >> If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised." >> >> Like I said, these selector names were chosen to prevent confusion, on purpose. I think that is good. I also think that a lot of though went into the design. > I personally think that > get and read: are bad and irregular. > > XTReadStream>>#read > "Read an object from self. > If there aren't any elements left in the stream, the Incomplete exception is raised." > > XTReadStream>>#read: anInteger > "Read anInteger's worth of elements from self and return them in a collection. > If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised." > > > funny how the comments are good. No need to change them. This is a sign.

March 25, 2015

Re: [Pharo-users] new link to query all projects in smalltalkhub

by Stephan Eggermont

On 24/03/15 17:36, Merwan Ouddane wrote: > Thanks for the instructions, > > I'll do it as soon as I can :) > > There is an issue that i'd like to report too, I have a team with a > non-ascii character, and i can't remove team members nor delete the > entire team, I'll try to fix it too. That sounds like a good issue to experiment with on your own installation first :) Thanks for picking this up. Stephan

March 25, 2015

Re: [Pharo-users] Boardician (board game framework)

by stepharo

Hi laura I would do a massive rename :) EDirector new play. does not tell me anything BPDirector new play. DPDirector new play. GDirector new play. neither :) Stef Le 24/3/15 15:41, Laura Risani a Ã©crit : > Hi all, > > A time ago i posted two board games on the list and StÃ©phane said that > he would like to extract from these and other ones he has gathered a > framework for doing board games. So i developed a little one called > 'Boardician' and implemented four little example games through it. > > DOCUMENTATION > http://boardician.blogspot.com.ar/2015/03/boardician.html > > DOWNLOAD <https://www.blogger.com/null> > You can install configuration BgBoardician from Configuration Browser > on 3.0 and 4.0 . This will download packages of framework > (BgBoardician) and example games (BgBoxPush, BgEatBullet, BgDropPiece, > BgEatElongating) > > To run example games send > > EDirector new play. > BPDirector new play. > DPDirector new play. > GDirector new play. > > > FEEDBACK <https://www.blogger.com/null> > If you like (i would really like you to) to send any feedback comments > on design / names / implementation / functionalities to add / > questions you can post a comment on the blog / mail me. > > Next i'll be adding tests and uploading development history to > project's repo. > > Best, > Laura

March 25, 2015