World: r3wp

hm.. I can reproduce it... and it must be GC related, because when 
I set recycle/off, the result is correct

But it's possible, that it's my extension which is the reason.. I 
guess. How much safe is creation binaries from C level and passing 
them to REBOL?

Hm... now I 've got System Error #1301: invalid datatype 176

with recycle/off it's fine... it must be related to my extensions.

sounds like a memory corruption problem

Creating and returning binaries is supposed to be safe if you do 
it in one go

Is there any place in your extension where you create more than one 
series in one command?

Is there any place in your extension where series are passed between 
commands and are supposed to survive between calls?

The act of processing large data may very well trigger such a vulnerability, 
because otherwise no garbage collection would happen to be done

Is this a known bug?

>> 2**3
** Syntax error: invalid "integer" -- "2**3"
** Near: (line 1) 2**3

Is this a known bug?

>> 2**3
** Syntax error: invalid "integer" -- "2**3"
** Near: (line 1) 2**3

Robert - spaces?

2**3 vs 2  ** 3?

:-)

Ah... ;-) To much c-coding. And there I don't use spaces that much.

REBOL3 A111 release coming - http://www.rebol.com/r3/changes.html

A111 binary downloads now available for Win32, Linux, OSX:
http://www.rebol.com/r3/downloads.html

(Along with a new Linux binary variant, 4.4, "libc6-2-11-x86".)

a very important point is that this version (exe + dll from Carl) 
is compatible with the RMA R3-gui

what does it mean, compatible, though?

presumably runs the gui

according to Carl :

The most current graphics library changes have been included. Many 
thanks to Cyphre and the RMA project.
Beforehand, it was better to use the RMA compiled host-kit
I also have seen that some bugs disappeared.

Is there a reason for R3's GET being more permissive that R2's?
All these return the value in R3.....In R2 they cause errors:
   get string!
   get :binary!
   get []
   get "xxx"

It seems to extend to all other types as well. It looks intentional.

Carl asks:


this week tried building libr3.so on PPC ... but there is a problem, 
the compiler is too old.

I tried updating gcc, but all the apt-get 
links are too old, and  it failed.   I'm looking for a ppc compiler 
>= 3.4, if you know where one is archived.

osx ppc?

apt-get sounds more like linux ppc.

I'll try to see if Carl can come in here to solve the issue.

tell him to fix his apt sources list to use archive.debian.org urls

that'll get his "apt-get links" working again

if there's any chance to get at a (i assume gcc) compiler >= 3.4 
depends on how old a distro he is using

(-> moving to Linux)

He got it working on Gentoo.

This may just be a variant of CC#1506.....But why does this throw 
an error:
    do [print 222 break]
    222
    ** Throw error: no loop to break

While this does not?
    also true do [print 222 break]
    222
    == true

That's http://issue.cc/r3/1509

It is definitely not #1506, though the behavior of the first example 
was complained about in that ticket.

The behavior in the first example is arguably correct, but let's 
not rehash that argument. See #1506 for details.

As Andreas said in another group, /wait works with CALL under Windows, 
but there is no /output refinement yet. I believe RT is hoping for 
outside help on CALL for R3 due to its complexity under R2. I don't 
know if there's a bounty for it or not.

there were some bounties for some R3 related stuff, but I don't remember 
if it was for CALL, most probably not ...

No bounties offered by RT though

Carl did offer to provide the ODBC sources but that has not happened 
either

You have a R2 implementation of CALL for Windows here: http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/misc/call.r


Shouldn't be difficult to port it to C and extend the existing R3's 
CALL implementation to support /output, /input and /error.

Too bad about /wait not being optional there. Is that a solvable 
problem?

This is the non-blocking version: http://softinnov.org/rebol/acall.shtml

The issue with this async CALL is that it's not possible to make 
user events in R2's event loop, so it's relying on a dirty port hack 
and a bit of busy looping IIRC.

I was thinking of fire and forget, but that was my next question.

Async call, and async in general, is a lot easier in R3. I would 
be quite interested in an async call port in R3, particularly when 
we start to get port plumbing.

From a quick glance at Cheyene's call.r, enabling /wait should be 
rather simple: don't enter the final UNTIL loop unless WAIT (or OUTPUT, 
or ERROR) is set.

I think you could also get rid of the until loop completely, by using 
WaitForSingleObject to wait for process termination. Which is exactly 
how the current win32 hostkit does it, btw.

but then, you probably couldn't in cheyenne, as it will block everything 
else.