AltME groups: search

but Glass will be built exclusively using OpenGL... its going to 
be vastly superior to AGG in what it can do.  never mind pixel details... 
we will have millions of concurrent objects on screen all in real 
time.

I may look at vectors in extension later to produce some sound streams, 
but have no time right now

Someone requested multi-dimension vectors or something like that 
some time ago. Is that already implemented? Would it be usefull?

knowing how smart you are this shouldn't take you more than a few 
hours the first time... and then a few minutes for following libs 
 :-)

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

ComLib: Using it quite often to control XLS. I hope to find the time 
to bite-the-bullet and givetti a try with a R3 extension. The current 
ComLib is good but fragile.

AdrianS, it's a little hard to work on that level right now, mainly 
because of the use of draw blocks which change all the time, and 
so a look would have to be constantly reimplemented, when things 
change in the UI system.

The problem with creating artwork now is that there is not a good 
method to implement it, other than by having to get your hands dirty 
and write the styles. There's no easy way to shove photoshop images 
into the R3 GUI. Maybe that will happen at some point. Feel free 
to post imagery if you like, but I'm afraid it's a bit of a waste 
of time right now.

About UI fads, I have been contemplating various designs that are 
not typical, but with things like the iPhone out, it's very difficult 
to differentiate from that, in a way that makes the R3 GUI easily 
recognizable. I would like to make a GUI that one doesn't forget 
that they have seen, similar to when you saw or used OSX the first 
time. I'm fairly resourceful, when it comes to building consistent 
GUI artwork.


About animation and gestures: If this is done correctly, they can 
be added as subsystems of the GUI.

Some time ago, I seem to remember some talk of masks to be used with 
styles for pixel accurate hit detection of non rectangular shapes, 
allowing for holes in styles, etc. Is this (still?) planned? If the 
framework allows for both bitmap and vector definition of styles, 
will any accompanying mask match the implementation? i.e. anywhere 
a bitmap is used, an optional bitmap mask could be used and where 
vector elements are used, a set of bezier (or other type) of curves 
would be optionally used for masking. If a particular style uses 
both bitmap and vector elements in its definition, would some data 
structure hold both types of masks?

can't wait for the time, when you will release some alpha or beta 
of the GUI for us to try our first experiments :-)

ladislav i foresee what i want and this R3 gui have not better reason 
to succeed than the previous intents since it's based on the same 
main problems to it's achievement in time you will get it.

I have no reason to shut my mouth when i see things so wrong. I exposed 
what i though of this process now please don't fuel me anymore do 
as i was far and in january 2011 remember i said this was going to 
a faillure.

I wanted to have this implicit NONE skipping for a long time. I'm 
not a fan of  using an either just to return "nothing". IMO an if 
that doesn't return anything at all makes a lot of sense if used 
with COMPOSE.

It's a DO action. The code in its argument only gets called as a 
result of the action, not at layout time.

view layout [
	button 
	do [ this at layout time [
]

Oh, you meant do [ this at layout time ]. It doesn't do it at layout 
time, only when the button is clicked.

The code performed by that action is evaluated by the DO dialect, 
but it is evaluated at runtime in response to the action being triggered, 
not at layout time.

Bolek has spent some time at the hospital.

I have interest but little time right now Henrik. What do I need 
to set up here to review and comment?

currently validation is triggered on window open to init state. then 
you can call it on the window as needed and it runs also as a reactor, 
hence every time a field is unfocused or a button is pressed. it 
also is triggered on window close, given the button that closes the 
window is a dialog button.

OK, when removing Title .... then my next question is - the window 
size is so small, that the button is not visible, unless I resize 
for the first time. But - Graham already reported that ....

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

bu this time i won't share them :)

In my opinion, you not only aren't a "free worker", but, actually, 
you are very costly in taking time and effort to deny the nonsense 
you are spreading here

how do we get time events in r3?

Pekr:  I had a contact who worked for Adobe and was a gui designer 
on many of their applications.  He is now an indepent contractor, 
but now that he's contracting he's enjoying his time to be with his 
family.  Adobe worked him hard for many years.  So, unfortunately 
he is not available to help out.

any... should read as... all languages at the same time...

The thing is, that for multimedia, kiosk, tablet, multitouch etc. 
UIs, all that stuff is useless, and that is my point all the time 
:-) Henrik - one question - aren't you afraid, that all the stuff 
you work on, might be dismissed by possible change in architecture, 
when some other subsystems are going to be added? And also - how 
all this stuff is going to be optional? Look - even low-level R3 
now has various boot options, so e.g. someone can write and replace 
even module system. Now how pluggable (functionality wise) is new 
GUI going to be?

You have some rules that you need to follow in any framework, otherwise 
they won't work for you. In the case for, for example db reactors, 
you need to know about the specific options, the rule that fields 
must be named for them to be used and how. But really, there are 
only few rules and once you've worked with attaching database records 
to a form, in a manual  way versus this way, you probably don't want 
to go back.


The other thing is an illusion of control with absolute flexibility 
without a framework. It simply lengthens development time and introduces 
bugs (something that we keep overlooking, eh?), and generally keeps 
the customer unhappy.

I worked with similar aproach in Clipper, and most of the time it 
was not flexible enough ...

Not sure it is now the right time to report bugs for area style, 
I simply regard it being very incomplete,  but - writing some czech 
chars into area/field does not work ...

GUI Enviroment. I didn't like it at first too, but I get used to 
it. OTOH, you don't need to acces guie most of the time.

Pekr, R3 is still in alpha stage. There are going to be changes in 
Rich Text Dialect, PARA handling will be different from what's it 
now, so focusing too much on look right now would mean wasted time.

I'm starting to think that this "release often" strategy is not a 
good idea at all and a waste of time.

Rebolek - I will be harsh, but others might feel, that what is waste 
of time is lack of communication and providing big picture. You accepted 
SCRUM methodology, but only for your team internal purposes. The 
rest of us knows nothing about what's happening at particular levels. 
If you stop informing ppl, then the only thing we would know about 
the GUI would be, that team of 4 ppl are working on it for 4-5 monts, 
with no visible result. Ppl are very eager to have GUI.

Releasing often is a waste of time.

Robert - I can't work with RMA team by writing code etc. My primary 
job makes me come home between 18:00 - 20:00, then I have another 
company where we run 700+ wifi users, some other projects. I am not 
complaining, I like it :-) It is just that a) little of free time 
remains b) you would not want my "code" to oficially accept :-)


But - I don't necessarily be the one, who just talks. Give me something 
specific to test. I think I now will find my way with Henrik/Rebolek 
on my own. It is just the current release format (flattened source) 
is a bit uncomfort to study code segmentation and separation, and 
- difficult to know what changed, if there's no changelog. (I know 
I could use diff on 256kb source, but ....)


So - I think I will let it as it is - it is enough if e.g. Rebolek 
says just few words for the release - e.g. - please test new tab 
... and I can look at it, and givi it a run ...

Thanks. Btw - were we succesfull in getting in contact with the gfx 
artist? IIRC someone suggested one person to Robert, but I think 
that the person in question was not interested. I wonder if Amiga 
community could help here? :-) I think they will be kind of friendly 
to REBOL, because of Carl. Or put it another way - will you Henrik 
come up with some final skin, once there is a time to address it?

I'm thinking there is a design issue with validation, particularly 
the initial state:


The latest version will show that the "Only Chars" field validates 
as OK, which is technically correct, but confusing, as absolutely 
nothing has been entered in the field.


The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation. All fields 
that show a black dot, actually fail validation and a black dot is 
shown as the initial state.


I understand what this means, but it may be confusing for someone 
who is using the validation system for the first time. The fix is 
simply to add the NOT-EMPTY validator to the field, for the field 
to fail validation initially.

Is this easy to understand?


I've studied the issue with setting an initial state for each field, 
but then there would be a problem with the validation system understanding 
prefilled values, and I would have to add functions to the validation 
system to mimick SET-PANEL that setup fields in a special way. I 
don't want to bloat the GUI like that. This method works fine, as 
long as you know what's going on.

I just think that the work is running in multiple levels (native 
- Cyphre, styles - Rebolek, high-level - Henrik), and at some point 
in time, it will all settle down and merge together ...

Of course I am tempted to see things we expect most - more complete 
styleset and at least basically usable gui, but I will test what 
comes-out, as I think talking about what will come next just makes 
guys nervous :-) Of course some basic time-frame  would be usefull 
...

Time frame is ASAP. The work is being done for apps (now not one, 
but two) that need to get into the field by RM Asset as soon as possible.

It was decided a long time ago to do future projects in R3 as we 
felt that continuing to write testing tools, frameworks, etc. under 
R2 would give a big pile of work later, when converting that to R3.

Considering also that the result of that decision is that Carl is 
now in tight communication with RM Asset, I think it was a good decision, 
as we avoid the months of darkness without info. It gives RM Asset 
control in what direction to take the GUI and to work towards R3 
being a usable product as quickly as possible, when you have to answer 
to other companies and customers. SDK is also a requirement, that 
we hope can be pushed through as quickly as possible.

A pair! has two more problems, actually:


1) it is redundant, since knowing the number of cells, and just one 
of the dimensions, you can easily compute the other one; such a data 
redundancy is, in databases, called "denormalized data" and is undesirable

2) the user frequently wants to give just one number, assuming, that 
the other is computed every time some cells are added or removed, 
thus, not wishing to give the value for both dimensions

the last time I worked on a grid, the sizing values where autocomputed 
and shared accross rows and columns.

ah... did you actually read the node names?  they are actually functions. 
  connecting them actually shows the value in the gray box in real 
time.

with elixir you can build google-wave like concurrent user apps with 
just a few nodes.  then you can wrap them in a pool and just provide 
the pool as the data to another node.


it is even project that we will be able to reverse-script a pool 
and provide its structure as an output, so that you can actually 
share the pool's structure in real time along with the data it is 
linked to.

the reason I am working hard on the R3 OpenGL engine is that I want 
to be able to display hundreds of thousands of things in real-time, 
smoothly.

i will try to think this  more  i like the idea of  having a fast 
view uppon rebol script as a view boxed/noded in realation one to 
another. I like the idea of behing able to "enter" those box/nodes 
to adapt them enhance them or simply redefine them. I like the idea 
of sharing pre-sets box and having a synchronised / shared tool box 
.If i design a tool and make it available then in a short time that 
tool becomes part of the hudge collective tool box and then is shared 
to every one.

Drag and drop - nice feature, about tab preview, I am not sure about 
that one. It felt a bit distracting last time I saw it. Can it be 
turned off as a feature?

Imagine saving the size, ordering, freezening of grid columns for 
e.g. It would be tiresome for user set it each time app starts .... 
just an idea ...

actually not, since some tabs contain nearly identical UIs. people 
are not used to looking at the tabs at any other time than when selecting 
them.

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

'stylize hierarchy, not at this time, I think. it would be easy to 
implement if we need it.

yeah .. it should be if anyone has the time and rights

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?

To have event transparent gobs is on my wish list for a very long 
time already.

to the focus discussion. I don't know why, but I agree with Rebolek 
this time :-) I know that I am fan of concepts, and subsystems. IIRC 
VID2 used something like abstracted feel storage. Maybe it was initially 
a good idea, but how often were 'feel objects actually reused? This 
was imo an example of a concept, which did not live to its expectations.


I know that R3 GUI is abstracted in better way. But I also feel, 
that we more clearly kind of encapsulated styles - they have all 
those on-* actors, which let the style to react to various events 
in its own way.

So - stating above - are we really sure that:


1) having abstracted all-styles-related visual representation of 
focusing brings us an advantage? One advantage might be, that if 
it is not central, lazy style coder might not implement visual focus 
representation, and then half of styles might miss it, or we might 
face some weird situations, when the style author implements the 
visual focus representation a different visual way.


2) are we sure that one central system will work for e.g. for some 
complex styles, where some special tricks might be needed to display 
focus visual representation correctly?

I don't know why, but I agree with Rebolek this time :-)

 - sounds like it's unusual. I though we're in agreement most of the 
 time :)

that's all

 - and then you have to change it per new style and every time you 
 change a box rounding, etc.

Ah, ok I understand the mechanism you've got in mind. But implementing 
this would take more time than I spent implementing focus in-styles. 
But this would be nice to have, I agree.

Mouse over on tab-button opens tooltip with preview that's done using 
to image! I saw some problem ssolie had here some time sooner and 
to image! was in the error description. I wonder if you've got latest 
R3, I had preview disabled in previous versions because to image! 
was causing crashes.

Pekr, if you've got some time to help, please, have a look at keyboard 
nav and post any problem you find to me personally to not polute 
this channel. This will help very much.

Dunno if it would be good concept (it might be confusing for user), 
but some time ago I was thinking about nested tab system. What I 
mean is - most of tabbing systems do work in a flat way. It is kind 
of primitive. But - sometimes you might want to use the same navigational 
keys for more complex styles, typically subpanels, grids.


What we recently got (and can be seen with e.g. style browser) is, 
that e.g. tab panel can be tabbed. Then arrow keys do switch between 
tabs. What I had in mind was to be able to press enter, to nest the 
tabbing, so that you "enter" the subpanel, and esc to escape back 
to the upper level (this part might be tricky for users, not sure 
about it - they might feel being locked inside of some style).

Any ideas?

ssolie, since it tests styles, the app should be complete, but may 
occasionally encounter styles that are unfinished. the program should 
be used, every time r3-gui.r3 is updated.

Button can be focused. Small enhancement request - can we add enter 
reactor for the button? I would find it usefull being able to run 
the button action hitting enter :-) btw - panels-2 - can't focus 
any button after the script start. Only after I invoke first button 
press ... now R3 crashed big time :-)

If something happens at least we should be back to full steam in 
much less time.

Brian, my project will start on February. There is no time to wait 
for anything REBOL based.

We should probably just get rid of LOAD-GUI, for the time being.

Carl is currently only observing, but I've not seen any comments 
from him on GUI development. But at this time, the number of RM Asset 
programs and tools that requires the R3 GUI is growing, so we are 
not in a position where we can hand things over to Carl and expect 
him to evaluate, rewrite and finish it.

Making simple architectures is hard. It requires an understanding 
of how to design systems that will work both in the big and in the 
small, while remaining simple. If you don't have this understanding 
(or don't get enough time to finish the design), you will tend to 
add more systems to cure the symptoms or counteract existing systems 
for scalability. I thought this was pretty basic?

These docs don't yet include the real subtleties of when to use IMPORT, 
when to use DO and when to use Needs. In particular, they don't say 
when *not* to use IMPORT directly and why, what the difference is 
between named and unnamed modules, or any kind of hints about overall 
program structure. This is partly because the docs were written (by 
Carl) before the module system was finished (by me) so that info 
simply wasn't known at the time, and partly because I could use some 
help with writing docs about those issues that don't read like a 
CS paper.

OK, now we finally have the requirements for delayed modules (and 
bug#1628). Time for me to work through the issues and implement them.

The questions I have are:

1. What do we do when a module is not added due to a policy issue? 
Currently the add accessor returns none if it is a version issue, 
and triggers an error for a checksum violation.

2. How do we determine (officially) that two modules are to be considered 
the same? Name and version?

2. Can we safely LOAD-EXTENSION more than once with the same extension?

3. Does LOAD-EXTENSION on an embedded extension have any side-effects 
beyond creating an object?

4. ... return the same source each time, or different copies of the 
same source? Testable by SAME?

5. Is is safe to delay the object returned by LOAD-EXTENSION instead 
of the source?

Excellent.  I'm looking for guru-level docs.  


If I'm reading this correctly, I will finally have everything I asked 
Carl for (in regards to Object! enhancements) at the '04 Devcon. 
 I'm going to spend some time stubbing out the functions I will need 
to do the advanced IDE tricks I've been wanting to do.  I'll have 
some questions for you once I get some of that done...

The modules that implement the protocols could be delay-loaded and 
registered with the general protocol dispatcher. Then the dispatcher 
could import the module the first time it is needed.

For the sake of completeness, here are the highlights of the alpha 
108 changes:

- Script headers can have an options block, a simple block of flag 
words. User extensible.

- The standard script header now has a lot fewer words in it. More 
stuff is optional or in the options block.

- Script compression, either binary and base 64 binary! encoded. 
Automatic, transparent.

- Script checksums, both to verify the script and for IMPORT to compare 
with. Applies to decompressed source.

- An optional script length header field (like http's Content-Length). 
This allows binary script embedding.

- Internal support for getting the end of an embedded script, so 
a multi-loader is possible.

- The 'content and 'isolate header fields are changed to option words. 
The content is still saved to a 'content header field.

- The 'content field, if set, is set to the start position of the 
script proper, even if there is stuff before it.

- The whole system/contexts/system concept is gone, as part of the 
system restructuring. Now we have SYS.

- The system/contexts/exports concept is gone too, replaced by a 
not-module-specific runtime library called LIB.

- The old type: 'extension is now the 'extension header option word. 
The only module type is 'module. And it's optional for most code.

- Mixins are now called "private modules", and are flagged by the 
'private option word. And they can have names.

- Private modules can be added to the system modules list (because 
of the names). This lets them be reused without being reloaded.

- Unnamed modules are now prohibited (until alpha 109, where they 
become private modules that reload every time).

- Delayed modules, which can be partially loaded and then not fully 
made until they are imported. Use the 'delay option word.

- A HIDDEN module source keyword, which applies PROTECT/hide to a 
word or words. Acts like the EXPORT keyword.

- Better errors are triggered when the bad things happen. Including 
new error codes.

- DO and MAKE--MODULE intrinsics are now in sys, as DO* and MAKE-MODULE*. 
No more system/intrinsics.

- DO-NEEDS is no longer exported (it's in sys). IMPORT block is a 
public alias for DO-NEEDS anyways.

- MODULE now makes modules that act more like those in script files. 
And has /mixin support too.

- A whole bunch of changes and fixes to native functions to support 
the above stuff.

Need to find some time to play with it first, but it sounds like 
"private" modules and/or IMPORT/no-lib/no-user will be most useful.

Part of exporting is copying the values to another context, where 
it is used. You don't normally get any references to the original 
module words. And part of importing is copying those words again 
to your own context (for isolated modules and for scripts), or binding 
to the runtime library. So in practice, the only known contexts that 
you can update the values in are your own, the runtime library, and 
the current task's user context. To upgrade other contexts they would 
need to register with you, and you would have to do them one at a 
time.

Next week, as time allows, I will be reformatting the module system 
into a loadable script that can work at lower boot levels. This will 
both be good documentation and allow better testing, for the module 
system and the boot levels too.

At the time he wrote that blog the name getting applied feature hadn't 
been added yet.

Technical reason = because one has a name and the other doesn't. 
I'm not dumbing it down, it really is that simple.


Say you are a module, and I want to import you. It's rather straightforward, 
I just add your exported words to my collection (how I do that depends 
on what I am, but that's a story for another time). And then I can 
use those words, no problem.


But what if I don't know whether you have been imported already? 
Or what if I know you have been imported by someone else, but I want 
to use you in particular instead of someone who just looks like you? 
Or what if you have data that you want to share, or resources that 
can't be used more than once at the same time? Or what if you want 
to know if a previous version of you was imported already, so you 
can get that guy's data or resources and take over for him?


To do all of these things, you need a way for others to refer to 
you, a name. If you have a name, I can put you in a collection with 
other modules and then others can look in that collection for a module 
of that name and if they find one they can know that it's you. Simply 
having some way to find you in a crowd makes all of that stuff possible. 
It really is that simple.

As of alpha 110, all tests of the module system pass! Time to write 
more tests :)

Time to show examples of all of what it can do... and get developers 
using some of this good stuff.

And I personally would suggest Git, put that'll take time and effort 
to get started with.

So.. time to learn yet another source control system?

But one step at a time :)

Well, forward-looking platforms either run prior code, or are totally 
new, so require some degree of time investment to get started on 
them.

ok, time to try the git on your url... scanning back.

Most of the time I write it host-kit.

The problem is that host-kit appears in many places spelled like 
that already. It may lead to errors to remove the - at this time.

Now someone should really write some short docs. This is so complex 
and surely was not created for normal mortal, who just wants to download 
few source files and build a distro? So I downloaded Tortoise Git, 
naively thinking this is all I need. No, so I installed Git preview 
version (not full msysGit). Now - what should I do? I created a directory 
called host-kit, right pressed mouse, and chose "create repository 
here" or something like that. Now once again I press right mosue 
button, and try either git-clone, or Git sync, but it does nothing 
... I think my problem might be (apart from being too dumb and not 
willing to spend tonnes of my free time with such complex stuff):

- I am required to have some kind of account at target site

- I don't have it somehow linked with SSH stuff (did not choose to 
use my putty installation during the installation phase)


How do I get the actual copy of R3 Host Kit? There might be plenty 
users as me, willing just to download recent sources, and build, 
not to commit anything ...

I installed TortoiseGit some time back, but Explorer started crashing 
soon after (XP x64 here) so I uninstalled it and the crashes stopped. 
I'll try it again.

One step at a time :)

it happened in various time for various users :-)

Well, do you have more time on Thursday?

It's better for the config to be higher level in the master build 
tables which are defined in REBOL.  Those tables define more than 
just GCC compile time symbols, but also code/data within the boot 
scripts used by the interpreter.

The goal of the current R3 build automation method is to save my 
time.


Currently, the platform table is only ~10 lines of REBOL, so it is 
difficult to beat using any other method.  And, even with the detection 
approach you mention, you need still tables.


However, that being said, if you want to create and test such a detection-based 
method and confirm it works over a range of OSes I would be happy 
to use it!  It must handle Linux, Syllable, BSD, OS X, Solaris, Windows, 
AmigaOS, Haiku, QNX, and various others, and also work for systems 
ten years old or more.

I'm open to any idea like this... as long as it saves *me* time.

Right now, the manual configuration doesn't take much time, because 
we're building only /core and /libr3... and for posix model.  Once 
more features are added, like graphics and sound, or specific OS 
support (e.g. like what Solie is doing) then we'll need to revisit 
it.