I'm building a C GUI application with GTK and Ren-C, a client for some social media websites, which would support filtering of posts based on keywords and rules.
I explored various ways of doing networking. R3 networking seems more complex than R2. While the additions in R3 and Ren-C should helpful for many use cases, currently my use case only needs the ability to download a web page.
I'm planning to use libcurl for now. To put things in perspective a little bit, in order to read a URL in libcurl, it would take a callback function with CURLOPT_WRITEFUNCTION. Whenever new data arrives from the network, the callback function would be called, similar to the behavior of read mentioned in the top post.
Using Rebol doesn't seem to reduce much complexity here, so I wouldn't mind using C for now...
Sounds like you're coming from having experience with Rebol2 (feel free to edit your post to add more background... I moved it over here to Introductions).
You probably like PARSE (?). There's a lot happening with UPARSE, here, but... it's early yet for the design.
Beware The Reasons Not To Use Ren-C 
It is not a production system--it is organic and constantly changing. Desktop builds are kept working but the long term priorities are in the browser, and testing in the browser too...
What I can hopefully promise to those who get involved in using it and designing it is that there will be interesting and novel techniques to enjoy.
What I can definitely promise is that if your objective is to get a task done and you find churn and seemingly endless design debate to be annoying and not thought-provoking... you will be unproductive and hate this project. If it will ever be in a state one would want as a "product" that would be years from now--and I have no promises that day will ever actually come.
My offering to some is that if their source is public and has reasonable tests that run on GitHub or wherever (to which I am given commit access)...that I will take on some responsibility for keeping your source in sync with changes. I can't do everything--and it may be that some features just go away entirely. But it can make it less of a problem when things change.
I'm building a C GUI application with GTK and Ren-C
There was a time when there was a (bad) CMake-based .lib and .a packaging process for Ren-C. It was used by Ren Garden, a Qt app.
Right now the only "lib" packaging (without a main()) that's really going is the web version. I'd like to revive Ren Garden, and it would certainly be nice if someone could help get the GitHub CI to build those lib packages and get things running.
But really, I want to temper expectations. I'm attacking kind of the foundational design issues, and that means a lot of mess and flux. There are comments and so some hope of understanding it...but things get out of date.
Help from co-designers who want to be involved is very welcome. But the scope is simply sprawling at this point. Serving users is nigh impossible...and even just having the handful of users who've been around for the ride for years is beyond what I can devote to an unpaid hobby.
Thanks for clarifying on expectations! Yes, I'm aware that Rebol derived languages are a less treaded space. I have found places of outdated documentation in Ren-C, but that's something one would expect for an unpaid hobby project.
A little bit more about my background - I was a software engineer in a top Silicon Valley big tech for 4 years, before I resigned and moved back to China. I have saved enough money and the cost of living here is not high, so I don't have to worry about money. I can afford to do things right instead of trying to get a task done. I'm a Buddhism practitioner and programming (as well as any other aspect of my life) needs to adhere to Buddhism. I discovered that definitional scoping is right, so I choose to express my thought in languages with definitional scoping. I also do reverse engineering and try to understand and modify disassembled binaries, so I'm fine with outdated documentation, etc.
Oh, I already built my librenc.a, linked it against my C program, and it seems to work so far. The lib probably includes a main(), but I guess that's fine.
Maybe a good fit, then! Hopefully you got a chance to look at the 2019 conference videos, but I gave a couple of talks on the "Amish" nature of programming, as well as the pursuit of "Timeless" character:
(and my detailed talk there with slides has some mostly-up-to-date information, which is a good place to look if you're going to be trying to understand any of the C.)
Binding has been one of the big enigmas, and Ren-C has been exploring a lot of techniques. A good recent summary of things is in Rebol and Scopes: Why Not?
Indeed. Well if you have time at some point, I'd be willing to do a web-screen-sharing meeting where I could do a bit of demo'ing of high points and rapid Q&A to bring you up to speed on anything you're curious about.
It's about time we had another Re-Meet where this could be conducted under the auspices but sadly youtube is blocked in China.
But if you have a decent VPN, the playlist is here
Welcome cggong!
Some time ago I started working on adding GTK3 for view to Ren-C . Got a bit stuck on the callbacks and since I started my new job I practically have had no time to spend looking into it 🏋♀️
Maybe @cggong can share his code?
There could be a difference here. When making just an application you know what fields to use and you can build this in C right away. In my case I want all to be done dynamically from within the Rebol code. But that discussion can be continued in a better place than the introductions here.
Again welcome cggong 
Thanks all for the welcome 
I still find myself missing Rebol2-GUI. It does not work on macOS Catalina or above. I was trying to migrate it to work on newer macOS. Unfortunately, the license of Rebol2-GUI mentions that "You may not reverse engineer, decompile, or disassemble the software," let alone the IP and redistribution clauses 
I'll probably submit a contact form to figure out the legal aspects of migrating it to newer macOS.
Do you mean r2 view? Because r2 VID's sources are readily available for inspection.
And although r2 View C sources weren't available, more likely than not a lot of it was used by Carl for the r3 View which is open source.
I don't know how familiar you are with the gui but only atronix have an active branch
But they never kept up the the changes made to renc so that's we don't have a GUI in ren-c. Also Brian excised all the code that supported the GUI to make it cleaner.
I tried some simple GUI with the Atronix branch before. It worked but the GUI doesn't look too nice. I would like a more aesthetically pleasing GUI. For now it seems GTK would make sense.
I just built Ren-C for my M1 MacBook and linked my GTK app with Ren-C. It works! I used the x86_64 Mac Ren-C binary for bootstrapping; Rosetta2 would run it. The script produced x86_64 object files and executable. I manually ran the gcc commands again and it was able to produce arm64 object files and executables, and I was able to link it to my application.
Historically, Rebol/View used the AGG 2-D graphics library but Maxim, the author, died in 2013 apparently during an epileptic seizure. So, a replacement library was sought. Zeng Shixin, who seemed to be the lead developer for Atronix, was doing some work to port to GTK and it's in a different repo
Feel free to share your projects!
I have linked libPython into my program to take care of some networking task. Moving on to the GUI part.
To support calling GTK from Ren-C, I'm planning to implement this following mechanism that allows a C program to define functions that can be called from Ren-C, provided that
- the function symbol is not stripped in the executable, so that it can be found by
dlsym()from libRen-C - the function takes a Rebol block as argument
The mechanism is implemented by adding a Ren-C native extension function extension-custom. It's callable from Rebol and implemented in C. From Rebol, it takes 2 arguments,
- function name as string,
- arguments as block.
The implementation simply calls dlsym() to get the function pointer by function name and call it with arguments.
Instead of putting the above code into a new extension, another possible way would be to use the existing TCC extension to compile the code dynamically. It would be great to leverage existing features without having to fork / extend Ren-C.
I'm glad you've been able to be a self-starter with the codebase while I've been away! 
Hopefully there are enough comments sprinkled around to give you a sense of what's going on, but don't hesitate to ask questions.
I really, really want people to be thinking along the lines of automated builds and tests for their projects that use Ren-C.
And I'd really like to see us package up a "libRebol" .lib and .so as one of the build products made on GitHub Actions.
I'd really like to see us package up a "libRebol" .lib and .so as one of the build products made on GitHub Actions.
Let me see how to add that when I have some time.
use the existing TCC extension
TCC does not support M1 chip. However, building libRebol to build a DSL interpreter is convenient and fits my needs. I'm very happy with this and I would like to try this approach for iOS game development as well.
There was a question I was thinking about yesterday... Is there a way to run multiple instances of Ren-C interpreter in the same process? This is easy in Lua but hard in Python. If I have multiple DSLs in my app, I might (or might not) want multiple instances of Ren-C interpreter. I haven't thought about it deeply enough to make sure whether this is desirable; if there is multiple instances of Ren-C, it creates the problem how to interoperate among them. I haven't come up with any situation that particularly requires multiple Ren-C instances, so just asking to see if this has been considered before.
At one time I thought we'd try doing what the JavaScript V8 engine behind Chrome/Node/etc. uses, something called "isolates":
But the direction I imagine going in now is more like Go, e.g. "green threads" as a more cooperative way of letting the interpreter shuffle state around:
What Color is Your Function? – journal.stuffwithstuff.com
Switching to Stackless: Why this, Why now?
So concurrency would be managed within the interpreter "service" itself--not as something that you'd have to do "locks" in native C code to surround on different threads. This would allow for concurrency...though (probably) only one CPU core would be running the interpreter code; just shuffling between whichever tasks/threads that were requesting to use it.
I'm in constant transit, currently in a search for a new place to live, and that's taking up a lot of time. So I don't really know what the timetable is on stackless, or much of anything at this point 
I'll see about getting around to my New Years status post shortly.