schani/clojurec

A Clojure implementation on top of C

clojurec's Issues

Please Review New README.md Material

https://github.com/schani/clojurec/wiki/Project-Status

Thanks again for the convo!

Build fails on Ubuntu 12.04

I get the error: Makefile ERROR: cljc.c:11:19: fatal error: khash.h: No such file or directory

runtime.c passes 'const char *' to 'char *' dummy

The evidence is here:

gcc -std=gnu99 `pcre-config --cflags`  -Wno-unused-variable -Wno-unused-value -Wno-unused-function -I../../src/c -I../thirdparty/klib -g -O0 `pkg-config --cflags bdw-gc glib-2.0` -c ../../src/c/runtime.c
../../src/c/runtime.c: In function ‘extract_name’:
../../src/c/runtime.c:670:22: warning: passing argument 1 of ‘make_string’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
  return make_string (utf8);
                      ^
../../src/c/runtime.c:453:1: note: expected ‘char *’ but argument is of type ‘const char *’
 make_string (char *utf8)
 ^
make: *** No rule to make target '*.o', needed by 'cljc'.  Stop.

The previous line effectively (and perhaps dangerously) casts the original pointer, though copied into another one in the meantime, before passing it to the same routine, so it seems reasonable that a cast is safe (i.e. the ultimate data type is char * but can "safely" hold a const char * under certain circumstances).

If that's not the case, then not only is this fix wrong, other lines of code might be wrong too, though disguised by silent unsafe casts performed by macros such as g_utf8_next_char here:

https://github.com/GNOME/glib/blob/master/glib/gunicode.h#L734

README example is incorrect

The section "From the command line" has some example commands, but the last one where I go into the "run" folder and type "make" just says there are no make targets.

is it still good to use the current version of clojure

Passing a function as an argument to a function.

The following code generates some odd behaving C code.

(run
'(
(defn f1 [x](cljc.core/print x))
(defn f2 f)
(f2 f1)))

value_t *_COLON_fn15779 = make_closure (FN_NAME (main_exit_value15768), env);
VAR_NAME (cljc_DOT_core_SLASH_main_exit_value) = _COLON_fn15779;
value_t *_COLON_fn15788 = make_closure (FN_NAME (open15780), env);
VAR_NAME (cljc_DOT_uv_DOT_fs_SLASH_open) = _COLON_fn15788;
value_t *_COLON_fn15793 = make_closure (FN_NAME (f115789), env);
VAR_NAME (clojurec_DOT_core_test_SLASH_f1) = _COLON_fn15793;
value_t *_COLON_fn15799 = make_closure (FN_NAME (f215794), env);
VAR_NAME (clojurec_DOT_core_test_SLASH_f2) = _COLON_fn15799;
value_t *_COLON_invoke15800 = invoke1 (VAR_NAME (clojurec_DOT_core_test_SLASH_f2), VAR_NAME (clojurec_DOT_core_test_SLASH_f1));
invoke2 (_COLON_fn15793, _COLON_fn15799,_COLON_invoke15800);
return 0;
END_MAIN_CODE;

Looks like it invokes f2 with f1 on the 4th line from the bottom, and then turns around does it again on the 3rd from the bottom. On the 3rd from the bottom I get and exception.

assoc keyword issue

I tried to run the follow code on iPhone 5.1.1, XCode 4.4:

(= (assoc {} :a 1 :b 2 :c 3) (assoc {} :a 1 :b 2 :c 3))

I got an EXEC_BAD_ACCESS error, env_fetch might returned a bad pointer

static value_t* FN_NAME (G__392173) (int nargs, closure_t *closure, value_t *arg0, value_t *arg1, value_t *arg2, value_t **argrest) {
environment_t *env = closure->env;
assert (nargs == 1);
{
value_t *_COLON_new_env392174;
{
environment_t *new_env = alloc_env (env, 1);
{
environment_t *env = new_env;
env_set (new_env, 0, arg0);
value_t *k392176 = env_fetch (env, 0, 0);
value_t *_COLON_c392177 = make_integer (string_hash_code (keyword_get_utf8 (k392176)) + 2);
_COLON_new_env392174 = _COLON_c392177;
}
}
return _COLON_new_env392174;
}

libgc's all lib is x86, not armv7

When I build clojurec on my mac-mini 10.7.5, I found that all is well, but when I sudo run:

cd ~/clojurec/run/ios/;
sudo ./bootstrap.sh

I found in libgc.os/lib/, all libxxx.a is x86_64 using lipo to see.

so the clojurec xcode can't build for armv7.

iOS simulator GC issues

I tried modifying the run/ios/bootstrap script to compile the Boehm GC for i386 so it can be used with the iPhone/iPad simulator, but it looks like Boehm itself relies on a depreciated API call to _dyld_bind_fully_image_containing_address.
This blows up at runtime in the latest iOS simulator.
The issue is still unresolved upstream:

https://github.com/ivmai/bdwgc/blob/master/dyn_load.c#L1400

(This isn't so much an explicit request for anything as much as a note to @aking and others who might give this a shot.)

Example compilation failed

Trying to compile the From the command line example, I get:

/tmp/ccBglPy9.o: In function `FN_mod9846':
/home/jonathan/Build/clojurec/cljc.c:9837: undefined reference to `fmod'
/tmp/ccBglPy9.o: In function `FN_hash_imap11476':
/home/jonathan/Build/clojurec/cljc.c:16494: undefined reference to `fmod'
/tmp/ccBglPy9.o: In function `FN_hash_iset11535':
/home/jonathan/Build/clojurec/cljc.c:16732: undefined reference to `fmod'
/tmp/ccBglPy9.o: In function `FN_G__14349':
/home/jonathan/Build/clojurec/cljc.c:28444: undefined reference to `ceil'
collect2: error: ld returned 1 exit status

Unfriendly Crash

I tried running a program that expected at least one argument, without providing arguments, and got this:

$ ./cljc
GC Warning: Failed to expand heap by -4096 bytes
GC Warning: Failed to expand heap by -4096 bytes
GC Warning: Out of Memory! Heap size: 0 MiB. Returning NULL!
Segmentation fault

Seems a little unfriendly. Perhaps there's a reasonable way to avoid this and do something more elegant instead?

Here's the source (it'll look familiar):

(ns cljc.user)

(defn -main
  [arg & args]
  (println "Here are your args:")
  (flush)
  (apply println (cons arg args)))