AltME groups: search

Max - I like your idea of 1 callback dispatcher per one extension! 
It is just elegant enough to start with! It is the opposite of rxi 
principles (rxi_call), just on rebol side ... I will try to support 
it with Carl ...

Max - this is interesting - I wonder where is the main event loop? 
Core dll, or Host code? I think host, so yes, it is replaceable. 
I still try to push Carl to switch to multimedia timers - would work 
much better.... I have good article on that, and Carl liked it.

Max said "with callbacks (devices?), there is no need to keep bugging 
Carl about A LOT of things people keep complaining about.  :-)" - 
my question is - how callbacks/devices allow you to plug-in different 
scenarios into REBOL?


Let's take multimedia timers for e.g. AFAIK, events are part of Host 
code, not a device. So how can you e.g. create device, which allows 
you to replace inbuilt timers?


OK, maybe timers are not good example. We have networking being done 
as a device. Can you easily replace REBOL's built in networking device 
with your own one, to try some different networking aproach for e.g.?

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.

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

will start by playing around with the C++ stuff, basically building 
a simple scene.... when that is working, I'll try to build an extension, 
allowing me to do the same calls via R3

BrianH can probably give you some pointers on what to try out if 
you're a proficient C++ coder.

I try to keep this as short as possible.

Imagine you have this file, called %test.r:

==file==

REBOL[
    Title: {Simple extension test}
	Name: ext-test
	Type: extension
	Exports: []
]

map-words: command []{
    word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
    return RXR_TRUE;
}

fibc: command[
    len [integer!]
]{
    RXA_TYPE(frm, 1) = RXT_INTEGER;

    i64 o = 0;
    i64 l = RXA_INT64(frm, 1);
    i64 i;

    for (i = 0; i <= l; i++)
        o = o + i;

    RXA_INT64(frm, 1) = o;

    return RXR_VALUE;
}

add5: command [
    a [integer!]
][
    a: a + 5
    return a
]

==end of file==


And now imagine that in R3 console you are in the directory where 
you have the file %test.r .
Now you type:

>> compile %test.r
>> import %test.dll
>> fibc 10
== 55
>> add5 5
== 10

And that's all.


If you want to try it, you need to have TCC (TinyC Compiler) - get 
it from http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25-win32-bin.zip
The script expects it instaled to %/c/tcc/ but it can be changed.
Then go to r3 console and type:

>> do http://box.lebeda.ws/~rebolek/rebol/srec.rip
>> cd %srec/
>> do %srec.r


Then you can try COMPILE etc. (see above). %test.r is included in 
the archive.

SREC is shortcut for Simple REBOL Extension Compiler.
    
Enjoy! (if it works ;)

IIRC (the dialect is 3 years old and I haven't touched it for few 
years, I just made some fixes in last few days to run it under R3), 
most loops are translated to C's WHILE. You can try writing some 
RebC code and when you COMPILE it, in the %work/ directory you can 
find %your-filename.c file, where you can see the dialect translated 
to C. Do not expect it to be optimized in any way :)

but the coupling with the core run-time is practically abscent.  
there is only one function I can use to have the run-time do anything 
and thats a pretty simple... do_rebol_string() which basically runs 
a block of code in the global space... beyond that I've only got 
network/file like ports, which basically are streamed I/O.  


I can't create data directly and leave it at the port, in a block, 
like I'd do for a proper event queue.   This is currently my pet 
peeve about the host... 


but let's not be judgmental... I'm VERY happy I have the host, so 
I can at least try to rig something up with bailing wire, duct tape, 
pliers, a bit of string & epoxy glue.  


 Extensions & the core allows me to hide this under a nice fiberglass 
 body  ;-)

But I will try to do this and specify the datatype. We will see.

Maxim, you do realize that the purpose of the current host release 
is to test and improve the host model, right? Not to build final 
projects? If you run into problems in the host model, try to fix 
them, not work around them. Otherwise your work is a waste since 
the host interfacing model is going to change in the next version, 
hopefully based on your and my feedback. And a callback solution 
that doesn't integrate with R3's multitasking model is worse than 
having none at all - since any code that might be written to use 
it would need rewriting, and probably rearchitecting, very soon.

brian, yes we can add our own devices... in fact, it seems quite 
easy, and I will probably be adding a DB trigger device within a 
week or two.  :-)


the thing is that there aren't any exposed or documented *native* 
hooks from the host into the core... 


so far, I've got a callback library (called wire) working which executes 
rebol code in global context using the Reb_Do_String() r3lib.dll 
exported function  :-)


now I just need to use that library within the extension and see 
how it goes... the moment I have *something* which works... I'll 
stop improving the hack... from there on, I'll just work on the architecture 
of the caller and callee, to see how we could make it simple and 
easy to setup, from the extension and within the application using 
that extension... generically.


the code in between can change completely, it wouldn't actually change 
the extension or application code (that's the idea anyways)... just 
a few includes and headers which map how to link to the callback 
system.  I'll also try to build a device, just to see how that can 
be used instead of callbacks... but I still need to use a callback 
from the extension in order to access the host... so for now my hack 
is essential, whatever I do.


in this case, I'll be dispatching the GLUT events within the rebol 
using this architecture... I should have an interactive OpenGL window 
by tomorrow... crossing my fingers.


for now I am busy rebuilding my old OpenGL project within the new 
cleaned-up MSVS solution I've been working on for 2 days now... there 
are soooo many properties, its scary and long to setup... especially 
in this setup where there are several interdependent projects within 
the solution... but now, at least, when I change stuff at any layer 
and build, it builds all the stuff correctly in one step...

I would like to point out, that wiki somewhere contains Ladislav's 
input on that ... I will try to find it ....

I like .rx name for an extensions. I also seem to understand, what 
is your motive for it. But - will not it confuse users? I mean - 
if I try to run R3 under Linux, I might be tempted to copy extensions 
to linux, becase I expect .r script to be cross-platform, so some 
ppl might expect .rx is just cross-platform too. But that surely 
is not the case - those are platform specific, no?

Ok, since we are not sure, I will take a deeper look into the code 
and try to ask Carl.

I agree with Andreas, when I looked into the hostkit code it looks 
that table of 'names' of the devices is hardcoded in the r3.dll at 
the moment. My only idea (workaround) was to try use for example 
'clipboard device name and try to replace the internal code with 
custom one for testing purposes. I haven't tried that though from 
that time yet. Not sure if it is worth the time. Better wait for 
new hostkit ;)

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

Andreas, no, but only because not yet tried that.  Only minor edits 
to the makefile required to build on Linux. If you get that to work, 
then can get you the r3lib to try it. Let me know.

Can't sensibly try without e.g. a OSX dylib.

Anyone want to try this?


write %cimgtest.dll read http://www.compkarori.com/r3extend/cimgtest.dll
secure [ extension allow ]
import %cimgtest.dll
test

Eh?  Didn't try that ...

Did you remove all references to the extension? If there are any 
references, the dll shouldn't be unloaded. There's no unimport function, 
so try LOAD-EXTENSION, then throwing away what it returns, then recycling.

RobertS, I built mine using MinGW .. didn't try CygWin

Brian, I do commercial app development in REBOL as well as in-house.


Petr, I'm not here to defend Spread. I mentioned it because when 
I looked at it before, it was something I marked to remember because 
it wasn't too large or complex and didn't try to do too much (compared 
to, say, AMQP). 

I only played with it breifly, I didn't put it into production. 

I want a REBOL solution too. :-)

Graham IMO almost every IPC need somewhat daemon runing. The library 
"could" be linked in extension and try to open communication with 
daemon, when it doesnt find the daemon let start its own (first process 
trying to comunicate), what is nice in Spread it combines P2P and 
multicast and members/group policy, and of course single/multi machines.

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)

