- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo bootstrap

by Guillermo Polito

Peter, The point is that âcleaning the imageâ is - not reproducible. A cleanup script may work with todayâs image but may not work with tomorrowâs one. - Itâs not only about cleaning. Imagine you observe that the tables keeping Unicode mappings are wrong. And there is no code to reproduce them. - it does not scale when it starts to become circular. For example, you want to refactor a part of morphic => but you are use morphic while the refactor is performed. We do that all the time, but at the cost of splitting and staging changes that require to be atomic, which adds more complexity to the process. Craig, Yes, Spoon was indeed an inspiration. However, some notes on top of your comments: - Oz/Espell's existing implementation works by introducing two object memories in the same VM, yes. However, the goal was to abstract Espellâs user from such detail and have other implementations such as a remote image one. For example, I wrote a prototype of Espell that manipulated an image loaded in the simulator. The result is that you had a high-level API provided by mirrors to manipulate an image without requiring a VM change. However it was also much slower, and required adapting the VM simulator to initialize it with an empty object memory, and being able to call primitives from outside the simulator while keeping the stack coherent. I dropped this prototype because it required a lot of engineering effort and at the same time Spur advanced really quickly, so I did not want to spend time in code that would soon be deprecated. I could however check if I can recover the code. - Also, I would not say that distributed object memories "are simpler" than keeping co-existing object memories, or not at least without exploring itâs flaws also :). A distributed object memory forces you to include in every peer that may receive code a distribution layer (at least sockets, class builder, compiler or serializer + dependencies). And we wanted to go further. We wanted to be able to easily manipulate an image that does not have those features. - The main point was to use the same infrastructure to build an image in an explicit manner (the bootstrap) as well as in an implicit on-demand manner (tornado). And I believe that the bootstrap is a more transparent process where we can control what happens. Guille > On 21 ene 2016, at 2:34 p.m., Craig Latta <craig(a)netjam.org> wrote: > > > Hi Christophe-- > >>> Another approach is to modify the virtual machine so that it marks >>> methods as they are run, and modify the garbage collector to reclaim >>> methods that haven't been run. Then you can create systems that >>> consist of only what is necessary to run unit tests, effectively >>> imprinting the unit tests. You can interact with the target system >>> from completely independent one over a remote messaging network >>> connection, so your unit tests need not include graphics support, >>> etc.[1] This seems much simpler to me than making a virtual machine >>> that can run multiple object memories, and distributed object >>> memories have several other important uses too. >> >> Guillermo also implemented this kind of approach with Tornado. > > Right, I read that in his PhD thesis. That's why I mentioned my > earlier work, when others claimed there was a precedent being set. > >> But is not so easy... > > Sure, I learned that first-hand when I did it. One important thing > I learned is that it's easier and more accurate to install code as a > side-effect of actually running it live, and not through analysis. It's > also useful to have the option of faulting code in when it's missing > from a running target, or pushing it in from a running source. > > > -C > > [1] http://netjam.org/context > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo on Bountysource Salt

by Guillermo Polito

YES! One-click contribution! :D Just did it. Thanks * 42! > On 21 ene 2016, at 2:26 p.m., Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Jan 21, 2016 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> We have set up a Pharo on the new Salt platform of bountysource: >> >> >> https://salt.bountysource.com/teams/pharo >> >> This is an easy way to support pharo development. If you support >> above a certain threshold, being a Salt supporter includes a >> membership for the Pharo Association. > > I never heard of this before, but its very interesting. I really like > the fee structure - only charging when funds are cashed out**. So if > I might earn some credit by solving some bounties, then I can spend > them on bugs important to me without any transaction friction. > > Thought I'd do a quick background check [2] [3]... > > [1] https://www.bountysource.com/fees > [2] http://www.marketwired.com/press-release/bountysource-raises-11-million-fir… > [3] https://opensource.com/business/13/9/bountysource-CEO-interview > > ** but actually wow, what a business model !!! All those free funds > held... the bank interest probably pays all the operational costs, > plus profit before even they charge that 10% when cashing out. But I > consider that a reasonable trade off if it helps maintain the > credibility. > > cheers -ben >

Jan. 21, 2016

ESUG '16?

by Alexandre Bergel

Hi! Anyone know when ESUGâ16 will take place? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

