Can't build native/HelloWorld

[tripleo1]

Steps:

cd xl2/samples/HelloWorld
cp ../../xl.syntax .
cp ../../native/library/runtime/C/xl.bytecode .
../../bxl HelloWorld.xl > HelloWorld_native.cpp
g++ -I../../ HelloWorld_native.cpp -o HelloWorld_native

gives:

/usr/bin/ld: /tmp/ccIKhQRM.o: in function `main':
HelloWorld_native.cpp:(.text+0x112): undefined reference to `xl::ui::console::arguments[abi:cxx11]'
collect2: error: ld returned 1 exit status

Is this supposed to work now? Or is more work needed?

[c3d]

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.

[tripleo1]

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...

[c3d]

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.

• If your intent is to use it for anything, my answer at the moment is, unfortunately: none 🥲
• If you want to play with it in a fun way, I would recommend that you download a binary of Tao3D, and I can probably still generate a "license key" to turn it into an unlimited "pro" version with all the add-ons. That one still "works" AFAICT, with a few caveats, but I can't easily rebuild it or fix bugs ATM, for reasons related to LLVM.
• If you want to help me restore the language to a good state, then I would recommend familiarizing yourself with the fast branch, which is at the moment 406 commits ahead of master. That's where all the fun happens

The 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.

1. The XL2 compiler which you tried still self-compiles, but has been on hold for several years (except for a bit of work to update its build system). It's not forgotten, in the sense that I still want to be able to self-compile at some point. However, once I realized that the "rewrite" implemented in that compiler (in the form of the 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.
2. The XL runtime, XLR, is the only one that ever got close to "production ready", although as a standalone language, it was way too weak. Since it was initially intended as a back-end for XL2, an assembler of sorts, it only has primitive data types, like 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.
3. However, when XLR turns out to be way more fun to use for a human than I anticipated, I used it as a basis for the Tao3D dialect. That explains why Tao3D inherited the brain-dead type system, something which I thought I would easily fix, but never had the time to actually do, because customers and deadlines and whatnot. Tao3D 1.61 is relatively stable and usable if you know how to use it, and I still use it to this day to create my slides. That one is stuck in the LLVM swamp, thought I suspect bit rot is also impacting the GL side of it nowadays.
4. The current XL compiler finally got a theoretical type system. However, when I tried to implemented it (specifically Haskell-style type inference), I ran into circles, until I realized that the type system I was thinking about can express type T is matching (X: not T), which makes it problematic to analyze. Still thinking about a solution for that one.
5. That XL compiler has one source code base with four internal implementations selected by the -O option (they derive from the Evaluator class). There is:

• A very slow Interpreter that corresponds to -O0,
• A 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,
• A "fast compiler" which is roughly a port of the Tao3D compiler to more recent versions of LLVM, but is a bit behind, language-wise, relative to the rest
• An "optimized compiler", that can produce C-quality assembly code in the very rare cases where it produces code that works.

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).