AltME groups: search

The macros are defined in the headers that come with the R3 host 
kit.

A Red/System extension kit would need to replicate the functionality 
of the macros, to implement the datatypes involved.

Fortunately the R3 host kit unions are tagged, so they can be used 
a bit more safely. Most higher-level languages that implement this 
kind of thing do something basically equivalent to the Variant type 
of VB, COM and .NET; even Objective C, Smalltalk, most Lisp/Scheme 
languages, and REBOLs have variant types. A variant is basically 
a tagged union type underneath. Having a cleaner way to do this in 
Red/System would be good., perhaps something like the polymorphic 
types in most functional languages. Red itself could have a dynamic 
value type like REBOL, which is basically another variant type. Red/System 
should have a way to specify different variant types because the 
variants of different platforms tend to not be compatible with each 
other.

Now after observing development of several GUI systems, there are 
always some particular things I find wrong with them: They were designed 
with small details in mind rather than the big picture. This means 
that when a developer uses a GUI system, he'll find that some things 
are easy, while others are very hard. For example, none of our GUI 
systems are particularly designer friendly, meaning that building 
a skin requires a programmer with artistic skills. There are not 
many of those around and that's a real problem. Saphirion's R3 GUI 
was derived from Carl's work in a way, where several parts were rewritten, 
because they didn't scale enough for real-world GUIs. The rest of 
the work has been about beefing up the R3 GUI to handle what is needed.


Development often seems to go in isolated sections: Building styles, 
building a layout engine, event handling, skin system, animation 
or whatever, without a properly coherent view on the whole thing. 
We talk about how we have a really nice feature, but that feature 
may not mean much, if it's not functioning in a coherent way with 
the rest.


If I were to restart VID Ext Kit as a new GUI system, I would rewrite 
it top down: Start with an application with the simplest, purest 
GUI description and write the GUI system down from there. I would 
recommend that a GUI system for Red needs to be written like that, 
starting as early as possible and let it grow downwards instead of 
upwards with a real application in mind rather than some neat demos.

btw - my brother ordered 3x Arduino kit for our friends, and for 
me he ordered BeagleBone Black. So I will see, if I can get Red programs 
running on it :-)

Should be able to find a free download via Microsoft site.  I think 
it is include in the Driver Development kit.

Saphirion's Host-kit has been updated:
-added PNG encoder
-added Core extension module for generic additional commands
-reworked compile/build process
-fixed security flaw in Encap
-fixed bug caused non-functional networking
-improved console output handling logic
-patched ENCODE to not crash on png
-updated LOAD-GUI with currentspahirion link
-recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe

Update on the web-page will be available on the weekend.

This replaces the Windows Driver Development Kit (WDK) that you normally 
have to install on Windows to compile drivers. The WDK is a full 
CD download, 650MB. You don't need the WDK, but currently, you do 
still need to run the Red/System compiler on Windows (or WINE on 
Linux) to compile Windows drivers. This limitation will be removed 
later, so you will be able to cross-compile Windows drivers from 
all other Red platforms, like you can with other Red programs.

MaxV, this document is for the VID Extension Kit, but it covers parts 
of how VID works as well:


http://hmkdesign.dk/project.rsp?id=vid-ext-kit&page=docs&section=developer&name=vid-extension-kit-internals.txt

the mezz code is a statically linked module.  it is linked by adding 
it or not within the host-kit boot up procedure.

Giuseppe, if it is textviewers that you are looking for, you may 
want to see Henrik's Vid Extention Kit.  http://www.hmkdesign.dk/project.rsp?id=vid-ext-kit&page=info
because if you are going to do anything slightly more complex than 
VID "text-list"  you will find data-list much more powerful. BTW, 
what are you supplying as data in your text-list?

The VID Extension Kit mostly solves this by not needing to know the 
quirks of each face. You just use SET-FACE consistently.

You can do this by adding the buttons to a panel and update the contents 
of this panel.


view/new layout [p: panel 500x500 []] ; start with an empty panel. 
note that VID does not support scrolling panels out-of-the-box. For 
this you need the VID Extension Kit.

append p/pane make get-style 'button [] ; you will need to adjust 
for offset here, otherwise the new phase will be placed on top of 
the old one.

