November 2017 - Pharo-users

Re: [Pharo-users] UFFI with asynchronous callbacks

by Todd Blanchard

Pretty sure that's the one I loaded. Still having issues with libclang on 64 bit with code locations. > On Nov 8, 2017, at 1:26 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > Esteban has version ported to UFFI https://github.com/estebanlm/TalkFFI <https://github.com/estebanlm/TalkFFI>. But I don't know is it working or not. > > 2017-11-08 10:15 GMT+01:00 Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>>: > I know, but its closer to "done" than starting from scratch. > > > >> On Nov 8, 2017, at 1:13 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5. >> http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.ht… <http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.ht…> >> >> cheers -ben >> >> On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> Just catching up.... >> >> I'm trying to work with 64 bit Pharo 6.(1? 2?). >> >> I've run into some issues that I have not been able to resolve. I've loaded up TalkFFI with the LibClang library and testLocation fails. Anything that tries to deal with getting a code location fails and I cannot figure out what the issue is yet. >> >> Also, callbacks do not work at all. >> >> One might say that this is only tested on 32 bit Pharo and that's fine, but I have a 64 bit computer loaded with 64 bit standard libraries and recompiling everything to get 32 bit versions is just not practical. Its past time to do the 64 bit thing. >> >> FWIW, my test library at this point is SQLite Amalgam header to see if I can automatically build a SQLite interface (should be easy as it is one file) but it is kind of frustrating that these libclang features are not working on 64 bit libs. >> >> I have been running in lldb to try to catch the crashes, and I have written a number of toy programs to make certain things are the sizes I expect. >> >> Still stuck at this juncture. >> >> Had to take a lil break and learn to program a Particle board for a work project but will resume next week. >> >> >>> On Oct 23, 2017, at 11:13 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> >>> >>> >>> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz <mailto:jan@cada.cz>> wrote: >>> Hi, >>> >>> I would like to connect fingerprint reader to pharo - so far I am able to use C library to connect to it using UFFI, >>> however the problem is that I can wait for fingerprint indefinitely ( blocking call to library) or register call-back for moment when fingerprint is available. >>> The registration function returns immediately, so it is clear that the callback will be called from another thread. >>> >>> Is such situation supported by UFFI ? >>> >>> Thanks for any tip, >>> >>> Jan >>> >>> Callbacks are supported. Here is an example... >>> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… <http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w…> >>> >>> @Todd, How did find working through this part? >>> cheers -ben >> >> > >

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Denis Kudriashov

Hi. Esteban has version ported to UFFI https://github.com/estebanlm/TalkFFI. But I don't know is it working or not. 2017-11-08 10:15 GMT+01:00 Todd Blanchard <tblanchard(a)mac.com>: > I know, but its closer to "done" than starting from scratch. > > > > On Nov 8, 2017, at 1:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > > AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5. > http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5- > UFFI-td4915060.html > > cheers -ben > > On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > >> Just catching up.... >> >> I'm trying to work with 64 bit Pharo 6.(1? 2?). >> >> I've run into some issues that I have not been able to resolve. I've >> loaded up TalkFFI with the LibClang library and testLocation fails. >> Anything that tries to deal with getting a code location fails and I cannot >> figure out what the issue is yet. >> >> Also, callbacks do not work at all. >> >> One might say that this is only tested on 32 bit Pharo and that's fine, >> but I have a 64 bit computer loaded with 64 bit standard libraries and >> recompiling everything to get 32 bit versions is just not practical. Its >> past time to do the 64 bit thing. >> >> FWIW, my test library at this point is SQLite Amalgam header to see if I >> can automatically build a SQLite interface (should be easy as it is one >> file) but it is kind of frustrating that these libclang features are not >> working on 64 bit libs. >> >> I have been running in lldb to try to catch the crashes, and I have >> written a number of toy programs to make certain things are the sizes I >> expect. >> >> Still stuck at this juncture. >> >> Had to take a lil break and learn to program a Particle board for a work >> project but will resume next week. >> >> >> On Oct 23, 2017, at 11:13 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: >> >>> Hi, >>> >>> I would like to connect fingerprint reader to pharo - so far I am able >>> to use C library to connect to it using UFFI, >>> however the problem is that I can wait for fingerprint indefinitely ( >>> blocking call to library) or register call-back for moment when fingerprint >>> is available. >>> The registration function returns immediately, so it is clear that the >>> callback will be called from another thread. >>> >>> Is such situation supported by UFFI ? >>> >>> Thanks for any tip, >>> >>> Jan >>> >> >> Callbacks are supported. Here is an example... >> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part- >> 4-ast-walking-with-visitors-callbacks/ >> >> @Todd, How did find working through this part? >> cheers -ben >> >> >> > >

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Todd Blanchard

