World: r3wp

There has been some speculation that the new extension and command! 
model that is coming with the next host kit will help solve this 
kind of thing. We shall see.

As mentioned a few times in the past, I don't think that user-defined 
devices are at all possible, with the current hostkit. And yes, I'd 
love to be proven wrong :)

Ok, since we are not sure, I will take a deeper look into the code 
and try to ask Carl.

I agree with Andreas, when I looked into the hostkit code it looks 
that table of 'names' of the devices is hardcoded in the r3.dll at 
the moment. My only idea (workaround) was to try use for example 
'clipboard device name and try to replace the internal code with 
custom one for testing purposes. I haven't tried that though from 
that time yet. Not sure if it is worth the time. Better wait for 
new hostkit ;)

Carl,   what is left to do for the extension model to support view 
as an extension..

I mean, with absolutely no graphics, or view events related code 
within the core ?

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

dinner time.

a little question... how will the gui be able to call rebol functions?

http://www.rebol.com/r3/notes/command-blocks.html

has anyone tried to build R3 host as a dll, and use it within R2 
 as a routine?

I have a client which might need R3 parsing but needs to use the 
R2 run-time...

R3 parsing is not totally necessary, R2 parsing can emulate everything

yeah, but some tricks are MUCH easier and probably quite faster to 
do in R3.

we are talking an expert PARSE user, and so far , this would be his 
main reason to move to R3, but then all his prior code isn't upgraded 
so its a bit daunting to just plunge right in the middle of a project.

As far as I remember (but prove me wrong) all of the R3 parsing additions 
have (sometimes complex) R2 equivalents. This means that you could 
compile R3 parse rules to R2 parse rules.

maybe but doing so on several thousand line parse rules is, well, 
more work than probably trying the R3 as a dll  :-D

You are thinking about scale relative to the wrong number. It's not 
a matter of how many lines the parse rules have, it's a matter of 
how many additions there are in R3 parse, and there aren't that many. 
Make the compiler once, and it will compile quickly. It could even 
do so at runtime.

R3 Host-Kit A100 has been uploaded to www.rebol.com.  This release 
can build CORE or VIEW (with externalized graphics lib.)


However, although the graphics lib is there, the DRAW commands are 
still in the process of conversion (Cyphre will be working on that 
part).


It's also an example (and a fairly simple one to learn from) of how 
to build a host-based extension module, including a few scripts that 
show how to process the module source to embed it in the boot.

Although Cyphre and I have both been able to build it using Mingw, 
other's have not been able to do so, and we're not sure why as of 
yet.


Therefore, we're not quite ready to distribute the host-kit to everyone, 
because we need more testing on it. However, if you want to actually 
test it (windows only), then ask Henrik for the download URL.

The host kit comes with all files necessary to build itself.  In 
theory, all you need to do is type "make" and it will produce R3/View 
(as r3.exe).  Also, make core will produce a core exe, w/o graphics.

why not just post the url ??

more eyeballs is better

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

are better

Ok by me, but someone will need to collect the comments and issues. 
 You want to do that?

Can we include our own protocols now ?

Sure .. I'll just add it to my Jira tracker

This secrecy is really over the top ...

so this host kit is only buildable under mingw, not VS?

No, I mean someone needs to digest the issues and fixes, and submit 
them back.

Heck, even if no one digests the issues, nothing is lost.

It's not secrecy...

If you don't post the URL, you'll simply not get the issues reported.

The host-kit can be built by any reasonable C and C++ compiler/linker.

k - I was able to build the a96 one - will give this one a go too

I'm fine with posting it.  But, I don't have the bandwidth for the 
backchannel, so we need someone else to handle that.

www.rebol.com/r3/downloads/host-kit-a100.zip

Thanks.

Any timeline for a Linux libr3.so?

also appreciate the link, Carl

Pretty easy to do, but let's take this one step first.

Do you have an integrated cross-plattform build for the host-kit?

Graham: I got the message on protocols and it's on the list.

If not, someone could write one, if you release a Linux hostkit as 
well. If you do, why not release a single cross-platform package?

Andreas, no, but only because not yet tried that.  Only minor edits 
to the makefile required to build on Linux. If you get that to work, 
then can get you the r3lib to try it. Let me know.

(That's because we don't build view yet for Linux.)

(Only Core)

Yeah, I'd really appreciate if you could send libr3.so to me. I already 
wrote an integrated build for the A96 hostkit.

What exactly do you mean "integrated build" -- you mean makefile?

A single source base which automatically builds correctly for the 
platform the build tool is invoked on.