terralang / terra Goto Github PK

src/tdebug.cpp does not compile on my 32-bit Linux system.
The problem appears to begin on lines 124 to 126 (in function printstacktrace):

#ifdef __linux__
        rip = (void*) uc->uc_mcontext.gregs[REG_RIP];
        rbp = (void*) uc->uc_mcontext.gregs[REG_RBP];

As I understand it, REG_RIP and REG_RBP will be undefined here on 32-bit systems.

clang output:

/usr/bin/clang++ -g -I build/LuaJIT-2.0.2/src -I /usr/include -I /usr/include -I build -fPIC -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_4 -DTERRA_CLANG_RESOURCE_DIRECTORY="\"/usr/lib/clang/3.4/include\"" src/tdebug.cpp -c -o build/tdebug.o
src/tdebug.cpp:125:45: error: use of undeclared identifier 'REG_RIP'; did you mean 'REG_EIP'?
        rip = (void*) uc->uc_mcontext.gregs[REG_RIP];
                                            ^~~~~~~
                                            REG_EIP
/usr/include/sys/ucontext.h:186:3: note: 'REG_EIP' declared here
  REG_EIP,
  ^
src/tdebug.cpp:126:45: error: use of undeclared identifier 'REG_RBP'; did you mean 'REG_EBP'?
        rbp = (void*) uc->uc_mcontext.gregs[REG_RBP];
                                            ^~~~~~~
                                            REG_EBP
/usr/include/sys/ucontext.h:170:3: note: 'REG_EBP' declared here
  REG_EBP,
  ^
2 errors generated.
Makefile:222: recipe for target 'build/tdebug.o' failed
make: *** [build/tdebug.o] Error 1

I'm using today's version from github.

(terralib shell) terralib.includec "ncurses.h"
terra: src/tcwrapper.cpp:184: bool IncludeCVisitor::GetType(clang::QualType, Obj *): Assertion `!"bool?"' failed.
Stack dump:
0.  /usr/include/ncurses.h:542:1: current parser token 'typedef'
zsh: abort (core dumped)  terra

The line 184 in the source code is:
assert(!"bool?");

I'm not sure what should be checked here. To my understanding this assertion will always fail since the compile-time string will be treated as a memory address different from zero. A negated non-zero value will evaluate to false and thus the assertion will always fail.

If the assert statement was put here to indicate that there is some code that still needs to be written, a comment would have been helpful.

This looks like a really promising project. Keep up the great work!

Is there ARM support on the roadmap?

I'm fooling around with a beagleboard at the moment. I've successfully gotten llvm/clang compiled and even terra too (with a small modification to tdebug.cpp where it handles mcontext_t), but alas it looks like tcompiler.cpp (and probably others too) are designed with x86 in mind.

Terra does not build as a shared library. To make my own shared library I need to statically link libterra.a and luajit.a. To make this work I had to

FLAGS=-g -fPIC $(INCLUDE_PATH)
and
changed
(cd $(LUAJIT_DIR); make CC=$(CC))

to

(cd $(LUAJIT_DIR); make CC=$(CC) STATIC_CC="$(CC) -fPIC")

After that I can build my shared library. Maybe i'm doing it wrong.

Since Terra currently generates a LuaJIT ctype for every terra type, so we are subject to this limit. Furthermore Terra internally generates some anonymous types that artificially bloats the number of ctypes. We need to fix the Terra types to only request/create a ctype in LuaJIT when they are directly needed (e.g., when a function type is called). This will also fix the issues with intermediate types using up ctype ids.

In this line (src/tllvmutil.cpp:148) STDOUT_FILENO is used. This is defined in <unistd.h>, and adding this include at the top allowed the latest master to build.

I first wanted to make a pull request, but then I've realized it's a Unix constant, and probably should be provided in some cross-OS way.

I was building on Xubuntu 13.04 myself.

Terra functions returning bool return a number, not a boolean true or false as they should according to LuaJIT ffi semantics.

terra bar() : bool ; return true end
=bar()
1
=type(bar())
number
b = ffi.new('bool[1]')
b[0] = true
return b[0]
true

As I seen in "Getting Started" section, Terra runs on 64-bit windows for now.
Will it run on 32bit windows in future, or maybe someone know a workaround to compile projects for win32 from 64-bit systems (or 32-bit linux), for example?

When compiling the sample program, terra exits with the error "terra: src/tcwrapper.cpp:665: int register_c_function(lua_State *): Assertion `llvmfn' failed.". I'm using the newest version of terra from git (commit 3157186), and compiling the code on Linux.

