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 > >
