- Pharo-users - lists.pharo.org

Re: [Pharo-users] LGit_GIT_ERROR: Invalid version 0 on git_remote_callbacks on latest 64bit 6.1 image?

by Paulo R. Dellani

You need to configure Iceberg with the path of the SSH key files you are using to authenticate with gitlab as well as the passphrase to unlock the private key, I only got it working after that. Have your done that? There is more information in the README/FAQ here: https://github.com/pharo-vcs/iceberg Cheers, Paulo On 11/08/2017 12:26 AM, Tim Mackinnon wrote: > Thanks for confirming this Esteban - perhaps I am doing something > wrong - I tried using the steps I was using successfully several > months ago namely: > > curl get.pharo.org/64/ <http://get.pharo.org/64/> | bash > ./pharo-ui Pharo.image > > Which got me the latest image - which sys info says is (not sure why > it still says 6.0 tho?): > > Pharo 6.0 > Latest update: #60520 > > I then open Iceberg, and click on Clone Repository > > In the dialog I enter: > > git(a)gitlab.com <mailto:git@gitlab.com>:macta/PharoLambda.git > And put src in the codeÂ subdirectory field, and then click on Create. > > I get theÂ LGit_GIT_ERROR ??? > > Hmm, out of curiosity, I just tried leaving the src field empty and it > then seemed to put an entry into Iceberg but then a Fetch gave me the > same error? > > Tim > >> On 7 Nov 2017, at 11:46, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> iceberg should work on 64bits, both on Pharo7 and Pharo6.Â >> Iâve been using it exclusively on 64bits since some months now and I >> know Iâm not the only oneâ¦ can you send a way to reproduce your >> problem so I can take a look? >> >> Esteban >> >> >>> On 6 Nov 2017, at 12:11, Tim Mackinnon <tim(a)testit.works >>> <mailto:tim@testit.works>> wrote: >>> >>> Hi - does Iceberg work on a 64bit image yet? Iâve not tried in a >>> while, and was surprised when I went to get a new image via the >>> command line that I am getting the error:Â LGit_GIT_ERROR: Invalid >>> version 0 on git_remote_callbacks >>> >>> I can see a post by Alistair in Jun asking about this, and it seems >>> 64bit hadnât been updated to work back then - but is this still true >>> in Nov? >>> >>> We seem very much in turmoil at the moment - and its unclear what >>> should work and not work. Is there a stable platform? If 64 bit is >>> only working for 7.x - should we remove it from 6.x so that people >>> donât inadvertently try to use it? >>> >>> Tim >> >

Nov. 8, 2017

PharoLauncher directories

by stephan

I run into all kinds of issues with the directory structure used by the new PharoLauncher. pharo-local seems to be shared now for multiple images. That makes using configurations practically impossible as they are not expecting to have to deal with pre-downloaded older and newer monticello files. The missing sources files is less of a problem. Stephan

Nov. 8, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Thierry Goubier

