World: r3wp

No problem, I know all about it :-)

I've left the alternative function! uses commented out in my code, 
so they'll be there awaiting a future version

Updated the C and 0MQ bindings to the latest changes

Jocko, input-line works on Linux. I'll test it on WINE later tonight

When I compile this:

either as-logic 0 [
	no
][
	yes
]

I get

Compiling /users/administrator/Red/test.reds ...
*** Compiler Internal Error: Script Error : Invalid path value: 1
*** Where: comp-either 

*** Near:  [emitter/branch/over/adjust/on c-true negate offset expr/1]

Weird error...

Yeah

Oh I see what's wrong, let me fix that

Fix pushed.

Thanks! Good turnaround again :-)

Took me some time, had to run all the tests suite several times, 
refactor the code and find a meaningful commit log message. ;-)

:-)

Jocko, input-line works both on WINE and on Linux, so I have no reason 
to believe it wouldn't work on Windows. What is your code that doesn't 
work?

Oldes, same for print-integer and print-1. What is your code that 
doesn't work?

Next:

dummy: func [return: [integer!]] [0]
either as-logic dummy [
	no
][
	no
]

*** Compiler Internal Error: Script Error : first expected series 
argument of type: series pair event money date object port time tuple 
any-function library struct event
*** Where: opposite? 
*** Near:  [first select/skip opp-conditions cond 2]

Having a quick look at this error.

Seems related to my previous fix.

Yeah, was to be expected

Added two tests to reflect the two cases above to cast-test.reds. 
It now fails with a compliation error.

Fix pushed.

Thanks, both

Peter, the compilation error in the new type casting tests was not 
the right one. Variable initialization cannot happen in EITHER blocks 
now since today's following commit: https://github.com/dockimbel/Red/commit/31b87b9565004574174ba3bf02b4dfaa2db665f2

That change was required to fix issue #84.

Kaj: you're welcome. But no more fixes until tomorrow, bed time here.

OK then, I'll release you from your duties for the duration of eight 
(8) hours ;-)

Thanks for the pointing out the initaliasation changes and fixing 
the tests.

Great to see continued activity and progress on Red.

Kaj, I tested this morning, input-line works under Windows
My mistake was that I did not allocate the input buffer by

in: allocate 255 but by in: "" , which is not really an allocation

on an other hand, I cannot simply include the C-library in my script 
by :

#include %C-library.reds


instead, I must extract the used functions. (here _input-line and 
input-line)


The error message at the compilation is not visible in the console, 
because a large amount of text is printed. Maybe a double declaration. 
Any idea ?

Jocko, this might be caused by a duplicate definition of ALLOCATE 
and FREE, but Kaj removed them from the C-library in the last revision. 
I just downloaded last revision and tested, I can include it in my 
scripts without any issue.

Gregg: thanks for your kind support.

print functions from Kaj's C-library has different precedence than 
ordinary print/prin when you call the red's exe from REBOL using 
CALL/console command.

Which means.. if I have code:

print-1 "int %d" 1
print "hello"

I get in REBOL console:
>> call/console %builds/test.exe
hello
int 1== 0

in CMD:
int 1hello

Confirmed here too (on Windows). PRINT-1 is printing after every 
other PRINT calls in a script.

It seems that they are not using the same streams.

This article explains the issue in the second note: http://support.microsoft.com/kb/190351/en-us

So flushing the C I/O streams is the solution:
  
    print-1 "int %d" 1
    flush-file null
    print "hello"

works fine.

A long-term solution could be to disable buffering of C's stdout 
stream, using a call to setvbuf(). It requires passing a stream pointer, 
so I am not sure this is doable now.

The issue is that PRINT and PRIN use syscalls directly, and thus 
don't go through the buffering that the C library does on all I/O

In particular, the standard I/O streams stdin and stdout are line 
buffered. Flushing them is often more forceful than necessary: the 
same effect is achieved by printing a newline

Also, when doing an input-line on Linux, stdout is flushed automatically, 
so you can print a question with a prompt directly behind it

On Windows, every print operation seems to be flushed automatically. 
I haven't seen it ordered incorrectly when intermixed with the Red 
syscalls functions

The differing behaviour is indeed very confusing, but I don't think 
the proper solution is to disable buffering. In my opinion, when 
Red uses the C library, PRINT and PRIN should also go through it

NULL can't be used any more as the return value for a function that 
normally returns a pointer: