- Pharo-users - lists.pharo.org

Packaging for Mac OS

by HernÃ¡n Morales Durand

Guys, I wish to package my Pharo applications for Mac OS. But I don't have a Mac and my own finances demonstrates I won't have one anytime soon. Do you know if there is a (free? :) remote Mac OS service (like a remote shell) where I can log-in, package my image, and download the resulting file? HernÃ¡n

March 25, 2015

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

by Ben Coman

One pattern is that the main application class be fully named, leaving the mnemonic prefix for the support classes. cheers -ben On Wed, Mar 25, 2015 at 4:14 PM, stepharo <stepharo(a)free.fr> wrote: > 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

Re: [Pharo-users] Settings browser

by Alain Plantec

> Le 25 mars 2015 Ã 12:19, Hilaire <hilaire(a)drgeo.eu> a Ã©crit : > > settingInputWidgetForNode: aSettingDeclaration > ^ (aSettingDeclaration name, 'Widget') asSymbol value: self. > strange that you send the #value: message to a Symbol here. Alain

March 25, 2015

Re: [Pharo-users] Settings browser

by Hilaire

Le 24/03/2015 21:22, Alain Plantec via Pharo-users a Ã©crit : > Have a look at the setting chapter (The Setting Framework) Hi Alain, Thanks Alain. I was already studying the chapter yesterday, but it appears there is an unexpected complication, In a singleton DrGeoStylePreference class I define the methods as follow: drgeoStylesOn: aBuilder <drgeosettings> (aBuilder group: #drgeoStyle) label: 'Style'; with: [ (aBuilder group: #point) label: 'Point' translated; with: [ (aBuilder setting: #pointColor) label: 'Colour' translated]. ../.. then pointColor ^ current "respond the singleton, widget build up set later" settingInputWidgetForNode: aSettingDeclaration ^ (aSettingDeclaration name, 'Widget') asSymbol value: self. pointColorWidget ^ (UITheme builder newMorphDropListFor: self list: #colorMorphCollection getSelected: #pointColorIndex setSelected: #pointColorIndex: help: 'Set the colour.' translated) minWidth: DrGIcons menuExtent x + 35 ../.. and so on. The complication comes from the SettingDeclaration>>inputWidget where the widget model is set to the SettingDeclaration, and it breaks: inputWidget "return the default widget for the input a the setting" ../.. inputWidget ifNotNil: [(inputWidget respondsTo: #model:) ifTrue: [inputWidget model: self]]. ../.. If I remove the #model: call, it is ok. Did I miss something? Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

March 25, 2015

Re: [Pharo-users] USB in Pharo?

by kilon alios

I have not used TalkFFI I only know that it exists. Very glad it works for you and I am also very interested on a blog post how you got it working and how you solved your problems. I am sure it will come handy one day :) On Wed, Mar 25, 2015 at 12:37 PM, Udo Schneider < udo.schneider(a)homeaddress.de> wrote: > 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 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