AltME groups: search

Inherently compilable

 alone still leaves open a wide range of design possibilities. "Redcode" 
 could still explore design spaces opened up by a quite reduced source 
 language.

DELECT takes a dialect that prepares the commands

The latter. I would like to keep decimal! name for a new BCD datatype.

Thanks Arnold. Not yet, I will make a 0.3.1 release for that, but 
it needs a few more days to stabilize.

FYI, I have started working on EXIT and RETURN implementation. It 
will probably take a day to design and implement them correctly. 
In the meantime, feel free to push issues with Red functions on the 
bugtracker.

Haven't read commints, so sorry if already answered - will there 
be a FUNCT equivalent, allowing to use local words only?

Doc, I can see Rudolf being pretty active with testing Red, Red/System? 
Nice, I thought we have lost him when R3 went into a non-development 
mode ....

Does this mean no GUI or just gui done in different way?

 See all the presentation slides for Red, a native GUI system will 
 be provided. Also a web server with a new web framework will be part 
 of Red stack, so modern style web apps will be supported.


The GUI will probably be done in different way than R3 underneath, 
maybe a gob!-like datatype will be a good match, but such implementation 
detail is not known until implementation starts. Also, it is possible 
to extract R3 GUI code, wrap it in a shared library and plug it in 
Red (but I won't be the one doing that and maintaining such wrapper).

I've finally been able to write a Red version of Fibonacci numbers. 
It executes twice as fast as R3

parameter: 35

fibonacci: func [
	n		[integer!]
	/local	a
][
	either n < 2 [
		n
	][
		a: fibonacci n - 1
		a + fibonacci n - 2
	]
]

prin "Fibonacci "
prin parameter
prin ": "
print fibonacci parameter

Red is a compiler, as simple as that

This might give you a clue - https://github.com/dockimbel/Red/issues/308

Kaj: nice! Actually, such kind of function (highly recursive, very 
small body) should perform 5-10 times faster than R3 in the target 
compiler. Functions with bigger bodies shoud be in the 10-15 range. 
Functions with pure math expressions should be in a 20-100 range.


Though, these are very rough early estimates I did on the base of 
a few micro-benchmarks.

Uh, what optimisations, Kaj? We are talking Red bing compiled to 
Red/System, so how comes, that the result is only 2 times faster 
than R3? I expected speed of nearly a R/S version. Something must 
be wrong, or Red would not make sense with such poor performance 
at all imo ...

Red is a high-level language with high-level abstract types. Once 
we get optimizations, Kaj's example should run 5-10 faster than R3. 
For some high-level expressions that have low-level counterparts, 
it is possible to achieve very high gains (in the 10-100 range), 
for those that do not have low-level counterparts, you can only expect 
typical gains from moving from an interpreter to a compiler (on average 
5-10 faster).


Also, there is also a source of additional speed gains: the possible 
runtime optimizations enabled by the JIT-compiler.

Those high-level layers are what makes Red able to accomplish all 
the things you like instead of being limited to a macro-assember 
level language (like C or Red/System).

it's the limit of the stack based compiler, simple to implement, 
slower than a registers based one

Steeve, performances gains will depends on the kind of code you run. 
For micro-benchmarks (like loop 10'000'000 [tail? ""]), the target 
compiler should perform 5-10 faster than R3. For "normal apps", you 
should expect a 10-20 gain (very rough early estimates). For math 
intensive apps, you'll be able to go up to x100 speed gains.

(Kaj, I'm trying to port a text editor to R3 currently, gobs are 
terrible and some times horrific)

Steeve, it is not that simple (I wish it would). You forget to account 
for a lot of things like e.g., exceptions handling and the GC.

I think gobs are very handy, it would be nice to see a portage to 
Red

But they tend to crash R3 a lot when the command api fail

I will probably do a Gob-like binding on Enlightenment

Well, I don't necessarily like big solutions/libraries. Of course 
it will make sense, if they are already a part of the toolchain, 
e.g. GTK being part of every linux distro, Android, etc. , ditto 
Cairo. So far I could see complaints about AGG not being accelerated, 
and what irritates me about such claims is - we never ever utilised 
full advantage of AGG, yet we complain. And then we are going to 
use crap like Cairo, just becau HW is going to help us. I would rather 
use smaller AGG instead of several times bigger Cairo lib, and orientiate 
myself on HW, which has floating point unit. Before we finish, even 
our small devices are going all to have FPU imo ...

Pekr: you have a wrong view on what the Red ecosystem is and will 
be. It is probably caused by 15 years of limited options from RT 
and closed-source nature of REBOL products.


In Red ecosystem, like in any most other languages ecosystems, you'll 
be able to choose GUI between different options. Don't give a wrong 
picture of Red by assuming that you will be limited to only one choice.

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

I understand that the 2 times faster than R3 includes the compile 
of the Fibonacci program? 

No the performance of the Red program is a bit dissappointing at 
a first glance for the programsource is not very different from that 
in Red/System?

the performance of the Red program is a bit dissappointing

 Maybe I should have kept Red project secret until v1.0 to avoid "deceiving" 
 people who thinks that any v0.x version should be equal to a v1.0...;-)

