World: r3wp

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.

rewriting things sometimes helps :-) .... but Carl already stated 
that he would have to have million to start the rewrite :-)

the point is the goal, not the rewriting ;)

the semantics for word values don't need much change IMHO

I think I know what your saying now Gabriele.  That any arg is going 
to be put into system/words?

Once a word is loaded, its in system/words and cant be aliaced anymore 
(HTH)

thats why the alias is a string. Else it would be loaded before 'alias 
is executed.

BTW is somebody using 'alias?

(Not me.)
Paul, go to a fresh console and type
>> hello
and press Enter.
Now you can see it was added to system/words:
>> last first system/words
== hello
So it is now unavailable to be used as an alias.
>> alias 'print "hello"
** Script Error: Alias word is already in use: hello
** Near: alias 'print "hello"

(Submitted my bug above to RAMBO.)

Apparently REBOL doesn't like set-paren!s  http://www.rebol.net/cgi-bin/rambo.r
 This is a really ugly bug that needs fixed ASAP, kills the interpreter 
no questions asked and no information given.

I just found a file that I can READ but not OPEN a port to. This 
bug can be seen on old and new versions of Core 
and View:
>> read %"/j/anton/mp3s/more/test-copy.mp3"

== {ID3^C^@^@^@^@^F^NTMED^@^@^@^D^@^@^@DIGTLEN^@^@^@^G^@^@^@472006TCON^@^@^@^E^@^@^@miscTRCK^@^@^@^B^@^@^@5TALB^@^@^@^\^@^@^@Psych
o...
>> port: open %"/j/anton/mp3s/more/test-copy.mp3"
** Access Error: Cannot open /j/anton/mp3s/more/test-copy.mp3
** Near: port: open %/j/anton/mp3s/more/test-copy.mp3
>> port: open/binary %"/j/anton/mp3s/more/test-copy.mp3"
** Access Error: Cannot open /j/anton/mp3s/more/test-copy.mp3
** Near: port: open/binary %/j/anton/mp3s/more/test-copy.mp3
>> read/binary %"/j/anton/mp3s/more/test-copy.mp3"
== #{
4944330300000000060E544D454400000004000000444947544C454E00000007
00000034373230303654434F4E000000050000006D6973635452434B0000...

Anyone else seen such behaviour ?

I'm on WinXP. I just copied the file to a different volume and it 
can be read there.

(Sorry, I can OPEN it there.)