AltME groups: search

I'm trying to compile a host-kit for amiga.. getting an error from 
RL_Init() stating Host-lib wrong size

its possible that the amiga core.library has a different number than 
what is in the include.

ssolie, try a size of 33.

Carl changed a few things in Win32, but never got around to propagating 
that to other plafs.

the HOST_LIB_SIZE is generated via a script according to the header 
comments

yes.. is there a linux one?

A107 had a Linux version yes.

that is true.. I couldn't find a 109 version

did you get a host kit for the amiga from carl?

I take it a couple of vectors need to be removed then.. which ones?

Wait, I have a patch for that somewhere.

I only managed to squeeze a few minutes out of Carl at the show

Let's just do a quick sanity check before wasting more time on this. 
Change the #define HOST_LIB_SIZE in host-lib.h from 31 to 33 and 
see if you still get the "wrong size" error.

then just see if the functions actually match to those.. in the host-kit


ex, does calling RL_Get_Value actually try to get a value from a 
block or is

nothing. it's a value kept in sync between libr3 and the sources

a simple sanity check

I'm such a make noob hehehe

its just a command-prompt function.

libdl.so is implemented as well as a more native amiga elf.library

libdl.so is a thin wrapper for elf.library

I've one more tip on the way of getting started with AGG: A109 has 
a stupid typo in it.

whew... I have a TO_AMIGA Carl added

Maxim, a subset is currently available called MiniGL

it allows you to hook up alternate graphics drawing within AGG or 
directly on the window which view opens.  though you still have to 
map all that nasty OS specific windowing event stuff first.  keep 
in mind that you might be able to do stuff like a datatype viewer 
right into the view engine  :-)

it being the CGR path to host-kit... its still an infant, but I think 
its promissing already... just worked out a few issues with Andreas 
and its working fine on windows now.

Andreas, sharing a common host-kit might be #ifdef hell though?

Yes, in a few places.

We just really need to get Carl to the point where the hostkit is 
kept as a single source base.

I maintain a Git mirror of the hostkit sources at http://github.com/rebolsource/r3-hostkit

is there a standard for EOL?  amiga uses LF as most sane OSs :)

and I'll probably put my CGR package on github too in a short while.

Why is there a BOOL and a REBOOL ?

I'd just rename the rebol BOOL to some other Identifier,and do a 
quick recursive file replace... I looked and its not used that much.

then give a note to carl so that it gets changed in the next host-kit. 
  cause I don't find it a good practice anyways.  strangely, I was 
wondering if BOOL would cause compiler hickups a few weeks ago.

we can supply a stdbool.h and stdint.h for the MSVC users if need 
be.. until MS catches up

anyway, just a thought

Is there a version of the host-kit that works with AGG without Windows?

in theory you can use to-image! on a gob!   but I'm not sure its 
been fixed in latest hostkits and not sure that really answers your 
question either ;-)

ssolie: the only file that needs to be reformatted so it supports 
other platforms than windows is agg_truetype_text.cpp + .h

Otherwise there is already available FreeType wrapper so the rest 
of code can work  even on OS4

But the current hostkit code needs some more work to extract the 
font/text rendering parts so they can be controlled by defs.

If you don't want to waste time on this I can have a look at it over 
the weekend and make the changes so you should be able compile without 
the text code for now. Just let me know.

scanning: reading back a few pages...

btw, I released a new host-kit which has custom gob rendering enabled 
(very early prototype) but its got an OpenGL rendering engine running 
within view.


you can see the download link in the announce group, if you want 
to try it out.

Andreas: the code base is a mix of both single source and multi-source 
tree.


I will not allow source files to become unreadable with every other 
line being #ifdef for a different OS. Those are not maintainable.

this being said I would like to have a private chat with you about 
some issues I encountered so far.

A: The OS/dirs are for code that is really quite different.  Merging 
into a single source does not help keep it in sync, because most 
coders only modify the platform of their choice. They can just as 
easily diff.

(Let's just say I've been doing source control for a long long time. 
;)

Just to get rid of this artificial distinction alltogether, and keep 
the hostkit a single distribution, from which all platform targets 
can be built.

Just checked: there is in fact not a single significant line of difference 
between the Linux and Win32 hostkits, except for the hostlib vector. 
So why not concentrate on a single distribution from which both targets 
can be built.

