Re: crack lang

[Conrad Steenberg]

Hi pancake,

Thanks for the bug report, I'm forwarding it to the crack-lang-dev
Google group/mailing list.

We hang out at #crack-lang on Freenode IRC if you'd like to come by.

Some more comments below.

On Tue, 2011-07-19 at 12:22 +0200, pancake wrote:
> make[1]: *** No rule to make target `model/TypeOfCall.h', needed by
> `all-am'. Stop.
>
> i think you forgot to commit that file (it is in crack-0.5 tarball), but
> not in the repo.
>
> btw . nice lang :)

I love it too, and it's getting better all the time. For me it has the
perfect mix of high and low level functionality. Very similar to Vala,
with a Python-like execution environment.

>
> Another cool thing would be to add support for valabind, this will allow
> you to create automatic bindings for any library described in a VAPI
> file (Vala) from your language. This is.. Gtk+, GStreamer, Poppler, SDL, ...
>
> http://hg.youterm.com/valabind
>
> let me know if you are interested in having this support.

It definitely sounds interesting. I can help if you would like to add a
writer for the crack interface files (which are themselves simplified
crack files) to valabind.

For components (mostly gtk+3.x) that already have .gir files, it would
probably be preferable to use those, right?

>
> Stuff I missed in your lang:
>
> * create relocatable binaries (like in -fPIC)
> * dump raw execution buffer to stdout (not only IR)
>
> NOTE: i would document that the way to generate a binary is by using -B
> llvm-native.. this sounds strange to me as long as I expected -o flag.

This might just be unclear in the documentation. To create a binary, use
the "crackc" command:

crackc myfile.crk -o myexecutable.exe

Cheers,
Conrad

>
> Best regards.
>
> --pancake

[Michael Muller]

On Tue, Jul 19, 2011 at 10:26 AM, Conrad Steenberg
<conrad.s...@gmail.com> wrote:
> Hi pancake,
>
> Thanks for the bug report, I'm forwarding it to the crack-lang-dev
> Google group/mailing list.
>
> We hang out at #crack-lang on Freenode IRC if you'd like to come by.
>
> Some more comments below.
>
> On Tue, 2011-07-19 at 12:22 +0200, pancake wrote:
>> make[1]: *** No rule to make target `model/TypeOfCall.h', needed by
>> `all-am'.  Stop.
>>
>> i think you forgot to commit that file (it is in crack-0.5 tarball), but
>> not in the repo.

Thanks for pointing this out - actually TypeOfCall.h is dead code that
happened to live on in my local working directory, it should have been
removed from the Makefile. This is now fixed in the repository.

>>
>> btw . nice lang :)
>
> I love it too, and it's getting better all the time. For me it has the
> perfect mix of high and low level functionality. Very similar to Vala,
> with a Python-like execution environment.
>
>>
>> Another cool thing would be to add support for valabind, this will allow
>> you to create automatic bindings for any library described in a VAPI
>> file (Vala) from your language. This is.. Gtk+, GStreamer, Poppler, SDL, ...
>>
>> http://hg.youterm.com/valabind
>>
>> let me know if you are interested in having this support.
>
> It definitely sounds interesting. I can help if you would like to add a
> writer for the crack interface files (which are themselves simplified
> crack files) to valabind.

