Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis <kilon.al...@gmail.com> a écrit : > > About your last part on platforms, I will be providing a way to inline C code > so one can you use C macros to detect the platform and generate code > accordingly. Or this could happen via a pragma too, it should not be an > issue. This also a reason why I previously talked about an "in place" > annotation and why specially named variables was my first choice instead of > pragmas. I am also not a big fan of pragmas syntax which for me at least > deviates from standard smalltalk syntax style. But as I said I am not against > their usage at all. > > Generally because this is no an afternoon project obviously, I will be > relying on C code inling at first for special corner cases and then I will > implement them as annotations the more the project moves forward.
Having a way to do the same as what asm inline is in gcc, but for hand-written C inside your Smalltalk derivative is cool: remap variable names, etc, so that your C generator handles all the interface between the inlined C and the surrounding Smalltalk. Same if you also add platform-dependent customisation for generation. Thierry > On Wed, Oct 17, 2018 at 1:30 PM Dimitris Chloupis <kilon.al...@gmail.com> > wrote: >> >> Hello Allistair >> >> I have used Slang only once and it was generating code that was indeed >> readbale but my aim is for more finer control over the output. Lets say I >> want import a specific C header file or I want a string to map to custom C >> type I created etc. So yes Slang is by no mean a bad tool at all its just is >> not designed with making source output that is undetectable as autogenerated >> by a human. But I will have to give it a more serious try because it may be >> closer than I initially thought. >> >> I am not against the usage of pragmas, and indeed are an excellent way to >> annotate stuff , my only concern is when I may want to annotate in place for >> some weird reason , but that may be doable with pragmas as well too. >> >> Smalltalk code that is 100% smalltalk should be able to execute , you >> mention however the execution of external C functions , problem is that in >> my case that code does not live in DLLs but in an executable so no I am not >> amaing to that level of execution. >> >> Also I have an easier solution for this too, when I made the CPPBridge, >> which is a Pharo library that allows the usage of C++ libraries from Pharo, >> I used a shared memory bridge to communicate back to Pharo giving the >> ability of both function calls and callbacks. If I really want to capture >> execution I can do it like this which is the exact opposite of what you do, >> instead of the VM capturing the executable it will be the executable >> capturing the VM if that makes any sense. This makes things far easier. As a >> matter of fact not only my CPPBridge does this it also allows to extend the >> pharo image file because it uses memory mapped files for the shared memory >> which like pharo image files are memory dumps. So there is a lot potential >> in that department. >> >> However my main goal is to use Smalltalk code execution to make sure the >> prototype works on a basic level, there will be a C cide in this project >> obviously which will act like a runtime that will provide live coding >> features. This is also a library I made in C that does this through the >> usage of DLLs that rebuilds and reloads dynamically. >> >> So I dont really need the VM to execute my code to check that is working >> cause the C compiler and the live coding runtime can handle this. I could >> even hook in the Pharo debugger, I have done this with my Atlas library that >> allows to use Python library from Pharo by sending the python error back to >> Pharo debugger where it triggers an error and the debugger pops to allow you >> to do your usual live coding magic and basically resends the code back to >> python. Because of my C livecoding library I can do this with C too. My only >> concern is how the C/C++ compiler reports errors because obviously it known >> that it kinda sucks on this. But hey I cannot make C better :D >> >> Generally speaking the tools I am making are not designed for general >> consuption but designed to solve my own problems. Of course I like to share >> them because there is always the chance for someone to find them useful as >> it has happened with Atlas for example. Plus as happened with Atlas one can >> take my code and adjust it to his or her personal needs. >> >> On Wed, Oct 17, 2018 at 1:04 PM Alistair Grant <akgrant0...@gmail.com> wrote: >>> >>> Hi Dimitris, >>> >>> As someone currently learning to use Slang (i.e. not an expert), I've >>> added my 2c below... >>> >>> On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis <kilon.al...@gmail.com> >>> wrote: >>> > >>> > Thierry you have done it !!! you just gave a very easy solution to my >>> > problems. >>> > >>> > Yeap Slang is quite close to what I am thinking, unfortunately Clement >>> > told me to stay away from it because the code is ugly and specially used >>> > for VM only. If I remember also correctly it does not generate readable C >>> > code either. But the idea as a concept is very close to what I imagine. >>> >>> I've found the C code produced to be quite readable, but that is >>> probably influenced by the fact that I have read the slang first. >>> >>> >>> > As a matter of fact you mentioning Slang made I have an epiphany that I >>> > dont have to create a new syntax at all, instead I could use specific >>> > variables or methods to provide type annotation. Thus like Slang I can >>> > use regular Smalltalk code that avoids changing types but without the >>> > need for type inference (although I am not excluding this either). >>> > >>> > So yes I am definetly want to move to the direction that Slang goes so I >>> > can fully utilise the Pharo IDE and minise code that I have to write. >>> > >>> > So basically I am thinking write code as you always write in Pharo and >>> > either >>> > a) Have special dictionary variables in each method that provide static >>> > type annotations for the arguments of the methods, its return type and >>> > local variables >>> >>> Slang uses method pragmas to define the variables types. This seems >>> to work quite well. >>> >>> >>> > b) Have special methods that provide such dictionaries seperately. >>> > >>> > Or probably both. This way I can write 100% Smalltalk code and use a very >>> > small compiler to read those dictionary variables for the type of the >>> > variables and functions/structs (essentially a class will be output for a >>> > C struct with pointers to functions for methods and variables for >>> > instance variables). Why invent a whole new language when everything I >>> > need already Pharo provides ? >>> > I could also use special variable dictionaries for all sort of things >>> > like generation of header files, generation of CMake files for automatic >>> > building. >>> > >>> > Also I like to use the way UFFI is doing C function signatures by using >>> > symbol arrays. >>> > >>> > So thank you all for inspiration it looks like all I need is Pharo AST >>> > methods (which I can from the AST packages) and SmaCC. >>> > So yeap looks like Magnatar will be a new Slang afterall, I will keep you >>> > posted. >>> > >>> > Also this also opens the possibility of autowrapping the generated c code >>> > back to Pharo through UFFI, so one can use C code as if its Pharo code. I >>> > can leverage the TalkFFI project that does this already. Seems all the >>> > pieces have fallen in their place. >>> > >>> > Keep the suggestions and advice coming, you guys are inspirational :D >>> >>> Do you intend that the Smalltalk code can be executed? This will >>> likely increase the complexity quite a bit. In the VM simulation we >>> end up creating a XSimulation subclass that provides the framework for >>> executing the smalltalk code, e.g simulating functions that are only >>> in C. >>> >>> There is also the problem of platform differences. Slang doesn't >>> really handle them well (pragmas can be used to indicated that methods >>> should only be compiled on certain platforms, and #ifdef type code can >>> be used, but it isn't enough). It would be nice to have a class that >>> provides cross platform functionality, and then platform specific >>> classes as required. >>> >>> HTH, >>> Alistair >>>