Well the compile is not a simple 1-to-1 translation. 

I am glad you did not keep it a secret, I enjoy seeing the developments. 
And it IS already faster then R3! :D

The speed difference with R3 is not a constant, the more code you 
put in the loop, the bigger the speed difference.

Arnold, the time does not include the compilation. That's a one-time 
operation, so it would be unusual to include it

Jerry: it's a bit premature, but yes, that should be the way to create 
and consume redbin data. You can also add SAVE to that list.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.

You should now feel a bit more "at home" with Red. ;-)

I have used FOURTH once or twice, a long time ago, never used others 
above that.

And his way of using it might be a good argument for continuing up 
to NINTH.

I'm serious. I think his idea was that real beginners should have 
a good idea on picking values from code.

It doesn't make much sense to me to add features that nobody will 
use, just because we can add it, doesn't mean we should. For beginners, 
if they can't get a good picture on picking values with accessor 
up to FIFTH, I can hardly think that adding more will be of any help. 


The only reason for having them is the above code pattern used by 
Carl, but it can't be used for now in Red. Also, users are free to 
add more accessors names in their own code if they feel the need 
for it.

that nobody will use

 - I don't buy that, since I only just now realized this is a good 
 way to produce certain types of more readable code. This means I 
 might start using SIXTH through TENTH more often.