do in last p/pane 'init ; you will need to initialize the face, which 
is the FACE/INIT block that resides in the face style definition. 
once the init block has been run, the face will set itself up and 
then you can show it

show p

This is just a simple version of what can be done.

To clear it again:

clear p
show p


If you want to do more than this, I think you need to use the VID 
Extension Kit, because you will be spending a lot of time managing 
scrollbars and panels. It has styles that are meant for this purpose.

Arnold, take a look at the VID Extension Kit. It attempts to make 
VID more complete, although it's no longer directly compatible with 
VID.

in R3 we can add sound support via the host-kit, but its not as good 
as it could be because we cannot add devices and/or any new type 
of event to easily (asynchronously) signal audio-related events.

there is no device code in the host-kit (which is the C api to rebol)

I thought devices were always built on top of extensions. Anyway, 
the devices are in the host kit, about six of them

OK, but the implementations are in the host kit

Kaj, yes, but the changes I plan will allow you to relatively easily 
use different renderer component. Even in current host-kit I would 
just replace the agg renderer with something more suitable for slow 
or not sufficiently equipped  ARM cpus but the "framework base" of 
the sytem would remain same.

Saphirion is building up a repository with a nightly-build infrastructure. 
We are currently working on these things:
- Win32 builds, mostly done

- automatic check of other repositories for changes and pulling changes 
for test-builds
- merging our host-kit to get View and R3-GUI
- cross-compiling for Win, OSX & Linux

Looks, like merging our host-kit is mostly done. Than we have a single 
R3 EXE with View

Nope, I want an includes-everything-reasonable prebuilt interpreter, 
even if a lot of it won't actually be loaded by default until you 
choose to import it (from inside, we have delay-loading). But that 
will just be one (official) set of applications made with the greater 
application construction kit, like the R2 SDK.

Bo: R3GUI depends on the R3 View engine, which is currently only 
publicly available for Win32 (and that only as part of the former 
host kit releases, not yet integrated with the open source R3). 


An Amiga port of R3/View reportedly also exists, but I don't know 
about its state.

if you compile the host kit you have full control over this.  Otherwise, 
Saphirion seem to have built an encap tool for R3.

What are the prerequisites?

>> do http://www.hmkdesign.dk/rebol/vid/src/vid-ext-kit.r

Script: "VID Extension Kit" Version: 0.0.1 Date: 29-Aug-2009/14:02:19+2:00
** Script error: insert-event-func has no value
** Where: catch either either applier do
** Near: catch/quit either var [[do/next data var]] [data]

I will be realistic - have not studied the styles yet, but from the 
style browser, I am very disappointed by the look :-( It really looks 
like Amiga 1.3, 25 yars old. Or some very old Unix. Who uses such 
plain buttons and field, with so basic borders? Or is there any skin 
system attached?


As for completness, still the most complete add-on kit for R2 VID 
is some 6 years or more old Romano Paolo Tenca's one - tabbing, grid, 
etc. supported ...

Romano's kit was GPL ... had drag and drop between styles but no 
one could use it with that license.

note that you cannot use the hostkit API directly, only the extension 
API.


what I did was a separate host-kit like header which creates defines 
for the functions I needed.  I added a platform #ifdef, so that it 
will automatically adapt to new platforms if I try to port it.

That's one layer of security Reichart.

But (given that failed for whatever reason -- human laziness in doing 
backups;  tsunami; all kit stolen in break-in; whatever), what's 
the *next* layer?

Secure systems need more than one layer -- as we've discovered with 
REBOL-->REBOL2-->REBOL3.

*All* the data still existed, distributed amond the many users. But 
we threw it away and started a new world.

It's not a a good case study to write up for prospective Altme users.

2:00 am here ... now before I go to sleep, I need some good news, 
e.g. when: host kit will allow View (merge of DELECT and commands), 
Extensions will allow Devices / Callbacks, and when are we back to 
VID? :-) - so that we can start porting R3 to WM and Android :-)

I have a few command line apps that do the job, but the best one 
I've found I got from a web site that isn't there any more. If you 
want it PM me and I will email it to you. Otherwise, try setx.exe 
from the Windows Resource Kit - it can do all sorts of stuff.

