Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM. Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is. 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result. Phil
Regards,
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings! -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
WOW this CCodeGenerator is great , I have downloaded it and tried the example and it generated the 'generated.c" file . Awesome !!!! thank you all Ok how about this visitor thing ? any links to it , no idea what that is and how to use it in pharo. Is it a way to code like continuations ? About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;) So it looks like I will be sticking with Pharo after all :D On Mon, Sep 15, 2014 at 2:28 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project
related
with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings!
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Sep 15, 2014 at 1:39 PM, kilon alios <kilon.alios@gmail.com> wrote:
WOW this CCodeGenerator is great , I have downloaded it and tried the example and it generated the 'generated.c" file . Awesome !!!! thank you all
Ah ah, happy to have made you day. Yes, Slang is the awesome thing for integrating things. You can debug in Pharo, and then compile to C. How cool is that?
Ok how about this visitor thing ? any links to it , no idea what that is and how to use it in pharo. Is it a way to code like continuations ?
Check the FileSystem-Core-Implementation package. Look at the FileSystemGuide and how ti works, including the FileSystemVisitor and its Collect and Select visitors down there. It is interesting material to get to terms with the Visitor/Guide thing. I reused/cloned a ton of this code for my current project where I do have to navigate network equipement structures and generate probes along the way. A tad mind twisting at the beginning but very useful once you get it. Once you have the guide, you can visit all the way you want. Like here, I generate HTML tree controls, D3 graphics, SNMP probes etc. There are samples also for AST, but this is a tad too much for me at the moment.
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
So it looks like I will be sticking with Pharo after all :D
Ah, swallowing the red pill is nearing. Enjoy, Phil
On Mon, Sep 15, 2014 at 2:28 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project
related
with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings!
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Please pay careful attention: this is one of those Pharo libraries that might not meet industry standard. But, it is so small and elegant that even an amateur can have a say with it :). The interesting thing about the red pill is that the reality that comes after taking the pill is less clean than the one from before the pill, But, it is richer! You can still choose the world you want to live in :) Doru On Mon, Sep 15, 2014 at 2:02 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 1:39 PM, kilon alios <kilon.alios@gmail.com> wrote:
WOW this CCodeGenerator is great , I have downloaded it and tried the example and it generated the 'generated.c" file . Awesome !!!! thank you all
Ah ah, happy to have made you day. Yes, Slang is the awesome thing for integrating things. You can debug in Pharo, and then compile to C. How cool is that?
Ok how about this visitor thing ? any links to it , no idea what that is and how to use it in pharo. Is it a way to code like continuations ?
Check the FileSystem-Core-Implementation package.
Look at the FileSystemGuide and how ti works, including the FileSystemVisitor and its Collect and Select visitors down there.
It is interesting material to get to terms with the Visitor/Guide thing.
I reused/cloned a ton of this code for my current project where I do have to navigate network equipement structures and generate probes along the way.
A tad mind twisting at the beginning but very useful once you get it.
Once you have the guide, you can visit all the way you want. Like here, I generate HTML tree controls, D3 graphics, SNMP probes etc.
There are samples also for AST, but this is a tad too much for me at the moment.
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
So it looks like I will be sticking with Pharo after all :D
Ah, swallowing the red pill is nearing.
Enjoy, Phil
On Mon, Sep 15, 2014 at 2:28 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang.
Is
the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings!
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
-- www.tudorgirba.com "Every thing has its own flow"
On Mon, Sep 15, 2014 at 2:11 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Please pay careful attention: this is one of those Pharo libraries that might not meet industry standard. But, it is so small and elegant that even an amateur can have a say with it :).
The interesting thing about the red pill is that the reality that comes after taking the pill is less clean than the one from before the pill, But, it is richer!
Exactly!!!!
You can still choose the world you want to live in :)
Get me my box of red pills back :-) Phil
Doru
On Mon, Sep 15, 2014 at 2:02 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 1:39 PM, kilon alios <kilon.alios@gmail.com> wrote:
WOW this CCodeGenerator is great , I have downloaded it and tried the example and it generated the 'generated.c" file . Awesome !!!! thank you all
Ah ah, happy to have made you day. Yes, Slang is the awesome thing for integrating things. You can debug in Pharo, and then compile to C. How cool is that?
Ok how about this visitor thing ? any links to it , no idea what that is and how to use it in pharo. Is it a way to code like continuations ?
Check the FileSystem-Core-Implementation package.
Look at the FileSystemGuide and how ti works, including the FileSystemVisitor and its Collect and Select visitors down there.
It is interesting material to get to terms with the Visitor/Guide thing.
I reused/cloned a ton of this code for my current project where I do have to navigate network equipement structures and generate probes along the way.
A tad mind twisting at the beginning but very useful once you get it.
Once you have the guide, you can visit all the way you want. Like here, I generate HTML tree controls, D3 graphics, SNMP probes etc.
There are samples also for AST, but this is a tad too much for me at the moment.
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
So it looks like I will be sticking with Pharo after all :D
Ah, swallowing the red pill is nearing.
Enjoy, Phil
On Mon, Sep 15, 2014 at 2:28 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be < phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang.
Is
the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings!
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
-- www.tudorgirba.com
"Every thing has its own flow"
thanks I am looking at it is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern Sure if I can stay in pharo while coding in C/C++ then why not ? Even if I still have to do work outside pharo. The problem is beginners like me do not realize the potential of their tools because of lack of experience, so its more likely I give up than you who you are a much more experienced pharoer than me. Afterall Neo needed Morpheas to show him that he is the chosen one ;) I invested a year of my life in pharo and I would love to invest a lot more and benefit back the community. This way everyone is a winner. Also Thierry mentioned Ring which led me to this http://rmod.lille.inria.fr/archives/papers/Uqui11a-RingJournalPaper-CSSJourn... from the looks of it is a source code analyzer ? much to study , a lot of potential and another happy Pharo user :) On Mon, Sep 15, 2014 at 3:02 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 1:39 PM, kilon alios <kilon.alios@gmail.com> wrote:
WOW this CCodeGenerator is great , I have downloaded it and tried the example and it generated the 'generated.c" file . Awesome !!!! thank you all
Ah ah, happy to have made you day. Yes, Slang is the awesome thing for integrating things. You can debug in Pharo, and then compile to C. How cool is that?
Ok how about this visitor thing ? any links to it , no idea what that is and how to use it in pharo. Is it a way to code like continuations ?
Check the FileSystem-Core-Implementation package.
Look at the FileSystemGuide and how ti works, including the FileSystemVisitor and its Collect and Select visitors down there.
It is interesting material to get to terms with the Visitor/Guide thing.
I reused/cloned a ton of this code for my current project where I do have to navigate network equipement structures and generate probes along the way.
A tad mind twisting at the beginning but very useful once you get it.
Once you have the guide, you can visit all the way you want. Like here, I generate HTML tree controls, D3 graphics, SNMP probes etc.
There are samples also for AST, but this is a tad too much for me at the moment.
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
So it looks like I will be sticking with Pharo after all :D
Ah, swallowing the red pill is nearing.
Enjoy, Phil
On Mon, Sep 15, 2014 at 2:28 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 12:31 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Mon, Sep 15, 2014 at 11:33 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo <santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang.
Is
the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
Both are subset of Smalltalk. This is best path to follow I guess: define your own DSL for your needs and implement a visitor to do code generation. We have done that for epidemiological modeling.
Or combine both: visitor which uses CCodeGenerator for emitting the result.
Yes, interesting idea, instead of generating strings!
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On Mon, Sep 15, 2014 at 2:21 PM, kilon alios <kilon.alios@gmail.com> wrote:
is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern
yes, this is what they are talking about! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
Le 15/09/2014 14:21, kilon alios a écrit :
thanks I am looking at it
is this relevant to pharo ? --> http://en.wikipedia.org/wiki/Visitor_pattern
Hi, Of course, the only difference between what you will find in java,dotNet,c++ examples and Smalltalk is that the latter does not support method signature because of it's typeless feature and you will have to define different methods. The smalltalk equivalent of (java code) void visit(Wheel wheel); void visit(Engine engine); void visit(Body body); void visit(Car car); would be the following methods: visitWheel: aWhell visitEngine: anEngine visitBody: aBody visitCar: aCar A small disadvantage, but everything has a price ... :) If you are interested in object patterns, you should buy the GOF book http://en.wikipedia.org/wiki/Design_Patterns It's a must have and it's smalltalk companion too http://www.amazon.fr/The-Design-Patterns-Smalltalk-Companion/dp/0201184621 see chapters here: http://stephane.ducasse.free.fr/FreeBooks/SmalltalkDesignPatternCompanion/ Regards, Alain
2014-09-15 13:39 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
LLVM is an industrial-class open source project included in, I believe, all GPU drivers (for compilation of CUDA and OpenCL code). It is also one of the best documented low-level compilation toolkits with performance to match the other open source compiler (gcc). LLVM-IR is fairly well documented.
So it looks like I will be sticking with Pharo after all :D
:) Thierry
Yeah I think I mixed it up with something else, anyway I found a very nice tutorial how to make a working compiler with LLVM http://www.ibm.com/developerworks/library/os-createcompilerllvm1/index.html http://www.ibm.com/developerworks/library/os-createcompilerllvm2/ looks like nativeboost on steroids !!!! On Mon, Sep 15, 2014 at 3:26 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-15 13:39 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
About LLVM sound very cool and I was googling about that few hours ago but from what I have read is a very undocumented part of LLVM so that maybe easier said than done. Looks like Pharo is not the only project having issues with documentation ;)
LLVM is an industrial-class open source project included in, I believe, all GPU drivers (for compilation of CUDA and OpenCL code).
It is also one of the best documented low-level compilation toolkits with performance to match the other open source compiler (gcc). LLVM-IR is fairly well documented.
So it looks like I will be sticking with Pharo after all :D
:)
Thierry
Slang has been externalized by Pavel. So, Smalltalk to C works. Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working. Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot. PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified). Phil On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Hi Phil, thanks for the update on Slang to C. Allways significant to have that. Two open questions: - would a slang to x86 asm via NativeBoost be doable / a nice target? - would targetting LLVM-IR be of interest? Thierry 2014-09-15 12:29 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
On Mon, Sep 15, 2014 at 1:28 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
I have to admit that I am happy to have Slang to C and it gets out of my competence from there :-) Now, Slang to asm, that's quite a chasm to cross. If what asm does is doing syscalls, well, I don't see the added value right away as NB Assembler would do that already no? Now, I am on Linux for about all of my Pharo code, so, C is nice enough.
- would targetting LLVM-IR be of interest?
Oh, that would be interesting. In order to get the IR interpreter and running things all over. Now, this should be extended to the whole VM then. But not sure we want that before we get 64 bits... Ah, I should have taken the research career :-) Phil
Thierry
2014-09-15 12:29 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
2014-09-15 13:56 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Sep 15, 2014 at 1:28 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
I have to admit that I am happy to have Slang to C and it gets out of my competence from there :-)
Yes, I believe it is very cool as it is. You need a full C toolchain around to make it work.
Now, Slang to asm, that's quite a chasm to cross. If what asm does is doing syscalls, well, I don't see the added value right away as NB Assembler would do that already no?
Hum, I would more like SSE and AVX code done this way: matrix multiplications, bitmap processing, heavily used code, SciSmalltalk stuff on very large datasets. To see NB only used as a way to write syscalls :(:(:(
Now, I am on Linux for about all of my Pharo code, so, C is nice enough.
- would targetting LLVM-IR be of interest?
Oh, that would be interesting. In order to get the IR interpreter and running things all over. Now, this should be extended to the whole VM then. But not sure we want that before we get 64 bits...
OpenCL, SPIR code generation and link to Cog. The ability to generate better code than when targetting C.
Ah, I should have taken the research career :-)
Hum, you know that researchers are allways on the lookout for SMEs to collaborate on projects :-) Thierry
On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-15 13:56 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Sep 15, 2014 at 1:28 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
I have to admit that I am happy to have Slang to C and it gets out of my competence from there :-)
Yes, I believe it is very cool as it is. You need a full C toolchain around to make it work.
Now, Slang to asm, that's quite a chasm to cross. If what asm does is doing syscalls, well, I don't see the added value right away as NB Assembler would do that already no?
Hum, I would more like SSE and AVX code done this way: matrix multiplications, bitmap processing, heavily used code, SciSmalltalk stuff on very large datasets.
Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain goes C code which gets compiled through some "black-hole toolchain" in the NVidia SDK with host and GPU blocks. That's too much to handle for my tastes, so the best is for me to have an engine (or for a better metaphor) and using Pharo to drive/steer/harness it.
To see NB only used as a way to write syscalls :(:(:(
You opened my eyes with the previous comment. Thx.
Now, I am on Linux for about all of my Pharo code, so, C is nice enough.
- would targetting LLVM-IR be of interest?
Oh, that would be interesting. In order to get the IR interpreter and running things all over. Now, this should be extended to the whole VM then. But not sure we want that before we get 64 bits...
OpenCL, SPIR code generation and link to Cog.
Indeed! CUDA =-)
The ability to generate better code than when targetting C.
True too. But aren't those compilers smart enough already? With current CPUs, well, it takes a strong man to do better things than the compiler it seems. Or am I mistaken?
Ah, I should have taken the research career :-)
Hum, you know that researchers are allways on the lookout for SMEs to collaborate on projects :-)
Duly noted :-) Feel free to tickle me :-)
Thierry
Phil
2014-09-15 15:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hum, I would more like SSE and AVX code done this way: matrix multiplications, bitmap processing, heavily used code, SciSmalltalk stuff on very large datasets.
Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain goes C code which gets compiled through some "black-hole toolchain" in the NVidia SDK with host and GPU blocks.
You may be interested to contact Bernard Pottier. His NetGen toolkit does CUDA code generation. NetGen is VisualWorks only for the moment, even if I know someone who would like to have it in Pharo (well, two guys at least).
That's too much to handle for my tastes, so the best is for me to have an engine (or for a better metaphor) and using Pharo to drive/steer/harness it.
Yes. I intended to do things around that, but didn't found the time.
Indeed! CUDA =-)
OpenCL, SPIR code generation and link to Cog.
The ability to generate better code than when targetting C.
True too. But aren't those compilers smart enough already? With current CPUs, well, it takes a strong man to do better things than the compiler it seems. Or am I mistaken?
You are. A lot may be done if your input language is not C, but this is not allways relevant to the Pharo situation. I should know a lot more about LLVM-IR generation in a few months time. I'll say if I see easy gains when doing Smalltalk code.
Ah, I should have taken the research career :-)
Hum, you know that researchers are allways on the lookout for SMEs to collaborate on projects :-)
Duly noted :-) Feel free to tickle me :-)
Noted :) Thierry
Thanks Damien :) so I want to further explore Slang , that means downloading the VMMaker , I am following the post of Mariano here https://marianopeck.wordpress.com/tag/vmmaker/ and install VMMaker like this 1 2 3 4 5 6 Deprecation raiseWarning: false. Gofer new squeaksource:'MetacelloRepository'; package:'ConfigurationOfVMMaker'; load. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') load. Question does CCodeGenerator contain the entire Slang ? I am downloading VMMaker to find how Slang plays with pointers and manual memory management so if you have any pointer (pun not intended) I will greatly appreciate it. On Mon, Sep 15, 2014 at 4:25 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-15 15:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hum, I would more like SSE and AVX code done this way: matrix multiplications, bitmap processing, heavily used code, SciSmalltalk stuff on very large datasets.
Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain goes C code which gets compiled through some "black-hole toolchain" in the NVidia SDK with host and GPU blocks.
You may be interested to contact Bernard Pottier. His NetGen toolkit does CUDA code generation. NetGen is VisualWorks only for the moment, even if I know someone who would like to have it in Pharo (well, two guys at least).
That's too much to handle for my tastes, so the best is for me to have an engine (or for a better metaphor) and using Pharo to drive/steer/harness it.
Yes. I intended to do things around that, but didn't found the time.
Indeed! CUDA =-)
OpenCL, SPIR code generation and link to Cog.
The ability to generate better code than when targetting C.
True too. But aren't those compilers smart enough already? With current CPUs, well, it takes a strong man to do better things than the compiler it seems. Or am I mistaken?
You are. A lot may be done if your input language is not C, but this is not allways relevant to the Pharo situation.
I should know a lot more about LLVM-IR generation in a few months time. I'll say if I see easy gains when doing Smalltalk code.
Ah, I should have taken the research career :-)
Hum, you know that researchers are allways on the lookout for SMEs to collaborate on projects :-)
Duly noted :-) Feel free to tickle me :-)
Noted :)
Thierry
hmm no that does not work I am getting this error (Cannot Resolve FreeType) , any solutions ? I also tried loading latest version same error MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: in Block: linearLoadPackageSpec: packageSpec gofer: gofer... MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer: MetacelloPackageSpec>>loadUsing:gofer: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [ :pkg | pkg loadUsing: self gofer: gofer ] OrderedCollection>>do: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: in Block: [ super linearLoadPackageSpecs: packageSpecs repos...etc... BlockClosure>>ensure: MetacelloLoaderPolicy>>pushLoadDirective:during: MetacelloLoaderPolicy>>pushLinearLoadDirectivesDuring:for: MetacelloFetchingMCSpecLoader>>linearLoadPackageSpecs:repositories: MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>load MetacelloMCVersionSpecLoader>>load MetacelloMCVersion>>executeLoadFromArray: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ :dict | ^ self executeLoadFromArray: anArray ] MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ] BlockClosure>>on:do: MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... BlockClosure>>ensure: MetacelloMCVersion>>fetchRequiredFromArray: in Block: [ ... MetacelloPharo30Platform(MetacelloPlatform)>>do:displaying: MetacelloMCVersion>>fetchRequiredFromArray: MetacelloMCVersion>>doLoadRequiredFromArray: in Block: [ ... BlockClosure>>ensure: MetacelloMCVersion>>doLoadRequiredFromArray: MetacelloMCVersion>>load UndefinedObject>>DoIt On Mon, Sep 15, 2014 at 5:38 PM, kilon alios <kilon.alios@gmail.com> wrote:
Thanks Damien :)
so I want to further explore Slang , that means downloading the VMMaker , I am following the post of Mariano here https://marianopeck.wordpress.com/tag/vmmaker/
and install VMMaker like this
1 2 3 4 5 6 Deprecation raiseWarning: false. Gofer new squeaksource:'MetacelloRepository'; package:'ConfigurationOfVMMaker'; load. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') load.
Question does CCodeGenerator contain the entire Slang ?
I am downloading VMMaker to find how Slang plays with pointers and manual memory management so if you have any pointer (pun not intended) I will greatly appreciate it.
On Mon, Sep 15, 2014 at 4:25 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-09-15 15:13 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Sep 15, 2014 at 2:33 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hum, I would more like SSE and AVX code done this way: matrix multiplications, bitmap processing, heavily used code, SciSmalltalk stuff on very large datasets.
Indeed! I'd live to generate some CUDA code from Pharo. But the toolchain goes C code which gets compiled through some "black-hole toolchain" in the NVidia SDK with host and GPU blocks.
You may be interested to contact Bernard Pottier. His NetGen toolkit does CUDA code generation. NetGen is VisualWorks only for the moment, even if I know someone who would like to have it in Pharo (well, two guys at least).
That's too much to handle for my tastes, so the best is for me to have an engine (or for a better metaphor) and using Pharo to drive/steer/harness it.
Yes. I intended to do things around that, but didn't found the time.
Indeed! CUDA =-)
OpenCL, SPIR code generation and link to Cog.
The ability to generate better code than when targetting C.
True too. But aren't those compilers smart enough already? With current CPUs, well, it takes a strong man to do better things than the compiler it seems. Or am I mistaken?
You are. A lot may be done if your input language is not C, but this is not allways relevant to the Pharo situation.
I should know a lot more about LLVM-IR generation in a few months time. I'll say if I see easy gains when doing Smalltalk code.
Ah, I should have taken the research career :-)
Hum, you know that researchers are allways on the lookout for SMEs to collaborate on projects :-)
Duly noted :-) Feel free to tickle me :-)
Noted :)
Thierry
Hello, Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C. 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be
the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain. However, I think Ronie was interested in doing such work. If he succeeds and reports performance improvement, then we can consider using his compiler to compile the VM.
Thierry
2014-09-15 12:29 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
Hello,
Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C.
Yes, I am aware of that. I remember that from the very beginnings of Squeak. Wasn't Smalltalk/X the one which had a more complete version of that C translation? I did an internship in a French company who had a Smalltalk to C translator done for them a long time ago.
2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
It would allow JIT-type compilation experiments than a Slang-to-C chain isn't designed for :) With a lot more work doing the various NB ports, of course.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain.
I would not suggest replacing C by LLVM-IR for VM work, in part because LLVM-IR is not what I would call a readable source code format... But I do know that even when doing C to C rewritting for embedded compilation, there is some low-level code that you can't write in C.
However, I think Ronie was interested in doing such work. If he succeeds and reports performance improvement, then we can consider using his compiler to compile the VM.
Keep us posted! Thierry
Hi All, On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
Hello,
Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C.
Yes, I am aware of that. I remember that from the very beginnings of Squeak.
Wasn't Smalltalk/X the one which had a more complete version of that C translation? I did an internship in a French company who had a Smalltalk to C translator done for them a long time ago.
2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
It would allow JIT-type compilation experiments than a Slang-to-C chain isn't designed for :) With a lot more work doing the various NB ports, of course.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain.
I would not suggest replacing C by LLVM-IR for VM work, in part because LLVM-IR is not what I would call a readable source code format... But I do know that even when doing C to C rewritting for embedded compilation, there is some low-level code that you can't write in C.
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration. Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved. Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL...> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl...> Sista: Improving Cogâs JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides> However, I think Ronie was interested in doing such work. If he succeeds
and reports performance improvement, then we can consider using his compiler to compile the VM.
Keep us posted!
Thierry
-- in hope, Eliot
On Mon, Sep 15, 2014 at 6:23 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clement@gmail.com>:
Hello,
Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C.
Yes, I am aware of that. I remember that from the very beginnings of Squeak.
Wasn't Smalltalk/X the one which had a more complete version of that C translation? I did an internship in a French company who had a Smalltalk to C translator done for them a long time ago.
2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
It would allow JIT-type compilation experiments than a Slang-to-C chain isn't designed for :) With a lot more work doing the various NB ports, of course.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain.
I would not suggest replacing C by LLVM-IR for VM work, in part because LLVM-IR is not what I would call a readable source code format... But I do know that even when doing C to C rewritting for embedded compilation, there is some low-level code that you can't write in C.
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM.
Why so? I am all in for using the VM based technology. Slang is great. Now, we need to interface with the outside world, and then it is C-based at one point.
People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al.
Super, that's why I bet my company business on Pharo for software development. I trust you guys.
We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration.
Ah, non blocking VM, a super cool thing to have. I am going through hoops at the moment to avoid doing direct SNMP calls to devices from Pharo...
Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved.
That's well said. Let's race to the top!
Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL...> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl...> Sista: Improving Cogâs JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides>
All very interesting things indeed. Now, doing application level code at the moment, I can't really dig into these. But I can use them and kick ass!
However, I think Ronie was interested in doing such work. If he succeeds
and reports performance improvement, then we can consider using his compiler to compile the VM.
Keep us posted!
Thierry
-- in hope,
Eliot
Hi Eliot, Le 15/09/2014 18:23, Eliot Miranda a écrit :
Hi All,
On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
I would not suggest replacing C by LLVM-IR for VM work, in part because LLVM-IR is not what I would call a readable source code format... But I do know that even when doing C to C rewritting for embedded compilation, there is some low-level code that you can't write in C.
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration. I certainly appreciate how much we own to your work on Cog. I wouldn't have come back to Squeak/Pharo without it (not after going through the Squeak VM when Ian Piumarta was taking care of it), and I'm thrilled by the performance goals you're targetting. This is great!
At the same time, I do use that C/LLVM today for automatic vectorization, GPU support, automatic parallelisation for CPUs with over a thousand cores, compiling for exotic embedded platforms... That work I have to do for R (or Python) I'd also like to explore it with Pharo and for that, FFI or NativeBoost have their uses. Including the fact that I can run experiments proving or disproving certain techniques/attempts without bothering Cog development until it is proven it is worth the inclusion :)
Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved. You have a point :) VM development is hard, and is vital for Squeak/Pharo.
Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRL...> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Yl...> Sista: Improving Cogâs JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides> You didn't announce the last one or I missed it?
Regards, Thierry
Le 15/09/2014 18:23, Eliot Miranda a écrit :
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration.
Hi Eliot, Not everybody has the necessary skills to help and contribute to your work, my assembly skills are really faraway and outdated now (... little frustration here :( ... ) but imho your work is unvaluable to pharo and smalltalk community - just to mention it, I noticed a 30 to 50% gain in a small bench I wrote for fun recently (a very dumb chess pawn moves generator) with the last Spur vm I was shocked :) 64bits + x2 perfs + non blocking (or multi threaded?) vm are giant steps forward that makes it possible for pharo smalltalk to compete with mainstream technologies Regards, Alain
Le 20 sept. 2014 02:11, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit :
Le 15/09/2014 18:23, Eliot Miranda a écrit :
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration.
Hi Eliot,
Not everybody has the necessary skills to help and contribute to your
work, my assembly skills are really faraway and outdated now (... little frustration here :( ... )
but imho your work is unvaluable to pharo and smalltalk community - just to mention it, I noticed a 30 to 50% gain in a small bench I wrote for fun recently (a very dumb chess pawn moves generator) with the last Spur vm I was shocked :) 64bits + x2 perfs + non blocking (or multi threaded?) vm are giant steps forward that makes it possible for pharo smalltalk to compete with mainstream technologies
We'll prevail! What we also need to do is to showcase the Smalltalk workflow and how nice it is. We cannot gain mindshare by technical prowess only. Phil
Regards,
Alain
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current technology trends (saas, cloud, server side dev) and progress in this field is important. Despite the fact I think that Smalltalk still has an advance in object oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
A Le 20 sept. 2014 03:27, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit :
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current
technology trends (saas, cloud, server side dev) and progress in this field is important.
Despite the fact I think that Smalltalk still has an advance in object
oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc. Phil
On 20 September 2014 08:45, phil@highoctane.be <phil@highoctane.be> wrote:
A Le 20 sept. 2014 03:27, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit :
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current technology trends (saas, cloud, server side dev) and progress in this field is important.
Despite the fact I think that Smalltalk still has an advance in object oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc.
The article that convinced me that objects are higher order functions (that close over a set of variables) is here: http://letoverlambda.com/index.cl/guest/chap2.html The meat of the article (as far as class/object/function correspondences goes) starts at "Let over Lambda". frank
Phil
Le 20 sept. 2014 10:57, "Frank Shearar" <frank.shearar@gmail.com> a écrit :
On 20 September 2014 08:45, phil@highoctane.be <phil@highoctane.be> wrote:
A Le 20 sept. 2014 03:27, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit
:
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current
technology
trends (saas, cloud, server side dev) and progress in this field is important.
Despite the fact I think that Smalltalk still has an advance in object oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc.
The article that convinced me that objects are higher order functions (that close over a set of variables) is here: http://letoverlambda.com/index.cl/guest/chap2.html
The meat of the article (as far as class/object/function correspondences goes) starts at "Let over Lambda".
Thanks for the reference. I still can't get myself to plunge into that I've to admit. The issue is that there are not too many people grasping this in typical business applications. Not to mention staffing teams. How do you use this in practice? I know you do lots of magic at your company. I also know that therr aren't that many Frank S. around... Phil
frank
Phil
On 20 September 2014 11:04, phil@highoctane.be <phil@highoctane.be> wrote:
Le 20 sept. 2014 10:57, "Frank Shearar" <frank.shearar@gmail.com> a écrit :
On 20 September 2014 08:45, phil@highoctane.be <phil@highoctane.be> wrote:
A Le 20 sept. 2014 03:27, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit :
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and how nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current technology trends (saas, cloud, server side dev) and progress in this field is important.
Despite the fact I think that Smalltalk still has an advance in object oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc.
The article that convinced me that objects are higher order functions (that close over a set of variables) is here: http://letoverlambda.com/index.cl/guest/chap2.html
The meat of the article (as far as class/object/function correspondences goes) starts at "Let over Lambda".
Thanks for the reference.
I still can't get myself to plunge into that I've to admit.
It certainly helps if you can speak a bit of Lisp. Or an ML language, if you just ignore the ()s. "let over fun" would be the ML/Haskell/F# version.
The issue is that there are not too many people grasping this in typical business applications. Not to mention staffing teams.
How do you use this in practice?
I don't :) Mostly, I find this stuff valuable in understanding new programming languages. If you know the bones of computing, you recognise the common patterns between languages. Helps me get up to speed with new technologies.
I know you do lots of magic at your company. I also know that therr aren't that many Frank S. around...
Sadly, I don't do much magic at work anymore: just doing CRUD in the cloud nowadays, and trying to talk sense into my colleagues. frank
Phil
frank
Phil
I may have more interesting fish to fry on the horizon... Let's keep in touch :-) Phil Le 21 sept. 2014 17:08, "Frank Shearar" <frank.shearar@gmail.com> a écrit :
On 20 September 2014 11:04, phil@highoctane.be <phil@highoctane.be> wrote:
Le 20 sept. 2014 10:57, "Frank Shearar" <frank.shearar@gmail.com> a
écrit :
On 20 September 2014 08:45, phil@highoctane.be <phil@highoctane.be>
wrote:
A Le 20 sept. 2014 03:27, "Alain Rastoul" <alf.mmm.cat@gmail.com> a écrit :
Le 20/09/2014 02:33, phil@highoctane.be a écrit :
We'll prevail!
What we also need to do is to showcase the Smalltalk workflow and
how
nice it is.
We cannot gain mindshare by technical prowess only.
Phil
I totally agree with you, but I think that those technical advances are vital in current technology trends (saas, cloud, server side dev) and progress in this field is important.
Despite the fact I think that Smalltalk still has an advance in object oriented systems/development, and offers a different perception it is hard to get the point about object system with people who are formatted by the hype or by their experience. Discussing with collegues about some smalltalk concepts is always interesting :)
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc.
The article that convinced me that objects are higher order functions (that close over a set of variables) is here: http://letoverlambda.com/index.cl/guest/chap2.html
The meat of the article (as far as class/object/function correspondences goes) starts at "Let over Lambda".
Thanks for the reference.
I still can't get myself to plunge into that I've to admit.
It certainly helps if you can speak a bit of Lisp. Or an ML language, if you just ignore the ()s. "let over fun" would be the ML/Haskell/F# version.
The issue is that there are not too many people grasping this in typical business applications. Not to mention staffing teams.
How do you use this in practice?
I don't :) Mostly, I find this stuff valuable in understanding new programming languages. If you know the bones of computing, you recognise the common patterns between languages. Helps me get up to speed with new technologies.
I know you do lots of magic at your company. I also know that therr aren't that many Frank S. around...
Sadly, I don't do much magic at work anymore: just doing CRUD in the cloud nowadays, and trying to talk sense into my colleagues.
frank
Phil
frank
Phil
Le 20/09/2014 10:56, Frank Shearar a écrit :
I am facing quite some people who are in the FP bandwagon and wonder how to bridge with their views. Like classes are just functions etc.
The article that convinced me that objects are higher order functions (that close over a set of variables) is here: http://letoverlambda.com/index.cl/guest/chap2.html
The meat of the article (as far as class/object/function correspondences goes) starts at "Let over Lambda".
frank
Phil
Woaw, very interesting, thank you for sharing :) Coding in dotnet at work, I sometime think about smalltalk objects methods as a set of lambda within a scope : the "object". To me, lambda use in c# lacks of organization and somehow leads to anarchy, functional programming fills this gap with a different way of thinking (I had fun doing some f# workshops at ms tech days). Your high order assumption is intriguing, I have to figure it. I often wondered myself how to visualize methods and message flow in Roassal (I feel that perception and representation is a key here) Regards, Alain
Sure, but enough of Smalltalk flavor to not want to go into C. For specific plugins, this is really cool to have. Phil On Mon, Sep 15, 2014 at 2:39 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C.
2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be
the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain.
However, I think Ronie was interested in doing such work. If he succeeds and reports performance improvement, then we can consider using his compiler to compile the VM.
Thierry
2014-09-15 12:29 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Dne pondÄlà 15. záÅà 2014 phil@highoctane.be <phil@highoctane.be> napsal(a):
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
I hope only super slow :-) I simply have no time for this project now. Help is welcome. -- Pavel
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com <javascript:_e(%7B%7D,'cvml','santiagobragagnolo@gmail.com');>> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com <javascript:_e(%7B%7D,'cvml','kilon.alios@gmail.com');>>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
On Tue, Sep 16, 2014 at 9:52 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Dne pondÄlà 15. záÅà 2014 phil@highoctane.be <phil@highoctane.be> napsal(a):
Slang has been externalized by Pavel. So, Smalltalk to C works.
Works nicely, even if there were a few glitches (like code generated twice at one point). Nothing unfixable, I got the beast working.
Allows for things like: write Slang, generate C, compile into DLL, load DLL, run C code. All in a single shot.
PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super slow/zombified).
Phil
I hope only super slow :-) I simply have no time for this project now. Help is welcome.
I was speaking about Smalltalkhub, not your project :-)
Phil
-- Pavel
On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Hola Santiago Como se llama tal proyecto, me podria ser util podria colaborar saludos Juan Marcelo On Mon, Sep 15, 2014 at 6:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Que proyecto?? ?_? el que pasa smalltalk a c? estan hablando de slang 2014-09-15 14:29 GMT+02:00 Juan <smalltalker.marcelo@gmail.com>:
Hola Santiago
Como se llama tal proyecto, me podria ser util podria colaborar
saludos
Juan Marcelo
On Mon, Sep 15, 2014 at 6:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Arduino to c++ /c Best Jmdc El 15/09/2014 09:33, "Santiago Bragagnolo" <santiagobragagnolo@gmail.com> escribió:
Que proyecto?? ?_?
el que pasa smalltalk a c? estan hablando de slang
2014-09-15 14:29 GMT+02:00 Juan <smalltalker.marcelo@gmail.com>:
Hola Santiago
Como se llama tal proyecto, me podria ser util podria colaborar
saludos
Juan Marcelo
On Mon, Sep 15, 2014 at 6:28 AM, Santiago Bragagnolo < santiagobragagnolo@gmail.com> wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
Also there is a project for generating C for arduino, (a project related with EToys), but i am not sure about how complete is.
2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
On Mon, Sep 15, 2014 at 11:28:24AM +0200, Santiago Bragagnolo wrote:
I may be wrong, but I think the closest thing out there is Slang. Is the pseudo smalltalk used to develop the VM.
A bit off topic, but just for clarification: "Slang" is not a language. It is just a casual name to refer to the subset of Smalltalk that can be easily translated to a language such as C. Some of this Smalltalk may be written in awkward ways in order to make sure it can be translated to a lower level language, but it is real Smalltalk nonetheless. The VM is not written in Slang, it is written in Smalltalk. When people talk about running the VM simulator, they are talking about running the VM in its native Smalltalk implementation, as opposed to running the code that is more commonly translated to C and linked to the platform support code. There is no psuedo Smalltalk involved, it is the real thing. Dave
Hi Kilon, you don't need any parser to do that, you need something to generate C / C++ code :) There are Smalltalk to C translators floating around, and I believe one of them is in the Squeak / Pharo code base to generate the VM (or part of it). If you want to do it yourself, you probably should: explore the Ring model as a way to export the package / class structure in C++ (just generate text as you go) and also make a pass method by method, asking for the RBAST of the method, and a visitor to generate the C / C++ equivalent to each node of the AST (and you'll find the Smalltalk AST very simple and nice :) ). Thierry 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
Is there a way to convert code from pharo to c or c++ ? Does pettit parser or other parsers offer such support ?
Side comments... Some code just has to be written in C, otherwise you cannot rely on the behavior being correct and ultimately that's a major show stopper for anything you might want to call "production" code. Anything having to do with calling operating system libraries is a typical example of this phenomenon. So, in those cases, translating Smalltalk to C (or interfacing to OS libraries with FFI interfaces) only gives you huge maintenance headaches in the long run. The resulting distractions due to bug reports will obliterate any engineering team's performance, and it's a race that cannot be won as framed. POSIX is there for a reason, let the C compiler do the job it's been doing for 40+ years. But suppose one wants to write C code with Smalltalk syntax anyway. Nevertheless, C99 and newer still apply and one must be aware of the subject matter. The danger is that Smalltalk is so much more user friendly than C, that once one starts writing C in Smalltalk one will never look at the automatically generated C. But is the mechanically generated C code valid? Because if not, then compiling such source code can be no better than "garbage in, garbage out", and then you cannot have production quality. Similar arguments apply to FFI interfaces. Please excuse my ignorance, but I'd like to assume someone's looking into this? What seems to follow is that the architecture of the system should try to minimize the dependencies on external libraries, precisely because the dependencies cause exposure to foreign rules and regulations that slow one down. Creating dependencies in a reasonable manner should be straightforward _for system users_, though. Letting externals create reliable dependencies on one's system should also be facilitated to promote healthy modes of interaction with the community at large. I feel one of our current challenges is to wholeheartedly admit there is no royal road to inventing our future, then act accordingly. Andres.
participants (17)
-
Alain Rastoul -
Andres Valloud -
Ben Coman -
Clément Bera -
Damien Cassou -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Jan Vrany -
Juan -
kilon alios -
Pavel Krivanek -
phil＠highoctane.be -
Santiago Bragagnolo -
Serge Stinckwich -
Thierry Goubier -
Tudor Girba