Open tripleo1 opened 2 years ago
Hi @tripleo1.
Interesting experiment you are trying to do here! Well, it used to work due to a weakness in how g++ was processing weak symbols. You can "patch it" as follows:
diff --git a/make-it-quick b/make-it-quick
--- a/make-it-quick
+++ b/make-it-quick
@@ -1 +1 @@
-Subproject commit e5fd9fe0398c9406e4556de6c577613c1d36e0d6
+Subproject commit e5fd9fe0398c9406e4556de6c577613c1d36e0d6-dirty
diff --git a/recorder b/recorder
--- a/recorder
+++ b/recorder
@@ -1 +1 @@
-Subproject commit 2f8a4db21337098b5e7f0130d5bf2a8928ef4647
+Subproject commit 2f8a4db21337098b5e7f0130d5bf2a8928ef4647-dirty
diff --git a/xl2/native/library/runtime/C/xl_lib.h b/xl2/native/library/runtime/C/xl_lib.h
index 8affebd9..fbfc03f4 100644
--- a/xl2/native/library/runtime/C/xl_lib.h
+++ b/xl2/native/library/runtime/C/xl_lib.h
@@ -329,7 +329,7 @@ namespace xl
{
namespace console
{
- extern std::vector< ::text > arguments;
+ std::vector< ::text > arguments;
}
}
@@ -584,4 +584,3 @@ int main(int argc, char **argv)
#endif
return 0;
}
Please note that since you are trying to use the native library, your -I
path is also suspect. I used:
g++ -I../../native/library/runtime/C HelloWorld_native.cpp -o HelloWorld_native
Also, you won't get very far down that path. IIRC, the bxl
binary is a bootstrap compiler, with very little true XL semantics. The nxl
compiler would be a bit better, but getting it to work is tricky, because it's only error message when a file is not found is "core dumped". So it's frustrating as hell.
Now, to be fair, the XL2 compiler is considered obsolete, and way down on my to-do list. At the moment, I'm (very occasionally) trying to get XLR to actually do something useful (like being able to run Tao3D without LLVM, because an old/incompatible/hard-to-predict version of LLVM is required for the graphics engine on many Linux configuration).
The reasons for this stupidly ugly mess are explained here: https://xlr.sourceforge.io/#history-of-xl. In two words: bit rot.
On 11/24/21 12:23 PM, Christophe de Dinechin wrote:
Now, to be fair, the XL2 compiler is considered obsolete, and way down on my to-do list. At the moment, I'm (very occasionally) trying to get XLR to actually do something useful (like being able to run Tao3D without LLVM, because an old/incompatible/hard-to-predict version of LLVM is required for the graphics engine on many Linux configuration).
The reasons for this stupidly ugly mess are explained here: https://xlr.sourceforge.io/#history-of-xl https://xlr.sourceforge.io/#history-of-xl. In two words: bit rot.
I just chose that one because it was the only one that seemed to work. I think I read most of what you wrote -- I was excited to find that this project was still alive (I discovered it many years ago).
So which compiler should I be using and what capabilities does it have?
Note: I just banged out an email without really considering your reply, but I'll read some more...
On 11/24/21 12:23 PM, Christophe de Dinechin wrote: I just chose that one because it was the only one that seemed to work. I think I read most of what you wrote -- I was excited to find that this project was still alive (I discovered it many years ago). So which compiler should I be using and what capabilities does it have?
It depends on what your intent is.
fast
branch, which is at the moment 406 commits ahead of master
. That's where all the fun happensThe current state of the various variants is detailed in the history chapter of the XL book, which is still somewhat up to date. Here is a quick summary.
translate
plugin) was enough to entirely define an evaluation model for XL (the ->
operator in XLR, now renamed to is
), I started focusing on that "runtime" implementation. A good news on that front is that I relatively recently found a way to unify the flavors of XL, in other words to be able to write old-style XL such as you can read it in XL2 and mostly have that work as-is with XLR.real
, integer
or text
, and everything is compile-time oriented. So you can create complex data structures like lists, associative arrays, etc, or even to process data files, but it's all only at compile-time. Creating the equivalent of a struct
type in C or a malloc
is next to impossible in that variant. It was a feature as a compiler back-end, but as a language, that's a serious limitation.type T is matching (X: not T)
, which makes it problematic to analyze. Still thinking about a solution for that one.-O
option (they derive from the Evaluator
class). There is:
Interpreter
that corresponds to -O0
,Bytecode
which is what I'm focusing most of my time on at the moment, hoping that I can make it fast enough to be able to rebuild an LLVM-free Tao3D,All these implementations are occasionally progressing a little here or there.
One good way to see progress is to ping me occasionally to re-motivate me to work on that 😄
Hope this helps.
Note: I just banged out an email without really considering your reply, but I'll read some more...
The email is this comment, or something else? (Asking because I found nothing else that matches).
Steps:
gives:
Is this supposed to work now? Or is more work needed?