Hi Steffen, in fact, I considered B) directly, but not up to the point of building onto C) and D) (with an obvious A, but that one is a given in Pharo implementation of strings). Thanks for the explanation, then. Regards, Thierry 2017-11-08 14:21 GMT+01:00 Steffen MÃ¤rcker <merkste(a)web.de>: > I see. How about the following (sketched) solution to avoid looping over > all characters? It might be very well the case that you already considered > (and dismissed) that path. > > A) Assumption > In order to allow any meaningful matching, the input to the scanner is > normalized according to the unicode spec. > > B) Abstraction > Treat each character and character group of an regex as a set of intervals > in the unicode code points. Lets call them "character tests" and lift the > common set operations union, intersection and difference to them. > > C) Construct NFA > NFA has potentially overlapping character tests at the transitions of each > state. > > D) Construct DFA > Given a product state s in the DFA and two transitions t1, t2 from the > original NFA, add three new transitions to the DFA: > - a transition labeled with the character test of t1 minus the character > test of t2 > - a transition labeled with the intersection of the character tests of t1 > and t2 > - a transition labeled with the character test of t2 minus the character > test of t1 > > E) Extension > Instead of sets of unicode intervals we could also use test-functions, > e.g. blocks. Then, in step D), the set operations are translated to boolean > operations: > - difference t1 - t2 becomes: t1 && not t2 > - intersection of t1 and t2 becomes: t1 && t2 > This would allow to use optimized test functions, e.g., bdds, instead of > relying on charcter tests only. > > > Cheers, > Steffen > > > > > > Am .11.2017, 23:16 Uhr, schrieb Thierry Goubier <thierry.goubier(a)gmail.com > >: > > Le 07/11/2017 Ã 23:00, Steffen MÃ¤rcker a Ã©crit : >> >>> I am not familiar with the literature on scanners. May I ask you about >>> some details on the "for all characters" algorithms you are referring to? >>> >> >> The two main ones available, from the typical Aho/Ullman textbook, are: >> >> - NFA to DFA conversion (i.e. build a NFA with your regular expressions, >> then convert it to a DFA) >> >> - Direct regular expression to DFA construction >> >> Both of them have loop of the type: >> >> for (each input symbol a) { >> ... >> >> Building a (or connecting to) a BDD library would be fun, indeed. But >>> within that time frame it seems not realistic. Anyway, after finishing my >>> thesis, I'd like to come back to that idea. >>> >> >> It would certainly be interesting. Please contact us again when you'll >> have time :) >> >> Regards, >> >> Thierry >> >> Ciao, Steffen >>> Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn < >>> aglynn42(a)gmail.com>: >>> A possible way to accomplish it would be to use an object graph with >>> an incremental query engine, such as EMF/CDO with Viatra or >>> something similar. You could then put different character sets in >>> connected objects and query only as far as you need to. >>> Andrew Glynn >>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >>> Windows 10 >>> *From: *Thierry Goubier <mailto:thierry.goubier@gmail.com> >>> *Sent: *Tuesday, November 7, 2017 7:17 AM >>> *To: *Any question about pharo is welcome >>> <mailto:pharo-users@lists.pharo.org> >>> *Subject: *Re: [Pharo-users] Binary Decision Diagram Package in >>> Smalltalk >>> Hi Andrew, Steffen, >>> 2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black <black(a)cs.pdx.edu >>> <mailto:black@cs.pdx.edu>>: >>> > On 28 Oct 2017, at 17:37 , Steffen MÃ¤rcker <merkste(a)web.de >>> <mailto:merkste@web.de>> wrote: >>> > >>> > Does that mean the sets/bdd would be constructed mainly at >>> comile time? Anyway, Andrew, feel free to contact me, I might >>> help you with this. >>> > >>> Thanks for the offer, Steffen! The problem is that I need to >>> use SmaCC for my current project, and really do not have a month >>> to take off and re-design the way that it builds its scanner. >>> Iâve talked to Thierry Goubier about, and he doesnât have time >>> either! It would be a fun project, though, and it ought to be >>> fairly separate from other parts of SmaCC. Iâve spent a fair >>> bit of time thinking about how to do it, but donât think that I >>> will be able to actually focus on it. >>> Yes, this is the essence of the issue. There are a few alternatives >>> about it, but none we have the time to pursue. >>> An alternative approach, which Thierry has suggested, is to >>> make >>> SmaCC work on the UTF-8 representation of the Unicode. Then we >>> could represent character sets as prefix trees. But the core >>> problem would still exist: you canât run an algorithm that >>> repeatedly executes >>> for all characters in the alphabet do: >>> when there are 2^21 characters in the alphabet! >>> The main issue is that `for all characters`... All the literature on >>> scanner building uses 'for all characters do'. >>> Thierry >>> Andrew >>> >>> >> >

Nov. 8, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Steffen MÃ¤rcker