It seems that fscanf is not properly registered with LLVM, but I have no idea why.

Regards,
Jan

Sample program:

cio = terralib.includec("stdio.h")

terra doit()
var f: &cio.FILE = cio.fopen("testfile")
var a: int = 0
var b: int = 0
cio.fscanf(f, "%d %d", &a, &b)
cio.fclose(f)
end

doit()

local math = require('math')
terra foo(n:double) return n == math.huge end
terra bar(n:double) return n == 1.0/0 end

foo(math.huge) returns 0 while bar(math.huge) returns 1

local S = terralib.require("std")
local IntVector = S.Vector(int)
terra foo()
    var v = IntVector.salloc():init()
    for i=0,10 do v:insert(1) end
    for e in v do S.printf("%d\n", e) end
end
foo()

results in the error

src/terralib.lua:534: Errors reported during compilation.
tmp.t:19: expected a struct with a __for metamethod but found &Vector(int32)
    for e in v do S.printf("%d\n", e) end

Replacing v with @v in the offending line fixes the problem, but this shouldn't be necessary.

Would it be possible to make printpretty() work on uncompiled function definitions? Currently, calling it forces the function to compile. This seems possible in principle, since the AST is there. I understand that the output would need to be a little different (missing types, for instance), but this can be really helpful for quickly seeing why a dynamically generated Terra function isn't compiling.

When trying to get the size of a pointer with sizeof, terra seems to think &int is not a type.

trie.ter:10: expected a terra expression but found table
    var size = sizeof(&int)
                             ^
trie.ter:10: argument to operator must be an lvalue
    var size = sizeof(&int)
                             ^
trie.ter:10: error while invoking macro or metamethod: src/terralib.lua:762: quoted value is not a type
    var size = sizeof(&int)
                         ^

The API docs suggest constant can be called without terralib., like global, but this isn't the case.

Should the docs or reality be considered at fault?

I try to make terra. It fails:

/usr/bin/../bin/clang++ -g -I build/LuaJIT-2.0.2/src -I  -I /usr/bin/../include -I build -fPIC -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_ -DTERRA_CLANG_RESOURCE_DIRECTORY="\"/usr/bin/../lib/clang//include\"" src/tcompiler.cpp -c -o build/tcompiler.o
clang: warning: /usr/bin/../include: 'linker' input unused
In file included from src/tcompiler.cpp:27:
src/llvmheaders.h:6:10: fatal error: 'llvm/Support/Valgrind.h' file not found
#include "llvm/Support/Valgrind.h"

I have:

Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

In a early attemp, I need to download clang and build locally, but wonder if I have something wrong or is a limitation of the make process

Hi @zdevito, thanks for building terra - looks very very neat! I have one question: It's possible to generate a native executable for both lua and terra like https://code.google.com/p/llvm-lua/ does? I'm asking that because isn't possible to use JIT on iOS and ffi on interpreter level is much more slow than plain C bindings.

Current workaround: at terralib.lua line 2998, replace:

•        local cb = terra.cast(castedtype,fn)
  

•        local fptr = terra.pointertolightuserdata(cb)
  

with:

•        local success, cb = pcall(terra.cast, castedtype, fn)
  

•        if not success then diag:reporterror(anchor, cb) end
  

•        local fptr = success and terra.pointertolightuserdata(cb)
  

Hi,

I am trying to use libuv with terra
In these lines I get error regarding casting to &C.uv_tcp_t:

client = [&C.uv_tcp_t] C.malloc(sizeof(C.uv_tcp_t));
C.uv_tcp_init(loop, client);

types are imported from libuv.h

this struct is defined as

typedef struct uv_tcp_s uv_tcp_t;

It works properly using your new macro

(btw, getting started example for new macro is outdated)

Thanks for terrific tool!

Regards
Pawel

On debian systems, clang is not in the llvm/bin directory. I was able to compile with the following change, but it may not be the best fix.

diff --git a/Makefile b/Makefile
index 6ee5b57..b4f5b68 100644
--- a/Makefile
+++ b/Makefile
@@ -10,8 +10,8 @@

