World: r3wp

on linux:
!>load probe mold load "1e-50"
1E-50.0
** Syntax Error: Invalid decimal -- 1E-50.0
** Near: (line 1) 1E-50.0

makes problems with prebol and friends

Doesn't do that on windows -- so definitely a cross-platform problem.

posted it to rambo

;Rebol is gong into limbo with this code. I don't think it should 
happen.
parse {my infinte parse loop} [any [string!]]

The interpreter stops respondin and start consuming a lot of cpu 
cycles.

Don't know about regular apps, but in the console I can interrupt 
that with the Escape key (as of 1.3)

whoa - doesn't let go of the memory, though. I ended up getting a 
Virtual Memory warning from Windows after doing that a few times. 
Memory consumption went down as soon as I quit the Rebol console.

Is there any knowledge when the Problem with open/direct will be 
fixed or what prio this has at RT? I already asked in the Mailinglist 
but got no answer. There was only mentioned that in one Beta it might 
be fixed.  The thing that i always don't understand with Software 
vendors of all kinds is that they always focus more on new features 
than on stability and perfectly working already built in features

RT is re-prioritizing things as they go, because the community will 
get excited about certain things, so it's good go consider putting 
a little time in on those. Other tasks have larger implications and 
take a lot of time to design and code. The /direct issue is a good 
example because they don't want to break file handling code (which 
is used in *many* scripts), nor do they want to just dump in a quick 
change and make matters worse in the long run.

What about a new refinement /stream and keeping /direct for backward-compatibility? 
And the old protocols are source, one could add an option to enable 
them. Would then be a small change to get scripts running again, 
until the bigger one of some rewriting is done.

So, understanding you correctly , there was a time when open/direct 
worked?  I need this to get access to large files without the system 
trying to load it completely into memory/buffering it. Without this 
option there is no way for me to use REBOL for my problem. I don't 
understand where the compatibility problem should be. Open/direct 
is defined to get non buffered access to ports. Was this different 
in the past?  As you say there are scritps where this feature is 
used, so there must be a version where this worked or was it used 
with the wrong behaviour ?. If so, i understand why there is a discussion 
to change the behaviour. But then the definition of open/direct should 
be changed and a new refinement be implemented which gives you the 
possibility to take advantage of non buffered port access. 


I know the community needs new features, not only for marketing purposes, 
but often enough i really don't understand how a priority is set. 
I know, it is not my business to decide such things. I am only a 
person interested in REBOLS future.

Thorsten, I just quickly tested with

 port: open/direct/skip %user.r 3 probe copy/part port 20 close port

and found View beta versions 1.2.54.3.1 thru to 1.2.57.3.1e  do the 
skip correctly. Those versions are the ones with the async core, 
which was found not to be quite stable enough, and it was removed 
for the next beta version, View 1.2.100.3.1

I was just amazed the open/direct didn' t return anything in View 
1.3.1 not even an error. Thanks to this hint. I Think i try one of 
these to keep up development, hoping there will be a fix or new solution 
in one of next releases. Perhaps it will be in the near future ;-)

I hope so too. It's a good bet it will work the same way in future 
versions, when it will be added again.

I would try to get 1.2.57.3.1e, it being the last in that set of 
versions.

the alpha also has /seek.

also, it's not that /direct does not work; it does, always has, in 
that it does not buffer. the problem is that it does not allow seeking, 
i.e. it only allows sequential access. so you can open a 2GB file, 
as long as you read it sequentially.

Where does the 2GB limitationcomes from??

32bit-integers.

Btw, would it help to have a native dll for file-access until rebol 
is smarter? should not be that hard.

That should certainly work Volker. If I had the need under Windows, 
that's what I would do. So far I've been able to live without it.

I am considering adding this wish to RAMBO:

Add EVENT/ENTRY-FACE (or EVENT/WINDOW), which will store

the top-level window face which is the entry point for host os events.
So EVENT/FACE is then free to be set to the face that is the
target of the event, as it was originally intended to be.


OR, instead of the above, and achieving backwards compatibility, 
you could:

Add EVENT/TARGET-FACE, which stores the target face.
(So EVENT/FACE stays as it is.)

any comments ?

I think it should be quite useful in wake-event to know which face 
an event will go to. Filtering possibilities increase.

even/face would be enough, no?

ah, I should read first what you actually suggest, sorry :-)

Two new bugs discovered originally by Cyphre posted:

	load {#object! [...]} bug

and

    VALUE? crashes the interpreter

to the VALUE? crash: the following code crashes too:


    x: bind make block! {error? try [any-type? get/any 'variable]} 'system
    do x

to #3885

It might be useful to add the info, that

    f: does [g print "version 1"]
    g: does [unset 'f recycle]
    do :f

circumvents the crash

OT: Is the RAMBO script somewhere accessible?

I don't think it has been released.

I agree.

do you guys think someone could look into #3822 red-icons related 
bug? I think that we should close that issue once and for all. The 
test case is very clearly described. It is either bug in REBOL or 
in Windows, but if not solved, timestamping is not reliable with 
REBOL in any way ...

Didn't Carl say red icons was now history?

no, I do not remember it .... I openly flamed his blog article, as 
it was really rudiculous ;-) He stated it no more appears on his 
machine, so the problem is solved ;-) But other ppl including me 
identified the problem exists even with WindowsXP for us ....

Doesn't it also occur with Linux?

Or, is it a specific Windows bug?

dunno, really - I tried that on linux and it did not appeared. The 
difference is only in one thing - you let os pass time-switch point, 
or you skip it. In linux, when you report time in console, you can 
see one other letter, which signals you if time shift is accounted 
for or not, but dunno how it is with Windows ...

#3885, #3895, #3896 and speed of 1.3.2 beta OK, passed all my tests

1.3.2 beta? I had to miss that one :-)

bad name - the official name is 1.3.1d

is there a list of fixes/additions somewhere? Or can I query RAMBO 
somehow to show me what tickets were done for certain version?

I think, that the tickets are the ones I listed above

search for "1.3.2"

I want timestamp bug resorted :-)

and don't even dare releasing new View without fixing rebol.exe -i 
script.r (launching desktop, ignoring -i) :-)) ... because then rebol.exe 
can't be used for batch processing on machines, where you simply 
don't go via manual installation process ....

Bug #3873 isn't a bug. REBOL does nesting of { and } when strings 
are specified with {}, and ignores { and } when strings are specified 
with "". The ^ is unnecessary in "{^}" because the } doesn't need 
escaping. The ^ is a syntax error in {{^}} because the } would already 
be escaped by the first { inside the string (the second overall), 
so escaping it again means that the string is never finished, as 
there must be one unescaped } after every unescaped { because of 
nesting. In both cases you either shouldn't put the ^ ( "{}" or {{}} 
), or should escape the ^ if you want it in the resulting string 
( "{^^}" or {{^^}} ). Sorry if that was a little confusing - I'm 
sure someone else can explain it better.

with all respect on I completely disagree.

1) I am not able to understand, why {^{} is a syntax error

2) I completely disagree, that Rebol should check pairs of {} inside 
a string - I do want to be able to handle strings with arbitrary 
contents