AltME groups: search

The right and efficient handling of refinements is really one of 
the most difficult parts in making a Rebol language interpreter/compiler.

I could write a book about designing and implementing a Rebol-like 
language, counting R#, I've implemented two interpreters and one 
compiler. I've also implemented a partial Rebol in Rebol interpreter 
five years ago (never published), mainly aiming at providing step-by-step 
and stop/restart evaluation features for debugging purposes. But 
my first tests showed that it  was running about 50 times slower 
than R2 itself, so unusable for real code.

Added REMOVE action, supports any-series! and none! datatypes.

But I won't delay the new release for that. Still a few issues to 
check and test all on ARM before making the release.

I've told him about it, he will give it a look, but he's not familiar 
with the way to achieve it with Red/System (I've pointed  him to 
your own work wrt to dialects), and Red is not yet ready for that 
(routines are not documented at all).

Still a bit early for a prime time, as we don't have yet proper errors 
handling. One thing that would be useful though, for anyone trying 
Red, would be to dig out Peter's extraction scripts from the repo 
(in /docs), update/enhance them if needed and make a nice CSS for 
displaying the resulting list of actions/natives/mezz. Anyone?

As is "Red" name:

http://en.wikipedia.org/wiki/Red_(Taylor_Swift_album)
http://www.sfr.fr/telephonie-mobile/series-red-de-sfr.html
and many more...

@Rebolek: as you have implemented a multi-line input support for 
your gfx console for R3, you might be interested in having a look 
at how I've achieved it for Red:


https://github.com/dockimbel/Red/blob/master/red/tests/console.red


I'm not fully satisfied by my implementation, but don't have more 
spare time to work on it further. If you have a better/simpler approach 
and are willing to share it, I'll be glad to include your improvements.


Adding to this, my current implementation doesn't handle well a multi-line 
string included in a multi-line block, it works, but the prompt is 
incorrect. I guess I should use a stack-based approach...

All these logos are missing some pegs. Could be a real cool way of 
depicting progress. All of the tower starting at the left (REBOL) 
site and ending as a full tower on the right Red site. We are now 
somewhere with the top two layers on the second pin. (Only to find 
out we moved the complete tower to the middle pin.)

Great progress Doc

Does Red support NaN, positive infinity, and negative infinity?

6. Decide on how to handle NaN and INFs.


I haven't looked at how R3 handles them yet, IIRC, R2 doesn't provide 
any support for them?

R3 should follow this. So many time you want to use short temp var 
p and q and then it all just quit on you :(

Curious. I never found that to be a problem and use q for quit many 
times a day. I hope 'q can be chosen freely.

I want both - Q and QUIT :-)

Arnold: if you have such issues with Q in console, you should simply 
set it to none in %user.r for Rebol. For Red, you would need to change 
the console.red script and recompile it for your needs.

Ok, one last possible bug to investigate in GTK-IDE script and we 
should be ready to release.

Hi do not recall it exactly but I think it was when I was developing 
the checkersgame program and somehow I had a variable q and when 
the code was executed the program and the console closed forcing 
me to restart REBOL.  

The solution you have chosen now will pretty wel have prevented this 
behaviour, still offering a shorthand for quit in console mode is 
welcomed by many. Good thinking again!

I plan to write an HOW-TO guide for that someday, but in the meantime 
and in a nutshell, this is what is required:

1) NAT_<name> enum entry in %macros.reds (order matters!)


2) pointer entry in REGISTER argument block (same order as in macros) 
in %natives.reds


3) an entry point implementation in %natives.reds (if the code is 
too big you can move it elsewhere as long as the entry point is in 
natives.

Of course, you'll need to use the internal Red runtime API and stack. 
No docs for now, as it is not stabilized fully, but you can guess 
a lot of it from other natives and actions implementation.

In boot.red
foo: make native! [
	[]
	#get-definition NAT_FOO
]
in natives
foo*: does [halt]
and registered as :foo*

in macros enum added NAT_FOO

found it... using:
code: as red-integer! stack/arguments
int: code/value


so now I can change colors in console... will clean it later and 
upload:) now back to work

Yes, and nobody has confirmed the proper library names on OS X

If so, you can try to comment out the #import of History-library, 
and in INPUT, "add-history line"

that's what I did now and the console is working.. just without history:)