LLVM_CONFIG ?= $(shell which llvm-config)
LLVM_COMPILER_BIN ?= $(shell $(LLVM_CONFIG) --bindir)
-LLVM_CXX ?= $(LLVM_COMPILER_BIN)/clang++
-LLVM_CC ?= $(LLVM_COMPILER_BIN)/clang
+LLVM_CXX ?= clang++
+LLVM_CC ?= clang
CUDA_HOME ?= /usr/local/cuda

LLVM_PREFIX=$(shell $(LLVM_CONFIG) --prefix)

struct foo {
x : int8[64];
}

GLOBAL_STRUCT = terralib.new(foo)
GLOBAL_PTR_TO_STRUCT = terralib.cast(&foo, terralib.new(int8[64]))

-- snip initialize x to some null-terminated string

in terra code:

c.printf('%s', foo.x + 0)

will work fine for the pointer, but not for GLOBAL_STRUCT

Trying to build I get the following output. I have downloaded the recommended llvm+clang distribution to /usr/local and created a Makefile.inc with LLVM_CONFIG=/usr/local/bin/llvm-config.

I do have years of installing or building various LLVM versions and getting things from MacPorts and Homebrew, so I can imagine environment problems on my end if this is not a problem others are seeing.

LUA_PATH=build/LuaJIT-2.0.1/src/?.lua build/LuaJIT-2.0.1/src/luajit -bg src/terralib.lua build/terralib.h
LUA_PATH=build/LuaJIT-2.0.1/src/?.lua build/LuaJIT-2.0.1/src/luajit -bg src/strict.lua build/strict.h
LUA_PATH=build/LuaJIT-2.0.1/src/?.lua build/LuaJIT-2.0.1/src/luajit -bg src/cudalib.lua build/cudalib.h
/usr/local/bin/clang -v src/dummy.c -o build/dummy.o 2>&1 | grep -- -cc1 | head -n 1 | xargs build/LuaJIT-2.0.1/src/luajit src/genclangpaths.lua build/clangpaths.h -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include""
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -x c++-header src/llvmheaders.h -o build/llvmheaders.h.pch
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/main.cpp -c -o build/main.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/linenoise.cpp -c -o build/linenoise.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tkind.cpp -c -o build/tkind.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tcompiler.cpp -c -o build/tcompiler.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tllvmutil.cpp -c -o build/tllvmutil.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tcwrapper.cpp -c -o build/tcwrapper.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tinline.cpp -c -o build/tinline.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/terra.cpp -c -o build/terra.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/lparser.cpp -c -o build/lparser.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/lstring.cpp -c -o build/lstring.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/lobject.cpp -c -o build/lobject.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/lzio.cpp -c -o build/lzio.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/llex.cpp -c -o build/llex.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/lctype.cpp -c -o build/lctype.o
/usr/local/bin/clang++ -g -I build/LuaJIT-2.0.1/src -I build -I /usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O0 -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fvisibility-inlines-hidden -DLLVM_3_2 -DTERRA_CLANG_RESOURCE_DIRECTORY=""/usr/local/lib/clang/3.2/include"" -include-pch build/llvmheaders.h.pch src/tcuda.cpp -c -o build/tcuda.o
rm -f build/libterra.a
ar -cq build/libterra.a build/tkind.o build/tcompiler.o build/tllvmutil.o build/tcwrapper.o build/tinline.o build/terra.o build/lparser.o build/lstring.o build/main.o build/lobject.o build/lzio.o build/llex.o build/lctype.o build/tcuda.o
/usr/local/bin/clang++ build/main.o build/linenoise.o build/libterra.a -o terra -g -Lbuild -lluajit -lterra -L/usr/local/lib -lclangFrontend -lclangDriver -lclangSerialization -lclangCodeGen -lclangParse -lclangSema -lclangAnalysis -lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMHexagonAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsCodeGen -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMAsmPrinter -lLLVMARMInfo -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport -lclangRewriteCore -pagezero_size 10000 -image_base 100000000
Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option
(maybe you meant: __ZN4llvm8FastISel13startNewBlockEv, __ZN5clang17ObjCInterfaceDecl15startDefinitionEv , __ZN4llvm17ScheduleDAGInstrs10startBlockEPNS_17MachineBasicBlockE , __ZN5clang4Sema21startLambdaDefinitionEPNS_13CXXRecordDeclENS_11SourceRangeEPNS_14TypeSourceInfoENS_14SourceLocationEN4llvm8ArrayRefIPNS_11ParmVarDeclEEE , __ZN5clang7ASTUnit16ConcurrencyState5startEv , __ZN4llvm24llvm_start_multithreadedEv , __ZN4llvm5Timer10startTimerEv , __ZN5clang7TagDecl15startDefinitionEv , __ZN5clang13MangleContext16startNewFunctionEv , __ZN5clang16ObjCProtocolDecl15startDefinitionEv )
ld: symbol(s) not found for architecture x86_64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [terra] Error 1

