World: r3wp

Ok, submitted to RAMBO.

I noticed Rebol/View 1.3.60 and 1.3.61 seem to have a problem making 
routine!s with a callback! arg in them. Anybody else ?

eg.
** Script Error: Invalid argument: callback!
** Near: setErrorHandler: make routine! [
    errorProc [callback! [string! integer! return: [int]]]
    return: [integer!]
] COMLib

The above routine has no problem being made in View 1.3.1.3.1

Cyphre has noticed that too.

Ah, just reading through rambo tickets, looks like this one is fixed 
already for View 1.3.2

:)

note that 1.3.2 is lesser than 1.3.61. ;) A lot of experimental code 
has been removed for the 1.3.2 release. They will be back in 1.4.

When can we expect 1.3.2 and when 1.4 ?

1.3.2 should be very soon. 1.4 i don't know.

So what can we expect from 1.3.2 ? Bugfixes? yes. Rebcode? no. Rebservices? 
don't know. Rich-text? probably no, as we haven't seen this in alphas. 
new datatypes? probably not. Something else? don't know.

kru, probably what you see in RAMBO :-)

Henrik in RAMBO I can see only bugfixes, but no informations on what's 
going to be added (if anything will be added).

rebservices would probably be considered a major change, so maybe 
that won't get in until 1.4.0

It would be great to know when can we expect 1.4.0 . In a month, 
two, half a year...I know that it's hard to predict release date, 
but give us some estimation, please :)

if i would, you'd then quote me on that. :P and anyway, only Carl 
could possibly tell you a date.

OK, I was just trying ;)

Ah no - temporal instability again :)

3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someoneId:	 cant overflow the word-table with 
garbage data. If data-words are added too, someone can.

Yuks, mouselcick to much..

3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someone cant overflow the word-table with garbage 
data. If data-words are added too, someone can.

not adding words to the global table leads to crashes, unless you're 
using them strictly as symbols (which is not the case if you are 
creating objects...)

Crashes or errors?

But yes, the words have to exist in case something in a block wants 
to bind to it. Or it gets complicated.

crashes.

(IIRC that was posted as a bug in RAMBO because there was a crash 
in some case...)

right, Gabriele, there was a crash in BEER when we were transmitting 
objects

anyway, the bugs are fully corrected now, I think

is there new release of Beer?

Hello, we have got a couple of useful changes and improvements. OTOH, 
I don't know, if Jaime sees it as fit for a new release.

A little wish, but I'm unsure if  it's a reasonable idea:


WISH: Include the mezz function 'do-events in ALL rebol products, 
 of course with the exception of  rebol/base


that could made sense since all new products will include rebservices.

and would made the services-code written by the users more compatible 
between all rebol versions.

OT. AFAIR in previews AltMe REBOL worlds, there was a "WISH" group, 
could be created again? or is correct to post wishes in the RAMBO 
group?.

Yes, there is a wish category for rambo submissions. (Be sure to 
also list the reason you wanted it.)

I thought that [ probe system ] hanging rebol got fixed.  I was playing 
with the new 'bind? function and discovered that a word that was 
unbound was returning the system object at which point Taskmanager 
claimed that REBOL was only using about 14MB RAM but killing the 
REBOL process freed up 400MB.  Try this:

use [this][
    that: does [this]
    this: does [print 'this]
]
probe bind? this
probe bind? 'this

>> source do-events
do-events: func [
    "Process all View events."
][
    wait []
]


It's not a big addition, but on the other end, you can easily use 
"wait []" or add 'do-event if not already in the VM you use :

	if not value? 'do-event [do-event: does [wait [ ]]

So your script will be compatible already.

DideC, 

Rigth. do-events is very easy to add. for that reason I have doubts 
if make sense to ask for add it in all products.

Maybe not a bug, but at least inconsistency:>> x: #{0000}
== #{0000}
>> x/1
== 0
>> type? x/1
== integer!
>> x/1: 1
** Script Error: Invalid argument: 1
** Near: x/1: 1

regarding #4000
does not crash here with XP

view layout [
	fld: field "hello" [?? value]
	btn "change" [set-face fld "changed"]
]

1. click in the field and press Enter
2. press "change" button
3. click in the field and press Enter again.
In both cases, VALUE = "hello".

The reason is because ctx-text/edit-text calls the action block, 
but passes face/DATA  (not face/TEXT).

TEXT and DATA are related only at INIT and are not maintained by 
the access functions.

Is this a bug ?

I was making a field validator function, and it was hard to understand 
why VALUE wasn't always equal to face/text.

It does not appear to be in Rambo.

I suppose the work-around is just to use face/text instead of value.

RAMBO it !
Accessors where made a bit to quicky OMO.

field are special case due to password input, and the accessors does 
not managed this well OMO.

Maybe looking to it and proposing correction into RAMBO would help.

I don't agree to the design of accessors at  all - they should be 
more general, taking more arguments - set-face 'attribute value, 
e.g. set-face 'color blue

It was discussed many times, and you are not the only one who think 
like this.

I am still for running facets again.

Anyone else see the problem that I see with 'alias:  http://www.rebol.net/cgi-bin/rambo.r?id=3986&

I'm not saying that it doesn't bind a word to system/words - its 
just my opinion that it shouldn't do so until it correctly ensuring 
the syntax is correct of the alias function

; for example if you do the following improper statement of the alias 
function
alias print "blah"

'; you will get an error message but then after you get the error 
message you will see that it still created 'blah in system/words

it shouldn't do so

 - that would require rewriting REBOL from scratch, and the result 
 would most likely be incompatible with the current REBOL.