OSDev.org

I'm happy to announce the beta release of Capri, version 1.16!

Capri is a script engine featuring a C-like syntax with a garbage collector and project-task-dependency-elements. It allows writing platform-independent scripts that can either be really simple or manage even the biggest, most complex projects. Concurrency can also be done very easily using built-in syntactical elements. It was initially created to write build-scripts, but as it has all the features of a scripting language, I decided to present it as a script engine. It could even be integrated into your OS as the shell script interpreter!

The program is in it's beta phase, but will be released open source once I've done some cleanup. There will be a project website with a documentation on all the features and syntax. If you want the sources earlier, write me a message or an eMail to [email protected].

Some of the features are:
- High flexibility. Write tiny helpers or build a large project!
- Platform independency. Write once - use on any of your host systems.
- Easy-to-use concurrency features, see the concurrency example script.
- Built-in tasks for things like file access
- Readable beautiful C-like syntax
- Garbage collection
- Specialization statements, see the specialization example script.
- Very portable, depends only on C/C++ library
- Eclipse plugin featuring syntax-highlighting

Downloads & resources

See the Capri release folder for everything release-related. It contains binaries, sources, the Eclipse plugin and documentation stuff, like the list of built-in functions.
I'll provide binaries for other systems on request.

Example scripts

These example scripts should give you an idea of what is possible with Capri, and contain comments explaining more of the syntactical elements:

- GhostLibrary.capri this is the script that builds my userspace library, the GhostLibrary.
- Compilation.capri an actual support script that you can use for building, see the GhostLibrary script on how to use it

- Dependencies.capri explains dependencies
- Concurrency.capri explains concurrency
- Types.capri explains the types in capri
- Specialization.capri explains the specialization statements
- Levenshtein.capri levenshtein algorithm implementation
- QuickSort.capri QuickSort algorithm implementation
- FunctionReferences.capri gimmickry about function references


Questions, Suggestions?

There are quite some more things I'd have to write here about Capri, but until the documentation is ready you can find some info in the example scripts.
Suggestions are highly welcome, criticism even more, and feel free to ask any question right here.

Greets, Max

I like the idea of scripting but not the OOP in a build system. Something more natural to the shell or C would be more familar to a cli developer. I think you are trying to write a build system to appeal to people who wouldn't normally write their apps using OOP.

Also with the hasChanges the coder has to check the files need rebuilding manually not the build system automatically.

b.zaar wrote:I like the idea of scripting but not the OOP in a build system. Something more natural to the shell or C would be more familar to a cli developer. I think you are trying to write a build system to appeal to people who wouldn't normally write their apps using OOP.

Also with the hasChanges the coder has to check the files need rebuilding manually not the build system automatically.

You are not forced to do anything OOP related, you can write scripts completely functional, or even without any functions. The project around the tasks is not required, neither are tasks. You can just write code in the global scope. The projects can be seen like namespaces, you can use them to encapsulate functionality and make it better reusable (import "SomeUtil.capri"; SomeUtil.doSomething()).

Yes the programmer has to check the files, but this has the advantage that you can make it more intelligent - for example check if any header has changed, if so rebuild everything; if only a source has changed build that specific source.

max wrote:You are not forced to do anything OOP related

The built in functions are all in OOP format.

max wrote:The project around the tasks is not required, neither are tasks. You can just write code in the global scope. The projects can be seen like namespaces, you can use them to encapsulate functionality and make it better reusable (import "SomeUtil.capri"; SomeUtil.doSomething()).

Encapsulation may be handy... but it's then forcing OOP again if you include someone's else's support script.

Is the order important? Can I list the assemble task before the compile task and the system will sort it out?
Say a compile generates another .asm file, will the assemble task know it's been changed if the compile task is specified last?

max wrote:Yes the programmer has to check the files, but this has the advantage that you can make it more intelligent - for example check if any header has changed, if so rebuild everything; if only a source has changed build that specific source. ;)

Checking headers can be included automatically in most cases with a compiler command switch. Still hasChanges may be handy if the compiler can't write a .deps file.