I see. How about the following (sketched) solution to avoid looping over all characters? It might be very well the case that you already considered (and dismissed) that path. A) Assumption In order to allow any meaningful matching, the input to the scanner is normalized according to the unicode spec. B) Abstraction Treat each character and character group of an regex as a set of intervals in the unicode code points. Lets call them "character tests" and lift the common set operations union, intersection and difference to them. C) Construct NFA NFA has potentially overlapping character tests at the transitions of each state. D) Construct DFA Given a product state s in the DFA and two transitions t1, t2 from the original NFA, add three new transitions to the DFA: - a transition labeled with the character test of t1 minus the character test of t2 - a transition labeled with the intersection of the character tests of t1 and t2 - a transition labeled with the character test of t2 minus the character test of t1 E) Extension Instead of sets of unicode intervals we could also use test-functions, e.g. blocks. Then, in step D), the set operations are translated to boolean operations: - difference t1 - t2 becomes: t1 && not t2 - intersection of t1 and t2 becomes: t1 && t2 This would allow to use optimized test functions, e.g., bdds, instead of relying on charcter tests only. Cheers, Steffen Am .11.2017, 23:16 Uhr, schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 07/11/2017 Ã 23:00, Steffen MÃ¤rcker a Ã©crit : >> I am not familiar with the literature on scanners. May I ask you about >> some details on the "for all characters" algorithms you are referring >> to? > > The two main ones available, from the typical Aho/Ullman textbook, are: > > - NFA to DFA conversion (i.e. build a NFA with your regular expressions, > then convert it to a DFA) > > - Direct regular expression to DFA construction > > Both of them have loop of the type: > > for (each input symbol a) { > ... > >> Building a (or connecting to) a BDD library would be fun, indeed. But >> within that time frame it seems not realistic. Anyway, after finishing >> my thesis, I'd like to come back to that idea. > > It would certainly be interesting. Please contact us again when you'll > have time :) > > Regards, > > Thierry > >> Ciao, Steffen >> Am 7. November 2017 16:33:03 MEZ schrieb Andrew Glynn >> <aglynn42(a)gmail.com>: >> A possible way to accomplish it would be to use an object graph >> with >> an incremental query engine, such as EMF/CDO with Viatra or >> something similar. You could then put different character sets in >> connected objects and query only as far as you need to. >> Andrew Glynn >> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >> Windows 10 >> *From: *Thierry Goubier <mailto:thierry.goubier@gmail.com> >> *Sent: *Tuesday, November 7, 2017 7:17 AM >> *To: *Any question about pharo is welcome >> <mailto:pharo-users@lists.pharo.org> >> *Subject: *Re: [Pharo-users] Binary Decision Diagram Package in >> Smalltalk >> Hi Andrew, Steffen, >> 2017-11-07 13:10 GMT+01:00 Prof. Andrew P. Black <black(a)cs.pdx.edu >> <mailto:black@cs.pdx.edu>>: >> > On 28 Oct 2017, at 17:37 , Steffen MÃ¤rcker <merkste(a)web.de >> <mailto:merkste@web.de>> wrote: >> > >> > Does that mean the sets/bdd would be constructed mainly at >> comile time? Anyway, Andrew, feel free to contact me, I might >> help you with this. >> > >> Thanks for the offer, Steffen! The problem is that I need to >> use SmaCC for my current project, and really do not have a month >> to take off and re-design the way that it builds its scanner. >> Iâve talked to Thierry Goubier about, and he doesnât have time >> either! It would be a fun project, though, and it ought to be >> fairly separate from other parts of SmaCC. Iâve spent a fair >> bit of time thinking about how to do it, but donât think that I >> will be able to actually focus on it. >> Yes, this is the essence of the issue. There are a few alternatives >> about it, but none we have the time to pursue. >> An alternative approach, which Thierry has suggested, is to >> make >> SmaCC work on the UTF-8 representation of the Unicode. Then we >> could represent character sets as prefix trees. But the core >> problem would still exist: you canât run an algorithm that >> repeatedly executes >> for all characters in the alphabet do: >> when there are 2^21 characters in the alphabet! >> The main issue is that `for all characters`... All the literature >> on >> scanner building uses 'for all characters do'. >> Thierry >> Andrew >> >

Nov. 8, 2017

Soup bug(fix)

by Siemen Baader

Hi all, who maintains Soup, the HTML parser? Stef? It seems to auto-close <button> (and <a>) tags when nested inside another element. I wrote this test that fails: testNestedButton "this works with nested <div> tags instead of <button> and when there is no enclosing <div> at all. but here <button> is auto-closed." "a does not work either" | soup | soup := Soup fromString: '<div><button> <span>text</span> </button> </div>'. self assert: soup div button span string equals: 'text' ---- Where should I look to prevent Soup from auto-closing the tag, and where & how should I submit my fix? cheers, Siemen

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Esteban Lorenzano

> On 8 Nov 2017, at 05:07, 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. thatâs unlikely to be true. what you will not have, definitively, is async callbacks (thatâs WIP and not for the immediate). Esteban > > 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] Writing "powerpoint" like presentations in Pharo?

by Offray Vladimir Luna CÃ¡rdenas

On 07/11/17 19:39, Sean P. DeNigris wrote: > Offray Vladimir Luna CÃ¡rdenas-2 wrote >> The idea of slides seems >> pretty anachronistic/boring for making presentations. > Amen, brother! Alan Kay would be proud :) > Maybe. I refer the whole aesthetics of slides (even the ones with animations or simulations). You go in slide at the time, bullet point by bullet point, loosing context and perspective. My usual approach is mind maps. In [1] you can see the exported SVG version of the one I use in a Grafoscopio workshop. Source code is in [2]. [1] http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.svg [2] http://mutabit.com/grafoscopio/Docs/En/Talks/Overview/grafoscopio-mapa.mm Cheers, Offray

Nov. 8, 2017

Re: [Pharo-users] [Pharo7.0a] Next batch of enhancements