As asked in http://www.freelists.org/post/luajit/About-building-a-simple-language-on-top-of-luajit-or-terra I'm evaluating lua as a runtime for a toy language. After read https://github.com/zdevito/terra/blob/master/api-reference.md look like is possible to extend the syntax. However, is possible to replace it? ie: I want to use a pythonic-like syntax and conventions, not lua.

I'm looking to build:

• Python-like syntax
• GO-like class system
• UTF8 strings
• Implement go-like channels or actors
• Functional abilities
• LINQ/SQL-like way to query collections
• Integrate database(sqlite) and data manipulation
• Be able to run in iOS (I understand if this is not ready rigth now)

And the other 2 things that look hard are:

• Have a REPL
• Have a debugger

Having a REPL I think is easy in a dynamic language, but the debugger is the one that look hard (is rare that new languages have a debugger). terra could work with the lua debug api?

If I run the following program to emit an executable from terra then run it under valgrind, valgrind complains about there being an illegal instruction:

stdlib = terralib.includec("stdlib.h")

local length = 8

local struct Entry{
  key : int,
}

local struct Table{
  occupancy : uint64,
  entries : &Entry
}

terra Table:find_entry(key : int) : &Entry
  if self.occupancy >= 6.0  then
    self:find_entry(key)
    return self:find_entry(key)
  else
    self.entries.key = key
    return self.entries
  end
end

terra main()
  var x : Table
  x.occupancy = 0
  x.entries = [&Entry](stdlib.calloc(length, sizeof(Entry)))
  x:find_entry(1)
  return 0
end

terralib.saveobj("bug", {main=main})

Valgrind error:

vex amd64->IR: unhandled instruction bytes: 0xC5 0xFA 0x7E 0x3 0xC5 0xF9 0x62 0x5
==22573== valgrind: Unrecognised instruction at address 0x400518.
==22573==    at 0x400518: Table_methods_find_entry0 (in /home/david/projects/terra/bug)
==22573== Your program just tried to execute an instruction that Valgrind
==22573== did not recognise.  There are two possible reasons for this.
==22573== 1. Your program has a bug and erroneously jumped to a non-code
==22573==    location.  If you are running Memcheck and you just saw a
==22573==    warning about a bad jump, it's probably your program's fault.
==22573== 2. The instruction is legitimate but Valgrind doesn't handle it,
==22573==    i.e. it's Valgrind's fault.  If you think this is the case or
==22573==    you are not sure, please let us know and we'll try to fix it.
==22573== Either way, Valgrind will now raise a SIGILL signal which will
==22573== probably kill your program.
==22573== 
==22573== Process terminating with default action of signal 4 (SIGILL)
==22573==  Illegal opcode at address 0x400518
==22573==    at 0x400518: Table_methods_find_entry0 (in /home/david/projects/terra/bug)

This code segfaults, because of global variable
When you uncomment line with assignment of new value to global it works properly
Also it works for constant value OK

local C = terralib.includecstring(
[[
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
]]
)


local gstr = global(&int8, "some text")
--local gstr = constant(&int8, "some text")
--gstr = "something new"

terra fun1()
    C.printf("gstr: %s \n", gstr)
    return 0
end

fun1:printpretty()

fun1()

http://www.vim.org/scripts/script.php?script_id=4663 is a functional terra.vim—I just hacked up lua.vim by removing the pre-Lua 5.2 conditions and adding Terra's keywords, types, etc.

It's not pretty, and almost certainly not the 'right' way to do this (which I imagine would involve piggybacking lua.vim), but it's at least something in the meantime.

(The most annoying problem is fixed: terra and quote now balance with end.)

I am trying to integrate Terra with the evented I/O library libuv, but I am having some troubles getting Terra to process the uv.h header. When I run includec() on the header I get this error:

src/terralib.lua:1479: expected a type but found table

A bit stumped on how to debug the problem further. Any ideas on what is going wrong?

For now I have moved on by just copying over bits of uv.h into Terra code by using includecstring(). So far I haven't seen the same error with my limited subset.

We support __sub but not __unm