I know, but its closer to "done" than starting from scratch. > On Nov 8, 2017, at 1:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > > AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5. > http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.ht… <http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.ht…> > > cheers -ben > > On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: > Just catching up.... > > I'm trying to work with 64 bit Pharo 6.(1? 2?). > > I've run into some issues that I have not been able to resolve. I've loaded up TalkFFI with the LibClang library and testLocation fails. Anything that tries to deal with getting a code location fails and I cannot figure out what the issue is yet. > > Also, callbacks do not work at all. > > One might say that this is only tested on 32 bit Pharo and that's fine, but I have a 64 bit computer loaded with 64 bit standard libraries and recompiling everything to get 32 bit versions is just not practical. Its past time to do the 64 bit thing. > > FWIW, my test library at this point is SQLite Amalgam header to see if I can automatically build a SQLite interface (should be easy as it is one file) but it is kind of frustrating that these libclang features are not working on 64 bit libs. > > I have been running in lldb to try to catch the crashes, and I have written a number of toy programs to make certain things are the sizes I expect. > > Still stuck at this juncture. > > Had to take a lil break and learn to program a Particle board for a work project but will resume next week. > > >> On Oct 23, 2017, at 11:13 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> >> >> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz <mailto:jan@cada.cz>> wrote: >> Hi, >> >> I would like to connect fingerprint reader to pharo - so far I am able to use C library to connect to it using UFFI, >> however the problem is that I can wait for fingerprint indefinitely ( blocking call to library) or register call-back for moment when fingerprint is available. >> The registration function returns immediately, so it is clear that the callback will be called from another thread. >> >> Is such situation supported by UFFI ? >> >> Thanks for any tip, >> >> Jan >> >> Callbacks are supported. Here is an example... >> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… <http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w…> >> >> @Todd, How did find working through this part? >> cheers -ben > >

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Ben Coman

AFAIK, TalkFFI hasn't been updated to UFFI for Pharo 5. http://forum.world.st/Porting-TalkFFI-LibClang-to-Pharo-5-UFFI-td4915060.ht… cheers -ben On Wed, Nov 8, 2017 at 4:07 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > Just catching up.... > > I'm trying to work with 64 bit Pharo 6.(1? 2?). > > I've run into some issues that I have not been able to resolve. I've > loaded up TalkFFI with the LibClang library and testLocation fails. > Anything that tries to deal with getting a code location fails and I cannot > figure out what the issue is yet. > > Also, callbacks do not work at all. > > One might say that this is only tested on 32 bit Pharo and that's fine, > but I have a 64 bit computer loaded with 64 bit standard libraries and > recompiling everything to get 32 bit versions is just not practical. Its > past time to do the 64 bit thing. > > FWIW, my test library at this point is SQLite Amalgam header to see if I > can automatically build a SQLite interface (should be easy as it is one > file) but it is kind of frustrating that these libclang features are not > working on 64 bit libs. > > I have been running in lldb to try to catch the crashes, and I have > written a number of toy programs to make certain things are the sizes I > expect. > > Still stuck at this juncture. > > Had to take a lil break and learn to program a Particle board for a work > project but will resume next week. > > > On Oct 23, 2017, at 11:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: > >> Hi, >> >> I would like to connect fingerprint reader to pharo - so far I am able to >> use C library to connect to it using UFFI, >> however the problem is that I can wait for fingerprint indefinitely ( >> blocking call to library) or register call-back for moment when fingerprint >> is available. >> The registration function returns immediately, so it is clear that the >> callback will be called from another thread. >> >> Is such situation supported by UFFI ? >> >> Thanks for any tip, >> >> Jan >> > > Callbacks are supported. Here is an example... > http://blog.openinworld.com/2016/09/pharo-libclang-ffi- > part-4-ast-walking-with-visitors-callbacks/ > > @Todd, How did find working through this part? > cheers -ben > > >

Nov. 8, 2017

Objective C Bridge

by Todd Blanchard

> On Oct 28, 2017, at 2:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi andrew > > you should contact esteban because he is writing an objective-C bridge. > > Stef Another one? I think we've written half a dozen now, no? There is some code in the VM libs that allows calling out. I worked on one with Avi for a bit about ten years ago. The callbacks/delegate bit was always problematic. It is one thing to call Objective C (really easy) but another thing to integrate with Cocoa and accept callbacks while keeping the VM live. I would really love one that let me write Cocoa from Pharo (especially iPhone apps). I do wonder if this new capability with Objective C blocks wouldn't maybe make things easier. http://www.friday.com/bbum/2011/03/17/ios-4-3-imp_implementationwithblock/

Nov. 8, 2017

Re: [Pharo-users] UFFI and Fortran

by Todd Blanchard

I keep running into issues on 64 bit FFI. Compiling 32 bit libraries is atypical and requires a lot of fiddling of unfamiliar build systems for various libraries so I'm just going to work in 64 bit land on Mac. > On Nov 6, 2017, at 7:25 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > > That would be phenomenal! Let me know if and when it's done and I shall > scream it out to all of social media! > > > > tblanchard wrote >> Yes - the reason I've been trying to learn FFI is specifically to get >> TensorFlow integration. >> >> I want a better ML workbench. >> >>> On Nov 2, 2017, at 9:08 PM, Ben Coman < > >> btc@ > >> > wrote: >>> >>> >>> >>> On Fri, Nov 3, 2017 at 11:10 AM, horrido < > >> horrido.hobbies@ > >> <mailto: > >> horrido.hobbies@ > >> >> wrote: >>> Sounds like it's possible to call into TensorFlow (Python) from Pharo. >>> That >>> would give Pharo a tremendous boost for machine learning applications. >>> >>> Am I right? >>> >>> Tensorflow has a C API for FFI from other languages. >>> * https://www.tensorflow.org/install/install_c >>> <https://www.tensorflow.org/install/install_c> >>> * https://www.tensorflow.org/extend/language_bindings >>> <https://www.tensorflow.org/extend/language_bindings> >>> >>> cheers -ben > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Todd Blanchard