It never occured to me to try with LIB instead of SYS, it's in LIB, 
too, of course! But calling LIB/MAKE-SCHEME crashes, too, so I guess 
the problem is somewhere else.

funny, I intended also to try interfacing with ImageMagick (maybe 
the ImageMagick Com + component.), as I have a need for another project.

Concerning the extensions dll's and source files, I think that they 
are no more compatible. I should check and put the latest versions.

you can try adding 

extern  void RL_Print(char *fmt, ...);

at the begining of your file.

ah, I did a little bit of searching and I think I understand... 

try using RL_PRINT() instead.

Would have to try again, but as far as I remember, RL_SET_VALUE would 
update the tail.

i just try it and it gives me that >> do %style-browser.r3

Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1220 
2010-11-26 13
:18:02Z cyphre $ Date: none
** Script error: guie has no value
** Where: catch either either -apply- do
** Near: catch/quit either var [[do/next data var]] [data]

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 ...

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

I would like to give GUI a try, but to be honest, the current public 
state is good only for reviewing, not for participation on the developement. 
I mean... I really don't want to hack one file which has 256kB. So 
I'm asking again, wouldn't it be better to put it into a real source-code 
system (or in case you have one already, which you probably have 
internaly, to create public mirror of it).

Oldes, that's possible. I'll try to make a zip archive of the current 
source directory.

You need to use the R3 version with the graphics APIs included - 
recent RT releases have been core only. Try http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip
(which I got from http://www.rm-asset.com/code/downloads/).

DideC: try to add the following line in front of "view win": 

append system/view/screen-gob win

DideC, try a tuple for the pen.

I will try to persuade him to publish it sooner, since I don't thing 
it is necessary to wait.

Shadwolf said: "...so your idea of a working rebol community is a 
rebol community with 10 R3/GUI because 10 of us has different ideas 
on the topic."

I must say I have no problem having 10 or more R3-guis... it's always 
better than having none. Of course it would be nice to have at least 
the core shared, but you will not have it if you even don't try to 
propose something.

We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

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 ?

and since i'm considere as a pain in the ass and you all try your 
best to not have this discussion with me  or with the others in the 
community then you go to what Carl did without any second thoughts 
in the end we will end with a strong win32 API based R3/GUI and no 
linux or macOS X ports. That' s the the projection I can make base 
on the actual work.

so what.. so try to make glut extension. what are you waiting for?

btw... for your area-tc there was designed the R3's rich-text which 
you even don't give a try.

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

Repeating from above:


We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

Otherwise even converting the old code shouldn't be so hard but I 
haven't studied it. Anyway RMA team will try to help such conversion 
related quetsions here if you start doing it.

Well, at least I have something to play with. If I will somehow proceed 
with adapting demo, I might try to experiment to change some style's 
look, to see how the design and functionality are separated.

I might try to "port" Carl's Spring look, to just see, how it works 
or not. It could show some potential problem with eventual skining 
...

try this:

load-gui
stylize [red-button: button [facets: [area-color: red]]]
view [
	red-button
	button options [area-color: green]
	button
]

I think this wirks just fine no?

OK, I will try new version, and see how it goes. I would welcome 
an example on 'intern, maybe I will find it in sources. Starting 
to warm-up to new gui :-)

not going at all - coming home from work at 19:00 and later :-) First 
thing I want to try is trying to play with different draw blocks 
:-) E.g. trying to "port" Carl's button :-)

I think switching panels is much simpler than you're trying here. 
Try looking at the source for tab panel.

Did you try some of the panel examples?

I haven't had time to play a lot

- then don't, just pick one example, try to resize the window, and 
see how it works.

I will try after the lunch :-) The "poke" above should still be there, 
Carl imo stores already used "forms" with their last values in temporarily 
block called test-panels....

Ladisla - thank, that was it. I mean - break-after fixed it.  With 
above - columns, to simply reproduce it, just view child, close the 
window, and call view child once again ... it breaks to console after 
a while with stack overflow. Well, now I know that 'columns is not 
used anymore, but you might try to look at it, if you have time, 
to see why it causes stack overflow ...

Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


