Kite Programming Language

Welcome to Kite

Kite is a programming language designed to minimize as much of the programmer experience as possible — quick development and running time and low CPU and memory usage. As this is a new project, we're just getting things started. Feel free to poke around and learn more!

kite-llvm 0.2.0 released

Written by Mooneer Salem on Wednesday 26th of December, 2012 in Usage

kitellvm 0.2.0 has been released.

Changes from 0.1.0:

  • Now uses the same Flex/Bison based parser that nonLLVM Kite uses, significantly improving compile time. 100% of Kite syntax can now be parsed as well.
  • Added string|format to the standard library.
  • kdoc (System.doc) support and prerequisite System.object methods now fully functional.
  • eval statement now supported (e.g. eval 1|print;).
  • Code versioning support from nonLLVM Kite is now active.
  • Fixed compile errors on some systems.

Download: http://kitelanguage.org/files/kitellvm0.2.0.tar.gz
Github (development/issue tracking): https://github.com/tmiw/kitellvm

kite-llvm 0.1.0 released

Written by Mooneer Salem on Saturday 8th of December, 2012 in Releases

kitellvm 0.1.0 has now been released. This is a very preliminary early version of the kitellvm code base and will probably have lots of bugs.

What kitellvm currently supports:

  • The vast majority of Kite syntax.
  • Most of the Kite standard library (see here for a reference).
  • An interactive REPL (ikt).
  • The ability to autoattach a gdb session to your application on an unhandled exception and view stack traces, etc.

What kitellvm does not support right now (not an exhaustive list):

  • kdoc (code syntax and the System.doc namespace).
  • The interface.* namespaces in the standard library.
  • File versioning.

Download: http://kitelanguage.org/files/kitellvm0.1.0.tar.gz
Github (development/issue tracking): https://github.com/tmiw/kitellvm

kite-llvm and eval support

Written by Mooneer Salem on Wednesday 5th of December, 2012 in Usage

Tonight, the eval construct was finally added to kitellvm. This feature has always been in the original Kite but was never added to the LLVM version.

What is eval, you ask? Think of it as a way to dynamically compile and execute code. Example:


harry-2:build mooneer$ bin/kite
eval "\"hello, world!\"|print;";
^D
hello, world!
harry-2:build mooneer$

You can also modify variables defined outside of the eval:


harry-2:kite-llvm mooneer$ cat tests/semantics/eval/modify_variables.kt
i = 0;
eval "i = i + 1;";
i|print;
harry-2:kite-llvm mooneer$ src/kite ./tests/semantics/eval/modify_variables.kt
1
harry-2:kite-llvm mooneer$

This works because eval is effectively equivalent to dynamically compiling a new method whose arguments are the contents of the symbol table at the eval call. :)

Feel free to leave a comment if you have any questions~

On debug symbols

Written by Mooneer Salem on Sunday 2nd of September, 2012 in General

LLVM has a facility to emit debug symbols. As you may know, debug symbols are what allow debuggers such as gdb to work. Im happy to report that kitellvm now emits debug symbols and allows gdb to have basic functionality:

(gdb) break exception.cpp:49
Breakpoint 1 at 0x144e609: file src/stdlib/System/exceptions/exception.cpp, line 49.
(gdb) run test_exc.kt 
Starting program: /home/mooneer/kite-llvm/kite test_exc.kt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, kite::stdlib::System::exceptions::exception::throw_exception (this=0x215a2d0)
    at src/stdlib/System/exceptions/exception.cpp:49
49                      int num_traces = backtrace(buf, NUM_TRACE);
(gdb) bt
#0  kite::stdlib::System::exceptions::exception::throw_exception (this=0x215a2d0)
    at src/stdlib/System/exceptions/exception.cpp:49
#1  0x0000000001421d7f in kite::stdlib::System::exceptions::exception::s_throw (exc=0x215a2d0)
    at src/stdlib/System/exceptions/exception.h:59
#2  0x00007ffff7f48168 in __static_init____o () at test_exc.kt:2
#3  0x000000000144a31b in kite::stdlib::language::kite::kite::ExecuteCode (ast=..., context=0x215afa0, 
    suppressExec=false) at src/stdlib/language/kite.cpp:265
#4  0x0000000001449ff1 in kite::stdlib::language::kite::kite::ExecuteCode (ast=..., suppressExec=false)
    at src/stdlib/language/kite.cpp:201
#5  0x00000000013ea54b in main (argc=1, argv=0x7fffffffe6a0) at src/apps/kite.cpp:98
(gdb) up
#1  0x0000000001421d7f in kite::stdlib::System::exceptions::exception::s_throw (exc=0x215a2d0)
    at src/stdlib/System/exceptions/exception.h:59
59                      static void s_throw(exception *exc) { exc->throw_exception(); }
(gdb) 
#2  0x00007ffff7f48168 in __static_init____o () at test_exc.kt:2
2       (make System.exceptions.TypeMismatch())|throw;
(gdb) list
1   run [
2       (make System.exceptions.TypeMismatch())|throw;
3   ] catch [
4       __exc|print;
5   ];
(gdb) 

Unfortunately, this works only on Linux (Apples gdb is too old, as it turns out). Eventually I want to be able to show function names/file/line numbers in exception stack traces on both OSX and Linux, but this may involve some work. Alternatively, would it be possible to automatically start gdb with the applications current process ID immediately upon getting an unhandled exception? This might require additional debug info to be output, though.

Interesting LLVM "bug" found

Written by Mooneer Salem on Monday 16th of January, 2012 in General

Today I added parser and codegen support for the return keyword. As in other languages, its designed for the developer to exit a method early. Unfortunately, it didnt work right away:

$ ./kite
method x()
[
    return 1;
];

x()|print;
^D
System.exceptions.NotImplemented: Could not find method print that takes 0 argument(s).
    in (main program) + 0x79
$

Investigating further, I noticed that it was generating the following LLVM intermediate code:

; ModuleID = '__root_module'

@0 = internal constant [5 x i8] c"x__o\00"
@1 = internal constant [6 x i8] c"print\00"

define i32* @__static_init____o(i32* %this) {
entry:
  %0 = alloca i32*
  store i32* %this, i32** %0
  %1 = call i32* @kite_method_alloc(i32* bitcast (i32* (i32*)* @x__o to i32*), i32 1)
  %2 = load i32** %0
  %3 = call i32** @kite_dynamic_object_get_property(i32* %2, i8* getelementptr inbounds ([5 x i8]* @0, i32 0, i32 0), i1 true)
  store i32* %1, i32** %3
  %4 = load i32** %0
  %5 = call i32* @x__o(i32* %4)
  %6 = call i32* @kite_find_funccall(i32* %5, i8* getelementptr inbounds ([6 x i8]* @1, i32 0, i32 0), i32 1)
  %7 = bitcast i32* %6 to i32* (i32*)*
  %8 = call i32* %7(i32* %5)
  ret i32* %8
}

define i32* @x__o(i32* %this) {
entry:
  %0 = alloca i32*
  store i32* %this, i32** %0
  %1 = call i32* @System__integer__obj__i(i32 1)
  ret i32* %1
  ret i32* %1
}

declare i32* @System__integer__obj__i(i32)

declare i32* @kite_method_alloc(i32*, i32)

declare i32** @kite_dynamic_object_get_property(i32*, i8*, i1)

declare i32* @kite_find_funccall(i32*, i8*, i32)

Note the part in bold. Two ret statements are being outputthe one from return, and the normal one thats generated at the end of every method. Normally LLVM would eventually generate machine code that simply skips over the second ret statement. Or so youd think.

What I noticed is that System__integer__obj__i() would do the correct thing and return a valid System::object pointer, while kite_find_funccall() would get a totally different pointer. Even though according to the above, the return value from obj__i() gets fed directly into kite_find_funccall(). I confirmed this time and time again in gdb.

The fix? Using the same code suppression logic that I implemented for break/continue to suppress the last ret. Now it works as intended:

$ ./kite
method x()
[
    return 1;
];

x()|print;
^D
1
$

EDIT: this was on LLVM 2.9. I have yet to try 3.0 to see if this issues fixed there. If not, a bug report might be pending in the future.

EDIT 2: Link to LLVM bug report. Was able to duplicate the problem in 3.0 as well.