World: r3wp

Revision control, test suites, rapid/daily builds, easy downloading 
of results.

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.

Yes, exactly. But not "rapid" or "daily" builds, automated builds.

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.

We've been doing that since 1999.

Build automation and test automation is one integral part of modern 
CI.

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

M: ok

BTW, Jeff Kreis (at REBOL) wrote the system we used for full cross 
platform networked automated builds.

Time to get that going again for R3.

You're probably right.

Back then we did it internally and used our own method. But, by now, 
there must be some external method that will work, right?

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

It's all doable.

The other important issue is that easy rollback (revert) is required.

And if we don't reinvent the wheel at every step, it'll probably 
be done sooner rather than later.

I don't think we need to invent anything for this part of it.

E.g. we still use makefiles... works fine.

The first step is having the sources version controlled.

And DevBase would not be my first choice for that ...

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

WRT the tools, we go down this road every year or so... but what 
happens is that no good solution is found.  However, I remain open 
minded.

Concretely: let's assume you have your internal sources in Subversion 
or Git.

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.

Those "externally visible sources" are what I consider to be the 
hostkit.

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

Don't think so.

(And yes, we probably should.)

Ok, making it now.

hey there.. any Qs for me?

ssolie: ok, I'll make the changes over the weekend and let you know

Cyphre: thanks! I look forward to testing this out with freetype.

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

From the REBOL side? view [] I guess

you might get a wee tiny window though

Doesn't have to have anything in it

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

I found some code to make the gob and then view it which is working 
fine for my testing now

win: make gob! [text: "Test Window" offset: 100x100 size: 300x200]

view/as-is win

Ah yes, you need it without using VID, of course

that was the tricky part for me

still getting used to rebol here.. :)

ssolie: the really 'bare-bone' sequence to show window is:


show append system/view/screen-gob make gob! [text: "Test Window" 
offset: 50x50 size: 200x200]
wait system/view/event-port

So the Amiga is first from non mainstream OSes. Which one do we choose 
next? Any mobile OS takers here? :-)

We have several users asking for Android

unless they've given up waiting

I have not given up waiting. Part of the reason I got an Android 
phone in the first place was to port R3 to it :)

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