World: r3wp

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?

Yes.

Installing X and everything on top manually is a cherished exercise 
on the way to enlightenment :-)

I did such installation several times, manually configuring everything, 
last time was in 1997. An OS requiring me to do that in 2011 is a 
joke.