just my colors are different.. instead of red color it's blue and 
underlined

While we're at it, I would really like you to confirm the availability 
and name of the cURL library, which I have penciled in as libcurl.dylib

also libcurl1.3 and libcurl1.4

And OpenGL? I have it penciled in as libGL.dylib

Beside donation, I would like to contribute to the Red codebase. 
However, the lack of document stops me. I did read Red/System document 
again and again, but it's not enough for me to start. I guess I need 
to read all the red source before I can contribute code? Or is there 
is another way for us to rush in easily and quickly?

Thanks! This one was tough to get out, so many new features to get 
right and bugs/regressions to fix!

I can see some lag of Red vs R3, althought not sure it is a fair 
measurement. Just tried with repeat i 1000 ["notning"], and while 
R3 response is instant, Red takes some fair amount of time to complete 
...

Close to 3000 hits on red-lang.org since the release, all traffic 
coming from reddit:


http://www.reddit.com/r/programming/comments/1awkcm/red_programming_language_version_032_released/


If you want to help Red, consider posting and upvoting Red there. 
;-)

Creating a reddit account is a 10 seconds procedure and email is 
optional.

BTW, we need to add doc-strings to all functions in %boot.red, I 
like the Rebol short but meaningful strings, but I have a few questions 
first:

1) Could we borrow them from R3?

2) Does that fall under Apache license too (I guess so, but just 
checking)?
3) In such case, where and how do we to put proper credits?

R3 doc strings were released as part of the source, so they are under 
Apache. They would taint Red to fall under the Apache licence, too, 
making it more restricted than BSL and incompatible with GPL

AFAIK it is and I really don't like it.

It is intentional and has several purposes: 


a) avoiding the creation of an hidden context for each iterator instance 
and especially the costly deep BINDing of argument block on each 
call.


b) making the iterator word available outside of the loop, can be 
useful when early breaking from loop, avoiding the passing of the 
counter through a BREAK/RETURN. It can also be used to check if the 
loop counter has reached its limit or not.


c) it is IMHO counter-intuitive for users, after a few years you 
get used to it, but it is a wall that every new user will hit more 
than once. I think that the extra step of defining it as local word 
is really not a big deal in comparison. Also, FUNCTION constructor 
could be enhanced to take care of that for you.

And the last value is 2, not 3.
red>> i
== 2

I *feel* same way, I usually use i, j, k, t, s as /local words to 
functions, and I don't worry to mess them with iterator words inside 
function. But we should explain why or how it is a bad idea to Doc 
(if it really is)

Anyway, you shouldn't use the same word for nested loops, that is 
just confusing and will lead to errors.

You need to created a new context on each REPEAT call (or use some 
hacked way of caching it) and you need to BIND the loop body (even 
probably BIND/COPY it to be cleaner). Now think about the costs of 
nested loops...and all that because you don't want to define another 
local word, that could anyway be added for you by FUNCTION. Think 
twice about the trade-offs.

Huh, it seems that both current versions of R2 and R3 are not binding 
the loop body on each call to the hidden context:


>> foo: func [code [block!] /local a b][a: 1 b: 2 repeat i 10 code]
>> foo [a: a + b]
** Script Error: a has no value
** Where: foo
** Near: a: a + b


I'm pretty sure I've seen it, maybe in older versions. Anyway, if 
current Rebol versions are not making that binding on each call, 
it makes most of my point a) irrelevant. So, you can forget about 
the binding cost. :-) Still the other concerns and limitation remain.

