World: r3wp

but its a compiler which can be easily embeded into any application.

mesa3D is using it in their driver engine to convert graphic calls 
to any GPU instructions... on the fly.  implementing a driver becomes 
just a question of providing LLVM instruction maps... although not 
trivial... still much simpler than having to go from HW to OS in 
a single driver  ;-D

we could add JIT compilation to rebol, we could have REBOL based 
extensions which are JIT compiled in real-time, for example  :-)

although we could all of this ourself... LLVM is a nice framework 
to make all of that easier.

so it is not a compiler, it is a virtual machine environment, no? 
What is the advantage here? REBOL is its own VM - if we get it to 
every platform, why would we need LLVM? How big is actually LLVM?

LLVM is a compiler, which you can control in real-time and easily 
embed.

Or you, as a dev. simply use LLVM to create REBOL executable? And 
as you have ti LLVM abstracted, you basically code to one host environment? 
I probably don't understand the model correctly ...

it would make for a powerfull extension, where we could simply run 
a rebol dialect like Rebolek's REBOL syntaxed-C and compile it in 
real time through an extension which serves as a jump vector manager.

so you code in a language similar to REBOL, but end-up with compiled 
code which is linked dynamically in the host...

how big is that runtime?

souce code is 7MB, but probably includes a lot of stuff we can trim 
for our specific purpose. the binaries are big wrt rebol, so it can't 
part of the host code(unless brian can build a very slim version 
of it), but it would make for a very nice extension.

shake, one of the most high-end visual effects software in the world, 
uses a system just like LLVM within their software and it made it 
much faster than all the competition because of it.

if some compiler adds more than 100KB to REBOL, then it is a no go 
:-)

sure, its not for the host, but its still not huge, and makes for 
a nice feature I'd add in any of my speed-critical applications, 
if I had access to it.

for elixir, for example, this would be extremely beneficial.

AFAIK, much of OSX is moving to LLVM.

btw it looks as though I might get some funding to build Elixir  
:-D

also FreeBSD, it seems

Shake is not good because of LLVM-like low level imo, but because 
of properly Graph based GUI. Now allow us something like that for 
View, and you get-me-interested :-) http://www.apple.hu/hun/mac/shake/shake/shake.html

Maybe I'm missing something but you can do graph-based processing 
even with R2.  There is really no special needs at the low-level.

pekr... wrt shake... and what do you think the graph does ?  ;-) 
 


the graph is compiled in real-time everytime you change its structure. 
 you can create your own nodes and add them to the engine, using 
the graph itself as a visual development platform.


 as I said, I worked for those guys... I have an intricate knowledge 
 of how it works.  I also implemented a REBOL implementation of shake 
 callings its rendering engine and intepreting its (C) Header files 
 to integrate all the nodes.  :-)

yes, in R2, globs is such an engine, and it works very well.

Regarding JIT/VMs: Recently I spent some time looking into this area. 
After the short investigation I believe JIT compiler which can be 
really useful(and fast enough) for Rebol can be written in kilobytes 
of code not megabytes.

They still sell Shake? I thought it was discontinued a couple of 
years ago.

yep.  but shake's technology was embeded within other apple tools. 
 the original nothing real guys still work at apple, all these years 
later  :-)

a VERY cool and somewhat, excentric, group of people hehe... nothing 
real parties at tradeshow events like siggraph... usually where the 
most sought after events...   S&M show with boobs on fire :-)  nude 
circus acts.  world-renowned dj's doing the music... ahh... those 
where the good times.

now.. you've got stuck-up companies like autodesk litterally controlling 
the whole industry with parties which would make your grandma wish 
she could leave early.  ;-)

shake still today is preferred for very large effects shots... it 
can layer 500 full frame cinema images (2048p or more) using a few 
hundred megs of RAM.  other softwares need 8GB of RAM just to handle 
10. and render exponentially slower.

So Max - when do we get FullHD editing in R3? :-)

give me a few months  ;-)

... so you want to do in few months, what was not done in 12 years 
of View's existence? Cool then :-)

a lot of the stuff is already coded... it just needs to be translated 
for R3.

it took me just a few hours to have OpenGL running in an extension.... 
 which includes downloading all the OGL libs, and C compiler and 
stuff.

well, for those of you who are on devchat... you can see my (humorous) 
host-lib compilation post there, but for all others... just I just 
want to tell the world that... 

ITS ALIVE!!!! hehehahahahaha (evil grin and laugther)...


yep, I am on the short list of lucky individuals who got the host 
code, and it compiled the very first time I tried, so, mission accomplished 
and congratulations to Carl.

Maxim - on Windows, or some other system?

on windows... I  don't have my Mac setup for compiling yet.

Cyphre has reported compiling on code::blocks (don't know what OS)

OK, and what compiler have you used?

MSVC express edition... the free version.

so far, I really like the Device model, there's nothing like C OOP 
without the ++  

Exactly like the Amiga philosophy used to be.  :-)


I guess C++ coders will just be screaming as to why this isn't all 
classes and objects...  but its simple to code in any case

As long as the host code can be integrated into existing C++ code 
that's good for me. I'll be testing that ASAP.

Just being able to compile the host source with a C++ compiler would 
be sufficient - having declarations still work, for instance. The 
rest could be handled with shim code, basicaly what most of the host 
code is anyways.

So far, that is - see recent blogs for details.

I try all to keep away from C++ these days. It just gives to much 
hassles when going from one compiler to the next.

Guys, there's a trouble with OS-X or so it seems. Any experienced 
OS-X coder to help? Message from Carl on R3 Chat:


I must set OS X on the back burner... I've wasted far too much time 
on it.

There are three choices on it:
1. find a tool that does what 
I need
2. make a tool that does what I need
3. join all the sources 
into one large .c compile

Note that gcc -fvisibility=hidden does 
not work, nor does __private_extern__ wor
k either.

I've got to 
get on with other projects now. So, if you happen to find the soluti
on, 
let me know. (PS, yes, using GCC > 4.0.)

Some explanation:


Back to OS X, the problem is that they're not really libs, they're 
.a's. This ev
en appears to be the case when -dynamic-lib is used.

I 
should mention that I've had -dynamic-lib built OS X libr3 and host 
working fo
r several days. But, the libr3 isn't in the form I want, 
because it's not intern
ally linked and resolved. Examining it with 
nm it looks like just a concat of .o
 files.

Specifically, I want 
all internal symbols resolved, and I only want to export th
e library 
interface.

If OS X only builds libs (dynamic or otherwise) as concatenated 
.o files, that's
 a serious breach of coding ethics! There are two 
reasons:

1. it means I can link against the internal interfaces 
- a serious short circuit
 in code encapsulation rules.

2. it means 
I can discover the entire internal structure of any product... say 
I
 want to peek inside Photoshop to see how it does something.

If 
I nm a lib that's been properly prepared, I should only see its API, 
nothing
else. So far, this has not been possible on OS X.

I suppose 
I could easily confirm this by nm'ing some of the various apps I 
have
on OS X and checking if I can see their internals. Let's hope 
not.

Wow, that explains why Apple has to sue developers for using undocumented 
APIs instead of just not exporting them.

wow

Well, I think I found the solution - it looks like Carl's assesmenmt 
of dylibs was wrong. Solutions posted in reply to him in chat.

I've been under that impression myself... but haven't found an exact 
solution.