(one can learn a lot by reading Carl's code)

I could use ordinals all the way to TENTH. It is a common practice 
in advanced REBOL code to assign these ordinals to other words that 
are used as local accessor functions for series-based data structures. 
Using those accessor functions makes the intent of the code written 
with them much easier to understand. This is a trick that Carl and 
I use pretty often, and the reason he defined ordinals that high 
ion the first place even if only the earlier ones tend to be used 
directly.

If by "aliases" you mean multiple words with the same values assigned 
to them, or something like C-style typedefs, then yes. If by "aliases" 
you mean the multiple-spelling words generated by R2's ALIAS function, 
then please no. R2-style aliases that aren't limited to spelling 
differences that only differ in character casing have proven to be 
a bad idea.

is that a bad thing?

Like Erste: :first

 "is that a bad thing?" - BrianH tried hardly to explain he did not 
 mean that, and he succeeded, at least for me

Right. Casing R2-style aliases are OK, and that is how case-insensitive 
words are implemented in R3 (and in R2?). Aliases which differ of 
something other than case cause major problems, corrupting object 
access when the other spelling already exists as a separate word 
in the same context, as happens automatically in R3 when the word 
is loaded in the user script  to be passed to the ALIAS function 
as a parameter. That's why there's a ticket to remove the externally 
visible ALIAS function from R3.


Just assigning the same value to another word, as Arnold suggests, 
is OK (and is what some other languages mean when they talk about 
"aliasing" so I understand your confusion).

I read the docs http://www.rebol.com/docs/words/walias.htmland as 
I understand it stampa: :print differs from alias 'print stampa 

because the latter does this in a way where ALL occurences of stampa 
even in different contexts are 'replaced' whereas the first form 
only applies to the current or global context not interfering with 
local usage.
Is that about it?

Almost. It doesn't "replace" the word in all contexts, it registers 
another spelling for the word in the place where word symbols are 
stored, then when you refer to the word with either spelling it will 
point to the *same* word.
However, if you write code like this: alias 'print 'stampa

then that code, just by being loaded, creates two words in the user 
context with those two spellings. So when the ALIAS function links 
the two spellings then there is a conflict in the user context, where 
"stampa" refers to both the word 'stampa and is an alias for the 
word 'print and at runtime you can't really tell which word you mean. 
If the system resolves this conflict by resolving to the alias then 
you have overriden the original word, which makes ALIAS a security 
exploit. If it resolves to the original word then ALIAS simply doesn't 
work. Either way, the function needs to go away ASAP.

I see the bad side. Alias shoul dnot have that big an impact unless 
an alias was designed on purpose into the language. For instance 
a support a complete spanish/chinese version for educational purposes?

Arnold, you can support a complete chinese or spanish version of 
R3 using a module and those worda: :wordb value assignements, no 
ALIAS required. But it would be a mistake to do that for educational 
purposes, because it would get in the way of them learning regular 
Rebol/Red code. You might want to do that for non-educational reasons 
though.

Re: FIFTH+, It should be easy to provide a REBOL compatibility library 
for things that aren't seen as essential for Red.

Certainly! Modules make the monolithic model not as useful. We even 
intended to switch to more of a modular model for R3 - that's the 
whole reason modules were added.

aliases can be used with refinements which is a bit weird 

>> alias 'any "xxxxxxx"
>> get/xxxxxxx 'red
== 255.0.0

I hope that it will be one of the first things done. The internal 
aliasing functionality is fine and should be still supported, but 
it should be locked down so it won't be possible to make an external 
ALIAS function. It even existing is a major problem.

(Sorry Doc about the off-topic stuff) And open-source forks that 
try to alter R3 to make ALIAS possible again will thus be that much 
less stable ond secure, so it will be an argument against their use. 
ALIAS is hostile to the R3 system model, and everything it might 
be a good idea to use ALIAS to do in R2 can be better done with other 
methods in R3.

(Seconded. If there is a link with Red, the link to Red is to prevent 
the same mistakes made again)

Kaj, you can translate refinements using wrapper functions, and it's 
a better approach when you need to combine code from several nationalized 
sources. If you accept the idea of nationalized code, then you have 
to accept multi-nationalized code. This kind of thing is why I made 
sure R3 supported private modules.

That's an awful lot of wrapper functions, can't be done by a pure 
translator, and degrades performance

Right. As opposed to ALIAS, which can bring your system to a crashing 
halt, if you're lucky; if you're not lucky it will fail silently 
and stay a security hole.

To illustrate my point in a dumb way: alias 'true "false"

Anyway, I increased the parameters of both Fibonacci and Mandelbrot 
to have a better benchmarking range for fast languages, such as Red/System

With this parameter and a more exact comparison, Red/System is 70 
times faster than Red

Kaj, you are assuming that people don't want to create deliberate 
bugs. If any REBOL-like language with an interpreter of JIT becomes 
popular, we are going to have to assume that some developers will 
be malicious. Remember SQL-injection attacks. Don't add a feature 
that is only better than another way of doing that feature in that 
it is so trivially easy to use as an attack vector that anyone could 
use it with the stupidest code imaginable.

Programming is a security hole. If you want to allow people to do 
safe programming, you have to make it safe by disallowing many things. 
That would obviously include ALIAS

Also, REBOL-like languages are easy to generate from a dialect. A 
translator could write data files in a dialect, which could be used 
to generate the wrapper functions and assignment statements. And 
a half-way decent optimizer could get rid of the wrappers using the 
same methods that would allow it to statically resolve refinements. 
There's no reason to support an astoundly worse method.

On my machine, REBOL catches up enormously when it can do many iterations 
in a very small loop. Apparently, a very small function will eventually 
fit in the CPU cache, so the VM gets less of a cache hit compared 
to compiled languages

I remember there being a spreadsheet expression evaluator that made 
it a point to have a small enough number of operations in its bytecode 
that it could fit two operations per byte. That means that with cache 
issues taken into account, its code was drastically faster than fully 
compiled code. The interpreter fit entirely in the instruction cache 
of a 486, and the bytecode was much smaller than regular native instructions, 
so the bytecode could be pushed into the CPU faster. This kind of 
a thing is even more of an issue now, with CPUs that are many times 
more faster than the memory busses, and even bigger caches.

R3 is obviously not designed with that kind of interpreter though, 
and isn't even bytecode compiled. That is more a trick for rebcode 
:)

If anyone wants to help Red and thinks he can't start programming 
yet, please give it a presence here under Tested on RPi:

Syllable would have to be ported to ARM, which is a lot of work

Possible to port Red to RISC OS too? Or a lot of work too %Y\ ?

I could contribute to the wiki (which one are we talking about here?) 

Now I have my 10x10 checkers game in Version 1.0.0 released I have 
some time to spend on the script Doc asked for. Can the specifications 
be reposted please?

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?

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

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!

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?

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

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.

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.

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.

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.

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" ;-)

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

:-)


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

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.

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.

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.