AltME groups: search

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.

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

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

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

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.

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.

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

But REBOL users might find it a bit misleading.

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

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

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

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

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!

Nope. I guess you have a console system now?

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.

You do realise you've downloaded a server OS? The real joke is REBOL/Core

It's still a favourite bragging exercise in very popular Linux distributions

I might have already lost a few potential users just because of that.

Yeah, we've had one paranoid tell us he wouldn't install AltME because 
it's a binary :-/

Null is not a replacement for function!.

That is to say; if a C function has a fixed parameter list, can it 
be called with fewer arguments?

You should make 2 bindings, one with function!, other with handle! 
(for passing Null). And a wrapper function for the latter one, to 
make it cleaner for the user.

I will look into the compiler internal error tomorrow, it needs a 
fix anyway.

Will you implement it, or add a warning?

For example, if you encode the arguments number as the first value 
pushed on stack, you can pass a variable number of argument. The 
called function needs, of course,  to use the same convention.

freebsd with libc requires a bit more work

Using Syllable as a development workstation for FreeBSD would be 
a cool feature :-)

well, i could hardcode a hack in the ELF emitter

A Red-generated FreeBSD binary: http://bolka.at/2011/tmp/hello-fbsd.bin
:)

Will merge it to main branch in a few minutes.

(Must write a cheer bot one of these days)

Silly question (I'm not in the loop), why was View necessary? Feel 
free to point to a blog post or something that explains it.

for example a struct of an 8-bit char! and a 32-bit integer! takes 
up not 40-bits but actually 64-bits in size (due to alignment constraints, 
in this case).

so this is one of the challenges that are required to solve, when 
creating a new binary emitter?

when writing a new emitter, the "challenge" is mostly the rather 
tedious task os transliterating C structs into REBOL struct!s

Have a look at the current ELF/PE emitters, for example:

https://github.com/dockimbel/Red/blob/master/red-system/formats/ELF.r#L87

https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L145

Getting /Core to run on FreeBSD looks like a real challenge :-)

Yes, but it requires me to install a lot of stuff...The real issue 
is that /Core is built on obsolete libraries version.

Can you push a fix for that? (I'm cooking at the same time)

Have you pushed your BSD-specific ELF fixes or does it require a 
proper target config?

that just hardcoded freebsd-specifics, so would have broke linux 
in that form. only a quick experiment to see what's really necessary

Could you parametrized those BSD-specific changes with a compiler 
option?

Kaj: Null allowed as a function! argument. The changes was very trivial, 
but I tested only if it compiled.

That would be good for the public. Myself, I would probably keep 
updating from trunk. I'm running a Git download through my Syllable 
build system to install a new version

Added a bunch of convenience wrappers to the 0MQ binding, to make 
functions more Red/REBOL like

Bytes don't require alignment, 32-bit values do. In message!, vsm-data1 
is aligned on a 32-bit boundary, leaving a 2-bytes hole after vsm-size.

It solves the problem that you don't know how to write a cast because 
in for example

handle! is a #define

Assignments can't be used inside an expression, nor can functions 
that don't have a return value.

Red/System is not meant to be a REBOL replacement, you will need 
to wait for Red.

Red/System cannot be a REBOL replacement, it doesn't live at the 
same level of abstraction.

I know, but this one is very doable. I guess it would be a nice project 
for Brian

I could remove the compiler check, so that your code "might" compile, 
but that opens a hole for several others issues.

assignements don't return a value in Red ? 
It should be doable without pain.

There is a possible evolution documented in the specification for 
that, allowing also multi-assignments as a side-effect.

a cool side effect

I mean writing wrappers for low-level ZMQ imported functions, so 
that they return consistent values. For example, RECEIVE should return 
a message! or null, but not a 0 that needs to be casted to logic!.

I just mean findind a way to catch those 0 values transparently.

Here a code example of how you could solve that:
	msg: receive ....
  	if zmq-error? [...process error...]


zmq-error? could just check a flag set by last zmq low-level calls.

Such constructs would make the binding a lot more high level and 
would require a lot more code. I'm trying to keep complexity down 
for simplicity and performance

The added code won't make any significant overhead in performances 
for a network communication library, the slow parts are the network 
exchanges.

We don't have goto and longjumps, either, so there's little leeway 
for implementing a transparent error trapping framework

If you want the function to return a logic! status and a result to 
be able to handle it locally, the result needs to fetched through 
a pointer, which also raises complexity. We can't handle addresses 
very well yet, either, because get-words only work for native functions

My point was: don't return a logic! statut from functions like RECEIVE, 
rather set a flag and check it after RECEIVE call.

Yeah right, I was confused by your will to return a logic!.

By the way, 0MQ is not a network communication library per se. It 
can do messaging equally well between processes and even threads, 
so wrapper performance is significant

Regression from a recent change, you should get a compilation error 
saying that x is missing a return value.

In this case, I don't need EITHER to return a value

Ok, so sounds like a check that shouldn't happen in such case.

It is more a matter of tracking than discussing.

I understand; it's just a rotten situation that the communication 
isn't integrated

Ah, the unintegratedness begins. When I type >> in GitHub to denote 
a REBOL result prompt, it interprets it as indent markup

If you had told me twenty years ago that I would be writing prose 
such as "Local logic! in prin-int leaks as global function!", I would 
have seen it as a sure sign of dementia

Kaj: thanks for the reports. I was aware of NOT issue and already 
encountered the local name clash, but never got the time to isolate 
it. Fixing them now, before going beta, is a good timing.

Red/System will go beta as soon as I:
- fix the remaining bugs from the tracker,

- decide on 2 last syntax issues discussed on the ML (concerning 
struct/pointer literal syntax and aliases)
- make a pass on the specification to fix/update/complete it.

I said "base natives", so not a whole REBOL reimplementation.

Yes, I know a few potential Red/System testers that are waiting for 
that too.

Right, I wanted to make a direct native compilation for Red too, 
but emitting Red/System might be shorter way to reach the goal.

As Red/System is a dialect of Red, the compilation should be quite 
easy to achieve.

No problem, it's just a note about the state, and it's ready for 
the solution

Message holders don't leak memory anymore, but now the payload of 
sent messages leaks, due to what seems to be a bug in callbacks. 
More in the tracker

Kaj: good to know that you working on improving the 0MQ binding. 
I will have a look on the callback issue.

Works fine on Windows, so it looks like a Linux-specific issue...

I think that's a good thing, but it may still be wise to postpone 
the implementation. Having Red will enable more people to contribute, 
but on the other hand, the lack of floating point is blocking a few 
contributors now

Floating point support should be added to Red/System if my tests 
shows that I can safely do the Red->Red/System compilation, else 
it will be supported at Red level. Anyway, it is not a priority for 
me, so it probably won't be added before Q4 2010 (unless someone 
wants to contribute by adding it to Red/System).

Andreas did a great debugging work on that.

That seems like a nice shortcut, then

If you use a variable, you need to pass thru the registers.

I've started working on a cURL binding. It can print the cURL version 
now :-)

I could call it a port from the R3 binding, but it will be more like 
a rewrite

Great to know you are working on a new binding. Let me know when 
you will put it online, so I can add a link from red-lang.org.

Ah, yes, because it will be a binding for Red, even though the binding 
is written in Red/System

Since R3 bindings are written in C, their level is comparable to 
a binding in Red/System. But the dynamics are quite different, that's 
what I meant

Hm, a cURL progress callback needs floats. It's pretty limiting if 
you can't get progress feedback