In order to support loading pre-compiled Terra code, and including the same C types from different calls to terralib.includec, it will be necessary to link Terra types together after they are created.

Whenever I pass more than one terra vector object to a terra function from lua scope, the 2nd vector does not seem to escape properly. Example code below. Notice that when lua variable d is passed to the terra add function, its components are all set to 0, when it should be {4.3, 3.2, 2.1, 1.9}.

local clib = terralib.includec("stdio.h")
terra check (v : vector(float, 4))
clib.printf("contents: %f %f %f %f\n", v[0], v[1], v[2], v[3]);
end

terra create_float_vector (a : float, b : float, c : float, d : float)
return vector(a, b, c, d)
end

terra add (v1 : vector(float, 4), v2 : vector(float, 4)) : vector(float, 4)
var v3 = v1 + v2
check(v1)
check(v2)
return v3
end

c = create_float_vector(1.5, 2.5, 3.5, 4.5)
d = create_float_vector(4.3, 3.2, 2.1, 1.9)

print("vectors initialized to...")
check(c)
check(d)

print()
print("argument values:")
e = add(c, d)

print()
print("result:")
check(e)

e.g.

terra foo(s : &int8)
var arr : int8[128];
foo(arr) -- error
foo(arr + 0) -- works
end

This behavior is different to LuaJIT by itself (same version) so I guess it's a (very minor) Terra bug.

=0x0f
stdin:1: expected near 'f'
=0x0F
15

Am I doing this wrong?

local struct foo {
    x : int
}

terra foo:bar()
    return self.x
end

local f = terralib.new(foo, 42)
print(f:bar())

'struct foo_0' has no member named 'bar'

I'm wondering has anyone tried getting a working Terra environment under Windows?

printpretty() doesn't show grouping with parens. So

terra foo()
return (1 + 2) * (2 + 3)
end

and

terra bar()
return 1 + 2 * 2 + 3
end

will print the same way. With this status quo, it can be hard to tell if a function dynamically generated from some other IR is actually getting generating correctly.

Running into another C wrapping bug with struct fields disappearing.
The current implementation for wrapping structures will use the first
RecordDecl it visits to create the "entries" fields. The problem this causes
is when the first RecordDecl is not "complete".

Example:

test = terralib.includecstring([[
    typedef struct foo foobar;
    struct foo { int x; };
    void test(struct foo f);
]])
terralib.linklibrary("libtest.dylib")

terra main()
    var s : test.foo
    s.x = 1
end

main()

Notice the typedef statement which will cause clang to generate two RecordDecl here. The first one from the typedef is not a complete definition. We won't have a complete definition until the actual struct statement.

If you run the test case you'll get an error about there being no "x" field.

I have a working fix, but unfortunately I am having some problems making it be stable.
The solution I am after is to basically defer creating the "entries" until we get a complete
RecordDecl definition (getDefinition() will return the actual definition if there is one otherwise NULL).

I basically just moved the GetFields call out of the block that creates the Terra type.
Then each time GetType() is called I check if the entries fields exists. With this change
it fixes the simple test case, but a more complex test causes the assert "unexpected class" to pop up in tcompiler. Not sure yet if this is related to my change or not. It also seems to break some of the Terra tests.

Any tips or suggestions if this is the right fix would be appreciated.

Hey, is C++ support is planned? I would love to learn and script the bullet physics engine with terralang. :D

includec takes additional arguments that are passed to clang. Unfortunately it doesn't seem to work to silence warnings. e.g.

terralib.includec('stdio.h', '-w')
:149:11: warning: 'gets' is deprecated
(void)gets;
^
/usr/bin/../include/stdio.h:638:14: note: 'gets' declared here
extern char *gets (char *s) __wur __attribute_deprecated;
^

The -w argument works fine to suppress the warning when compiling a C program with clang that uses gets.

Deprecation warnings should probably be silent by default, as includec('stdio.h') does not imply that I would actually use gets, so the warning is for nothing most of the time

LLVM is beginning the process of replacing the current JIT with it's newer MCJIT. While the version in 3.3 was a little buggy, it has been improved and stabilized in 3.4.

The main problem for Terra (and others) is that you can no longer add functions to a module once it is compiled. MCJIT is multi-module (you can link references/call-sites across modules) so the common approach is place every function in its own module and judiciously use prepare_call/prepare_global.

Useful references include the LLVM blog post and the follow-up on effective migration techniques, and the recent pull-request for Julia of a similar migration.

