World: r4wp

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.

AdrianS: for a View-like engine, it would makes sense, but such approach 
suppose that you are building all the widgets yourself, while what 
I want is use native or third-party widgets. We've experienced in 
the last decade with View, how difficult it is to come up with your 
own complete set of widgets with good look'n feel.

Some of you might not have noticed but Red is maturing fast, it justs 
lacks I/O support to be already usable for building small scripts/apps. 
So, even if it is still in alpha stage, we need to come up with a 
plan for building a good user-oriented documentation (there is already 
someone working on the Red formal semantics description). I do not 
want to rewrite the REBOL/Core documentation, but a lot of core concepts 
and datatype will be identical, so, what do you suggest we do for 
documenting Red?

A couple of observations: I would think that the slow going with 
View had a lot to do with the size of the community as well as an 
architecture that didn't easily permit the use of vector graphics, 
preferably designed using external tools, for drawing widget states. 


WRT Red, it makes sense to use native controls in order to get off 
the ground quickly, but the UI subsystem should allow for owner drawn 
controls. By allow for, I mean that these should be able to exist 
side-by-side with native controls, and, if defined using a vector 
source, widgets should do bitmap caching at the appropriate times 
for better performance. I guess what I'm saying is to please think 
about how owner drawn widgets would fit into whatever is the initial 
implementation.

Great explanations Nenad! My apologies if sometimes I seem to ask 
for the known things.. 


For the documentation we need a Red marker pen and mark the REBOL 
documentation where appropriate for Red.

I took a little time (just 5 minutes LoL) to see if I could find 
a starting point for the documentation extraction script from the 
suggested makedoc2.r script but 'parse is not my best REBOL skill.


Besides graphics and a killer application as Pekr described, having 
CGI support for Red can bring a lot of attention to Red too imho. 
(And this could bring financing Red up too when Red programmers are 
making money making websites using Red.)

I agree with Henrik 90%. The hard part is picking the target app 
and important elements. A game, or modern app with animation elements 
is a very different target than an "efficiency above all" business 
app. One of my failed attempts with REBOL was to get Carl, for just 
this reason, to identify a target audience. It guides your design. 


In the case of a Red/REBOL GUI, maybe there is no single design or 
dialect. Making small apps simple is hard to match to the needs of 
complex apps. If you're writing database/CRUD apps, wouldn't it be 
great to have a toolset designed just for that? That same toolset 
won't work well for games though.


I think using an IDE as the first target app is a *fantastic* idea. 
It covers a lot of areas, including the possibility of building on 
an extensible app framework (something lighter than Eclipse :-), 
files, documents, workflow, tool integration, customization, and 
many UI elements. And *we*, developers, are the target audience.

VID gets a lot of things right. Let's not forget that.