- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Github API on github

by Norbert Hartl

Now the interesting question.... *drumroll* Will iceberg use this library??? Norbert > Am 26.10.2017 um 15:06 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Even more awesomeness :). Thanks for doing this! > > Doru > > >> On Oct 26, 2017, at 2:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> I already contacted Guille in a private message on this one. >> >> Because now we have three (sorted in order of appearance): >> >> 1. https://balletie.github.io/GitHub/ (from Balletie, very complete) >> 2. https://github.com/astares/GitHub-API (a wrapper I wrote to play with the API) >> 3. https://github.com/guillep/github-api (Guille) >> >> If time permits we should consolidate this into a single one (maybe on https://github.com/pharo-vcs/github-api) >> >> Guille will contact Balletie as a next step. >> >> Thanks >> T. >> >> >>> Gesendet: Donnerstag, 26. Oktober 2017 um 13:32 Uhr >>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Betreff: Re: [Pharo-dev] Github API on github >>> >>> Awesome. >>> >>> Doru >>> >>> >>>> On Oct 20, 2017, at 10:07 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> Hi guys, >>>> >>>> I extracted and extended some of the github API from iceberg, so it can be used as a standalone project. Maybe this is useful for somebody. >>>> >>>> https://github.com/guillep/github-api >>>> >>>> It should be easy to extend and add new functionalities, so don't hesitate if you need some missing request :) >>>> >>>> Guille >>>> >>>> -- >>>> >>>> Guille Polito >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> CRIStAL - UMR 9189 >>>> French National Center for Scientific Research - http://www.cnrs.fr >>>> >>>> Web: http://guillep.github.io >>>> Phone: +33 06 52 70 66 13 >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> âThe smaller and more pervasive the hardware becomes, the more physical the software gets." >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling."

Oct. 26, 2017

Re: [Pharo-dev] Github API on github

by Tudor Girba

Even more awesomeness :). Thanks for doing this! Doru > On Oct 26, 2017, at 2:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > I already contacted Guille in a private message on this one. > > Because now we have three (sorted in order of appearance): > > 1. https://balletie.github.io/GitHub/ (from Balletie, very complete) > 2. https://github.com/astares/GitHub-API (a wrapper I wrote to play with the API) > 3. https://github.com/guillep/github-api (Guille) > > If time permits we should consolidate this into a single one (maybe on https://github.com/pharo-vcs/github-api) > > Guille will contact Balletie as a next step. > > Thanks > T. > > >> Gesendet: Donnerstag, 26. Oktober 2017 um 13:32 Uhr >> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] Github API on github >> >> Awesome. >> >> Doru >> >> >>> On Oct 20, 2017, at 10:07 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Hi guys, >>> >>> I extracted and extended some of the github API from iceberg, so it can be used as a standalone project. Maybe this is useful for somebody. >>> >>> https://github.com/guillep/github-api >>> >>> It should be easy to extend and add new functionalities, so don't hesitate if you need some missing request :) >>> >>> Guille >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âThe smaller and more pervasive the hardware becomes, the more physical the software gets." >> >> >> > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Oct. 26, 2017

Re: [Pharo-dev] Github API on github

by Torsten Bergmann

I already contacted Guille in a private message on this one. Because now we have three (sorted in order of appearance): 1. https://balletie.github.io/GitHub/ (from Balletie, very complete) 2. https://github.com/astares/GitHub-API (a wrapper I wrote to play with the API) 3. https://github.com/guillep/github-api (Guille) If time permits we should consolidate this into a single one (maybe on https://github.com/pharo-vcs/github-api) Guille will contact Balletie as a next step. Thanks T. > Gesendet: Donnerstag, 26. Oktober 2017 um 13:32 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Github API on github > > Awesome. > > Doru > > > > On Oct 20, 2017, at 10:07 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > Hi guys, > > > > I extracted and extended some of the github API from iceberg, so it can be used as a standalone project. Maybe this is useful for somebody. > > > > https://github.com/guillep/github-api > > > > It should be easy to extend and add new functionalities, so don't hesitate if you need some missing request :) > > > > Guille > > > > -- > > > > Guille Polito > > Research Engineer > > > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 > > -- > www.tudorgirba.com > www.feenk.com > > âThe smaller and more pervasive the hardware becomes, the more physical the software gets." > > >

Oct. 26, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by Tudor Girba

