koka-lang / libhandler Goto Github PK

I am getting the following error when compiling on Mac OS.

build variant: debug, configuration: gcc-amd64-apple-darwin18.2.0
src/exception.c:11:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
^~~~~~~~~~
1 error generated.
make[3]: *** [depend] Error 1
make[2]: *** [Prt/CMakeFiles/libhandler] Error 2
make[1]: *** [Prt/CMakeFiles/libhandler.dir/all] Error 2
make: *** [all] Error 2

System Version: macOS 10.14.1 (18B75)
Kernel Version: Darwin 18.2.0

I think the problem is that on my computer malloc.h is in the malloc folder. If I change that offending line to

#include <malloc/malloc.h>

the error goes away.

Hi! I loved your technical paper on this and wanted to play around with it. Unfortunately, however, I wasn't able to get it to run. I get a linker error even when trying out the test suite:

~/Projects/cpltest/libs/libhandler on master
❯ ./configure
--- Configuring build ---
use '--help' for help on configuation options.

--- Check system ---
Found gcc  (at /usr/bin)
C compiler 'gcc' found
Compiler target: x86_64-apple-darwin15.6.0
Normalize target ABI from x86_64 to amd64 (used on Linux, etc)

Configure for target: gcc, amd64-apple-darwin15.6.0

Found ar  (at /usr/bin)
found archiver: ar
The C compiler is C99 compliant.
The C++ compiler is C++11 compliant.
Assembly setjmp found for this ABI: 'asm/setjmp_amd64.s'
Jump buffer size: 72
Do not use linked exception frames for C++
Function strncat_s: not found
Function alloca: found
Header stdbool.h: found

--- Configuration summary ---
System:
  target      : amd64-apple-darwin15.6.0
Build:
  c compiler  : gcc -std=c99 -pedantic -Wall
  c++ compiler: g++ -std=c++11 -Wall
  assembler   : gcc -Wall
  linker      : gcc
  archiver    : ar rcs

Use the following commands to build:
> make depend
> make

To run tests:
> make tests

Test release version:
> make tests VARIANT=release


