Embedding ren-c into c program - for newbs

I am not experienced in c ... I know or knew the language but compiling, linking, makefiles ... :frowning:

Is there any "getting started" page for this sort of thing? I feel really dumb by not knowing this stuff. So far I have downloaded ren-c source and compiled it. Made a simple c file, included the header ... but I guess I need the library now. Which I don't know if is already built by make (and I can't find it), or do I have to call make specifically to build it, or this should all be done in different way altogether.

#include <stdio.h>
#include <stdlib.h>
#include <endian.h>
#include <reb-host.h>

int main()
{
  printf("Hello World!!\n");
  char *output = rebDo("1 + 1");
  int result = atoi(output); // "ascii to integer"                                                                                                                                                                                                                     
  printf("The result of the addition was %d\n", result);
  free(output);
  return 0;
}

I call and get

gcc -I /home/jimny/Work/ren-c-master/src/include/ main.c -o test2
/tmp/ccDfnqns.o: In function `main':
main.c:(.text+0x1d): undefined reference to `RL_rebDo'

Which means (if I understand) that it finds the header, but not the library / code?

Oh no. It's...a person. Asking... questions... :-/

You're very much on the right track, I'm just not ready for you yet!

The first design of the API was C++ based, you can see a bit here:

What has happened is a bit of redesign, to try and back off C++ and really start doing weird-o things, like sniff the bytes:

So basically being able to read rebDo("1", rebEval(plusFunction), "1", END), if you will. No C++ just differentiating UTF-8 data from various other bit patterns.

You're just too early! :slight_smile: I'm making this stuff up as I go along.

Please join us in chat. https://chat.stackoverflow.com/rooms/291/rebol

Thanks for swift reply. If I understand, you are saying the ability to compile ren-c as a library (or dynamic library) is not yet there? I assume some kind of c api must of course be there since console must use it?

If this is true ... then for now only way would be to compile whole ren/r3 to executable and replace main function to not behave as a console but as what I want?

(I apologize if this is stupid question ... but my lack of solid understanding of stuff around libraries/compiling/linking ...)

--

Or, maybe I should then first explore the reverse route. Making c bindings that I cal from ren/r3. I've seen few examples of that. Like abolka's ZMQ binding. Is there any nice examples or documentation on that maybe?

I was trying to make a simple Extension, but I can't find macros like RXA_INT64? I couldn't find what substitutes "access macros" in old reb-ext.h

Is there any example of what to use to currently do extensions or where to look? Please don't say extensions aren't possible any more ...

My understanding is that ren-c was a library, but currently isn't, and work is being done to bring it back to that state.

The host kit has been wiped, and so are extensions. Now, I believe if you want something like that you compile it into the ren-c binary like FFI and ODBC which are compile options.

hum .. what was the reason to wipe extensions?

does FFI work?

The host kit (by which extensions were implemented) was a way of hiding the r3 source and since it's now open source, it can be removed.

Yes, FFI works.

There are two APIs. Let's call one the "internal" API, and the other we will call "libRebol"...as more akin to Red's libRed (though I can easily say it is has a very significantly better design).

We still have extensions, you just choose whether to use the lighter or heavier API. The heavier API is really just the core itself...picking apart the memory of value cells and having to interact with the GC...it's twiddly and hard to use. And because it pulls in all the definitions in the core, you have more likelihood of name collisions with other C libraries you're using. The lighter API doesn't carry that baggage... you just have handles to black box cells.

The problem with the old way of working from "hostkit"--RXIARG and such--is it was the worst of both worlds. It exposed to userspace the memory of the cells, with no actual mechanics to manage interaction with the GC. It was also missing major pieces of functionality.

We're in the midst of a shift to where the "libRebol" API is finding some footing, to the point where the console itself can be built just on that without going underneath. And yes, you're right, just replacing that main() is kind of how you'd do it for the moment. But please realize this is very formative work, it's just getting started... so if you want to "use" it, you'll really have to be helping develop it.