Just catching up.... I'm trying to work with 64 bit Pharo 6.(1? 2?). I've run into some issues that I have not been able to resolve. I've loaded up TalkFFI with the LibClang library and testLocation fails. Anything that tries to deal with getting a code location fails and I cannot figure out what the issue is yet. Also, callbacks do not work at all. One might say that this is only tested on 32 bit Pharo and that's fine, but I have a 64 bit computer loaded with 64 bit standard libraries and recompiling everything to get 32 bit versions is just not practical. Its past time to do the 64 bit thing. FWIW, my test library at this point is SQLite Amalgam header to see if I can automatically build a SQLite interface (should be easy as it is one file) but it is kind of frustrating that these libclang features are not working on 64 bit libs. I have been running in lldb to try to catch the crashes, and I have written a number of toy programs to make certain things are the sizes I expect. Still stuck at this juncture. Had to take a lil break and learn to program a Particle board for a work project but will resume next week. > On Oct 23, 2017, at 11:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz <mailto:jan@cada.cz>> wrote: > Hi, > > I would like to connect fingerprint reader to pharo - so far I am able to use C library to connect to it using UFFI, > however the problem is that I can wait for fingerprint indefinitely ( blocking call to library) or register call-back for moment when fingerprint is available. > The registration function returns immediately, so it is clear that the callback will be called from another thread. > > Is such situation supported by UFFI ? > > Thanks for any tip, > > Jan > > Callbacks are supported. Here is an example... > http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… <http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w…> > > @Todd, How did find working through this part? > cheers -ben

Nov. 8, 2017

Re: [Pharo-users] QCMagritte on Github

by stephan

On 27-10-17 12:39, laurent laffont wrote: > Hi, > > my team starts to use QCMagritte. For our needs we have imported > SmalltalkHub repository to Github here: > https://github.com/Afibre/QCMagritte > > I don't know if you (Diego, Stephan, Tobias) plan to use Github > instead of SmalltalkHub. At least Github allows branches & pull > request. Definitely, and I'm still struggling a bit with Iceberg. I would definitely favor a setup where the whole open source part is build on each commit using travis and images are put on (e.g.) bitbucket. The current jenkins builds are waiting for Diego to finish some changes, and he is a bit distracted with plans for a new house. Tobias told me he's also interested, so I assume he'll provide a modified baseline for other platforms. At a certain point we might want to fold all of QCMagritte back into Magritte, but that is a discussion for later I think. Stephan

Nov. 8, 2017

Re: [Pharo-users] Open Debugger, Save and Quit

by Richard Sargent

Some of this can be seen in VA Smalltalk. Errors during start up are captured and can be debugged after the start up has completed. The idea of an Error Queue Viewer is a nice touch, along with the possibility of remote debugging. On Nov 7, 2017 6:55 PM, "Ben Coman" <btc(a)openinworld.com> wrote: On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > In a headless image, I'd like to do the following: if there's any error, > arrange to have a debugger open on the next (headful) launch, and then save > and quit. > > I'm drawing a blank - how would I do that? > > I explored various dead ends, the culmination of which was the > image-breaking: > actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] > fork. Halt now ] > > Thanks! > Sorry not a solution, but you sparked a side-thought... To avoid sometimes being swamped by Pre-Debug windows. Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into. This "Error Queue Viewer" would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window. In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened. The same error-queue might provide a similar interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected. cheers -ben

Nov. 8, 2017

Re: [Pharo-users] Open Debugger, Save and Quit

by Ben Coman

On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > In a headless image, I'd like to do the following: if there's any error, > arrange to have a debugger open on the next (headful) launch, and then save > and quit. > > I'm drawing a blank - how would I do that? > > I explored various dead ends, the culmination of which was the > image-breaking: > actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] > fork. Halt now ] > > Thanks! > Sorry not a solution, but you sparked a side-thought... To avoid sometimes being swamped by Pre-Debug windows. Instead of an error bringing up an individual Pre-Debug window, we could have error go into a queue which a singleton Pre-Debug window could have a view into. This "Error Queue Viewer" would have on row per error, and you click on a row to open a normal debugger, much like you click <Debug> button in the existing Pre-Debug window. In a headless image, the Error Queue Viewer would not appear, but the error would keep being queued until the next time the Error Queue Viewer is manually opened. The same error-queue might provide a similar interface point for Pharo Remote Tools, so you can see errors that occurred while you were not connected. cheers -ben

Nov. 8, 2017