+1. We've had similar discussions around supporting "smoke" for Qt
and KDE (see http://techbase.kde.org/Development/Languages/Smoke). We
might want to get together for virtual chat on how we want to go about
this. Also, see this thread for our existing thoughts on the subject:
http://groups.google.com/group/crack-lang-dev/browse_thread/thread/996881c8abea9877

>
> For components (mostly gtk+3.x) that already have .gir files, it would
> probably be preferable to use those, right?
>
>>
>> Stuff I missed in your lang:
>>
>> * create relocatable binaries (like in -fPIC)

We'll need to do that at some point when we start building shared libraries.

>> * dump raw execution buffer to stdout (not only IR)

I thought about this at one point in the context of generating cached
module files - it's not obvious to me that this can be done from LLVM,
though.

[Michael Muller]

On Thu, Jul 21, 2011 at 1:37 PM, pancake <pan...@youterm.com> wrote:
> hi

>
> On 07/20/11 17:11, Michael Muller wrote:
>>
>> Thanks for pointing this out - actually TypeOfCall.h is dead code that
>> happened to live on in my local working directory, it should have been
>> removed from the Makefile.  This is now fixed in the repository.
>

> good. i've just updated the repo and it's now happily building now.

>>>>
>>>> btw . nice lang :)
>>>
>>> I love it too, and it's getting better all the time. For me it has the
>>> perfect mix of high and low level functionality. Very similar to Vala,
>>> with a Python-like execution environment.
>>>
>>>> Another cool thing would be to add support for valabind, this will allow
>>>> you to create automatic bindings for any library described in a VAPI
>>>> file (Vala) from your language. This is.. Gtk+, GStreamer, Poppler, SDL,
>>>> ...
>>>>
>>>> http://hg.youterm.com/valabind
>>>>
>>>> let me know if you are interested in having this support.
>>>
>>> It definitely sounds interesting. I can help if you would like to add a
>>> writer for the crack interface files (which are themselves simplified
>>> crack files) to valabind.
>>
>> +1.  We've had similar discussions around supporting "smoke" for Qt
>> and KDE (see http://techbase.kde.org/Development/Languages/Smoke).  We
>> might want to get together for virtual chat on how we want to go about
>> this.  Also, see this thread for our existing thoughts on the subject:
>>
>> http://groups.google.com/group/crack-lang-dev/browse_thread/thread/996881c8abea9877
>>

> i would be happy to get also a decent girwriter.vala for valabind.
> supporting GIR would be probably
> better than supporting VAPI... but VAPIs are much more readable than plain
> XML files... so valabind
> is the way to go imho..
>
> another backend for valabind would be QT... i found QML quite interesting,.
> but you end up
> wrapping C code into QObject classes with Q_INVOKABLE wraps to be able to
> use them from QML..
>
> I would love to simplify all this process with just a qtwriter.vala or so..

>>>
>>> For components (mostly gtk+3.x) that already have .gir files, it would
>>> probably be preferable to use those, right?
>>>
>>>> Stuff I missed in your lang:
>>>>
>>>> * create relocatable binaries (like in -fPIC)
>>
>> We'll need to do that at some point when we start building shared
>> libraries.
>

> cool.

>>>>
>>>> * dump raw execution buffer to stdout (not only IR)
>>
>> I thought about this at one point in the context of generating cached
>> module files - it's not obvious to me that this can be done from LLVM,
>> though.
>>

> i was more thinking on code injection on remote processes, but yeah.. cache
> will be ok too :)
>
> ---
>
> lemme paste something i send to Conrad:
>
> yeah. actually I love Vala.. but I miss native code generation for it.. so
> dropping the dependency of a C compiler.. speeding up compilation times and
> so on...
>
> The thing i like from cracklang is the language itself. it looks clear,

Thank you :-)

> flexible and powerful.. but something I really hate is the runtime
> library... C has no runtime library and you end up linking against the

What is it that you hate about it? You mentioned that "hello world"
contains a lot of extra code - that's true. That's because the core
libraries (crack.lang & crack.io) are currently compiled in. Are
there other things that you hate?

> libraries you want to do stuff. (libc, ..)
>
> In Go, the full compiler is reimplementing all the required stuff to create
> binaries, comunicate with kernel, etc.. which is pretty heavy, but ok.. and
> well. C++, Ooc and other big langs tend to depend on big runtime libraries
> which end up generating huge binaries for just simple hello worlds.
>
> Vala allow to create really small binaries, because all the required stuff
> lives in GObject or libc...
>
> I would like that Crack just gets the code it really needs, so if you just
> write a print hello world i dont need to import hashtables, socket stuff and
> other unnecessary stuff.
>
> Another thing i have noticed is that crack doesnt' finds the runtime.so in
> the proper path, and this library is not containing all the basic runtime

runtime.so is an extension - it's C++ code with a little glue function
so that we can resolve crack symbols from it at compile time. As
such, it lives in the crack library directory which is segregated from
the main system library directory to prevent casually attempting to
import a normal shared library.

This is the same kind of model that Python uses, it works well for JIT
mode, but poorly for AOT. In retrospect, I think it would have been
preferable use a stub file during compile to reference a normal shared
library - then this segregation wouldn't be necessary and the runtime
wouldn't be burdened with the extension glue function that is only
used at compile time. We'll probably add this feature eventually.

> stuff as long as a hello world binary contains much more than just the hello
> world. It would be good to move all this stuff up to the library, so if you
> compile it statically you will end up taking only the objects (or functions)
> the program needs.

As I said earlier, a lot of this stuff is core libraries written in
Crack, the executable shouldn't be pulling in any more than what it
needs (no datastructures in "hello world"). However, it would
certainly be nice to store those things in a shared library and the
mechanics necessary to generate that stuff in a shared library (or
two) would certainly be a welcome addition to the executor.

>
> ---
>
> Best regards.
>
> --pancake
>