main.t:64: invalid conversion from SDL_Color to SDL_Color
                var surface = SDL.TTF.RenderUNICODE_Solid(font, render_string, tileType.color)

tileType is of type TileType, which looks like this:

struct TileType {
    name : &uint8,
    symbol : uint16,
    color : SDL.Color,
    flags : int
}

Where color is defined like this:

SDL = terralib.includec("SDL/SDL.h")
SDL.Color = SDL.SDL_Color
SDL.Color:complete()

Whereas RenderUNICODE_Solid is defined this way:

SDL.TTF = terralib.includec "SDL/SDL_ttf.h"
SDL.TTF.RenderUNICODE_Shaded = SDL.TTF.TTF_RenderUNICODE_Shaded

I guess there's a problem since SDL_ttf.h includes SDL.h, and so does my terralib.includec("SDL/SDL.h") code?

Using terra, is possible to use a debugger like gdb or lldb or something else that let do step, inspect vars, etc?

Hello!
I'm a maintainer at MacPorts, and I'd like to include terra in our packages palette. I'm having some difficulties understanding the includes in src/treadnumber.c. I modified the makefile to link with our existing luaJIT (it's a separate package), and I noticed two C files are included from the luaJIT source. Would it be possible for terra to be independent of luaJIT source?

terralib.includecstring([[
#include <tmmintrin.h>
__m128i foo(__m128i a, __m128i b) { return _mm_shuffle_epi8(a,b); }
]], '-msse4.2')

warning: implicit declaration of function '_mm_shuffle_epi8' is invalid in C99

Which is the same error if you put that in a .c file and compile without -msse4.2. The same code compiles fine if you pass clang the flag, it doesn't seem possible to do that in Terra.

If you include a header that has an asm block anywhere, no matter whether it is actually used by your program, you can not start JIT.

To make clear how serious this is:

mydependency.h
-> includes myoptionaldependency.h

Now if "myoptionaldependency.h" contains an asm block, regardless of whether it is used or not, it will stop you from using JIT. This could get quite ugly with deep layers of inclusion, where one of them somewhere for some reason uses asm

e.g. terra foo.t --help should pass --help on to foo.t instead of displaying the help for terra

LuaJIT passes the arguments on to the script correctly

require'lfs'
error loading module 'lfs' from file '/usr/local/lib/lua/5.1/lfs.so':
/usr/local/lib/lua/5.1/lfs.so: undefined symbol: lua_gettop

This is likely because Terra links statically to LuaJIT, which will exclude the unused LuaJIT symbols by default. How might this be resolved? I think there's a way to tell the linker to include those symbols? Probably that should be enabled by default in the Makefile?

Lua relies on thrid-party libraries due to it's "batteries not included" philosophy, so this is probably going to be a problem for most people.

In these cases it seems very clear which overload should be used (in terra function):

assert_ne([int64](n), [int64](0))

call to overloaded function is ambiguous. can apply to both (int32,int32) and (int64,int64)

assert_ne([int](n), [int](0))

call to overloaded function is ambiguous. can apply to both (int32,int32) and (int64,int64)

Tried to compile on Manjaro Linux (Arch Linux based distro)but at first it didn't work. Got error messages like "unknown type name 'ucontext_t'". Tried to include the ucontext.h header in tcompiler.cpp and it compiled just fine!

string=terralib.includec('string.h')
buf=terralib.new(int8[1024])
=string.strerror_r(1,buf,1024)
terra: src/tcwrapper.cpp:608: int register_c_function(lua_State *): Assertion `llvmfn' failed.
Aborted (core dumped)

It works with the ffi:

ffi=require'ffi'
ffi.cdef'const char* strerror_r(int errnum, char *buf, size_t buflen);'
buf = ffi.new('char[?]',1024)
=ffi.string(ffi.C.strerror_r(1,buf,1024))
Operation not permitted

Not a bug, probably a misunderstanding.

local C = terralib.includec("stdio.h")

Can be used to load the functions in stido.h. To load another library in a nonstandard location say library Foo, i did

export INCLUDE_PATH=path to header files
in a .t file

F = terralib.includec("foo.h")
terra what()
return F.myfunction(2.1)

caused
LLVM ERROR: Program used external function mfunction could not be resolved.

Fixed as
local ffi = require("ffi")
F = terralib.includec("foo.h")
ffi.load("/usr/share/mylibs/libfoo.so",true)

terra what()
return F.myfunction(2.1)