Hi Christophe-- > > Another approach is to modify the virtual machine so that it marks > > methods as they are run, and modify the garbage collector to reclaim > > methods that haven't been run. Then you can create systems that > > consist of only what is necessary to run unit tests, effectively > > imprinting the unit tests. You can interact with the target system > > from completely independent one over a remote messaging network > > connection, so your unit tests need not include graphics support, > > etc.[1] This seems much simpler to me than making a virtual machine > > that can run multiple object memories, and distributed object > > memories have several other important uses too. > > Guillermo also implemented this kind of approach with Tornado. Right, I read that in his PhD thesis. That's why I mentioned my earlier work, when others claimed there was a precedent being set. > But is not so easy... Sure, I learned that first-hand when I did it. One important thing I learned is that it's easier and more accurate to install code as a side-effect of actually running it live, and not through analysis. It's also useful to have the option of faulting code in when it's missing from a running target, or pushing it in from a running source. -C [1] http://netjam.org/context -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by Ben Coman

On Thu, Jan 21, 2016 at 6:18 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > What about something like this? I'm not very familiar with hashing. Could you explain the benefit of this approach? cheers -ben > > > ^self species hash hashComposer > add: leftFraction; > add: leftOffset; > add: topFraction; > add: topOffset; > add: rightOffset; > add: bottomFraction; > add: bottomOffset > > HashComposer>>#add: anObject > > ^hash := (hash + anObject hash) hashMultiply > > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Wednesday, January 13, 2016 8:34 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash > > On 13-01-16 18:38, David Allouche wrote: >> Why did you use a single expression instead of using a temporary variable? I find it harder to understand. > > I did find it very slightly easier to understand. It is not a strong opinion however. > > The ideomatic smalltalk would be > > ^#(leftFraction leftOffset topFraction topOffset rightFraction rightOffset bottomFraction bottomOffset) > inject: self species hash into: [:hashValue :selector | > (hashValue + self perform: selector) hashMultiply ] > > but that would be slower. > > I would be tempted to add a binary message > > Integer>>+** aNumber > ^(aNumber +self hash) hashMultiply > > (I'd prefer +#*, but that doesn't parse) > > hash > ^self species hash +** > leftFraction +** leftOffset +** > topFraction +** topOffset +** > rightFraction +** rightOffset +** > bottomFraction +** bottomOffset > > > > Stephan > > >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo on Bountysource Salt

by Ben Coman

On Thu, Jan 21, 2016 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We have set up a Pharo on the new Salt platform of bountysource: > > > https://salt.bountysource.com/teams/pharo > > This is an easy way to support pharo development. If you support > above a certain threshold, being a Salt supporter includes a > membership for the Pharo Association. I never heard of this before, but its very interesting. I really like the fee structure - only charging when funds are cashed out**. So if I might earn some credit by solving some bounties, then I can spend them on bugs important to me without any transaction friction. Thought I'd do a quick background check [2] [3]... [1] https://www.bountysource.com/fees [2] http://www.marketwired.com/press-release/bountysource-raises-11-million-fir… [3] https://opensource.com/business/13/9/bountysource-CEO-interview ** but actually wow, what a business model !!! All those free funds held... the bank interest probably pays all the operational costs, plus profit before even they charge that 10% when cashing out. But I consider that a reasonable trade off if it helps maintain the credibility. cheers -ben

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by Thierry Goubier

2016-01-21 13:49 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > Hi Thierry, > > Good question, and yes it is possible. > Itâs good that you raise this point, I will add a class side instance > creation method for this to the GitHub class. > What is nice is that this lowers the barrier for people to try the > bindings out. > I was thing of being able to use it as a Metacello-based code delivery conduit, especially since if I combine that with GitFileTree loading from a zip approach, then it could become an all-in-memory approach (no git installation, no external filetree) > Do note that you are rate-limited to 60 requests _per hour_ if you donât > authenticate. So itâs not much. > I'll keep that in mind if it takes many requests to get the full history. > If you use some functionality which requires authentication (for example > requesting the logged in user), > you will get a GHBadCredentialsError with a message âRequires > authenticationâ. Makes sense to me. > Yes, this would be perfect. Thanks! Thierry > > Skip > > On Jan 21, 2016, at 1:37 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi Skip, > > this is great; I think you have something important there, and I'm just > sad to have far too much to do to contribute... I'd just have a question > then: is it possible to use it in anonymous mode? I would like to explore > if it could be used as a way to get delivery mode (read-only access) to > packages with history/versionning (reusing GitFileTree `build MC metadata > from git log` code). > > Regards, > > Thierry > > 2016-01-21 11:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > >> Hi everyone, >> >> I am announcing a new version for the API bindings to GitHub in Pharo. >> For documentation and information on how to load it, see the new project >> homepage: >> >> https://balletie.github.io/GitHub/ (generated with Pillar. Plug for >> Damien and Cyril) >> >> For a list of changes in this release, follow this link: >> https://github.com/Balletie/GitHub/releases/tag/v0.5 >> >> To load absolutely everything, including the tests and the tool, evaluate: >> >> Metacello new >> baseline: 'GitHub'; >> repository: 'github://Balletie/GitHub:master'; >> load: #(tests tool) >> >> If you have loaded the tool, it can be opened via the world >> menu, under âToolsâ. >> >> Feedback welcome :) >> > > >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by Skip Lentz

Hi Thierry, Good question, and yes it is possible. Itâs good that you raise this point, I will add a class side instance creation method for this to the GitHub class. What is nice is that this lowers the barrier for people to try the bindings out. Do note that you are rate-limited to 60 requests _per hour_ if you donât authenticate. So itâs not much. If you use some functionality which requires authentication (for example requesting the logged in user), you will get a GHBadCredentialsError with a message âRequires authenticationâ. Makes sense to me. Skip > On Jan 21, 2016, at 1:37 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Skip, > > this is great; I think you have something important there, and I'm just sad to have far too much to do to contribute... I'd just have a question then: is it possible to use it in anonymous mode? I would like to explore if it could be used as a way to get delivery mode (read-only access) to packages with history/versionning (reusing GitFileTree `build MC metadata from git log` code). > > Regards, > > Thierry > > 2016-01-21 11:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > Hi everyone, > > I am announcing a new version for the API bindings to GitHub in Pharo. > For documentation and information on how to load it, see the new project homepage: > > https://balletie.github.io/GitHub/ <https://balletie.github.io/GitHub/> (generated with Pillar. Plug for Damien and Cyril) > > For a list of changes in this release, follow this link: https://github.com/Balletie/GitHub/releases/tag/v0.5 <https://github.com/Balletie/GitHub/releases/tag/v0.5> > > To load absolutely everything, including the tests and the tool, evaluate: > > Metacello new > baseline: 'GitHub'; > repository: 'github://Balletie/GitHub:master' <>; > load: #(tests tool) > > If you have loaded the tool, it can be opened via the world menu, under âToolsâ. > > Feedback welcome :) >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by Mariano Martinez Peck

On Thu, Jan 21, 2016 at 9:30 AM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > Hi Mariano, > > 1) By default it lists the repositories of which you are 1. the owner, 2. > a collaborator and 3. an organization member. > So even though you might not contribute to some projects, they are shown > in there because you are member of the organization which owns it. > I opened an issue for allowing filters in the bindings when listing > repositories: https://github.com/Balletie/GitHub/issues/26. > > 2) Thereâs an open issue in the repository for implementing pagination. > See here: https://github.com/Balletie/GitHub/issues/1. > Right now, not all repositories are shown because another request should > be made to the API for the next âpageâ of results, > like in the web UI. > > The same holds for commits by the way: not all commits in the log of the > tool are shown because pagination has to be implemented. > > Would be cool to use something like FastTable or FastTree to load new > pages on the fly. > > Hope I answered your questions :) > Hi Skip, Yes, thanks, you have answered both questions :) Damn, I want to browse my OSSubprocess repo ahahhaha. Keep the work going! > Skip > > On Jan 21, 2016, at 12:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi Skip, > > Very cool! Thanks! > BTW, I am trying the UI tool and I found 2 problems: > > 1) It lists projects that I have nothing to do with them > 2) It does not list some of MY projects > > Am I doing something wrong? > > On Thu, Jan 21, 2016 at 8:18 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> As usual I can only agree with Sven, this is documentation is for >> seminars how to write proper documentation. Great work, will give it a try >> :) >> >> On Thu, Jan 21, 2016 at 1:03 PM Skip Lentz <skip.lentz(a)inria.fr> wrote: >> >>> Thanks for the kind words :). >>> If you feel like thereâs some doc missing I will write something for it, >>> just tell me. >>> >>> > On Jan 21, 2016, at 11:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> > >>> > Wow, great work, beautiful documentation. >>> > >>> > An excellent example of the right way to do a Pharo add-on library ! >>> > >>> > Thank you. >>> > >>> >> On 21 Jan 2016, at 11:30, Skip Lentz <skip.lentz(a)inria.fr> wrote: >>> >> >>> >> Hi everyone, >>> >> >>> >> I am announcing a new version for the API bindings to GitHub in Pharo. >>> >> For documentation and information on how to load it, see the new >>> project homepage: >>> >> >>> >> https://balletie.github.io/GitHub/ (generated with Pillar. Plug for >>> Damien and Cyril) >>> >> >>> >> For a list of changes in this release, follow this link: >>> https://github.com/Balletie/GitHub/releases/tag/v0.5 >>> >> >>> >> To load absolutely everything, including the tests and the tool, >>> evaluate: >>> >> >>> >> Metacello new >>> >> baseline: 'GitHub'; >>> >> repository: 'github://Balletie/GitHub:master'; >>> >> load: #(tests tool) >>> >> >>> >> If you have loaded the tool, it can be opened via the world menu, >>> under âToolsâ. >>> >> >>> >> Feedback welcome :) >>> > >>> > >>> >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Jan. 21, 2016

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

by Mariano Martinez Peck

