World: r3wp

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

For what it's worth, I just implemented a print-newline because that's 
easier and more efficient than PRIN NEWLINE

The 0MQ binding now works on Linux for the first time. I'm quite 
happy with that :-)

Cool! :-)

I've converted the library functions to pass opaque binary messages 
(byte-ptr!) now, as do the R3 and R2 bindings

The examples are now responsible for converting from and to strings 
(so the Red examples are not compatible with the current R3 and R2 
examples)

I am installing FreeBSD8.2 on Vmware to test Red...Wow, it is like 
trying to install Linux in 1996...I am really surprized, I wasn't 
expecting an Ubuntu-like installer, but at least a decent package 
manager...Here's my attempt at installing git:

# pkg_add -r git
Fetching ...
...
# git
git: Command not found.

Great!

Btw, network configuration is not done by default, you need to activate 
it manually....seriously, in 2011?

FreeBSD's main principle is to never update the installer ;-)

You'd probably be much better off with PC-BSD or Desktop-BSD

http://www.pcbsd.org

Thanks, didn't know about those BSD variants.

I managed to get git running. Let see if I can get Red sources.

Hmm, I guess there is no chance to make REBOL/View run on FreeBSD 
without X...

Nope. I guess you have a console system now?