World: r4wp

I have just uploaded a basic script to generate Red/System API docs 
to Github. It could do with a lot of polishing, perhaps you could 
take a look?

Red/System API Docs ... Just what I need, Thanks, Peter. :-)

I would like to report a bug in red-system. I would prefer not to 
register myself anywhere. Which is the simplest way ?

Arnold, I'm talking about the RPi wiki I linked above

Added to the favorites!

Marco, you can report it here, and someone will then re-post it in 
the bugtracker on github.

red-system question:
How can I create a simple array of constants?

That's a bit tricky. There's no explicit support for specifying that

You can write such a list in the arguments of a function, so you 
can make a constructor function that takes the constants and delivers 
the array

Actually, when you use a typed constructor function, you already 
get access to the arguments array, but it's an array of stuct!s of 
type typed-value!

If you can use the array in that form, you can use that trick, but 
you have to stay within the function because the array is on the 
stack

I have some design notes for supporting literal arrays of scalar 
values (integers, bytes, floats, booleans), but as we haven't had 
the need for them in Red construction so far, I have not implemented 
such support yet.

I am trying to write a test red-system program but it is a pain:

I write it in my editor, then open a Rebol console and do change-dir... 
do/args ... then:

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. Which is the right method?

Are you compiling the same program again while it is already running?

No, but now I see that I must wait some seconds before a new compilation.

On which platform are you?

win 7. Acer Aspire 2.0 Ghz

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. 


I don't get this part...Your program seems to be still running while 
you think it has finished.

If you have no loop in your code nor system calls that might block, 
you could try disabling your anti-virus program to see if that's 
not the one interfering.

Does call/console work under Windows 7?


call/console "ver" causes REBOL to hang on my machine after printing 
"The handle is invalid twice."

Perhaps it is better to use call/output?

>> console-output: make string! 2000
== ""
>> call/output "ver" console-output
== 0
>> console-output
== "^/Microsoft Windows [Version 6.1.7601]^/"

In C/C++, A file which might be included by other files would likely 
start with "#ifndef _OOXX_H #define _OOXX_H" and end with "#endif". 
How would I do that in Red/System? Thanks.

Red/System will only include a file once no matter how many  #includes 
it encounters.

Thanks, Peter.

Yeah, can't believe they didn't fix that in C* in fourty years

I'm offering another matching funds drive to help keep Doc working 
on Red.  I'll match funds donated to him by December 25, 2012, up 
to a total of $1000.  If you're interested in Red, please help Doc 
focus his efforts on the project.

Cool :-)

I have been testing my compiler help script and notice the compilation 
of my red test script takes about 150 ms and after that the compiling 
to native code takes 3791ms and the linking is done in 92 ms. 

The step in the middle seems to take relative long. This is because 
Rebol does the bulk of the work here? For the JIT compiler there 
will be a faster Red compile one.

The "step in the middle" is the compilation of:

- the Red/System code generated from Red code (user + boot script)
- the whole Red runtime code (in Red/System)
- the whole Red/System runtime code (in Red/System)

The current "slowness" is caused mainly by:
1) all the runtime parts being recompiled for each user script
2) REBOL relative slowness

The cures are:

- for 1), precompile runtime parts, and recompile them only on changes

- for 2), Red self-hosted compiler will give a good boost (x10 is 
my target)


Also, the self-hosted Red and Red/System compilation speed will be 
improved compared to the current versions. In the end, we should 
have very fast static and dynamic compilation, the target to reach 
for the JIT compilation mode is less than 100ms for short scripts, 
typically, most functions should compile under 10ms.

^ Things like this are why you're "Doc"Kimbel and not "Mr"Kimbel 
:)

;-)

Actually, there is a quote from Jack Shephard (the doctor and main 
character in L.o.s.t. TV show) that I repeat to myself when facing 
lots of new bug reports or complex issues: "I can fix it" ;-)

That's so dramatic (...and rightfully so at times, I'm sure)  :)

Doc, what are your current expectations about timing for a Red GUI? 
 Do you want to make it VID-like?  (my vote is for yes).  GUI was 
the "hook" for R2, and I think a GUI as simple to use as VID, even 
if not encompassing as many features, would increase RED's appeal 
dramatically.

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

The cool stuff to show-off would be - bring your Red on your SD card/USB 
stick, plug-it-in, go to its dir = show "no-instal" option, show 
some GUI dialect, press a button, generate android app, and with 
one command or a dialect, push it to Google play. Then I can send 
you my friends short/long description, how long it took him to get 
his app there, downloading and installing all the JAVA crap and all 
dependencies ...

That could send a message to the overbloated world out there, and 
could win some audience ...

Curious too about time frames for file access, network protocols, 
2D drawing API, sound, etc.  Are those things on the horizon yet? 
 Looking forward to when you can port higher level things like mysql 
dialect, games demos, etc.

You answer makes me want to send you more money :)

You -> Your

:-)


File and network I/O: should be done for Christmas (maybe alpha state 
for networking). I will provide then HTTP client/server support shortly 
after. Expect more network protocols to come in Q1/Q2 2013. 2D/sound 
will be part of the work on GUI, so will happen later in 2013. Mysql 
support through networking: I will very much like to have that, as 
Postgresql support too. Expect them before summer 2013 (or maybe 
before for MySQL, if I need it for a killer Red demo). ;-)

Pekr: that is the kind of "killer-demo" that we need to make Red 
reach out developers far beyond REBOL community.

BTW, functions support should be finished this weekend, then I will 
work on object! and error! implementation new week.

new = next

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.

In short: Write apps and pretend we have a complete, perfect and 
luxurious GUI system with no work-arounds. Then write that GUI system.

red-system question:
which is the difference between pointer! [byte!] and c-string! ?

It would be great if the GUI system used a combination of vector 
and bitmap rendering for widgets. Vector drawing could be used for 
initial drawing or when a GUI was re-sized. Thereafter, the widgets 
could cache their bitmap (if so configured). Maybe I'm stating the 
obvious and this is already how things are planned to work.

Henrik:I agree with your way of thinking, that is the kind of pragmatic 
approach I take often too when designing any dialects or even APIs. 
For the Red native GUI system, I will prototype it with the first 
big Red app I plan to write: the Red IDE.

which is the difference between pointer! [byte!] and c-string! ?


C-string! points to a stream of bytes terminated by a NUL character, 
while pointer! [byte!] has no such requirement.