There are 4 environments on Windows (aside from the per-process ones), 
the system, user, default user and volatile environments. The setenv.exe 
I found can set any of these 4, the setx.exe in the Resource Kit 
can set the system and user environments.

Some changes will break VID, so there is probably more reason to 
create a VID extension kit.

VID extension kit == independent from R2-forward.

I have some plans for such a kit, but it depends on if I will get 
time to do it and if it collides with R3 GUI development. It involves 
removing some parts of the current VID, like the WindowsXP style 
buttons and making SET-FACE and GET-FACE uniform for all styles. 
Also adding some new styles and the new resize scheme would go under 
that. It would make VID way less painful to use.

Anyone run the Arm version of core on one of these plug computers 
?  http://www.globalscaletechnologies.com/p-22-sheevaplug-dev-kit-us.aspx

I'm not doing anything with DELECT until after it's settled. A complete 
rewrite of DELECT with a new dialect model is scheduled for the next 
host kit release.

with R3 I want to replace every part of the kernel with commands, 
but for that, we need access to the object! datatype within extensions 
(or host-kit).

GCC should suffice. And as Carl is already using it for the Host 
Kit, it may also be possible.

Incidentally, the VID Extension Kit has a lot of functions to help 
in these situations for finding a specific face.

To for example find the window a face sits in:

root-face face

re Cairo: Cairo seems to be popular mainstream. But AGG is used in 
a lot commercial projects silently so it is hard to tell. The facts 
are:  
1. Cairo is slower than AGG.(when comparing SW rendering)

2. Cairo is a graphics library, AGG is a 'kit' to build graphics 
libraries.

by forcing it to front, do you mean modal or just moving any window 
to front? (The kit has a simple function for the last bit)

sorry, but you are giving me a lot of ideas for the VID Extension 
Kit :-)

No, the dialect is simply a tool for building a face tree and it 
can be as complex as we want. Same in the R3 GUI.


How that face tree is otherwise managed during runtime (resizing, 
events, etc.) is up to other functions that exist elsewhere in VID, 
long after the role of the dialect is gone. What the VID Extension 
Kit does is add keywords for resizing and a few other elements, so 
the face tree holds a bit more information.


The resizing system is then used later to perform adjustments to 
the face tree, when you resize the window. That's just one example 
of doing only minor modifications to the dialect itself.

it's a very nice feature for doing certain lists and face-constructs 
(part of the VID Extension Kit)

This is not obvious with VID, because you might build such a layout 
in a special setup, but in the VID Extension Kit, you have face constructs. 
A face construct is simply a style that accepts a particular dialect 
as input. The dialect is parsed into VID which then in turn generates 
an internal face tree. This means you can build styles that do something 
like:

view layout [
	paper [
		size a4
		dpi 300
		at 20x20 image bay.jpg
	]
]


The point is that every time you feed the paper new data, using SET-FACE, 
it's re-rendered from scratch using VID.


You can also build very complicated list views that dramatically 
change appearance and number of faces, every time you feed it new 
data.

a way around it, would be to do a "soft show": all [face/show? show 
face]. this can be installed in feel/hot in the vid-feel.r file, 
if you have access to the VID sources.


also using size 0 would not work in the VID Extension Kit when resizing.

Is the R3 Host Kit available?

If you don't want to handle resizing manually, you could look at 
the VID Extension Kit.

is there any known way to make rebol spontaneously quit? I've run 
into a case where it just quits, when I focus a field in the VID 
Extension Kit, but I have no clue what does it, although I can reproduce 
it every time.

shape collisions  :-D
a little milestone  in my rebol game development kit... 

The first version of an SAT-based collisions lib for arbitrary convex 
polygon  is now fully functional:

test it in action in this test script:


do http://www.pointillistic.com/open-REBOL/moa/files/ctest-preboled.r


note that it handles shape rotation which isn't always supported 
in implementations of this algorithm on other platforms.

MAJOR milestone for Game kit.


test app updated and includes multiple shape collisions and propagation. 
 quite fun  :-)

also: press g to view spatial sorting grid, its a bit mesmerizing 
to see


do http://www.pointillistic.com/open-REBOL/moa/files/ctest-preboled.r