REBOL []

do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child

CLICKER was not adapted, so no matter how hard you try, without adapting 
it, you cannot achieve good results

OK, just try very simple layout:

lay: [button "OK"]

child: make-face 'hpanel [break-after: 1]
set-panel-content/no-show child lay
view child

I would like to try working on the Amiga-native graphics for R3. 
Please send me a copy of whatever sources I need to get started. 
I also need a copy of R3 for Amiga which Carl has not yet released.

Unfortunately (or not, depending on your opinion) the module system 
doesn't have many unit tests. The reason for this is because it is 
written using design-by-contract rather than test-driven-development. 
Once the design is final we will write tests to try to break it.

that might work.  I could put the needs to the cgr module within 
the opengl-cgr... I'll try that.

ssolie, try a size of 33.

(Unless you already have 33, then try 31 :)

then just see if the functions actually match to those.. in the host-kit


ex, does calling RL_Get_Value actually try to get a value from a 
block or is

hmm, let's try the linux checksum as well :)

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.

Ever try an elf-to-mach-o converter?

Ok. Then try make an unstripped .so from the unstripped .o and strip 
-x the .so afterwards.

Henrik: I have a blog where I'm going to try and document my progress.. 
see http://solie.ca/

Well, there should be no problem for us yet, no? So far, R3 uses 
SW rendering, there's not much to worry about in regards to OS-X 
API, no? Later on, as we have proper codec system, or we try to accelerate 
gfx or video, it might be a different topic.

BTW last night I added freetype font rendering to the hostkit so 
ssolie will be able to try render text on AmigaOS4.

henrik:R3/Lobby>> help
sh: xdg-open: command not found
sh: x-www-browser: command not found
** Access error: external process failed: "Undefined error: 0"

** Where: browse parse try either either forever command-loop make 
context do catch either either -apply- do try chat
** Near: browse help-url

Seems these are broken in A110 for OSX.

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 ?

You can try do download the zip again as I did. There was a wrong 
version.

sorry guys, I screwed the archive yesterday. If you want to try it 
again, please use this one: http://cyphre.mysteria.cz/tests/r3gl-proper.zip

Yes, VirtualBox OpenGL is very poor. I may try something in Parallels 
later.

If you want just to try A110, go to REBOL3 GUI group here, there's 
a link to download a binary and dll .... we will have to wait for 
Carl to resurface and correct the release, or even better - to merge 
the changes to official location ...

wait a bit ... I'll try to redownload Carl's HostKit

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/

I'm beginning to wonder what is going to happen if we try to use 
git on many of the older systems...

I try to stay about 3-5 years behind "recent" in order to make the 
code work over the greatest range of systems.

Let me see if I can find a curl-config that runs... then I can try 
the build again.

try `make NO_CURL=1`

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

Anyway, I've got something to try out now on Linux, which is good. 
 For systems that might never run git, perhaps Andreas knows how 
to use git to auto-build gzips that we can have posted on the github.

We can quickly try it out, it is really simple.

Try it:
svn co https://svn.github.com/rebolsource/r3-hostkit.git

On the other hand, I've never met anyone who went back after giving 
a modern DVCS (which means mostly Git and Hg) a serious try.

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 ...

Ah, sync might actually try to upload something, or simply delete 
my own files?

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.

I don't know. I can try changing it to see if it cleans up. 


Was going to add config notes to rebol.com git page but can't remember 
docbase login procedure. I know I have a docbase account but I seem 
to recall two levels of login are required or something.

Yes. But I want to try to get it out today.

If you have local commits which are not in the remote repository, 
if you _pull_ Git will try to merge your local changes with the remote 
changes.

Andreas, it is easy to move the TO-* to the command line.   It was 
originally put in a file to try to keep the gcc line shorter (easier 
to see compiler warnings.)