by Pavel Krivanek

2017-11-05 18:39 GMT+01:00 PBKResearch <peter(a)pbkresearch.co.uk>: > I donât see why there is a flame potential here; I certainly wonât start a > flame war. My previous post was a bit heated, as a protest against the > abuse of language; removing a facility may make Pharo easier to maintain, > but it is not an enhancement for the user. I wasnât aware that the theme is > broken; it seems to work well whenever I use it. > > > > It may be that I am the only one weird enough to continue with this theme > (which was the standard Pharo theme when I first met it). If so, I shall > have to accept the majority view. I shall keep a note of the .st package > you supplied, and try filing it in when I have to move on to Pharo 7. I > donât think keeping it as an optional extra will really work. It will be an > orphan, because no-one other than the existing Pharo maintainers will have > the knowledge to maintain it. It will presumably only need maintenance if > there is some change in the superclass UITheme, and only those responsible > for the change will know where the consequential effects will be seen. > > > > There is one possibility which occurs to me. You have presumably > refactored the subclasses of UITheme, so that it no longer matters to the > other themes whether watery is present or absent. So you could file it in > again, marking it as deprecated and not to be maintained, and strange > people like me could use it at our own risk. When some other change occurs > which makes this theme irretrievably broken, perhaps in Pharo 8, 9 or 10, > it could then be deleted. > > > > Definitely no flame â just a serious suggestion of a compromise. > > > > Peter Kenny > Hi Peter, there are some other themes that are managed externally and if there will be some issues with updating it to the latest Pharo versions, I'm sure that people will help if they will be kindly asked. The Watery theme is working in general but broken in many small details including the Spotter integration. One thing that newcomers try to do as first is to play with changing of themes and to provide them an inconsistent theme that emulates look of an OS that is not used anymore does not throw a favorable light on Pharo. Cheers, -- Pavel > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Pavel Krivanek > *Sent:* 05 November 2017 12:48 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] [Pharo7.0a] Next batch of enhancements > > > > Removing of the Watery theme is an enhancement in sense of "cleanup". The > code was not maintained and partly broken. To have this theme in the image > was a problem for management of the two default Pharo themes because the > Watery theme was superclass of them and added a significant level of > complexity and mess. > > > > But let's be positive. I can imagine that this thread has a huge flame > potential so I spent a few minutes to prepare Watery Theme as a standalone > package (see the attached *.st file). And no, it was not a simple file-out > operation. So I hope that people that want to use the Watery Theme will > rather discuss in what repository to place it and who will maintain it. In > Pharo we want to focus on two basic themes - one white and one dark. We > simply see no reason why this theme should not be an optional external > package. > > > > Cheers, > > -- Pavel > > > > > > 2017-11-05 12:00 GMT+01:00 PBKResearch <peter(a)pbkresearch.co.uk>: > > I waded through the list of 'enhancements', and was astonished to find > this. Is there to be an alternative way of producing the same appearance as > the 'Watery' theme? If not, how can the removal of a facility be called an > 'enhancement'? I always switch to this theme when I load a new image, > because I find the plain buttons in the standard theme ugly. > > I managed to find the fogbugz entry - not easy, because it has been > closed, so clicking on the link gives 404 - and it just says 'UIThemeWatery > should be removed according to the current Pharo 7 plans.' I can't recall > seeing these plans put up for discussion; if I had, I would certainly have > protested then. Does having this theme as an option cause any problems > elsewhere, so as to justify removing a facility. If not, can I put in a > plea to have this so-called enhancement reverted? It has been installed > only a week ago, so it can't be a major problem. > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf > Of Stephane Ducasse > Sent: 05 November 2017 09:08 > To: Pharo Development List <pharo-dev(a)lists.pharo.org>; Any question > about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] [Pharo7.0a] Next batch of enhancements > > Report period: 23 October 2017 to 5 November 2017 > > * 20587-remove-UIThemeWatery > >> https://pharo.fogbugz.com/f/cases/20587-remove-UIThemeWatery > > Issue URL: https://pharo.fogbugz.com/f/cases/20587 > PR URL: https://github.com/pharo-project/pharo/pull/395 > Diff URL: https://github.com/pharo-project/pharo/pull/395/files > > Thanks to pavel-krivanek > > > > >

Nov. 8, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Esteban Lorenzano

> On 8 Nov 2017, at 06:55, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Pretty sure that's the one I loaded. > > Still having issues with libclang on 64 bit with code locations. that was made for 32bit. I never tried it witht 64bit libclang so I would not expect it works just like that ;) Esteban > >> On Nov 8, 2017, at 1:26 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@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 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