World: r4wp

My tests are bit random, they test just what I need but I will add 
them, it's probably better than nothing.

Also I've run into some weird problems with float32!. I try to separate 
the code and write some simple examples.

That's fine, regression tests are supposed to be for very specific 
situations that occurred

Hi Doc and everybody, since I'm studying the opportunity to create 
myself - in a loooong future - a test  version of Red/system running 
over the JVM - I asked myself, after reading some doc titled "Create 
ypour own programming language" by Marc-Andre Cournoyer, if in any 
case Doc had thought about this way of doing things for his future 
implementation of Red (not Red/system), as described by this excerpt 
from the doc itself under the section :  PROTOTYPE-BASED

Except for Javascript, no Prototype-based languages have reached 
widespread

popularity yet. This model is the easiest one to implement and also 
the most
flexible because everything is a clone of an object.

Ian Piumarta describes how to design an Open, Extensible Object Model 
that
allows the language’s users to modify its behavior at runtime.

Look at the appendix at the end of this book for a sample prototype-based

language: Appendix: Mio, a minimalist homoiconic language. For a 
follow-up about these concerns here is the URL related to the Extensible 
Object Model upon which the author has based his own Mio language, 
itself inspired by the IO language  -  http://piumarta.com/software/cola/objmodel2.pdf

Prototype-based: certainly, that's the REBOL way, so that will be 
the Red way too.

I've put some (I think) useful functions to https://github.com/rebolek/user.reds

There are things like int-to-float and float-to-int conversion and 
some string support functions.

Thanks Rebolek! I like the ** power function. :-)

It's unfortunately integer! only, I need float! version, so maybe 
for next release I find something :) i'm most happy with float-to-int 
and int-to-float, I was really missing it from Red/System.

I was planning to add them as intrinsic ASM functions in the backends, 
but in the meantime, your implementation will certainly be useful.

Hi Doc, I didn't express correctly in my last post and you missed 
the point - I already know that Red will be prototype-based but the 
question is : will the object model implementation you'll use be 
flexible enough to permit you and/or the end-user  to easily extend 
  Red with other  new types, or change primitive functionality and 
semantics at some later time. The author of this article has done 
some studies and experiments about this fact and within his 16 pages, 
he explains how it could circumvent these possible limitations without 
sacrificing efficiency - even if I'm not advanced enough to take 
his word as truth per se. I thought it would be useful to you to 
see such writing before you committed to much material, based on 
your current architecture and internal implementation details - about 
which I don't know anything, I must confess. Sorry if this is more 
of an annoyance than a useful tip but I thought it could be useful 
as a reading to anyone interested in implementing some programming 
language - be it not fully Red related.

Thanks for fixing #224, I''ve added #225 (good old 11 float stack 
check :-)

Sometimes progress doesn't feel like progress :-S

There's another reason: look in the tracker

Kaj, you're right, but even if I fix the examples, both errors are 
still present.

OK, that would be bugs, then

Doc, thank you for your swift response to my bug reports. There's 
clearly visible daily progress in Red/System and it's getting more 
and more usable every day. Red/System clearly shows advantages of 
open sourced language compared to closed source ones. I'm really 
happy with it and I look forward to next versions of Red/System.

I look forward to the first version of Red :-)

BTW, yesterday I've encountered a strange bug that's very hard to 
separate. The bug is that EITHER will always execute FALSE block, 
even if the condition is TRUE (EITHER is in function and the function 
is in WHILE loop, but that's not enough to trigger the bug). When 
I try to separate the problem the bug is gone. When I leave the function 
as is and just remove all unrelated stuff, the bug is also gone. 
It happens only when I compile my whole project. When I have more 
time, I will once again try to separate the problem and when unsuccesful, 
I will post the project as is for you to check it.

Thanks Rebolek! You can send me the whole project source code if 
you want, it might be hard to pinpoint the cause of such kind of 
heisenbug without looking at the disassembled code.

Pekr: I'm working on it. :-)

OK, as you are back on track with Red development, another donation 
sent ....

Thanks Peter! :-)

Petr* (I was just writing to Peter WA Wood).

@Gerard: 


Red will allow to extend itself in several ways. New types could 
be added easily by defining a set of new action! functions associated 
with a new datatype!. Also, the language syntax and semantics themselves 
could be changed by using the internal compiler API (not sure I will 
implement that in the bootstrapped version to avoid compatibility 
issues with the final compiler version).

As you can see, these features are not related to the object model 
from the user POV, because Red (like REBOL) are not OOL to me (I 
mean by OOL, languages that force you to use the object model). Anyway, 
the article looks interesting, so I'm saving the complete reading 
for the time when I'll work on the Red object! datatype (not implemented 
yet).

I am also look forward to the first version of Red. And I am willing 
to rewrite my REBOL book into a Red Book.

That would be great Jerry! Another incentive for me to work even 
more on it. ;-)

With all the talk of Red ... are you aready working on it? I thought 
you are working on Red/System still?

I am too dumb to use Red/System .. so I'm waiting for Red too :P

Janko, that's just prejudice. If I can work with Red/System, anybody 
can!

Janko: yes, I am currently working on Red compiler implementation. 
I will push it in the v0.3.0 branch as soon as it is stable enough.

wowo!!

Thanks Doc for the explanations - I asked myself if the kind of extension 
you described were already possible with your current plans - without 
knowing or having to bother with the way the objects are implemented 
- your answer is good news to  me.

Keep up the good work Doc - we're ALL behind and with you  !

Doc, have a look at http://box.lebeda.ws/~rebolek/sintezar.zip

Compile file %sintezar.reds and see function ADSR in %env.reds. Even 
when I pass TRUE, EITHER always executes FALSE block. I tried to 
simplify it, but I wasn't succesfull, so it's bit bigger project 
than just few lines, sorry :)

Looks interesting. I can see how you're finding those expression 
bugs. :-) This is a really nice example of how Red/System can replace 
C

Have you tried swapping the order of the arguments for adsr to see 
if it makes any diffrence? especially putting the  adsr! argument 
in the last position..

Rebolek: thanks, I've reproduced the issue and I'm searching for 
the cause.

I've just pushed a fix for your issue. I know correctly get the TRUE 
block being executed when it should.

Doc, Not to rush you, just curious about the progress of Red and 
its Unicode support. Unicode is very important here in China. :-)

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Porting existing C code to Red/System is fine as long as:
- the C source code license allows it.
- the used C algorithms are fast and light on memory usage.

Please take some time to give good thought about this kind of things 
and specifying in more detail what is needed, so other people get 
a chance to help out with doing a little programming for Red (/system). 
While not everybody is a topgun like yourself, there is a lot of 
legwork that could be taken out of your hands.

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Arnold: sure, if someone is willing to take some of these coding 
tasking, I'll be happy to provide more detailed requirements.

This is exactly the point! If you look in the archives you will notice 
some remarks by Carl where he was disappointed in that others didnot 
pick up some tasks. Okay first of all REBOL being not open source 
it makes no sense helping documenting stuff but there is no chance 
to do this kind of thing if there is no info of what exactly is to 
be done, as an outsider you are always one step behind and if you 
invest precious time into some work only to discoved they already 
did this. This is not an invite to do anything.

Do you think that my above description of the needs is not enough 
for you to decide if you want to do it or not?

Keep in mind that even UTF-16 is not a fixed-size encoding. Each 
codepoint either takes 2 or 4 bytes.

UTF-32 (aka UCS4) is a fixed-size encoding. It's rarely used though.

Brian: right!