String "notations" (CString, UTF-8 String)

[showstopper]

We're dealing with multiple types of strings in ooc code next to our default, the "ooc string". Let's introduce a special syntax to declare raw CStrings or UTF-8 strings.
Ie.

Raw CString: c"Hey, I'm a CString!"
UTF-8: u"Ohai, I häve funny symböls."

These letters are only suggestions. Furthermore, it might be interesting to discuss if UTF-8 should be the default and therefore making the u"Unicode" type obsolete.

[nddrylliog]

utf-8 should definitely be default everywhere, so u is obsolete indeed.

[rofl0r]

"utf-8 should definitely be default everywhere"
not on windoze :)

[fredreichbier]

+1 for making UTF-8 the default.
Raw CStrings would mean zero-terminated char*s?

[wandernauta]

@rofl0r Indeed Windows has different standards internally (UTF16 IIRC), but it should be possible to work around those and just pretend everything is moonshine and roses (i.e. UNIX).

[duckinator]

iirc I saw commits about these. What's the status on this?

[nddrylliog]

The conspiracy branch has c"Raw strings ftw!"

[alexnask]

@nddrylliog Do you think I should implement those to master?

[nddrylliog]

I think conspiracy is the new master, it's simply not ready yet: people should patch against conspiracy, not master, and master should be kept (as 0.9.4) for stable projects for now.

conspiracy will be ready when CHeaderParser will be more stable, when it will output enough information for coke to function (and exist, ha). For now it justs spits a bunch of .c/.h files and a Makefile, that's not really acceptable for the end-user. Yet, it's much cleaner and I think we can remove a few features still (and rewrite others).

[alexnask]

Ok so for now all I will do on the master branch is fix bugs. I trust you will port some of these changes to conspiracy (if you want to I could do that too) ?

[alexnask]

@nddrylliog By the way, what do you have in mind for coke? I mean, what kind of information should rock generate for coke input?

[nddrylliog]

@Shamanas If the fixes apply to conspiracy as well, it would be nice to backport them there, yep.

As for coke, mostly we'll need info for recompilation. The goal is that you should be able to edit the .c files and recompile pretty easily. Also, rock should be able to use info from the previous compilation round, only regen what's need and tell coke about it.

coke and rock would work hand-in-hand, with rock handling all the parsing+tinkering+generation knowledge, and coke handling the 'running external compilers' knowledge.

So actually it would go like this:

• Be in project home
• Run 'coke' (runs the 'all' target by default, why not? that's actually a part of make I like)
• By default (without a Cokefile), coke runs something like 'rock -v', and reads what rock generates to run the C compiler.

With a Cokefile you could define more things: e.g. how to build different libs, which deps to get (although that could simply be part of the .use file), which executables to produce, workarounds for compiler settings / platform-dependant stuff: all kinds of things rock itself will remain blissfully unaware of.

In fact, there's no reason why coke should have to wait for rock to have entirely finished to start compiling C files (multi-core / parallel ftw): we could start thinking about a way for rock and coke to communicate, and we should think about which features of ooc make it hard to really establish a 'dependency graph' between modules (I'm thinking maybe stuff like 'extends') Because once we have a clear dependency graph, it's really easy for coke to know what to build in what order and what to rebuild when a .c file has changed (again, something rock could forget everything about).

That's why rock should probably output a bit more than just 'B depends on A', perhaps it could go further, and just output in an easily readable format (JSON? YAML?) info about the memory structure of the various types we creates: this would allow the creation of Python/Rubyy/etc. bindings trivial as well (by third-party tools).

I hope you see where I'm going here, if not, keep asking and I'll keep rambling until it becomes clear.

[wandernauta]

(Minor note: GNU make doesn't by default run the 'all' target, but the first target, which is named 'all' by convention.)

[alexnask]

I see what your goal is. So basically a Cokefile will be usefile on steroids, with more info than simply package info and C compiler options, and coke will basically be what links rock and the C compiler.

I like the idea of compiling the C files as rock is generating them.

The idea of a 'dependency graph' seems nice but difficult to implement, as you said we have to plan this out perfectly.

When it comes to coke communicating with rock, I don't think it would be much of a challenge, as you said the perfect solution would be for rock to output information that can easily be parsed (JSON sounds fine), although I would implement a new option for it rather than -v (something like --info=JSON) and just launch a rock process from coke and retrieve its output to be parsed.

When you talk about 'memory structure of the various types we create' what exactly do you mean, apart from information on its fields, methods and generic types, or do you mean those ?

[nddrylliog]

@wandernauta Ooh, correct. Thanks for the note.

[nddrylliog]

@Shamanas Well, I think we can draw the line between a .use file and a Cokefile.

A .use file will definitely be parsed by rock itself, to figure out the dependencies between different libraries/projects. Perhaps it should be separately parsed by coke to know which C flags to use? After all it doesn't make sense to make rock aware of C compiler flags at all, and it makes sense to be able to tweak C flags in .use files even after rock is done generating .c files of its own.

.use files will also be used by package management programs (maybe coke should play a role there? like 'prepare' being a default target that checks everything is in place. from the info in the .use files?), like nirvana/reincarnate used to do (and do again, apparently?)

As for Cokefile it's mostly just for specifying 'targets', and more high-level stuff: if we need to download assets from elsewhere and uncompress them somewhere, that's what you specify in a Cokefile. If we need to create an archive and upload it to some FTP server, it goes in the Cokefile as well.

If your single source repository contains 4 different libs (each with their own usefile), it's your job to create 4 tasks specifying which .use file to use to generate a library, and what name the library should have, in which directory it should be generated, etc.