~/Projects/cpltest/libs/libhandler on master
❯ make depend
use 'make help' for help
build variant: debug, configuration: gcc-amd64-apple-darwin15.6.0
gcc -MM  -Iinc -Iout/gcc-amd64-apple-darwin15.6.0 src/*.c > out/gcc-amd64-apple-darwin15.6.0/temp.depend
sed -e "s|\(.*\.o\)|out/gcc-amd64-apple-darwin15.6.0/\$(VARIANT)/\1|g" out/gcc-amd64-apple-darwin15.6.0/temp.depend > out/gcc-amd64-apple-darwin15.6.0/makefile.depend
gcc -MM  -Iinc -Iout/gcc-amd64-apple-darwin15.6.0 test/*.c > out/gcc-amd64-apple-darwin15.6.0/temp.depend
test/perf.c:37:3: warning: "no high resolution timer" [-W#warnings]
# warning "no high resolution timer"
  ^
1 warning generated.
sed -e "s|\(.*\.o\)|out/gcc-amd64-apple-darwin15.6.0/\$(VARIANT)/\1|g" out/gcc-amd64-apple-darwin15.6.0/temp.depend >> out/gcc-amd64-apple-darwin15.6.0/makefile.depend
rm -f out/gcc-amd64-apple-darwin15.6.0/temp.depend

~/Projects/cpltest/libs/libhandler on master
❯ make
use 'make help' for help
build variant: debug, configuration: gcc-amd64-apple-darwin15.6.0
gcc -Wall  -g -Iinc -Iout/gcc-amd64-apple-darwin15.6.0 -std=c99 -pedantic -o out/gcc-amd64-apple-darwin15.6.0/debug/libhandler.o -c src/libhandler.c
gcc -Wall   -o out/gcc-amd64-apple-darwin15.6.0/debug/asm/setjmp_amd64.o -c src/asm/setjmp_amd64.s
ar rcs  out/gcc-amd64-apple-darwin15.6.0/debug/libhandler.lib out/gcc-amd64-apple-darwin15.6.0/debug/libhandler.o out/gcc-amd64-apple-darwin15.6.0/debug/asm/setjmp_amd64.o

~/Projects/cpltest/libs/libhandler on master
❯ make tests
use 'make help' for help
build variant: debug, configuration: gcc-amd64-apple-darwin15.6.0
gcc -Wall  -g -Iinc -Iout/gcc-amd64-apple-darwin15.6.0  -o out/gcc-amd64-apple-darwin15.6.0/debug/libh-tests.exe test/main-tests.c test/tests.c test/test-exn.c test/test-state.c test/test-amb.c test/test-dynamic.c test/test-raise.c test/test-general.c test/test-tailops.c test/test-state-alloc.c test/test-yieldn.c  out/gcc-amd64-apple-darwin15.6.0/debug/libhandler.lib
Undefined symbols for architecture x86_64:
  "__lh_longjmp", referenced from:
      _jumpto in libhandler.lib(libhandler.o)
      __jumpto_stack in libhandler.lib(libhandler.o)
  "__lh_setjmp", referenced from:
      _handle_with in libhandler.lib(libhandler.o)
      _capture_resume_yield in libhandler.lib(libhandler.o)
      _capture_resume_call in libhandler.lib(libhandler.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [out/gcc-amd64-apple-darwin15.6.0/debug/libh-tests.exe] Error 1

Using nm to peek into setjmp_amd64.o, we can see that the functions it wants do indeed exist, but with a single underscore:

❯ nm out/gcc-amd64-apple-darwin15.6.0/debug/asm/setjmp_amd64.o
0000000000000033 T _lh_longjmp
0000000000000000 T _lh_setjmp
0000000000000061 t ok

I think I need to walk away from this to think about it for a bit. I don't know if it is a MacOS thing or not (I'm on El Cap). Have you seen anything like it?

Thank you for your time.

Edit: sorry, I didn't see that macOS isn't a tested platform. However, it looks like these linking errors are the only real thing standing in the way, hopefully.

I am also very interested in using/supporting/promoting this project. Despite it being "under active development", I went ahead and packaged it for Conan.io package manager.

https://github.com/bincrafters/conan-libhandler

@daanx Would you be willing to comment on the current trajectory of the library, and your goals for it as an OSS project?

It would be very helpful to developers who might want to try using this library, contributing to it, and/or promoting it. I think that if more people heard about this library, it would get a LOT of attention very quickly, but perhaps it's not the right time for that yet. It's hard to know, because it's very unusual for such a library to appear and be "effectively complete" in one month, and there has been no further commits or discussion for 5 months. In June, the technical report said that the work was planned to continue via an internal implementation, and the README disclaims that it's under active development and subject to change.

An updated status would be highly appreciated, but in any case, thanks for such an interesting contribution!

Hi, when I was trying to build a project that uses libhandler on Mac (Mojavae), it causes the following error:

Undefined symbols for architecture x86_64:
  "_lh_check_value_ptr", referenced from:
      _prt_receive in PrtExecution.c.o
      _receive_handler_action in PrtExecution.c.o
      _prt_receive_handler in PrtExecution.c.o
      _PrtResume in PrtExecution.c.o
  "_lh_handle", referenced from:
      _prt_receive_handler in PrtExecution.c.o
  "_lh_register_malloc", referenced from:
      _PrtInstallProgram in PrtExecution.c.o
  "_lh_release_resume", referenced from:
      _PrtResume in PrtExecution.c.o
  "_lh_yield", referenced from:
      _prt_receive in PrtExecution.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

After testing some use cases with different handlers op kind, I realized that LH_OP_SCOPED seems slower than LH_OP_GENERAL. I tried changing the handler kind on https://github.com/koka-lang/libhandler/blob/master/test/test-state.c#L57-L58 (and the corresponding resume function) and I see that it's considerably worse when using LH_OP_SCOPED. It's always likely that I'm doing something wrong, but these are the times I'm getting for an N=1000000:

• LH_OP_TAIL_NOOP: 0.017538s
• LH_OP_SCOPED: 5.653231s
• LH_OP_GENERAL: 0.745435s

The following code sample can be found at the top of page 3 of the research paper.

int divexn( int x, int y ) {
return (y!=0 ? x / y : exn_raise("divide by zero")); }

Both Apple Clang 8.1 and MSVC15 failed to compile this with the errors below:

AppleClang 8.1.0.8020042

libhandler_example.c:8:10: error: returning 'void' from a function with incompatible result type 'int'
  return (y != 0 ? x / y : exn_raise("divide by zero"));
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MSVC 15

'divexn': function must return a value
return value type does not match the function type

The following change satisfied both compilers, but is it functionally equivalent?

int divexn(int x, int y) {
  if(y != 0) {
    return x / y;
  }
  else {
    exn_raise("divide by zero");
  }
}

I am getting the following error when I run the make command:

use 'make help' for help
build variant: debug, configuration: clang-amd64-pc-linux-gnu
clang -Wall -g -Iinc -Iout/clang-amd64-pc-linux-gnu -std=c99 -o out/clang-amd64-pc-linux-gnu/debug/libhandler.o -c src/libhandler.c
In file included from src/libhandler.c:45:
inc/libhandler.h:390:1: error: unknown type name 'ptrdiff_t'
ptrdiff_t _lh_linear_handler_init(const lh_handlerdef* hdef, lh_value local, bool* init);
^
inc/libhandler.h:391:36: error: unknown type name 'ptrdiff_t'

void _lh_linear_handler_done(ptrdiff_t id, bool init, bool do_release);
^

src/libhandler.c:308:2: warning: 'gets' is deprecated [-Wdeprecated-declarations]
gets(buf);
^

/usr/include/stdio.h:638:14: note: 'gets' has been explicitly marked deprecated here
extern char *gets (char *__s) __wur attribute_deprecated;
^
1 warning and 2 errors generated.

Makefile:153: recipe for target 'out/clang-amd64-pc-linux-gnu/debug/libhandler.o' failed
make: *** [out/clang-amd64-pc-linux-gnu/debug/libhandler.o] Error 1

prtdiff_t is not found.

Assembler folder does not have anything for PPC. Is it possible to add it? I can do testing, but cannot, unfortunately, write assembler from scratch.

The typedef for lh_freefun currently has an argument type of const void *, which is non-conforming with the C standard library. Per the C11 standard, section 7.22.3.3, free is defined to have the following signature:

void free(void *ptr);

Can this typedef be updated in libhandler? It currently generates warning C4028 in MSVC when trying to pass the standard free function.

Has libhandler been tested with Visual Studio 2019? Since it's a static library, applications (like the P compiler) that (want to) use 2019 will need to retarget libhandler specially in order to use it.

Unfortunately since this is a C++ project, it might be necessary to keep two copies of the project files around, one for each of 2017 and 2019...

While we're at it, <WindowsTargetPlatformVersion> should be changed to simply 10.0 so that the latest available libraries are used and we don't have to retarget every six months to keep up with Windows 10's update pace.