AltME groups: search

If we want to pursue IPC chat, make suggestions, and get Carl involved 
(at least get some his thoughts), we should do it in a different 
group or somewhere else. Should we do it on AltME or somewhere else?

Andreas: thanks? With A100+, it seems that we need some other headers: 
ext-types.h, reb-defs.h (also present in src/include ). However, 
although they compile, it seems that they cannot be opened under 
r3 ( access error: cannot open %xxx.dll ... reason: none). I suspect 
the absence of a given #define flag, but not easy to debug. Anyway, 
I think that it would be useful  to clarify. If anybody already succeded, 
please give us the set of files and the config used. If not, could 
somebody do the test ?

thhanks, I will try. But my problem is not here. I have two concerns 
:  for the extensions dealing with strings (not the simple example 
where one reverse the order of chars), the compatibility is no more 
achieved (because of changes in the representation or processing 
of strings ?) Then I have to compile using the new headers. And when 
I do so, the extension is no more loadable (even a simple one like 
your example)

Sorry, don't get what you want to do. You can run some init code 
when the extension is loaded.

Hmm, I somehow don't manage to compile my odbc extension with a109, 
on import I get the following error

>> import %../lib/odbc.dll
** Script error: make-scheme has no value
** Where: do -apply- make catch case case -apply- apply import
** Near: do body obj


I do understand that it's related to MAKE-SCHEME moving into SYS 
context,. Do I have to import SYS into my extension module's context 
first and, if so, how? NEEDS: [SYS] doesn't work, my extension is 
already declared with TYPE: MODULE OPTIONS: [EXTENSION DELAY], trying 
to access MAKE-SCHEME directly thru SYS/MAKE-SCHEME makes the intepreter 
crash.

We have been discussing adding a header option to tell the system 
to put off loading an embedded extension until after the mezzanines 
have loaded (or have that be the default, and have an option to load 
before the mezzanines). I haven't looked over the startup code yet 
to see how to do this, but it shouldn't be too hard. I'm waiting 
for Carl to decide on the option (he seems to be the namer of that 
kind of thing right now, I'm just an implementor).

I'm completely C/C++ newbie, so I would like to know, how to make 
the extension, if I have precompiled DLL.
For example, In R2 I can simply download the DLL like this one:
http://zlib.net/zlib125-dll.zip

And simply do:

zlib.dll: load/library %zlib1.dll

zlib-version: make routine! [ return: [string!] ] zlib.dll "zlibVersion"
zlib-version
;== "1.2.5"


Is there someone who can write a simple tutorial - C extension with 
the zlib-version command?

I understand the REBOL part of it, but would like to see how to do 
the DLL trick part. Including the correct gcc command.

No, you can't do that from zlib1.dll, you'd have to use the zdll.lib 
in lib/.

That's also a question for me ...

Part of the answer is that using it in a cpp exe will allow to execute 
these functions without te burden of executing a c process while 
masking the dos window (which is a huge challenge here, and I do'nt 
know why). In the case of Rebol, yes, the interest is not so evident.

Maxim, yes, I have seen bindings to other languages, but I am still 
not convinced that its much simpler than coding directly in C or 
C++

Oldes, I did not know im-min.r. It's a nice work. I have not enough 
experience in Extensions to do such work, as the input-output methods 
of R3 extensions are a little tricky.

however we do it, the problem is not in how, but that we forget to 
do it in the first place.

__VA_ARGS__ can only appear in the expansion of a C99 variadic macro
Never mind... I really have to do real work now :)

And, what would you do: (1.) Save wand pointers on REBOL side, or 
(2.) only on C side and provide just IDs (index) to this pointers 
(which is probably safer but would require dynamic array on the C 
side)?

REBOL doesn't have pointers, it has references, and it doesn't have 
addresses. So the only way you could legitimately get a pointer is 
to return it from a command. But you don't want to have any way to 
construct an illegitimate pointer in REBOL and pass it to a command 
because that would be a much worse security and stability problem 
than just having commands at all, and treating pointers as integers 
lets you do that. So there is the handle! type to store pointers. 
A handle! is an immediate value that is the size of a pointer, but 
that you can't convert directly to or from any other value, or even 
mold it to see its contents. When you return a pointer from a command 
you set the value to the handle! type. Then that handle! will be 
usable when passed back to other commands in the same extension, 
and maybe even when passed to other extensions, depending on address 
space issues. Handles are also used to store function pointers in 
R3, and other opaque system values like library addresses.

the problem with my function is, that the utf8 string is not null-terminated, 
how to do it properly?

One question about your function. When do you free the memory you 
allocated to utf8str?

what you can do, is wrap your command within a function in the extension's 
module and expose that function.  this allows you to control the 
return type of the command better and handle it within the comfort 
of rebol.

Why do you think the first idea is too complex? I for now don't get 
the "I would like to have just one function" argument.

When I have func which require something like:  double *distortion 
  so it modifies the value of existing REBOL variable, how to do 
it?

And you don't have to worry about the GC collecting a double since 
it will always be in a value slot, so all you have to do is protect 
the series or context it is in.

He was asking about changing the original. The only way to do that 
is to pass a reference to the series or context that contains the 
original value slot.

yes, that's correct.  I though he want's to do something like:
d: 0.0
change-decimal d
probe d
== 1.234

yes.. that's what I wanted to do:)

Having:
	double mean, standard_deviation;
What I must do to get REBOL block with these two values in it?

Ok, done. We will add more stuff like the style browser. I need to 
talk to the guys how to best do it, so that it all works right out-of-the-box.

Seems to be better.  But what is final result expected ?

>> do %test-framework.r

Script: "Test-framework" Version: none Date: 19-Nov-2010/15:00:45+1:00

Script: "Line number" Version: none Date: 1-Nov-2010/14:21:20+1:00
Script: "Catch-any" Version: none Date: 3-Nov-2010/4:58:46+1:00
== make object! [
    log-file: none
    log: make function! [[report [block!]][
        write/append log-file to binary! rejoin report
    ]]
    skipped: none
    test-failures: none
    crashes: none
    dialect-failures: none
    succeeded: none
    failures: none
    exceptions: make object! [
        return: "return/exit out of the test code"
        error: "error was caused in the test code"
        break: "break or continue out of the test code"
        throw: "throw out of the test code"
 ...

I tried to use SciTe editor to run a simple gui script: rebol [] 
 do %r3-gui.r3 view [button]

Otherwise, the only option is to shut down completely and not do 
any development work in the open, but only in invisible elitist circles. 
We all know how well that approach has served REBOL in the past.

I used to develop a Chinese Font Engine in R2 using Win32 API GetGlyphOutline(). 
Now I am trying to do it again in R3, but this time I will get the 
glyth data from OpenType font files directly. Basically, I can read 
the Glyph data now, However, when the glyth has zero contour, my 
OpenType font format parser got error. The OpenType Spec offered 
by Microsoft is not clear to me on this.... Hope I can solve this 
problem soon. I cannot wait to see Chinese Characters in My R3 GUI. 
:-)

And, as another poll question: do you find all four alternatives 
useful, or would you prefer to use just some of them?

Initialization is hard: for a FIXED face we still don't have a way 
how to specify the offset, do we?

well, we don't need to do it that way...it could be just used as 
'gob/offset setter' duirng the layout parsing...no need to ster the 
value afterwards.

yes, easy to do

Do you really hide something by setting its size to 0x0?

wow, a progress ... will read it shortly .... guys, I have one question, 
which will most probably get dismissed, but I'll at least try to 
ask:


- when prototyping stuff in console, and e.g. when your gui crashes 
from some reason, I am very used to just "unview". But - in R3 I 
have to do either "unview none" or "unview 'all" (not caring about 
the name of the window)


So my question is - couldn't the aproach be rethought, and old R2 
functionality brought back? Especially "unview 'all" in comparison 
to (imo) more rebolish R2 "unview/all" is non intuitive for me ...

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

that a face is inadvertently presented as zero-sized

 - this may occur, should a style implement its own layout engine, 
 which is possible to do.

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

In human languages, words are almost all polysemous. The true meanings 
of words is given by the context.

Carl was able to expel all the horrors syntactic found in other languages. 
So we can almost read code like a human language.
Do not lose this goal, if you can.

hello.  I got to run the R3 gui and got some troubles : i use the 
r3-a110-3-1(1).exe and the r3-guihttp://94.145.78.91/files/r3/gui/r3-gui.r3
and run this : do %r3-gui.r3 and got this in return :

The term "faceless" is pretty accurate. What I'm worried about is 
that it will fail if the gob doesn't have any face assigned to its 
data field. It would be more robust to do this instead:
faceless?: func [
    {find out, whether a gob is faceless}
    gob [gob!]
][not same? gob select gob/data 'gob]

Throw in enough conditions and it becomes faster to...

 - I do not want to throw in any unnecessary conditions. The condition 
 I used was verifiably necessary, but I do not know whether there 
 is any other.

It would be hard to do a code injection with this code, since SAME? 
takes two arguments so you can't easily inject with a function that 
takes an argument, without causing an error in the call to SAME?. 
The only other way to inject code would need debug permissions. So 
it's not a big deal here.

What I want to do is to make a box with an Image as borer pen. Not 
able to do it with R2 nor R3 (see 'View group).

Henrik: I get crashes of R3 when doing following:

>> do %r3-gui.r3

>> do %panels-21.r3 ; close a window, and do the same example again 
- it takes 2-3 runs to crash the R3

when I close the window, I expect all objects do exist defined in 
the guie structure? The question is, what does consecutive run of 
the script do to the system then :-)

unload" window (layout)" - possibly just by setting the window face 
to NONE. Most of the time, you don't want to do that, so I don't 
think any special functions are needed.

Sorry, I mistook the third panel for a VPANEL, but that just simplifies 
the explanation that this is not a bug:


1. The button can vertically resize, as its min/max size is not the 
same. This is correct behavior according to the specs of the style. 
This is not the same as saying that this is esthetically sensible 
behavior in the button style.

2. The panel in which the buttons reside can also resize vertically, 
because the button can resize vertically. This is correct behavior.

3. The parent VPANEL, when resized vertically, can resize its inner 
faces to their limits, like an accordion. The limits are defined 
by min/max size. The second and the third panel, which both display 
squashed buttons do this, because their vertical size define the 
vertical size of the two cells of the parent VPANEL. This is correct 
behavior.


To get rid of the problem the button should have vertical min/max 
size being the same. That's all.

A simpler way to show exactly the same behavior is:

view [vpanel 2 [hpanel [button "1" button "2" button "3"]]]

Btw... the main problem I see is, that current R3 is not able load 
PNG24 image. If I would like to do own GUI, and or game in Rebol, 
I would like to use semitransparent images. (I know that there is 
a lot of people who don't like bitmaps, but I see bitmap usage useful). 
I can load any image to Rebol using ImageMagick, but that is not 
a way we want to go... IM is too large to be used as common Rebol 
way how to deal with basic images.

I know... I just do what I can.. to point out that we are missing 
something, what I consider as a basic functionality.. http://issue.cc/r3/1812

Not defending. We gotta do what we gotta do. I was there for a lot 
of the core development phase and involved with most of it, and it 
had almost nothing to do with the GUI or host kit. It was a major 
change that required a huge amount of work by Carl and me, probably 
the most extensive core change in the entire R3 project so far. We 
were glad that the GUI and host kit were being worked on separately 
so we could focus on this.

Actually, yes. The Unicode changes had a lot of scope, but were still 
pretty shallow. The system structure was still the same. A107 was 
in many ways pretty similar to R2. We had planned for the A108 changes 
for two years, and a lot of the existing R3 code was written with 
that in mind, but to actually do it was a big deal. Plus, I've had 
to rewrite the module system from the ground up 3 times now, one 
of which took me 2 months and was never released publically.

There are many missing parts and a lot of bugfixes and changes that 
I know very little about, since I don't work with the lower level 
stuff. Some of the styles are already begun internally and it's possibly 
not a good idea to include them on the roadmap as community projects.

Also with the SCRUM tool, it probably needs to be finished, before 
we can tell what else is missing and that will not be a community 
project.


Each part mentioned above really needs to be done, but it was a lot 
less clear to me what exactly is ready in the GUI to do those things 
until some analysis today.

The idea for the roadmap was to remove the need for RM Asset to do 
these styles ourselves later, when we are busy writing R3 end user 
apps, otherwise it could take a good 1-2 years before they would 
be publicized. The roadmap would be shaped around which styles are 
needed and which basic features need still to be implemented in the 
GUI.

they will of course be added as needed. that's the best way to do 
it.

Pekr, I can't be sure at this time, because currently the styles 
are worked on via immediate need for fixes for things like the SCRUM 
tool, which is partially why I couldn't complete the roadmap. It's 
probably fair to say that the styles currently present in the style 
browser will be completed by RM Asset, but that may change.


What I imagine is that some of these styles that I mentioned will 
be comprehensive, long running separate, autonomous projects. A style 
like graph will need a ton of features, possibly separated into substyles 
and it would hopefully not depend on anything, but low-level features 
in the GUI system. Someone like Maxim could do this as he knows how 
to do high performance graphics. A windowing system can also be run 
as a separate project. Each project could be immediately stored on 
github.


RM Asset can do everything ourselves, but in the end, this will just 
take much, much longer, perhaps an additional year, which affects 
everyone interested in the GUI.

We follow a very simple strategy: We develop what we need, step-by-step 
and immediatly use it. So, we are not going to develop anything that 
we might need later at the moment. And, we are not first developing 
all styles, add a ton of features and than do our apps. We develop 
the styles just to the point where we can use them and than stop 
untill we need more.

Oldes  thank you for quoting me outside it's contexte to serve your 
purpose that quote is  a reply to Kaj proposition to do my own R3-GUI.

this quote implies any comunity work have to be based on a first 
step which seek the compromised best solution... which fundamental 
step wasn't done with the R3/GUI since their purpose is not to manage 
a  compromised vision of  R3/GUI edicted by the community but it's 
just to implement on top of the design edicted by Carl. In the actual 
design the least I can says is that you will need at least to do 
the work three time to support Win32API , X11 API and Quartz API.. 
+  any other windowed api. Knowing you are only 5 guys in RMA is 
it stupid to notice that and from this try to get the better solution 
the one that will give you best chance of success ?

the point here is the dialect edicted by carl can be adapted to any 
other library so why not considere taking a library already ported 
to the 3 main OS. Wich we would have the full sourcing and the would 
even in a shrinked version of it to save us the pain to do X times 
the work X being the number of  OS we want the R3/GUI on ...  and 
this  will too avoid us compatibility issues...

do for a R3/GUI we need the whole GTK+ or the Whole QT ? first of 
all lest analyse the way R3/GUI interface to win32 API it doesn't 
use that whole api specification it's limited to the ground management 
and rendering fonctions.

my point is instead of having to do this interface 3 times for windows, 
linux, macOS X  why not  take the time to discuss the probability 
to do it with another library that could be use as it  on the 3 main 
OS ...

GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.

Oldes > "so what.. so try to make glut extension. what are you waiting 
for?" >> once again with the if your not happy do it yourself is 
that what a community should stand for? Problem is Oldes this debat 
I try now to start you should have started it like in feb 2010  and 
come with conclusion out of that ...  but no RMA took the project 
in hands and since then there is nothing more to talk about and that's 
serves your purpose because you only want minimal involvement in 
this matter

GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.

cyphre yeah you want pathetic brainless followers that appauds any 
of your moves.... Sorry that's not my style.. The thing is the people 
telling me to do my own branch of R3/GUI  for free obviously to there 
benefits don't know how to do such a project on their own to start 
with so there is obviously nothing to be expecting coming from them.

patience ? since when do we know that  R3/GUI is externalised to 
R3hostkit ?  Since when do we know carl is having terrific problem 
on this matter ?

Sorry, what I want has nothing to do with you and your 'gurus' :)

sorry to point out that in 6 month of your project leading guys there 
is nothing to read apart RMA's propaganda on how they are great and 
how they will do awesome things for rebol...

Cyphre - to get smooth (amiga-like) scrolling, with low CPU overhead 
(do you remember my scrolling news bar?), is your HW acceleration 
helpfull, or it would need any other specific links to DirectX stuff? 
Just a question ....

once angain those documents are just here to serves you own interest 
not our... My interrest is to have a R3/GUI that is based on a community 
real effort and organisation, that produce documentation and that 
tends to involve everyone and not limiting them to the role of beta 
testers.  My interest is having this library with one to one link 
everywhere. My interest is to have this module/library  discussed 
all aloing and with futur granted ... We don't know if RMA will produce 
something affortable we don't know if after this first shot what 
will be the level of evolution we can expect from it ... Do we will 
need to pass to bounties to get new things added to it once the main 
release is done ? how will be integrated and rewarded external contributions 
to that project ? why only the 5 of RMA should get money out of this 
project?

We should start talking look & feel at some point too, as it really 
looks completly strange :-) Cheap gradients with Aqua like old Mac 
look mixed with 70ties Unix grey aproach :-). How can anyone create 
anything like that nowadays? This is really strange, as I remember 
Gabriele's effect-lab, Cyphre's styles pack, and also Henrik's first 
UI attempts, and those looked much better ...


I need to know, if it will be adressed, as I am scared to touch the 
gui, as I fear it will do really something bad to me :-)

But I think the problem is that you want "the community" to do that 
work for you and profit from their work without doing anything yourself...

Shadwolf - this is not the right group to discuss advocacy/strategy 
kind of things. But here's my take:


- RMA is a commercial entity, and Robert made it clear enough - they 
develop GUI to the point, when it will be usefull for their business 
apps. The chances are, that if it is good for them, it will also 
be good for others


- Robert is a good guy! He pays several top community guys, and - 
he gives result of such work - FOR FREE!


- RMA guys are VERY open, to listen to other's opinion, it is just 
they will accept only REALISTIC proposals - trying to convince them 
to change to differet underlying toolkit CAN'T work at this point. 
Even if such a toolkit would be good time solution, there are no 
free resources to make such a big change


- RT (Carl), plus the community, should be gratefull, to have at 
least RMA's GUI, if there is not other gui in the spot, and RT itself 
is not active in that regard.


- If I should name at least something what I am not considering so 
optimal, then it is a bit of a closed nature of development. I mean 
- I might wrongly understand initial impression of a SCRUM model. 
I missed the big picture, plus particular reports ... but - ANYTIME 
I was not lazy to ask, my questions were answered. Anyone but me 
can do just the same - ask. This is called - communication :-)

So much for RMA and their relation to development of R3 GUI ....

As for the move to other toolkits. Reading some of your opinons, 
and not being good in low level details, I still dare to say, that 
you might get some things wrong. There would be imo no direct benefit 
in moving R3 Graphics to GTK+, Qt, etc. Most of those toolkits are 
just bigger. You also seem to overrate the difficulcy of porting 
View to different platforms. Just look at Steve Solie - he did Amiga 
port in nearly a no time - one month? Noone imo expected R3/View 
running on Amiga. All is needed imo is - free hands, knowledge, and 
will to do the port.

It would be nice if Cyphre would isolate platform specific layer 
of gfx, but that is what I understand from one of his latest messages 
he is going to do  ... then the porting should be even easier.

Pekr native is a pain that's all ... it took already 5 years to do 
rebol VM version 3 on windows 32 and it's not over and according 
to the source code of r3-host-kit there is no GUI part in linux or 
macOS X.. we don't know either if more than the 3 main os will be 
supported and in what extense. Doing a change on 1 VM  means finding 
a way to do it on all other VM that's why if i remember well along 
the years R2 was supported on lesser and lesser OS and that's why 
too the rebol VM source code grow to a point that it was impossible 
for Carl to maintain it .That was the main justification for the 
retrofiting of Rebol VM  in the rebol 3  project... mean while all 
the  industry changed can you seriously say that  java vm is the 
same now that it was 5 years ago same goes for mono.

Industry has move to the cloud, so we have to focus IMHO on the language... 
and RT must offer cloud Services... 

and when you reach the mass market you may consider to built small 
VM for specific OS... 

RT has fail his idiom to be portable on over 40 different platform... 
and worth of that is REBOL has no VM on iPhone, Android, Symbian, 
or WebOS... 

even if R3 and with host-kit in theory you can do it, who is going 
to do it ?

Seems smilies don't do much in AltMe.. (used to IRC)

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.

I'm not sure if I understand what do you mean by absolute margin 
position, but sounds to be quite difficult to work with it.

Some DTP or word processing functions let you embed non-rectangular 
objects in their text, and the text wraps around their curves. I 
don't expect your system to do this, but it's a really cool feature.

there's support for CSS-like box model in R3GUI, this has nothing 
to do with text gobs.

Andreas, \thanks for the Fix notes (posted int !REBOL3 group)


I'll add your changes to my A109 and embed the latest CGR code into 
it.  I'll to release this by tomorrow, but no guarantees, i've got 
a lot of other stuff to do.

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.

i did the very same stuff you are trying to do now back for A102 
:)

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  :-)

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.

I thought Android API is in JAVA? How do you want to link/bind?

yes I do.. just need to handle some events now so I can make it quit 
as well

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?

Would CTRL-C map to the EVT_INTERRUPT event?
I'm asking because when I do this:
>> wait system/view/event-port


R3 never returns and I cannot interrupt it. I'd like to fix this 
is possible.

Steve, on window close issue, we need to decide.


The issue is this: when use hits a close button (or causes OS-side 
close event), do we close the window at the host layer, or do we 
send an event, allowing the higher layer to pre-empt the close.

As it stands right now, R3 accepts the EVT_CLOSE and can do nothing 
to stop it.

1ooo cows do not work? Time to rewrite cow as R3GUI style!

I'm trying to run the hello world example at http://www.rebol.com/r3/docs/gui/guide.html

Here is what happens when I try load-gui:
>> load-gui
i
Fetching GUI...
GUI Version: 0.2.1

(Developer test GUI theme)

** Script error: expected command! not font

 ** Where: size-text font-char-size? make make-text-style parse fontize 
 do do either load-gui

** Near: size-text gob

Is this a host-kit issue or ?

Thanks guys. GUI seems to function now after changing the fonts. 
I left a comment in REBOL3 GUI. Now I need to make the buttons actually 
work (more event work to do).

I found out, that Genesi is now sponsoring Linaro Linux, which tries 
to unify distros for ARM target. They gave away 50 smartbooks:

http://bbrv.blogspot.com/2010/12/momentum-is-building.html
http://www.genesi-usa.com/products/smartbook


From past month's discussion with BBRV, I believe they are able to 
send us a machine to port R3. And now again - this is not my port-it-for-me 
request, just a note, to eventually start a discussion, how do we 
get ourselves on ARMs. Carl could have one smartbook to port Core, 
and someone willing to play with the HostKit port could have another 
one. In the case someone is interested, I could try to negotiate 
it with BBRV.


Of course - ARM is a broad term. I never heard of Linaro. We have 
some TI hardware, and I know there are some embedded systems for 
such stuff, mostly commercial and expensive, and Linaro might be 
an answer here. Another HW option is BeagleBoard (cheaper, more OSes 
supported, even QNX, Android):

http://beagleboard.org/

Mostly a matter of either setting up a system to do the compile, 
or setting up a cross-compilation toolchain.