World: r3wp

so much it bleeds  ;-)

Hmm... REBREQ looks very familiar.. very much like the Amiga's standard 
IO request :-)

hehe... that's not where similarities end ....  ;-)

Besides the r3 core, what other bits would RT be providing for these 
kits?  include files?

What you see in the .tar.gz is the complete hostkit. Sources, headers, 
and the proprietary libr3 binary blob.

so the idea would be to create sub-dirs with whatever platform-specific 
stuff needs to be there... simple

oh, and a makefile I expect (or whatever build system)

Yes. But the makefile provided with the Linux hostkit (in make-gcc/) 
should get you pretty far.

I think gmake is a good common denominator these days for build systems

Agreed. The current makefiles are written for a much lower common 
denominator, though.

lower than gnu make?

Yeah.

that takes me back :)

Think HP-UX make from 1992 or something :)

_That_ low :)

do I have to?

Hopefully not.

hehe

I used hpux in the good old days... no thanks :)

Aargh! http://www.rebol.com/r3/downloads/r3-host-kit-a107-42.tar.gz
defies automated downloading

ttfn.. this looks like it will be a fun little project.. just need 
to get the blessed libr3.so from carl

Got it built on Syllable Server

I am not sure it is realistic to get gfx going under the Amiga for 
the Amiwest. OTOH IIRC AmigaOS has ported AGG already, so maybe we 
will be lucky :-)

Got it to run on Syllable Server, but it now has the irritating property 
of requiring the interpreter library to be in your current working 
directory that you start REBOL from. So I patched that away

It segfaults on loading R3 Chat. I don't think that was the case 
with the previous host kit I had (alpha 98, I think). It also works 
with the RT A107 binary

R3 Chat works fine for me, with Linux binaries built from the A107 
hostkit.

And I agree, the current linking is quite annoying. Here's a patch 
how I fixed it: https://gist.github.com/d1c120789a4b7acb635d

Andreas - any enhancements could go into default host-kit distro,no? 
:-)

Yes, just didn't yet get around to opening a CC issue for it.

Pekr, I bet the AGG part will be easy to compile on AmigaOS. I compiled 
AGG on quite few platforms and it went smooth. IMO More work needs 
to be done on the event loop and window management in this case.

Yep, the R3 specific interface is fairly elaborate

Considering I was the one who ported AGG to Amiga I don't think it 
will be a big issue... :-)

The tricky part will be the event handling and such which I have 
yet to figure out.

well, Amiga's event model is so clean , and actually the R3 event 
stack... well, its closer to it than the R2 was.

I got the A107 host kit working on Syllable Desktop

congrats!

Thanks. This is still using the same trick as the first port almost 
a year ago, by using the Linux binary of the R3 interpreter library

How did you test it Kaj? (I'm curious about testing these things)

It's become a bit more complicated because R3 is now using the dynamic 
loader, but the Linux library still works on Syllable Desktop

R3 Chat still doesn't work, though, but for a different reason than 
on Syllable Server

I'm only testing it by starting the interpreter and trying a few 
commands

Please don't use it to control nuclear facilities ;-)

just reading up on syllable... neat looking os

I like that it is amiga inspired ;-)

Thanks

Anyone know if we can shorten a block supplied to us in an extension?

it has to be the same block, not a copy.

something like the 'REMOVE function, but accessible from within the 
extension/host-kit

I think I'll be able to run the custom Gob Renderers in a multi-threaded 
setup by next week.


This means one thread will simply be rendering while the other will 
be handling events and manipulating data.


it should work since I've got changed state control built-into the 
primitve API, which lets the renderer know when to update its internal 
data... this will simply be set by the other thread.

if I can get the MM_timers to trigger the rendering refreshes on 
the renderer's thread, then the custom gob renderers can live on 
their own, and not even require explicit calls to refresh by the 
main thread.   


all you will need to do is manage data in the main thread, update 
it once the renderer is sleeping and it would update on its own when 
it awakes again.

if a data change takes more time than a single refresh interval, 
(i.e. the change is still occuring when the renderer awakes for its 
next refresh) then the renderer simply reuses the previous internal 
data. while its new user data is being setup.