Red would raise an error ("word has no value!") running the same 
code in the interpreter. You would need to write it this way to make 
it work:


    foo: func [code [block!] /local i][repeat i 1000 bind code 'i]


That makes the required BIND operation explicit, so the same flexibility 
as in Rebol could be achieved but in a user-controlled way and only 
when needed.

My first reaction was the same as Endo and Bolek, because I'm used 
to the way it is. I rarely have to alias a loop counter for access 
outside the loop, and I like the language being smart enough to help 
me, so I don't have to declare these things all the time, or worry 
about leakage.  However, my recent work on the idea of a new, general 
LOOP func (%mezz/new-loop.r here for those who didn't follow it) 
made me keenly aware of loop costs.


I've only had a few instances where it really mattered, but I've 
still almost always avoided FOR, for performance reasons.  Doc thinks 
things through carefully, and he has already said that FUNCTION could 
probably be smart enough to handle things for us, but we would have 
to consider how that works, to avoid environment dependent behavior. 
And how it affects very simple map/filter funcs. That is, do those 
one-liners now need /local specs.

Now is the time to discuss this, but it sounds like Doc has thought 
this through, and made his choice for clear reasons. If he's set 
on it, then we should look at what, if anything, needs to be done, 
to make Bolek, Endo, and others happy.

Maybe this is where something like my new LOOP could be used. It 
would be a general purpose func that trades performance for flexibility 
and automatic localizing of loop vars.

Compiling the console works out of the box as described on my Macbook. 
I am impressed. The Repeat by Endo does what I read it that it should 
be doing. The Doc: is it intentional?
red>> repeat i 10 [  ]
== 10
red>> i
== 10

is what I expect it to be after the performing of the repeat. Unless 
you argue that i should only be valid inside of the repeat, but you 
should work with a function then not with a repeat. I do not see 
what is not to be liked about that?

In REBOL and Red it is the human way that is leading not the programmers 
mind that is used to bend along with the computers view of the world.
Again beautiful progress Doc.

Arnold, the point is that Rebol makes the loop counter a local word 
in a hidden context. It saves user from having to defining it as 
local manually (I have argued above about how I think this is, in 
practice, rather counter-productive).


We need to find the right balance between human-friendliness and 
efficiency/productivity.

Yes, so i should not be defined after performing the repeat. There 
is something to say about that.  On the other hand after performing 
the repeat, in my mind i is at the end of the range and thus has 
to be equal to the last value. Stupid humans ;)

The biggest problem I see right now is that it binds to the global 
context, which will confuse existing REBOLers. I still think it can 
be solved cleanly, and the performance gain is probably worth it. 
And you know how I hate premature optimization. :-)

In %boot.red, UNLESS's second arg is called 'true-blk. Should it 
be 'false-blk? Or should both UNLESS and IF call it 'then-blk?

A simple suggestion: instead of "is TRUE"  I would suggest to use 
"is true" meaning anything distinct from FALSE and NONE.

Indeed, and it can already be done easily:

I still prefer having FUNCTION take care of it and using simple word! 
values, else it looks odd and misleading (i: 5 looks like one expression, 
while it is two expressions in fact).

Is it correct to state that FUNCTION automatically localizes all 
refinement, get-word, and set-word values found in the function body? 
And that is all that makes it cifferent than FUNC?

If so, since I don't know, why not just set-words?

Have you tested that? As far as I know, it only adds set-words to 
the arguments and refinements

Things are clearly laid out, but slot order and the stack are important 
to understand.

Clearly. From a testing and coverage perspective, it would be great 
to have a matrix (and an easy way to generate it) to see how complete 
each type is, or make sure you have everything in place when building 
a new type.

Let me finish my pass on boot doc strings, and then I may look at 
that.

SAME? is a tricky one. I will make it very basic for now, and we 
can fix it when more accuracy and details are needed.

I don't know how Ladislav's identity article applies, since R2 and 
R3 differ as well.

SAME? is not implemented yet, we need first a matrix of datatypes 
and consider each case one by one, then implement it.

Doc, do you want any TBD marks for things that aren't implemented 
yet? e.g. /all and /header in LOAD?

For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.

Just from quick tests and a glance at code.

For FORM I have:
	"Returns a string representation of a value."
and for MOLD:
	"Returns a loadable string representation of a value."

Can we use the ROUND doc strings from REBOL, since Ladislav and I 
wrote them outside of RT?

I know ROUND is TBD, and you probably want it native, or you could 
use the old mezz version.

Even though REBOL uses /dup for APPEND and INSERT, would /dupe be 
a better refinement name?

Forth and RPL (I've done a lot of code in RPL long time ago) use 
DUP as abbreviation for "duplicate".

(Bookmark it, you might throw at me that quote someday in the future 
after I make a purely subjective and arbitrary change from Rebol. 
;-))

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

The issue seems to be with the console as the tests work in both 
the compiler and the interpreter.

'For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.' Gregg, suggested reading:

http://en.wikibooks.org/wiki/REBOL_Programming/mold

Your "construction syntax" is a bit long but accurate and meaningful 
naming.

Take that out and it works fine.

