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