Thanks Ronie. Please keep us posted with the progress. Cheers, Doru > On Oct 19, 2017, at 7:48 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi ClÃ©ment, > > Last night I was checking again the VM. If I remove the hack in the ioProcessEvents, I can receive the events with SDL2, but as soon as I type on the main Pharo window I get a crash in an objective-c message send by SDL2. I still need to debug SDL2 itself with debugging symbols. > > I am not sure whether I will be able to fix the problem without modifying SDL2. In the worst case escenario, we will have to move to the minheadless vm. > > Best regards, > Ronie > > 2017-10-18 4:49 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi again, > > I made many more attempts since those mails: I wrote this page showing how to deploy my game in native app at 50fps on Linux, Mac and Windows. > > Currently I deploy with: > Ubuntu 64 bits: Pharo61-64 (Pharo61-32 also works with the right lib installed) > Mac OS X 64 bits: Pharo5Alpha-32 (On Pharo61 the keyboard events do not work correctly) > Windows 64 bits: Pharo61-32 (There are bugs with the SDL2 window, the top bar is not displayed, but the game work. Reportedly it would work better with Pharo61-64 but the default Pharo64 VM on Windows still does not feature the JIT, once the default VM does, I will update). > > My goal is to deploy on all platforms with Pharo61-64 (and later Pharo7-64). > > I wrote this mail since maybe you are interested in knowing that with Pharo5Alpha-32 and the set-up described on the page of my game the keyboard events work fine on Mac, so it may be possible to write a fix for Pharo61/Pharo7 based on that. > > Best, > > > > > On Fri, Sep 29, 2017 at 8:56 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx ronie! > > > On Fri, Sep 29, 2017 at 1:42 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi ClÃ©ment, > > > > I just checked on my machine and it is also not working. It seems to be a VM > > bug. It will take me some time to debug it. I have some suspicious on > > ioProcessEvents . > > > > Best regards, > > Ronie > > > > 2017-09-29 10:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> > >> > >> > >> On Fri, Sep 29, 2017 at 10:29 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > >>> > >>> Hi, > >>> > >>> IMHO, it will make Pharo much more robust if core libraries as sdl, > >>> cairo, etc will be shipped with each plateform dependent virtual machine and > >>> the image modified accordingly to use these core libraries. > >> > >> > >> That's how it is now but some of it is not working (Here SDL events and > >> there are 2 SDL2 libs by default). > >> > >> I think we should still have a minimal image starting with a minimal UI > >> without using FFI/SDL/Cairo or whatever lib. Else when we start on a > >> platform where one of this thing is not properly supported yet (See the > >> problem on the raspberry pie with some Pharo alpha version) it is too hard > >> to understand what is going on. > >> > >>> > >>> > >>> The delivery of Pharo application to end users is an issue because of > >>> these recuring problem. > >> > >> > >> Honestly I was trying to write a doc on how to deploy Pharo client app > >> with SDL2 and Cairo but I have only a version working in Pharo 4 on Mac and > >> Linux, while in theory I could have it working in Windows/Mac/Linux in the > >> latest Pharo. > >> > >>> > >>> Hilaire > >>> > >>> > >>> > >>> Le 28/09/2017 Ã 15:02, ClÃ©ment Bera a Ã©crit : > >>>> > >>>> Btw for some reason in the one-click version of Pharo 32 bits on Mac > >>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts > >>>> (the VM use randomly one lib or the other). I randomly chose one that I use > >>>> and deleted the other one, do you have advises on which one I should prefer > >>>> ? Maybe the events are working only with the other one ? > >>>> > >>> > >>> -- > >>> Dr. Geo > >>> http://drgeo.eu > >>> > >>> > >>> > >> > > > > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Oct. 26, 2017

Re: [Pharo-dev] Github API on github

by Tudor Girba

Awesome. Doru > On Oct 20, 2017, at 10:07 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi guys, > > I extracted and extended some of the github API from iceberg, so it can be used as a standalone project. Maybe this is useful for somebody. > > https://github.com/guillep/github-api > > It should be easy to extend and add new functionalities, so don't hesitate if you need some missing request :) > > Guille > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 -- www.tudorgirba.com www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

Oct. 26, 2017

Re: [Pharo-dev] feenk log

by werner kassens

