I've finally managed to fix most of the problems with the initial release and at last arc.arc now loads cleanly. Am in the process of testing each of the functions and macros in arc.arc to see if they work as expected. Now it seems that Arcueid is getting that much closer to being complete!
New in version 0.0.2:
- Readline support in the REPL. Note that you'll need the development headers for readline (libreadline-dev on Ubuntu) for this to work. This is also the reason why the REPL is GPLed instead of LGPLed.
- All of the Arc definitions are there, though they've not all been tested and they likely don't all work.
- Tracing and disassembly. There is a (trace) function that toggles tracing. Everything run on the REPL becomes traced until it returns. (disasm <somefun>) will disassemble a function and show its bytecode definition.
It's tagged v0.0.2 and is commit 602da1f00f7937e0fcf57c71b376673c5aab3ad6
Do a git pull. Oops, some debugging code I was using temporarily made it into the repo. Will try to ensure this doesn't happen again. Last commit should be: fdeb76087b48ff19d9f2666d05a4429ac4145b24
to the end of /etc/ld.so.conf and then run ldconfig -v. This is a frequent issue when it comes to shared libraries that get installed in /usr/local/lib. I have no idea why most Linux distros don't like to put /usr/local/lib in ld.so.conf by default. It is extremely irritating, since most everything one builds from source installs there by default.
Interestingly, this is what /etc/ld.so.conf looked like before:
include /etc/ld.so.conf.d/*.conf
And this was in /etc/ld.so.conf.d/libc.conf:
# libc default configuration
/usr/local/lib
The "include" line doesn't seem to do what it looks like it's supposed to do. :-p The man page for ldconfig doesn't mention "include" at all (nor #-comments...). It would be funny if Linux Mint came with this kind of ld.so.conf but its version of ldconfig thought "include" was just another directory in the list.
I'm a bit of an anime/manga/visual novel fan and one of my favorites is a show called Shingetsutan Tsukihime (Tsukihime, Lunar Legend). The main heroine is named Arcueid Brunestud and I thought the name was too good to pass up for this kind of project. I hope Type Moon doesn't give me problems over this later...
I haven't had a lot of time to work on it which is why it took so long. It's just a side project... In retrospect I probably should have announced it sooner but I wanted to have something a bit usable first.
I use Emacs org mode which is why the file arcueid.org is named as it is.
You'll need the autotools installed (autoconf/automake/libtool). Do an autoreconf -i in the main project directory. This should generate a configure script from the configure.in and all of the automake and libtool stuff for it. From there it should be configure / make / make install the way it normally is. You can do configure --enable-unit-tests if you have GNU Check installed so that you can run the unit tests.
I ran autoreconf -i, and then configure, and I ran into this error:
./configure: line 12048: syntax error near unexpected token `CHECK,'
./configure: line 12048: ` PKG_CHECK_MODULES(CHECK, check >= 0.9.4,'
So this means GNU check is not installed? It's not recognizing the PKG_CHECK_MODULES macro. Where can I install GNU check from? Googling found nothing.
It's the unit testing framework I'm using, and shouldn't be necessary in a tarball distribution (maybe I should make one soon...). The error looks like you also don't have pkg-config installed (http://www.freedesktop.org/wiki/Software/pkg-config).
All of these are readily available in the Debian / Ubuntu repositories. It has no dependencies that have to be built from source, at least on Debian/Ubuntu. Package name for check is just 'check' and pkg-config is just 'pkg-config'. What distro are you trying to build Arcueid under anyhow?
I'm just using ubuntu. Lucid, I think. I installed check and pkg-config, no problems. But I still see the same error.
On a second machine I'm using linux mint which tracks the debian rolling release. There:
$ ./configure
..
checking gmp.h usability... no
checking gmp.h presence... no
checking for gmp.h... no
configure: error: in `/home/akkartik/arcueid':
configure: error: Bignum (libgmp) test failed (--disable-bignum to disable)
See `config.log' for more details
$ sudo apt-get install libgmp10
libgmp10 is already the newest version.
Have you got libgmp-dev installed? It cannot find the development headers which you'll obviously need to compile it. Anyhow, you can use --disable-bignum if that still doesn't help. If you're still having problems you can download a tarball of Arcueid 0.0.1 in the files section of the github page. That has a configure script so you ought to be able to ./configure && make && make install from there. I should try building the thing on a clean install of Ubuntu to fully identify all the dependencies for building straight from the cloned sources.
Still unclear why ubuntu lucid is having trouble. It's a pretty vanilla server distro. I'll keep pottering with it, see what I can find out.
What do I do after building it? I tried running src/arcueid, both from the top-level dir, and from the arc dir. It segfaulted each time. Poking around with gdb now.. oh, do I have to make install before I can use it?
(I never realized how complex the makefiles get when you use autotools..)
Well, the arcueid binary expects to find arc.arc in /usr/local/share/arcueid, and like I said there's practically no error handling. You can either do a make install (which should copy arc.arc to that place where the arc binary can find it), or you can run it as src/arcueid arc/arc.arc (explicitly specifying the path to arc.arc on the command line). Oh, and do a git pull!
You don't, at least not for now. I found it faster to just write a version of the compiler in C using compiler.arc as a prototype (the fact that I've done this should be obvious by comparing compiler.c and compiler.arc). Seems there are a few more bugs in the compiler: the or macro seems to be expanding all wrong, and anything but nil crashes it. I need to take a closer look.
Oh, and please do a git pull now before you do anything else. I've just managed to fix the bug that was preventing arc.arc from being loaded properly, although of course arc.arc makes reference to many global functions which still aren't defined in the core and will crash the interpreter. Next step will be to find these and implement them.
Well, it might possibly be interpreted as 1 because the length of a symbol is 1, but this then raises the question as to why (len 'symbol) should not produce an error the way taking the len of other atoms does, e.g.:
arc> (len 1)
Error: "length: expects argument of type <proper list>; given 1"
arc> (len 'symbol)
1
The way I see it the most logical value for (len nil) is 0, that is if you want it to be the same as the empty list, and taking the len of any other symbol should produce an error.
I just did a git pull on Anarki and indeed now (len nil) returns 0 as it should. However, (len 'sym) still returns 1, and I have to ask why this is so and not an error the way all other non-nil/string atomic values are.
I don't like len!sym being 1 either. I think ppr.arc is the thing that should be fixed, perhaps by having it use its own spinoff of 'len. But I didn't try to fix that; I just did the minimal change needed to get len.nil to work properly again.
(translation, in case it's just someone who clicked the wrong country:
dido: Who's the third?
almkglor: Hmm! It is three! Maybe someone just clicked wrong?)
I wonder if some of the work in optimizing Self, such as polymorphic inline caches [1] might be applicable for non-object oriented dynamically-typed languages such as Arc.
It's supposed to be a predicate for a non-nil atom. I just realize that could better be written as (~acons current) instead, given that (acons nil) is also nil.
I was confused because (~no current) is just the same as current by itself, and I didn't realize you wanted to test for non-nil atoms. Obviously (~no current) isn't what you want, because it returns true for lists.
arc> (~no nil)
nil
arc> (~no 'a)
t
arc> (~no '(1 2 3))
t
But I don't think (~acons current) does what you want either. Because (acons nil) is nil, (~acons nil) is true.
arc> (~acons nil)
t
arc> (~acons 'a)
t
arc> (~acons '(1 2 3))
nil
I think (~alist current) returns true for non-nil atoms, because (alist nil) is true.
Ruby is what pays the bills right now, but as CTO of my own company I've got to always be looking to the future. I bet the company's development on Ruby back in 2002 when the company was founded, and my intuition served us well. Now, I'm betting that Arc or a language like it might well be the cutting edge within the next five years.