most of it is math, AGG is just reflecting the vector maths I am 
doing.  its also responsible for about 90% of the CPU use :-(


but for now its not an issue since the game kit doesn't actually 
use these shapes for the user graphics, only for collision detection.

but not working anymore with the host-kit

Endo, I solved this in the VID Extension Kit.

Is there a method to find the active window? I actually thought I 
had this in the VID Extension Kit, but apparently not.

(the work I mention above is the extension and host kit work)

does syllable use a kit system like beos did?

kit system?

We have a modular monolithic kernel, not a real microkernel. But 
still, most functionality runs in userspace servers. BeOS groups 
them and calls each a kit

I think you could position Syllable with two major values:

1. Do you want to surf secure? Use Syllable, no virus etc will work

2. Do you want to avoid observation? Use Syllable, no root-kit etc. 
will work.

Depending on linking issues, of course. Fortunately the R3 host kit 
seems to be compatible with that linking model :)

someone test the new linux host kit of carl ?

I'm testing the Linux host kit. Anything you want to know?

If you're willing to test the host kit, I think Carl will be willing 
to bump the priority for other architectures

(The R3 Host Kit, that is.)

Can we update the REBOL's Agg sources to the 2.4 version to be used 
with open sourced host-kit?

AFAIK There is no real test framework for R3. Only the DRAW and SHAPE 
tests included in host-kit.

OK, Carl asked me to announce this, so this will be quick and dirty:

The VID Extension Kit for R2:


This is a library that overhauls VID and the styles to improve the 
experience in using it and creating bigger programs with it. This 
is very much a work in progress, but if I continue to keep it under 
wraps, I'll never get it out. :-)

Quick feature list:

- Full tab navigation
- Field validation and autoformatting
- Full resizing
- Many new flags

- Much better face control: disabling/enabling faces, different setting 
and getting of panels, complex face navigation

- Many new styles: Selectors, balancers, lists, fields, panels, scrollers, 
iterators

- Many VID bugs are fixed, although the impossible ones still remain

- Many new VID bugs are introduced as well :-) Some styles are not 
working.

Try it out at:

http://www.hmkdesign.dk/rebol/vid/src/vid-ext-kit.r

A simple style browser is available at:

http://www.hmkdesign.dk/rebol/vid/tools/style-browser.r

Very preliminary docs at:

http://www.hmkdesign.dk/rebol/vid/docs/vid-extension-kit.html


I'll release the full sources later, but have a look and see what 
you think. Remember to ask questions.

REBOL 3 embedded host-kit extension for ODBC database access

The R3 ODBC Extension allows easy access to databases and data sources 
supporting ODBC. 


The extension supports SQL statements SELECT and INSERT, UPDATE and 
DELETE as well as catalog functions for tables, columns and types. 
It supports statement parameters and is Unicode aware. It supports 
direct and prepared execution of statements.


If you're used to the commercial REBOL/Command (or the nowadays freely 
available REBOL/View) ODBC database access methods, you should have 
no problems using the ODBC API presented here. There's next to no 
differences in functionality, it differs mostly in that the extension 
isn't used with ports, but with "ordinary" functions OPEN-DB, OPEN-SQL, 
DO-SQL, CLOSE-SQL and CLOSE-DB. This may change when it's possible 
to provide the extension as an asynchronous R3 device, since the 
ODBC functions may be blocking.  


For now, the API is implemented as an embedded host-kit extension 
(it should easily be possible to provide it as an external dll) and 
is available for the Windows platform. So far it has been tested 
with MySQL, PostgreSQL and Intersystems Caché as well as the Microsoft 
Text Driver. Of course it's supposed to work with any ODBC data source.

I would expect that you either won't need a sdk for R3 if you have 
host kit ... or, it will cost you :)

I think that Host Kit is going to be for free. But RT might produce 
some commercial Extensions ...

How does it work? the host kit, I'm kind of lost here...

Doc: the code is in sort of "prototype state" and It was meant as 
possible implementation for R3 in future (once Carl put the encryption 
algorithms codebase into the R3/host-kit or someone write an extension 
for that).

I wrote it because I wanted to know if we could get rid of unnecesary 
C code that is currently in R2 to just handle the protocol logic 
while the performance of the crypto algorithms will remain in C. 
The current size is less than 20Kb of Rebol script code so IMO it 
could be useful and also easier maintainable way.

