Comments on: Introducing Score! The idea is that the host should have a complete view of most stuff on the target (can't be everything of course) so the host can generate code for the target which is the point. The target should only get the "end product" and execute it. There are some targets our there that doesn't allow you to generate and execute code directly and needs to be sent from the host. The idea is that the host should have a complete view of most stuff on the target (can’t be everything of course) so the host can generate code for the target which is the point. The target should only get the “end product” and execute it. There are some targets our there that doesn’t allow you to generate and execute code directly and needs to be sent from the host.

]]>
By: njrabit/2011/01/20/introducing-score/#comment-616 njrabit Fri, 21 Jan 2011 09:06:53 +0000 ) is an LGPL alternative that is comparatively tiny but looks fairly complete.

]]>
By: Daniel Collin/2011/01/20/introducing-score/#comment-615 Daniel Collin Fri, 21 Jan 2011 08:43:08 +0000 In this case, LLVM can be used as an offline compiler, thus does not need to run on the platform In this case, LLVM can be used as an offline compiler, thus does not need to run on the platform

]]>
By: njrabit/2011/01/20/introducing-score/#comment-613 njrabit Fri, 21 Jan 2011 01:46:53 +0000 Sean: Yeah. I'm going to take a look at Clojure at some point to see if there is something that I can use for inspiration. From what I heard they have made some changes that cripples it a bit compared to Common Lisp but as I haven't cheeked it out myself yet I won't comment on it but of course a good idea to take a look around. Sean: Yeah. I’m going to take a look at Clojure at some point to see if there is something that I can use for inspiration. From what I heard they have made some changes that cripples it a bit compared to Common Lisp but as I haven’t cheeked it out myself yet I won’t comment on it but of course a good idea to take a look around.

]]>
By: Sean Parsons/2011/01/20/introducing-score/#comment-611 Sean Parsons Thu, 20 Jan 2011 23:08:34 +0000 Julien: Thanks. I haven't dived into detail on how to expose third party API's yet, but as Score! code is native it's all about having the right calling conversion and loading the data/code into memory. I appreciated all help but first I need to get some things in stone and I will likely start to focus on one platform first instead of doing all at once and yeah, as I wrote about LLVM might be the road I take. Julien: Thanks. I haven’t dived into detail on how to expose third party API’s yet, but as Score! code is native it’s all about having the right calling conversion and loading the data/code into memory. I appreciated all help but first I need to get some things in stone and I will likely start to focus on one platform first instead of doing all at once and yeah, as I wrote about LLVM might be the road I take.

]]>
By: Daniel Collin/2011/01/20/introducing-score/#comment-609 Daniel Collin Thu, 20 Jan 2011 22:04:38 +0000 Nice approach. For native functions, would you expose direct API, or would be create a uniform layer independent of the platform. If you expose direct API, how would you handle the different platforms? Moreover, how would the user aware of the memory use? I really think it's an interesting approach, while I really don't see a solution for all problems that comes up to my head. For the implementation I really recommend using LLVM. It really gives you all choices. It allows to debug code in the VM and then compile it for the release mode. I gonna look at your implementation as soon as you provide it. And if you are interesting in, I may be able to give you a hand, I like writing those kind of thing ( it remembers me my lua->x86 compiler ;-) Nice approach. For native functions, would you expose direct API, or would be create a uniform layer independent of the platform. If you expose direct API, how would you handle the different platforms? Moreover, how would the user aware of the memory use? I really think it's an interesting approach, while I really don't see a solution for all problems that comes up to my head. For the implementation I really recommend using LLVM. It really gives you all choices. It allows to debug code in the VM and then compile it for the release mode. I gonna look at your implementation as soon as you provide it. And if you are interesting in, I may be able to give you a hand, I like writing those kind of thing ( it remembers me my lua->x86 compiler ;-)

]]>
By: njrabit/2011/01/20/introducing-score/#comment-607 njrabit Thu, 20 Jan 2011 21:35:25 +0000 Yeah. The point in here that you have access to the whole language at compile time and you can do whatever you want there. For example Lisp generates native code directly when you setup a fixed regular expression and similar things can be done here which is very powerful. Yeah. The point in here that you have access to the whole language at compile time and you can do whatever you want there. For example Lisp generates native code directly when you setup a fixed regular expression and similar things can be done here which is very powerful.

]]>
By: Aras Pranckevičius/2011/01/20/introducing-score/#comment-605 Aras Pranckevičius Thu, 20 Jan 2011 20:12:56 +0000 – basically, adding that DeepProfilingAttribute only any class/assembly (it’s .NET speak) inserts profiling begin/end instrumentation samples at each function. You get access to AST of the program at compile time, and can modify it as you wish. Rodrigo (author of Boo language) talks in depth about it here: