AltME groups: search

How do you start the host kit version of R3, which has a separate 
library?

The host kit version does

The host kit became available for OS X when Andreas solved the linking 
problem on OS X for Carl

The R3 host kit source will taint you more, because it's commercial

Looking at the R2 mezzanines has already tainted you, and the fact 
that you can see the source of the R3 host kit doesn't mean that 
it's open source - it isn't

Resize doesn't break anything, however it's been re-used in the VID 
extension kit with some modifications, which I don't think are compatible.

Henrik, your VID extension kit is really cool and we'll definitely 
want to look at it for ideas for future VID improvements :)

Windows Phone 7 won't get a REBOL version without a ground-up rewrite, 
as the platform doesn't allow native code. Older Windows Mobile releases 
never were supported, though R3's host kit could in theory support 
them.

An error return code is defined for extensions, but it's not used 
anywhere in the host kit or documentation, so we don't know how to 
use it

The callbacks documentation is incomplete, and refers to the host-ext-test.c 
file for examples, but this isn't in the current host kit

If the latter, this question is better suited for the !REBOL3 Host 
Kit group.

The host kit is the only place I know of

First of all you should sync the host-kit imho.

The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.

btw... many host-kit fixes are pretty easy if you know where to look... 
for example to enable image gobs in Carl's host-kit, one must just 
remove the temp_remove and replace:
	int gobw = GOB_CONTENT(gob)->size & 65535;
	int gobh = GOB_CONTENT(gob)->size >> 16;
to:
	int gobw = GOB_W(gob);
	int gobh = GOB_H(gob);

https://github.com/rebolsource/r3-hostkit/blob/4d3bdeaa77cf1ec7c5d97738509ecec4fdf4b7e7/src/agg/agg_compo.cpp#L594


And that's all... I really wonder why you keep the host-kit updates 
hidden. Even Carl was able to put it on github:/

Carl is the one to release host-kits. He has full access to our code-base. 
As Brain said, from time-to-time RMA changes are merged.


IMO it doesn't make sense that we fork the host-kit and have two 
release in the wild.

This is to let people directly use it without having to fiddle around 
with the host-kit.

And I was somehow thinking we want more than one man to fiddle with 
the host-kit... but maybe I'm wrong :) also we are probably almost 
out of topic here.. sorry for that.

And for a couple months or so before then he didn't touch the host 
kit or GUI. That is what "focusing on core development" means.

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.

I will not participate to any bug tracker, bug correction, or testings 
regarding R3/GUI until we don't have a full detailled schematic of 
R3-host-kit, while we don't know where we are going with this project, 
and while we don't know if a better path can be found to avoid this 
project to fall in porting maze.

Shadwolf, if you want a REBOL GUI that can just be recompiled on 
all platforms based on OpenGL or QT or GTK, the current host kit 
fully supports that. You can just build such an interface on it

Ok, except that the power of REBOL was that it can run under 40 different 
OS !

Nowadays, it runs good for R2/View under Windows and MacOS... Linux 
lots of problems because there's so many version of Linux...

And for R3/GUI we have Windows version... and when Windows 8 will 
be released... not sure it will work.

Community has falling down and it is hard with no open source to 
attrack new developpers... I know host-kit is hybrid open source 
model...

Real question in 2011 is : port language on JVM because every computer 
and device (except iPhone) has a JVM in order to reach the mass market.

Make it popular and then we can found money, people to work on small 
VM that make the power of Power.

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 ?

Nicolas, those 40 different OSes weren't really 40 different OSes, 
they were mostly different builds for at most a dozen different OS 
variants. Most of those OS variants are now no longer developed, 
or have changed so significantly that they are essentially different 
OSes now. The platforms that RT is actively supporting now for R3 
covers the vast majority of the current market, more than would be 
expected for an alpha product, and the host kit allows you to port 
it to the most obscure OS you want, as long as it can work on the 
scale that REBOL works at (not your microwave).


every computer and device (except iPhone) has a JVM in order to reach 
the mass market

 - Of the most popular smartphone platforms, only RIM and Symbian 
 (sometimes) have a JVM; iPhone, Android, WP7, and WebOS don't.

afaik, its within the port mechanism, when events are created, for 
some reason, the resize events don't end up at the port handler.


I remember trying to fix this in the host-kit and didn't find the 
solution.  I tried a few things but nothing worked... so I moved 
on but that's like 3 months ago already so the details are fuzzy 
in my mind.

I don't agree, and I've also built large apps, both with the VID 
Extension Kit, which supports the philosophy of restrained access 
to faces and RebGUI, where face hacking is necessary. The former 
is significantly easier to work with, than the latter due to not 
needing to be explicit on every single twist and turn. The lack of 
proper uniformity does not leave room for an intelligence beyond 
the style level, and you will not unveil the potential for reducing 
code size, testing times and greater overall consistency and stability.

Kaj, perhaps this is the same misunderstanding as for host kit work. 
It seems that many times, when Carl or RM Asset offers a task to 
the community, the response is negative.

Kaj, perhaps this is the same misunderstanding as for host kit work. 
It seems that many times, when Carl or RM Asset offers a task to 
the community, the response is negative.

Could the RMA build be updated to alpha 111? This all started because 
the release notes of alpha 111 said that R3 was now compatible with 
the RMA GUI, but RT's build is a core build. This is why Jocko had 
to compile his own build from the alpha 111 host kit.

it won't be necessary with actions (I hope). you simply call actors 
directly. About chaining them, how does it make sense to chain an 
on-click and on-hover actor? They are separate actions. What you 
need is the ability to stack the action code for actors, so that 
if an actor is already defined for a style, then the new action code 
could be appended to the original code. I use a similar design in 
my private version of the VID Extension Kit, but am also forced to 
use the traditional actions as they are part of the standard face.

noted. perhaps Bolek can answer if this is already possible (I'm 
already doing that in the VID Extension Kit).

Pekr, the 'hard crashes' are most probably related to one bug that 
is waiting on Carl to trace/fix since it looks we are not able to 
do it from the host-kit side.

GrahamC, I think the issue here is that the bug can't be found unless 
Carl provides a debugging version of R3, so we can find where the 
bug occurs, whether it's in the host kit or the core. I can't be 
sure as it's something that was discussed last over 6 months ago.

Nope, you just can't build a single binary with a statically linked 
r3lib. You can build a host kit exe with a dynamically linked r3lib 
with any mezz changes you want.

I succesfully 'overloaded' some mezz functions in R3 in the RMA hostkit. 
See the inclusion of %rma-patches.r file in src\tools\make-host-init.r 
in the RMA host-kit release. So it is possible to do some fixes that 
way.(of course not every part can be tweaked such way)

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.

thing is I see that BOOL is used in the host-kit as return values, 
so expecting the same dll to be compatible with different compilers 
might be dangerous.

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

FYI - I filed some bug reports for the host-kit for the more annoying 
problems I've hit. Feel free to add comments to the reports.

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.

There's something wrong with that diff... where did you get Linux 
A107 host-kit?

I'd say just hold off right now... I'm going to be changing the host-kit 
release mechanism very soon.

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.

But, if you grep the .h files, you'll notice that various ones are 
generated, not created by hand, and that's just the host-kit side.

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.

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

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

Here is the problem with OS X host-kit release:
http://www.rebol.com/r3/docs/osx-linker-symbols.html

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?

Because the host-kit side cannot know the state of execution in the 
core, it is necessary to use RL_Escape() to signal the event.

What we want eventually is for host-kit to detect ESC, and call RL_Escape 
for that too.  But, that requires that we use raw stdio processing 
(or use an OS that's good enough to detect and signal us on a specific 
key press), so it's not implemented yet.

Win Vista, 32 bit, Dell Latitude D830, 2GB RAM, Intel Core 2 Duo 
1.8:


Script: "Host-Kit Graphics: Basic gfx benchmark" Version: 1.0.5 Date: 
none
GFX benchmark result
0:00:08.044 49.726 FPS

Well, the host kit has been heavily rearranged

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 ?

I'm really happy that someone is porting the host-kit to an alien 
host.


1) it proves that the design was pretty well thought out to begin 
with

2) might convince people that porting actually is possible, without 
much help from RT.
3) shows that it doesn't require 100 programmers 6 months

4) shows how Carl is cooperative with host-kit issues, even when 
one isn't in the "inner circle"

Henrik: I think we should focus on a more mobile-oriented target 
next. Haiku could be interesting given its unique API. AROS is just 
an Amiga clone so I don't see much value in that one from a host 
kit testing point of view.

the final repo will probably be rebol/r3-host-kit

I blogged a bit about the FreeType implementation in the host kit 
at http://solie.ca/


Besides the bold/italics issue I also noticed the line length is 
not being calculated correctly or similar because the text is rendering 
beyond the window bounds. If we can fix both of these issues I think 
the FreeType implementation should be as good as the win32 implementation.

I tried to build R3 host kit (carls-R3A110-a660e4a) for Visual Studio 
2010 (make-vc10), I got the error  C1083: Cannot open include file: 
'netdb.h': No such file or directory	c:\users\awi\documents\rebol\hostkit\carls-r3a110-a660e4a\src\include\sys-net.h

Downloaded .zip file. Tried it now - it works. It just does not seem 
to copy dll to the place of the exe, or something like that:

Linking executable: bin\Release\r3.exe
Output size is 317,50 KB
Running project post-build steps
post-build-win.cmd bin\Release\

Execution of 'post-build-win.cmd bin\Release\' in 'C:\!rebol\!R3\r3-host-kit-A110\make-cbp' 
failed.
Nothing to be done.

I still miss something like general R3 porting group. Or will we 
set-up one group per target platform here, as we did with Android? 
I think this group is good for technical host-kit stuff, not general 
porting stuff ...

I wonder how much differ the RM-assets' host-kit from the latest 
Carl's one.

If RM want more people to join the GUI development, they should sync 
the host-kit with Carl.

It would also be very useful if the Amiga patches were incorporated 
into the host kit

But I would rather wait for the RMA's host-kit release before the 
test.

For those who are impatient I put the RMA Host-Kit on this URL: http://www.rm-asset.com/code/downloads/files/rma-host-kit.zip

It's not yet on the official RMA download page but Robert will be 
updating the page content soon.

R3 final? I suppose this means R3 is now beta instead of alpha. That 
is good news because it means I may be able to get an updated libr3.so 
for the Amiga soon. I'm waiting on that library so I can continue 
work on the host kit and submit my changes.

I modified text-test3.r3 script from the host-kit to use normal sized 
font (12) not anti-aliased and used a little bit longer text content 
(but not extremely much. just two lines with length cca 1400 chars)... 
the result is:

Good news: I do not notice any difference between ansi/unicode content.

Bad news: in both cases R3 uses almost 23% of my CPU time when I 
just move mouse over the text, which is pretty much:/

and if you have the mingw cross-compiler installed within cygwin, 
that will do just fine with the current host kit

btw, you don't need msys to compile the host kit. mingw alone is 
sufficient

Using the Cygwin compilers turned out to be unnecessary, so I can 
get away with just the Cygwin base install plus make for the NDK, 
TDD-GCC for the host kit, and Git for Windows for the Git support. 
Only one set of compilers per target platform, but 3 mostly duplicated 
sets of general command line tools.

the extensions API actually marshals all of that so the internals 
of the GC don't really affect the host kit that much.  


A part from the raw image! data, we don't really have any reason 
to believe that any pointer we share with the core is persistent.


In any case I don't rely on it, because AFAIK Carl has insinuated 
that we never really have access to the internals and pointers we 
get are actually interfaces, not interal references (for security 
reasons).

Btw, I usually try not to read GPL code for features that I might 
have to implement in my pubic projects (not only Red). I've also 
stayed away from the host-kit source code for the same reason, knowing 
that I might have to work on similar features someday.

The host kit is published but the licence is undetermined, so you 
could argue it's public domain

Are the View sources complete in the host-kit or are some part of 
it sill buried in the closed Core?

I think they are complete, but the official word is that the host 
kit will be separated under two licenses: one part open source and 
one part not open source. Both projected licenses are still unspecified

About calling functions in shared libraries and calling conventions, 
there seem to be differences between CPUs and compilers across operating 
systems. There's a lib, called libffi, to help with this, and it 
has bee widely ported.
http://en.wikipedia.org/wiki/Libffi


Why isn't a lib like libffi used in Red? Is it because of overhead, 
making it slower? Or maybe using such a lib makes little sense the 
way Red is implemented?


When looking at the host-kit for R3, I see functions to open, close 
and find functions in DLLs, but I don't see the calling of those 
functions. Shouldn't that be part of the host kit?

R3 does not have such ability, so I'm confused by your "When looking 
at the host-kit for R3, I see functions to open, close and find functions 
in DLLs, but I don't see the calling of those functions."

The R3 host-kit is a good source for how to do it.

You list of 5 things:


1) Not sure, I wanna do that. It takes time away from me finishing 
version 1.
2) I have set the goals for ver. 1.
3) No (see Q&A)

4) "Ask for cooperation" - World would need schemes for the different 
protocols. I will welcome others work in that area. Me (and most 
likely others too) would like to see World on more platforms than 
the current 3. Host kit is open source. I will welcome ports to other 
platforms. (That's what I can think of for now, but I'll keep it 
in mind.)

5) It's faster for me to write the documentation than building a 
comm/doc infrastructure. I'll write the World 'bible'. Work has started, 
and I'll use more time on it, when version 1 is a bit closer.

I've been hoping to fix that. I can load a hot-patch into R2, and 
include a patch in a host kit build in R3 or replace functions from 
%rebol.r if necessary.