Testing with a string! between a refinement and its argument, I get 
odd results (but no crashes so far). Definitely a bug.

After pulling your doc-strings locally and recompiling the console 
I get the same output as you.

I've just run the Red tests on both Windows 7 and OS X. Same results 
on both:

** - Red Test Suite******************5331 / 5666 **

Evenetually we can test for missing doc strings and use some for 
reflection test, at the least.

I get the same serialization results here. Great to have so many 
tests Peter, and easy to run.

I've just checked the quick-test docs and see that I forgot to mention 
the log file. I'll certainly need to update the docs.

OpenCV 2D lines demo: http://www.wuala.com/fjouen/Code/OpenCV/Red/pub/lines2.jpg/


Webcam driver and videos playback code example in Red/System can 
be found in this thread: http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C17Mar2013190850930275100%3E


François is close to 100% covering of OpenCV for Red/System. Once 
that (huge) work done, we would need to create some good dialect 
to access all those features from Red.

PARSE helps making the dialect implementation shorter, faster (for 
interpreters) and more elegant.

I don't care about Curl, I regard it being an interim solution. Any 
REBOL-like language has to support what makes REBOL being a REBOL 
in a first place. And one of its concepts is abstracted interfacing 
- ports, schemes, that it :-)

I did not say anything against float support. Actually I said - Yes. 
But my (most probably limited) understanding is, that float support 
for Red is easier than ports etc., so that it will be done, and IO 
comes next ...

Right, adding basic float support to Red is not difficult, but as 
floats are not needed internally to build Red, they are low priority 
(but if someone wants to contribute it, it will be welcome). Moreover, 
the runtime lexer is disposable code, it will be soon replaced by 
a new one with Unicode support and more complete syntax support. 
So extending it now for additional literal forms is a bit of waste 
of time.


If someone is interested in implementing float support anyway, the 
decimal! name is reserved for a future BCD datatype, so possible 
names are: real! or float!. It will be a 64-bit float, so mapped 
underneath to Red/System float! type. A support for float32! at Red 
level is not planned, converting float! to float32! at Red/System 
level when needed (i.e. OpenGL API) should be enough.

I've started on some Red mezzanines in %Red/mezz/ here. Early days, 
but my hat is off to Doc for how far Red has come already. Yes, I 
crash the console a lot, and I can't DO files yet, but I can paste 
code into the console, play, and still make really good progress.

HELP and WHAT are next on my list.

I tried to compile the OpenCV test script for Linux-ARM on a Windows 
system, and I get the following error:

*** Compilation Error: invalid import specification at: libopencv

Is this because I need OpenCV installed on Windows first?

Unfortunately, I am getting the same error trying to run it on Windows 
and Linux-ARM:

# chmod 755 opencv-cam-test
.# /opencv-cam-test

./opencv-cam-test: symbol lookup error: ./opencv-cam-test: undefined 
symbol: isNaN

And sqlite3...

The zip doesn't want to download for me. Must be a sign I should 
run lean for the moment, and bug Doc for a few features. :-)

I'm really impressed with all you've done Kaj. And since I'm going 
to start on a DLL interface shortly myself, I will no doubt bug you 
for advice.

I've hacked Ladislav's INCLUDE to let me build .red scripts, and 
I built a console with my mezzanines. When you get back, I'll chat 
with you about it, and send it to test. It compiles fine, but some 
funcs fail if compiled in. If I then paste them into the console, 
they work fine. e.g.

negate: func [n [number!]] [n * -1]

You can also use Fossil to download and update it comfortably:

Yeah, I'm posting mezz stuff here so it can be evaluated and discussed, 
along with how to organize things, without polluting the core yet.

It sure is nice to develop in the interpreter and port to Red/System 
with minimal changes

Playing with Francois's OpenCV binding.  I get an error on Linux 
ARM when compiling his OpenCV camera test.  The error is:


./opencv-cam-test: symbol lookup error: ./opencv-cam-test: undefined 
symbol: atexit


I've looked through all the code for the OpenCV cam test, the OpenCV 
binding itself, related libraries and Red/System source and I can't 
find "atexit" anywhere.  Am I overlooking it?  Any ideas what code 
this message is coming from?

Nevermind.  Windows search is a piece of garbage.  Wrote a Rebol 
search and found it right away in C-library.reds.