But what's really more important: any chance to see a libr3.so for 
Linux soon?

libr3 on Linux and Amiga expects a hostlib vector of size 33, r3.dll 
on Win32 one of size 31.

Well, there is a problem, because the libr3.so must be in sync.

There will be a host-kit release archive, then there will be the 
separate dll/so objects in a table.

The issue is that the builds are automated to a whole other level... 
beyond what you are seeing in the host-kit source.

Correct. You're seeing a snapshot.

The fact that the host-lib is out of sync is an interesting puzzle. 
In theory, that is impossible to have happen if a /Core is released 
along with a /Host-Kit.

That is a process and as such language and toolchain agnostic.

Continuous integration is really a separate dimension from automation... 
it's a set of objectives for more frequently producing test targets.

And whatever you want to call it, the process is simple: you have 
a single code base, version controlled. Upon every change to this 
code base, you automatically build and test on all supported platforms.

Without human intervention. You commit a piece of code, and automagically 
7 machines pick up the changes and start building.

Continuous integration is really a separate dimension from automation.

carl, I have to go now... take a peek at the private messages... 
I'll pick up later.

Some of that was the goal of DevBase... but there are only so many 
hours in a day.

And as you obviously want to maintain the closed-source nature of 
libr3, that step will already require a bit of work.

Then the first step would be to create a post-commit hook (a script 
that runs on every commit), that exports your internal sources into 
the externally visible sources.

Andreas, we should probably switch to a different group to keep all 
this together... is there a group already on this?

what would be the simplest code to open a window in r3?  the window 
doesn't have to have anything in it

you might get a wee tiny window though

I think Steven just wants to fire a window creation sequence in the 
host

They allow C libs now. So, if someone wants to make the host-kit 
work on Andoid, it might be a quick port.

First step would probably be a Linux ARM build. Which will be really 
rather quick.

A console-mode core build could even be used on Android directly 
from the terminal.

Android has a native library API model. We could make a host that 
acts like a native library for Java according to that API.

I assume that there is a native API for BB as well, but don't know 
anything about it.

(yes, it went defunct a while back)

http://github.com/carls/R3A110-- a temp test area for Host-Kit A110

and a LEG

foo.c, bar.c and a makefile

I seem to remember from last time we tried this... there's a special 
linker tool required on OS X.

But, it was a while ago, so I could be wrong.

I think the reasonable way is to get you a reasonable linker.

So, you're telling me that everyone who built software for 10.4 used 
a bad linker?

Perhaps I can cross build the lib from a linux box... ?

Yes, but that's a lot of work.

Here;s a direct link:

https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19907

Unfortunately I don't have the exact machine I tried not handy at 
the moment. But I know it was a 10.4 OSX and I know that the above 
"exports.tar.gz" worked.

I can have Cindy setup a new devl account... but I suspect this will 
all lead down a road that will cost me a lot of time.


I don't see why cross building from Linux or BSD is a problem.  It's 
just a lib, not an app.

Because setting up the cross compiler is a lot of work.

How would I know? I  built such a cross-compiler before:
$ uname -sm
Linux i686
$ gcc -dumpmachine
i486-linux-gnu
$ i686-apple-darwin9-gcc -dumpmachine
i686-apple-darwin9

And that'd still need a Mach-O linker.

I'm not seeing my Dev_Event device's RDC_QUIT vector being called 
when I exit r3 with a 'q' from the command line. I do see the RDC_INIT 
vector being called.

yes, setting up a timer at the moment

i have a dirty hack somewhere for linuxisms :)

the Dev_Event device has a #ifdef TO_WIN32 on it

took me a while to figure out why no events were happening... heh 
:)

if RDC_QUIT isn't working should I file a bug report?

i think so, yes. even if it is not a bug, it'll help clarify when 
the quit callbacks are actually supposed to be called.

you have a message loop :) ?

btw.. how do I add line feeds in altme?  so everything isn't a new 
line

do you have a window opening for the window gob already :) ?

one small step at a time

I found this line in the host-kit when handling the closing of a 
window:

Close_Window(gob);	// Needs to be removed - should be done by REBOL 
event handling

My question is how do I do this the right way?


I think I need to do an RL_Event(EVT_CLOSE) and then somehow wait 
for REBOL to notify me. How will REBOL notify me it is ready to perform 
EVT_CLOSE?