Hi Doru, you say BLVector is implemented as having instance vars x,y instead of using an Array (like polymath), i guess perhaps because of speed considerations? but i wonder why you then dont use FloatArrays for vectors, their precision, although generally bad, is sufficient for graphics and they are faster for vector operations? werner

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Tudor Girba

Hi, To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. Cheers, Doru > On Oct 26, 2017, at 10:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 2017-10-26 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Another question. >>> >>> Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. >> >> No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. >> >> Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. > > I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. > > Doru > >> >>> And what about Rectangle? (Bloc implements own BlRectangle). >> >> These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. >> >> We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). >> >> Doru >> >> >> >>> 2017-10-26 9:26 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> #(1 3 4 5 7 -2) asVector >>> >>> Meh. >>> Ugly. >>> >>> { 1. 3. 4. a. b } asVector >>> >>> is the natural consequence. >>> >>> v := (1,3,4,5,7,-2) asVector >>> >>> keeps the parens. But why do I need to do that? >>> >>> Autoformatting messing with my parentheses is just a mistake. >>> I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. >>> >>> And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. >>> >>> Phil >>> >>> >>> >>> On Thu, Oct 26, 2017 at 8:52 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>> >>>> Automatic formatting will turn it into >>>> >>>> vector := 1,3,4,5,7,-2. >>>> >>>> Which is not as nice. >>>> >>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: >>>> >>>> vector := width, height, depth. >>>> >>>> >>>> Question: why not extend @ notation? >>>> >>>> x @ y @ z? >>>> >>>> Peter >>>> >>>> >>>> >>>> On Thu, Oct 26, 2017 at 8:22 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>> >>>>> I also like the , message for those vectors and the concatenation of dimensions makes sense. >>>>> >>>>> vector := (1,3,4,5,7,-2). >>>>> >>>>> looks how it should be. >>>>> >>>>> Readable, easy to translate vector stuff from reference text. >>>>> >>>>> Phil >>>>> >>>>> >>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <astares(a)gmx.de>: >>>>>> >>>>>> Hi, >>>>>> >>>>>> there might be reasons for an own 2D vector class (instead of using Point). >>>>>> But still I dislike the reimplementation of "," because for me so far it >>>>>> has the meaning of "concatenating things". >>>>>> >>>>>> >>>>>> >>>>>> Like concatenating coordinates :-) >>>>>> >>>>>> >>>>>> >>>>>> Here you redefine it to create vector instances and it works only up to three >>>>>> so far. Right? >>>>>> >>>>>> I understand that this gives some similarities with the math notation (1,2) >>>>>> but I personally would prefer to use: >>>>>> >>>>>> 1@2 asVector >>>>>> >>>>>> or Vector2D x: 1 y: 2 >>>>>> >>>>>> Thx >>>>>> T. >>>>>> >>>>>> >>>>>> >>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >>>>>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>>>> Betreff: [Pharo-dev] , for vector creation >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As mentioned in the separate thread, we played with introducing the extension: >>>>>>> >>>>>>> , aNumber >>>>>>> ^ BlVector2D x: self y: aNumber >>>>>>> >>>>>>> This means that (10,20) will return a 2D vector. >>>>>>> >>>>>>> We also have (10,20,30) which returns a 3D vector. >>>>>>> >>>>>>> , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. >>>>>>> >>>>>>> Please voice your concerns. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "Every thing should have the right to be different." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "When people care, great things can happen." >> >> >> >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Oct. 26, 2017

[Pharo 7.0-dev] Build #228: 20026-Diff-has-incorrect-positions-red-and-green-colors-of-changed-text

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #228 was: SUCCESS. The Pull Request #396 was integrated: "20026-Diff-has-incorrect-positions-red-and-green-colors-of-changed-text" Pull request url: https://github.com/pharo-project/pharo/pull/396 Issue Url: https://pharo.fogbugz.com/f/cases/20026 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 26, 2017

Re: [Pharo-dev] , for vector creation

by Tudor Girba

