World: r3wp

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:

Compiling /users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
...
*** Compilation Error: wrong return type in function: receive 
*** expected: [message!], found: [none] 

*** in file: %/users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
*** in function: receive
*** at:  []

It is caused by NULL clashing with EITHER return type static analysis. 
I am giving NULL an any-pointer! pseudo-type to solve that.

I have pushed a new commit that should fix your issue.

Works. Thanks again! The 0MQ binding compiles again after some time

About using C functions for printing, is there one that don't interpret 
backslash-escaped characters?

Probably if you use print-1 "%s" STRING, because the second is not 
the format string

Actually, I've already had print-1 "\n" ... print "\n" instead of 
newline. Aren't the escapes interpreted at compile time, only in 
literal strings?

Doesn't print-line/puts() work?

print-line prints backslashes as-is

Right, print-line works, I thought that puts() was interpreting C 
escape sequences.

I'd been wondering about it, but you can just write literal strings 
in full REBOL format

By the way, do we want to keep PRIN? My toes curl a little every 
time I see it. I know it's longer, but I would be OK with replacing 
PRIN & PRINT with PRINT & PRINT-LINE - or PRINT/LINE in Red proper

I had a hard time with PRIN at beginning too, but got used to it 
after a few years of practice.

I would probably keep PRINT for printing with an added newline. But 
replacing PRIN is welcome if a better alternative is found.

PRINT/LINE and PRINT-LINE are a bit too long, especially for using 
from the (future Red) console.

You'd probably end up with PUT for PRIN

That's what I was thinking, but PUT is a bit generic verb. OTOH, 
users coming from other languages wouldn't be shocked by PUT used 
in this context.

Yes, it's not great, either. The problem with PRIN is compounded 
in Red/System because now you get prin-int and such

Well, that can be changed to put-*, not a big deal.

Another option could be WRITE, if it is not used latter in Red/System.

But REBOL users might find it a bit misleading.

I suppose READ and WRITE will get a REBOL like implementation?

Yes, but at Red level.

At Red/System level, we might have something like READ-PORT, WRITE-PORT.

With the latest series of Red versions, the 0MQ binding didn't work 
anymore due to crashing on a certain imported function call. This 
is now fixed, probably as a side effect of the last few fixes

Shouldn't newline be a byte/char, as in REBOL? It's a string now

It's for consistency when passed to PRIN/PRINT and avoid requiring 
PRIN-INT.

I would keep PRIN. And instead of PRIN-INT I would like to see FORM.

The problem with FORM is that it implies a new buffer allocation 
that you need to free at some point.

Yes, the C library print functions do that automatically