I think you've concentrated on the task being important not the target. I like the idea that make checks the files and you write a script to create that file if it needs to be created. Your system makes a task the requirement for the target and this then checks it's file dependencies. It looks like a very manual system.

b.zaar wrote:The built in functions are all in OOP format.

No, they are only functions grouped in projects.

b.zaar wrote:Encapsulation may be handy... but it's then forcing OOP again if you include someone's else's support script.

Same thing - it's not OOP, it's only functions grouped in projects to make them easier accessible. It's like C but allowing namespaces.

b.zaar wrote:Is the order important? Can I list the assemble task before the compile task and the system will sort it out?
Say a compile generates another .asm file, will the assemble task know it's been changed if the compile task is specified last?
[...]
It looks like a very manual system.

It is a very manual system, because I don't like the idea of everything happening by magic - you get exactly what you write. The task order within the files is not important; see the dependencies example for how dependencies are called. There's always an entry pointer - by default the task "all" - and from there on everything goes its way. If you specify a different task in the command line (e.g. "capri clean") then this task and all it's dependencies is called.

Very nice.

I'll have a play with it shortly.
Love the fact that you released an Eclipse plugin

seuti wrote:Very nice.

I'll have a play with it shortly.
Love the fact that you released an Eclipse plugin

Thank you! Hope you like it. Yes the plugin makes it a little easier to write scripts

Updated to version 1.17b, fixed some bugs (including an evil one that made it crash when no "build.capri" was available on Linux/Mac).

Very excellent work! Thanks for sharing

I got a little question: In order to write such an interpreter system, what are the steps you had to go through and major topics you had to learn?

iocoder wrote:Very excellent work! Thanks for sharing

I got a little question: In order to write such an interpreter system, what are the steps you had to go through and major topics you had to learn?

Hey iocoder

Thanks a lot!
Well, Capri is an AST-Interpreter, that means it interprets the syntax tree that the parser generates.
So to write such an interpreter, you have to write:
- a Tokenizer (also known as Lexer) that has the ability to given you token by token. You say "next()" and it gives you the next token, like a keyword, literal, identifier, punctuoator, number.. and so on
- a Parser that uses the tokenizer to build the AST. for example, it always remembers the current token, so you can say isKeyword("function"), then skip to the next and see if there is an identifier.. than build an AST from this information
- now you can either convert that AST to some kind of intermediate code or simply interpret the AST

If you're interested in this, I will make Capri open source, then you can take a look.

Greets, Max

You could even JIT-compile the build script. Following steps are needed (they're very similar to max's):
- lex the code
- parse the token list to an AST
- compile the AST to assembly
- JIT the assembly

Of course, you can do it without the 2nd and 3rd step, but for getting into the topic, it makes your life easier. Also consider that you will have to optimize at some point, too, or you will get poor performance for big (or recursive) build scripts.

For getting an idea about how JITting can be done, read this article.

no92 wrote:You could even JIT-compile the build script. [...]

Yes you could use JIT, but when doing that you should better not compile everything, but only the parts that are called very often, because compiling itself would also take a little time (similar to Java's HotSpot).

You should make this open source; honestly I wouldn't trust a build tool to build my project unless I could build the tool itself. Plus, you'd get the benefits of open source, including bugfixes and stuff, and a bugtracker and stuff if you use github. Also, assuming you are using VCS, if your hard drive broke you'd have all of the history and the whole project backed up for free. And you would still have complete control on what gets into the project and stuff like that.

It seems good, especially for OSDev. Keep up the great work

Lionel wrote:You should make this open source; honestly I wouldn't trust a build tool to build my project unless I could build the tool itself. Plus, you'd get the benefits of open source, including bugfixes and stuff, and a bugtracker and stuff if you use github. Also, assuming you are using VCS, if your hard drive broke you'd have all of the history and the whole project backed up for free. And you would still have complete control on what gets into the project and stuff like that.

It seems good, especially for OSDev. Keep up the great work

Hey Lionel,
Thank you for the good feedback!
In fact I do already host my project as a private project on bitbucket to have VCS, and also I'm planning to release it as open source on github. I first want do a little cleanup & documentation and let some people test it & give their experiences on here before I make the first public release.

Didn't noticed this topic I was excepting it long ago