Hi, > On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-10-26 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Another question. > > > > Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. > > No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. > > Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. Doru > > > And what about Rectangle? (Bloc implements own BlRectangle). > > These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. > > We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). > > Doru > > > > > 2017-10-26 9:26 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > #(1 3 4 5 7 -2) asVector > > > > Meh. > > Ugly. > > > > { 1. 3. 4. a. b } asVector > > > > is the natural consequence. > > > > v := (1,3,4,5,7,-2) asVector > > > > keeps the parens. But why do I need to do that? > > > > Autoformatting messing with my parentheses is just a mistake. > > I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. > > > > And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. > > > > Phil > > > > > > > > On Thu, Oct 26, 2017 at 8:52 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > > > Automatic formatting will turn it into > > > > > > vector := 1,3,4,5,7,-2. > > > > > > Which is not as nice. > > > > > > And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: > > > > > > vector := width, height, depth. > > > > > > > > > Question: why not extend @ notation? > > > > > > x @ y @ z? > > > > > > Peter > > > > > > > > > > > > On Thu, Oct 26, 2017 at 8:22 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > >> > > >> I also like the , message for those vectors and the concatenation of dimensions makes sense. > > >> > > >> vector := (1,3,4,5,7,-2). > > >> > > >> looks how it should be. > > >> > > >> Readable, easy to translate vector stuff from reference text. > > >> > > >> Phil > > >> > > >> > > >> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > >>> > > >>> > > >>> > > >>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <astares(a)gmx.de>: > > >>> > > >>> Hi, > > >>> > > >>> there might be reasons for an own 2D vector class (instead of using Point). > > >>> But still I dislike the reimplementation of "," because for me so far it > > >>> has the meaning of "concatenating things". > > >>> > > >>> > > >>> > > >>> Like concatenating coordinates :-) > > >>> > > >>> > > >>> > > >>> Here you redefine it to create vector instances and it works only up to three > > >>> so far. Right? > > >>> > > >>> I understand that this gives some similarities with the math notation (1,2) > > >>> but I personally would prefer to use: > > >>> > > >>> 1@2 asVector > > >>> > > >>> or Vector2D x: 1 y: 2 > > >>> > > >>> Thx > > >>> T. > > >>> > > >>> > > >>> > > >>> > Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr > > >>> > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > > >>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > >>> > Betreff: [Pharo-dev] , for vector creation > > >>> > > > >>> > Hi, > > >>> > > > >>> > As mentioned in the separate thread, we played with introducing the extension: > > >>> > > > >>> > , aNumber > > >>> > ^ BlVector2D x: self y: aNumber > > >>> > > > >>> > This means that (10,20) will return a 2D vector. > > >>> > > > >>> > We also have (10,20,30) which returns a 3D vector. > > >>> > > > >>> > , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. > > >>> > > > >>> > Please voice your concerns. > > >>> > > > >>> > Cheers, > > >>> > Doru > > >>> > > > >>> > > > >>> > -- > > >>> > www.tudorgirba.com > > >>> > www.feenk.com > > >>> > > > >>> > "Every thing should have the right to be different." > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >> > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > > > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Oct. 26, 2017

Re: [Pharo-dev] UnifiedFFI Docs

by Esteban Lorenzano