> > > Let's say we define a subclass of SharedPool called FFISharedPool. > FFISharedPool 's job is to manage autogenerating a C file, compiling it for > the platform, and organizing parsing the relevant output. Let's say we use > a convention like class-side pragmas to define include files, and compiler > flags. The VM provides two crucial pieces of information: > > 1. the platform name > 2. the word size > > One can't run a Mac OS VM on Linux, and one can't run a 64-bit VM on a > 32-bit operating system. So taking this information from the VM accurately > tells the current system what ABI (application binary interface) to use, > and that's what's important in generating the right constants. > > So we use these two pieces of information to index the method pragmas that > tell us what specific files to include. > > Let's imagine we subclass FFISharedPool to add a shared pool for constants > for an SQL database. We might have a class declaration like > > FFISharedPool subclass: #MYSQLInterface > instanceVariableNames: '' > classVariableNames: 'MYSQL_DEFAULT_AUTH MYSQL_ENABLE_CLEARTEXT_PLUGIN > MYSQL_INIT_COMMAND MYSQL_OPT_BIND MYSQL_OPT_CAN_HANDLE_EXPIRED_PASSWORDS > MYSQL_OPT_COMPRESS > MYSQL_OPT_CONNECT_ATTR_DELETE MYSQL_OPT_CONNECT_ATTR_RESET' > poolDictionaries: '' > category: 'MYSQLInterface-Pools' > > The job of FFISharedPool is to compute the right values for the class > variables on every platform we want to deploy the MYSQL interface on. > > So we need to know the relevant include files and C flags for each > platform/word-size combination. A few of them might look like > > > MYSQLInterface class methods for platform information > mac32 > "I describe the include files and C flags to use when developing a > 32-bit MYSQL FFI interface on Mac OS X" > <platformName: 'Mac OS' wordSize: 4> > <cFlags: #('-m32') includeFiles: #('/opt/mysql/include32')> > ^self "all the info is in the pragmas" > > mac64 > "I describe the include files and C flags to use when developing a > 64-bit MYSQL FFI interface on Mac OS X" > <platformName: 'Mac OS' wordSize: 8> > <cFlags: #('-m64') includeFiles: #('/opt/mysql/include64')> > > The above might cause FFISharedPool to autogenerate files called > MYSQLInterface.mac32.c & MYSQLInterface.mac64.c. And these, when run, > might output ston notation to MYSQLInterface.mac32.ston & > MYSQLInterface.mac64.ston (or maybe to stdout which has to be redirected to > MYSQLInterface.mac32.ston; whatever). > > Now, you might use pragmas, or you might answer a Dictionary instance. > What ever style pleases you and seems convenient and readable. But these > methods define the necessary metadata (C flags, include paths, and ...?) > for FFISharedPool to autogenerate the C program that, when compiled with > the supplied C flags and run on the current platform, outputs the values > for the constants the shared pool wants to define. > > > You can get fancy and have FFISharedPool autogenerate the C programs > whenever one adds or removes a constant name. Or you can require the > programmer run something, e.g. MYSQLInterface generateInterfaces. It's > really nice if FFISharedPool submits the file to the C compiler > automatically, but this can only work for e.g. 32 & 64 bit versions on a > single platform. You have to compile the autogenerated program on the > relevant platform, with the necessary libraries and include files installed. > > You could imagine a set of servers for different platforms so one could > submit the autogenerated program for compilation and execution on each > platform. That's a facility I'd make it easy to implement. I could > imagine that a programmer whose company develops an FFI interface and > deploys it on a number of platforms would love to be able to automate > compiling and running the relevant autogenerated code on a set of servers. > I could imagine the Pharo community providing a set of servers upon which > lots of software is installed for precisely this purpose. That means that > people could develop FFI interfaces without even having to have the C > compiler installed on their platform. > > You could also add a C parser to FFISharedPool that parses the > post-preprocessed code and extracts function declarations. But the > important thing is autogenerating the C program so that it generates easily > parsable output containing the values for the constants. You can extend > the system in interesting ways once you ave this core functionality > implemented. > > So once the program is autogenerated and compiled for the current > platform, it is run and its output collected in a file whose name can be > recognised by FFISharedPool. > > Hi Eliot, OK, I have currently a very first prototype where I can autogenerate the C file from a FFISharedPool subclass, compile it, run it and get the ston file output. Please, read below. > > Now the class side of FFISharedPool might be declared as > > FFIShardPool class > instanceVariableNames: 'platformName wordSize' > > and on start-up FFIShardPool could examine its subclasses, and for each > whose platformName & wordSize do not match the current platform, search for > all the matching FOOInterface.plat.ston files, parse them and update the > subclasses' variables, and update that pool's platformName & wordSize. It > could emit a warning on the Transcript or stdout (headful vs headless) > indicating which subclasses it couldn't find the relevant > FOOInterface.plat.ston files for. > > But the end result is that > > a) providing the system is deployed with FOOInterface.plat.ston files for > each interface and platform used, a cross-platform application can be > deployed *that does not require a C compiler*. > b) providing that a system's FOOInterface files have been initialized on > the intended platform, a platform-specific application can be deployed for > a single platform *without needing the ston files*. > > I was thinking the following. Having to distribute the FFI wrapper (take as an example the myself wrapper) with the .ston files is a bit of a pain with MC. So I was thinking...what if FFISharedPool has all the machinery to allow FFI lib wrapper developer (the developer of the MySQL wrapper), to autogenerate the ston file as we said, BUT, the ston file is stored as methods in the MYSQLInterface subclass? Probably under a "autogenerated" protocol. That way, it's very easy to distribute and in addition, at system startup it's easier to "search" for the "ston files". The only drawback is the for very large ston files MC will suffer a bit.. but.. Thoughts? > Does this make more sense now? > > c) at startup the image checks its current platform. If the platform is >>> the same that it was saved on, no action is taken. But if the platform as >>> changed then the relevant ston file is selected, parsed, and the values for >>> the variables in the shared pool updated to reflect the values of the >>> current platform. >>> >>> So the C compiler is only needed when developing the interface, not when >>> deploying it. >>> >>> >> OK >> >> >>> >>>> Then Nicolas made a point that if we plan to manage all that complexity >>>> at the image level it may become a hell too. >>>> >>>> So.... what if we take a simpler (probably not better) approach and we >>>> consider the "c program that exports constants and sizes" a VM Plugin? >>>> Let's say we have a UnixPreprocessorPlugin (that would work for OSX, Linux >>>> and other's Unix I imagine for the time being) which provides a function >>>> (that is exported) which answers an array of arrays. For each constant, we >>>> include the name of the constant, the value, and the sizeof(). Then from >>>> image side, we simply do one FFI call, we get the large array and we adapt >>>> it to a SharedPool or whatever kind of object representing that info. >>>> >>> >>> >>> >>> This is what I suggestred in teh first place. That what is >>> autogenerated is a shared object (be it a plgin or a dll doesn't matter, it >>> is machine code generated by a C compiler form an autogenerated C program >>> compiled with the platform's C compiler) that can be loaded at run-time and >>> interrogated to fetch the values of a set of variables >>> >> >> OK, got it. But still, it would be easier if the "platform" in this case >> is the "machine where we build the VM we will then distribute" right? i >> mean, I would like to put this in the CI jobs that automatically builds the >> VM, and not myself building for each platform. >> > > NO! For example, why would a company that has some proprietary arithmetic > package implemented in its secret labs in C or C++ and accessed through the > FFI want to have that code on the Pharo community's build servers? > > >> >> *I mean, my main doubt is if this job of autogenerating C code, compile >> it, run it, export text file, and distribute text file with the VM, could >> be done as part of the VM building. * >> > > For fuck's sake. Developing an FFI is not something one does when > building a VM. It is something one does wen using the system. f you want > to do this you *use a plugin*. The FFI is a different beast. It is to > allow programers to interface to external librarys that are *independent > from teh VM*. > > I'm not going to answer this one again. OK? > > > >> >> >> >>> . But I think that the textual notation suggested above is simpler. >>> The test files are easier to distribute and change. Shared objects and >>> plugins have a habit of going stale, and there needs to be metadata in >>> there to describe the set of constants etc, which is tricky to generate and >>> parse because it is binary (pointer sizes, etc, etc). Instead a simple >>> textual format should be much more robust. One could even edit by hand to >>> add new constants. It would be easy to make the textual file a versioned >>> file. Etc, etc. >>> >>> >> >> OK. Got it. And do you think using X Macros for the autogenerated C (from >> the SharedPool) is a good idea? >> And then I simply write a text file out of it. >> >> >> >>> >>>> I know that different users will need different constants. But let's >>>> say the infrastructure (plugin etc) is already done. And let's say I am a >>>> user that I want to build something with FFI and I need some constants that >>>> I see are not defined. Then I can simply add the ones I need in the plugin, >>>> and next VM release will have those. If Cog gets moved to Github, then this >>>> is even easier. Everybody can do a PR with the constants he needs. And in >>>> fact, if we have the infrastructure in place, I think that we each of us >>>> spend half an hour, we may have almost everything we need. >>>> >>>> For example, I can add myself all those for signals (to use kill() from >>>> FFI), all those from fcntl (to make none blocking pipes), all those from >>>> wait()/waitpid() family (so that I can do a waitpid() with WNOHANG), etc >>>> etc etc. >>>> >>>> I know it's not the best approach but it's something that could be done >>>> very easily and would allow A LOT of stuff to be moved to FFI just because >>>> we have no access to preprocess constants or sizeof() (to know how to >>>> allocate). I also know this won't cover macros and other stuff. But still. >>>> >>>> If you think this is a good idea, I can spend the time to do it. >>>> >>>> Cheers, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, May 10, 2012 at 10:09 AM, Nick Ager <nick.ager(a)gmail.com> >>>> wrote: >>>> >>>>> <snip> >>>>> Well, like opendbx, maybe because opengl has quite standard >>>>> interface... >>>>> </snip> >>>>> >>>>> and >>>>> >>>>> <snip> >>>>> It's not that it's not doable, it's that we gonna reinvent gaz plant >>>>> and it gonna be so boring... >>>>> I'd like to see a proof of concept, even if we restrict to libc, libm, >>>>> kernel.dll, msvcrt.dll ... >>>>> </snip> >>>>> >>>>> <snip> >>>>> Is the unix style select() >>>>> ubiquitous or should I use WaitForMultipleObject() on Windows? Are >>>>> specification of read/write streams implementation machine independant >>>>> (bsd/sysv/others...) >>>>> </snip> >>>>> >>>>> Perhaps *a* way forward is to try to find existing projects which have >>>>> already created cross-platform abstractions for platform specific >>>>> functionality. Then we can use FFI to access that interface in a similar >>>>> way to OpenGL and OpenDBX. For example NodeJs works across unixes - perhaps >>>>> they have a useful cross-platform abstraction, boost has abstractions of >>>>> IPC etc >>>>> >>>>> Nick >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -- Mariano http://marianopeck.wordpress.com

Jan. 21, 2016