Currently it works in client-side mode only but there is already 
support for ASN.1 certificates also I tried to write the code so 
the server-side mode and other cipher-suites shouldn't be hard to 
add.

I plan to release the prototype to open public after some cleanup 
but if you want to waste some time with the current 'raw stuff' just 
post me privately and I'll send you a copy.

Gabriele, could you try the style browser for the vid extension kit, 
please? AFAIR there is little to no DRAW used in it.


do http://97.107.135.89/www.hmkdesign.dk/data/projects/vid-ext-kit/downloads/style-browser.r

I've never experienced PARENT-FACE as reliable, so for the VID Extension 
Kit, I made separate functions to set it properly.

It should be possible to integrate it in R3 by rewriting the network 
part of the host kit (if both licenses are compatible).

Marco, the one thing that VID then doesn't do so well is allow groups 
of faces to be SET-FACEd and GET-FACEd easily, which is probably 
what scared you. The VID Extension Kit solves this by allowing these 
functions to work on entire layouts.

@Henrik I have a mix of "settable" and "unsettable" values (eg. the 
color of a "box") and I don't use your kit (at the moment).

Find Carl somewhere, and ask him to finish R3 host kit, so that we 
can port it ;-)

With host-kit I would like to see a baremetal version of R3 :-) That 
would be extremly cool.

Cyphre - we would buy R3 for a reasonable price. Make a 300 USD SDK 
kit for Android, and I am fine with that.

Pekr, thats exactly what I mean..I wouldn't sell R3 (nor I can :)) 
I'd seell IPhone/Wii/Android/whatewermakessense kit for small apps 
that will work on all the OSes.

For instance, there is no reason that we should wait for Carl to 
start an Android port of the host kit. Even knowing that the r3lib 
has compiled on ARM is more than we require at this point, though 
it's nice to hear; we certainly aren't at the point where we actually 
need that build in our hands. Carl is not the limiting factor at 
the moment.

in the VID extension kit you can say:

set-face my-panel object

object: get-face my-panel

Well, I've done that in my own VID extension kit (which I'm still 
contemplating whether I will release some day): Provide more styles 
with very specific purposes. This strongly reduces the need to be 
specific many times all over a layout and the layout becomes much 
smaller and cleaner. Also avoiding stylize inside the layout helps.

I prefer one well supported engine instead of 10 less supported. 
Everybody is free to do anything. What I don't like is, that sometimes 
new stuff distracts the crowd and splits the effort. In the same 
way I think that VID Ext Kit, in current days, is contraproductive 
product, but this is just my opinion.

With Host kit how do we role our own R3 code into the builds?

I think the instructions for the Visual studio host kit instructions 
needs to be modified a bit more.  I'm a newb to Visual Studio but 
found the instructions confusing for the adding of the additional 
files and for finding the "additional include directories"

HOST KIT FOR LINUX!   And I'm three days behind already.  Why didn't 
anyone send a memo to read the blog?   :)


Woohoo, back to REBOL programming...     And just so ya know, when 
I embed this in OC it'll be CORE BOL  ;)

yes - few months back we fixed ca 80 tickets a month. Now Carl is 
on Extensions and Host kit. However - some bugs could be bumped-up, 
and this one seems being pretty serious ...

I think that OSX host kit can wait a little bit.

Carl's Twitter message: "And yes, we will open the R3 Host Kit to 
all developers before the end of Dec. We did it this way to avoid 
a possible flood of dev feedback."

Carl's a bit silent lately. I wonder if he is working on new website, 
or continuing his work on Host Kit ....

I'm thinking about using the js-kit.com commenting service. But I 
would "hide" it via a RSP page to have more control how to integrate 
it.

I'm seeing some odd root kit like behaviours ... cheyenne is clearly 
serving up pages,, but the icon is gone from the system tray and 
it does not appear in the processes list in the windows task manager!

Hmm... generated VID Extension Kit docs on the fly for website in 
0.009 seconds. Looks like there are things to optimize. :-)

Start by providing the __attribute__ for thread-locals, assuming 
that the .so supports that.  If not, we'll need to move the thread 
local vars into a struct, and allocate it dynamically.  However, 
we'll still need at least one thread-local from the host kit side, 
to provide the base pointer for each thread.

Also: You must be a an Authorized Developer for the Wii console and 
obtain a Wii development kit