> On 25 Oct 2017, at 21:39, Todd Blanchard <tblanchard(a)mac.com> wrote: > > OK, new question. > > How do I file this in? I was able to load tonel from iceberg. I added the repo and it gave me a choice of packages to load and I loaded them using the iceberg browser. > > I added this to the iceberg browser and there are no packages listed and I have absolutely no clue how to get this code into my image. > > I'm about 80 hours into trying to get my head around FFI and really getting discouraged at how many walls I'm hitting trying to get a foreign library interface done. in Pharo7, you do nothing, is there by default. you do not âfile inâ, you add an iceberg project and then you load the baseline, as any other project. about the walls: you didnât chose a simple library to learn FFI, you chose one of the hardest libraries that exist. What you are doing is like trying to learn to be a doctor through open-heart operations :) Esteban > >> On Oct 25, 2017, at 7:35 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> :) >> >> Did you look at this project: https://github.com/estebanlm/libclang-pharo-bindings/ <https://github.com/estebanlm/libclang-pharo-bindings/> ? >> >> it was using parseTranslationUnit (no 2)â¦ there you can find how is being used (I just converted it to tonel format, but older versions are in filetree) >> >> Esteban >> >>> On 24 Oct 2017, at 19:17, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>> >>> Hey Esteban, >>> >>> Now that you have outed yourself as a maintainer of FFI, I have a question. :-) >>> >>> I want to call the libclang function: >>> >>> /** >>> * \brief Parse the given source file and the translation unit corresponding >>> * to that file. >>> * >>> * This routine is the main entry point for the Clang C API, providing the >>> * ability to parse a source file into a translation unit that can then be >>> * queried by other functions in the API. This routine accepts a set of >>> * command-line arguments so that the compilation can be configured in the same >>> * way that the compiler is configured on the command line. >>> * >>> * \param CIdx The index object with which the translation unit will be >>> * associated. >>> * >>> * \param source_filename The name of the source file to load, or NULL if the >>> * source file is included in \c command_line_args. >>> * >>> * \param command_line_args The command-line arguments that would be >>> * passed to the \c clang executable if it were being invoked out-of-process. >>> * These command-line options will be parsed and will affect how the translation >>> * unit is parsed. Note that the following options are ignored: '-c', >>> * '-emit-ast', '-fsyntax-only' (which is the default), and '-o \<output file>'. >>> * >>> * \param num_command_line_args The number of command-line arguments in >>> * \c command_line_args. >>> * >>> * \param unsaved_files the files that have not yet been saved to disk >>> * but may be required for parsing, including the contents of >>> * those files. The contents and name of these files (as specified by >>> * CXUnsavedFile) are copied when necessary, so the client only needs to >>> * guarantee their validity until the call to this function returns. >>> * >>> * \param num_unsaved_files the number of unsaved file entries in \p >>> * unsaved_files. >>> * >>> * \param options A bitmask of options that affects how the translation unit >>> * is managed but not its compilation. This should be a bitwise OR of the >>> * CXTranslationUnit_XXX flags. >>> * >>> * \param[out] out_TU A non-NULL pointer to store the created >>> * \c CXTranslationUnit, describing the parsed code and containing any >>> * diagnostics produced by the compiler. >>> * >>> * \returns Zero on success, otherwise returns an error code. >>> */ >>> enum CXErrorCode >>> clang_parseTranslationUnit2(CXIndex CIdx, >>> const char *source_filename, >>> const char *const *command_line_args, >>> int num_command_line_args, >>> struct CXUnsavedFile *unsaved_files, >>> unsigned num_unsaved_files, >>> unsigned options, >>> CXTranslationUnit *out_TU); >>> >>> The parts I'm not clear on are turning an array or ordered collection of strings into an argv/argc, turning an array of CXUnsavedFile's (FFIExternalStruct) into an array of pointers and count, and getting data back in an output argument as CXTranslationUnit which is an opaque pointer to a C++ object. >>> >>> Any tips on these mappings would be great. I've currently guessed it as: >>> >>> clang_parseTranslationUnit__cxIndex: cxIndex source: sourceFile arguments: argv unsavedFiles:unsaved options: opts >>> >>> | argc unsaved_files num_unsaved_files options error out_TU | >>> argc := argv size. >>> unsaved_files := unsaved ifNil: [ #() ] ifNotNil: [ unsaved ]. >>> num_unsaved_files := unsaved_files ifNil: [ 0 ] ifNotNil: [unsaved_files size]. >>> options := opts sum. >>> >>> error := self ffiCall: #(CXErrorCode clang_parseTranslationUnit2(CXIndex cxIndex, >>> String sourceFile, >>> String *argv, >>> uint argc, >>> CXUnsavedFile *unsaved_files, >>> uint num_unsaved_files, >>> CXTranslationUnitFlag options, >>> CXTranslationUnit *out_TU)). >>> >>> (error = CXError_Success) ifTrue: [ ^out_TU ]. >>> self error: error >>> >>> Thanks. >>> >>> >>>> On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>>> On 21 Oct 2017, at 21:15, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >>>>> >>>>> Esteban will probably reply to this thread >>>> >>>> yes, I will :) >>>> >>>>> >>>>> >>>>> On Thu, Oct 19, 2017 at 10:34 PM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>>> I have found the problem with VoidPointer3 generating accessors. >>>> >>>> can you report that on fogbugz ? >>>> (along with your solution) >>>> >>>> thanks! >>>> Esteban >>>> >>>>>> >>>>>> No idea how to contribute back a fix but this is what I've found. >>>>>> >>>>>> FFITypeArrayType>>annonymousClassCreator >>>>>> ^ String streamContents: [ :stream | >>>>>> stream >>>>>> nextPutAll: '(FFITypeArray ofType: '; >>>>>> print: (self objectClass type isPointer ifTrue: [self externalTypeWithArity >>>>>> printString] ifFalse: ['#',self objectClass type class]); >>>>>> nextPutAll: ' size: '; >>>>>> print: self objectClass numberOfElements; >>>>>> nextPutAll: ')' ] >>>>>> >>>>>> Recalling that we are trying to come up with an accessor that can pull out a >>>>>> void*[3], this produces >>>>>> >>>>>> '(FFITypeArray ofType: #FFIVoid size: 3)' >>>>>> >>>>>> which produces an error as FFIVoid's size is undefined. In general, this >>>>>> will be wrong for any pointer type and will probably get the size >>>>>> calculation wrong. >>>>>> >>>>>> Doing a little digging I find that >>>>>> >>>>>> FFITypeArray>>ofType: aType size: aSize >>>>>> >>>>>> delegates resolution of aType to FFIExternalType>>resolveType:aType and this >>>>>> can take all kinds of different things including the native type name. >>>>>> >>>>>> It would be better if this generated the native name for pointers. >>>>>> >>>>>> (FFITypeArray ofType: 'void*' size: 3) >>>>>> >>>>>> So I changed it to: >>>>>> >>>>>> FFITypeArrayType>>annonymousClassCreator >>>>>> ^ String streamContents: [ :stream | >>>>>> stream >>>>>> nextPutAll: '(FFITypeArray ofType: '; >>>>>> print: (self objectClass type isPointer >>>>>> ifTrue: [self externalTypeWithArity printString] >>>>>> ifFalse: ['#',self objectClass type class]); >>>>>> nextPutAll: ' size: '; >>>>>> print: self objectClass numberOfElements; >>>>>> nextPutAll: ')' ] >>>>>> >>>>>> and this seems to work fine. >>>>>> >>>>>> Onwards... >>>>>> >>>>>> On Oct 19, 2017, at 7:18 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>>> >>>>>> Thatâs great - itâs been kind of magical but a couple things have changed >>>>>> since you wrote it and some bugs have crept into ffi. >>>>>> >>>>>> Right now Iâm finding the generated accessor for the VoidPointer3 is >>>>>> actually generating a void 3 accessor and that doesnât work. I spent all day >>>>>> yesterday tracking it to the accessor generating code. >>>>>> >>>>>> Sent from the road >>>>>> >>>>>> On Oct 18, 2017, at 22:29, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>>>> >>>>>>> I'm working through Ben's great blog post about playing with libclang and >>>>>>> I am puzzled by something. >>>>>> >>>>>> >>>>>> Thx Todd. Knowing someone is looking at it encourages me to expand it. >>>>>> I'm interested in looking at your specific questions, but it might not be >>>>>> until next week after this stint of long work days. >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> invalidateSessionData >>>>>>> handle atAllPut: 0. >>>>>>> >>>>>>> zero;s out the handle. Cool. However, >>>>>>> >>>>>>> handle isNull >>>>>>> >>>>>>> does not return true despite it being used in the getString method as >>>>>>> >>>>>>> ^ handle isNull >>>>>>> ifTrue: ['external memory invalidated by session restart'] >>>>>>> ifFalse:[LibClang clang_getCString__cxString: self]. >>>>>>> >>>>>>> Looks like there should be an isNull on ByteArray that returns true if all >>>>>>> bytes are zero but it isn't there. Was it dropped for some reason? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> Sure the documentation could be better, that is definetly important, but >>>>>>> is already good enough and UFFI is a very technical subject much more suited >>>>>>> to a mailing list . Its not physical possible to cover the massive potential >>>>>>> of UFFI. >>>>>>> >>>>>>> On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Please do not hesitate to do Pull Requests. >>>>>>>> Luc told me that he wants to do a pass on it and Esteban promises that to >>>>>>>> me >>>>>>>> but he is super busy. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> >>>>>>>> wrote: >>>>>>>>> Wonderful! Thanks. >>>>>>>>> >>>>>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>>>>>>>>> >>>>>>>>>> On 17-10-17 23:06, Todd Blanchard wrote: >>>>>>>>>>> Anyone know what happened to this? >>>>>>>>>>> >>>>>>>>>>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> >>>>>>>>>> >>>>>>>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI <https://github.com/SquareBracketAssociates/Booklet-uFFI> >>>>>>>>>> >>>>>>>>>> has a link to a bintray pdf download >>>>>>>>>> >>>>>>>>>> Stephan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >

Oct. 26, 2017