World: r3wp

playing again the history of one to two weeks

 means I process all messages of that period in the same order and 
 send them to a dummy receiver.

Of course, there is some non reproducibility regarding the time axis, 
as this takes around three to four hours compared with two weeks 
in reality and more processes running at the same time on the production 
server.

On the production server the crash happened in reality with less 
messages two times during a period of  around two hours.


The crash happens not always at the same message. This can depend 
of the time behaviour or that the data, that are retrieved from the 
ODBC source is from a live DB, with many inserts, updates and deletes.

Without ODBC the crash did not happen.

Perhaps you can send the same message 2000 times to see if the content 
of the messages makes any difference.

And just do some minimal ODBC activity to see if that still triggers 
it.

Ok, submitted a ticket for the DLL callback crash "root block overflow", 
I mentioned a few days ago. (Gabriele, sorry, first I submitted an 
empty one).

Carl will need to delete that.

I've just noticed a new global word PATH existing since View 1.2.10, 
an undocumented function.

It doesn't seem to do much that is useful..

i think it's an internal function that is being exposed by error. 
(i think the newer betas lack the code to unset internal words like 
native, path, or even set-browser-path)

Is it worth a ticket ?

my guess is that native is used to define the natives coming from 
components, and path is probably used somehow in path evaluation 
(though i have no idea why it should exist as an accessible function, 
maybe it is related to components initialization too)

not sure, a reminder is never bad, though i guess Carl is aware of 
this.

Probably it's better to wait for betas closer to a full release.

I just uncovered this while working on that JumpField over in the 
View group...

>> print compress {A: #"^M"
{    switch A [
{    #"^M" [print {A}]
{    ]
{    }
#{
789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
1D6B63B962B900B34009D526000000
}
>> do decompress #{

{    789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
{    1D6B63B962B900B34009D526000000
{    }
** Syntax Error: Invalid char -- #"
** Near: (line 1) A: #"
>> print decompress #{

{    789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
{    1D6B63B962B900B34009D526000000
{    }
: #
switch A [
 [print {A}]
]

>>

The error reduces to:
>> load {#"^M"}
** Syntax Error: Invalid char -- #"
** Near: (line 1) #"

Here's another one:

>> load {#"^J"}
** Syntax Error: Invalid char -- #"
** Near: (line 1) #"

(DO first tries to LOAD the decompressed string.)

The decompressed string was identical to the original string. The 
compression/decompression has nothing to do with it. The problem 
is in loading a string of code copied straight from an editor or 
somewhere. If that code had been MOLDed first it would have been 
OK.
>> mold #"^M"

== {#"^^M"}        ;<--------- note the double escape, this string 
loads properly.

I think rebol doesn't load #"^M" and #"^J" because they are CR (ascii 
13) and LF (ascii 10).  In rebol, these are molded to #"^M" and #"^/".....

.... mmm that may explain LF because it has an alternate representation 
#"^/", which is by default molded by rebol, but that doesn't explain 
#"^M"...  Anyway, it seems to be a bug. I vaguely remember it was 
found before.

^M and ^J are newline characters. The syntax of REBOL doesn't allow 
direct newline characters in strings surrounded by " characters. 
In the example you use, the string is read twice - first in the console, 
and then next in the load. Each time the string is read it is unescaped 
(the effects of the ^ char is applied). Since you are unescaping 
twice, you need two ^ characters, the first to escape the second.

Not an error, sorry.

yesp, it's not a bug as Brian says.

Just an unusual handling because of the way I copy/pasted it..

If you are using /View, try reading from clipboard:// rather than 
pasting - no escaping will happen then.

^M and ^J (in causing the load error) are exceptional in the alphabet 
of A  - Z.  For example:
	>> load {#"^A"}
	== #"^A"

None of the rest require double-escaping. I am trying to think of 
the reason why rebol treats the newline characters differently.

anton: that's not a suprise

>> {#"^A"}
== {#"^A"}
>> {#"^/"}
== {#"
}

see the difference?

the closing " is on a different line. that causes an error.

see also:

>> load {#"^""}
** Syntax Error: Invalid string -- "
** Near: (line 1) #"""

anothe way to look at it is to look at the binary representation:

>> as-binary {#"^A"}
== #{23220122}
>> as-binary {#"^/"}
== #{23220A22}

{#"^/"} - then char-molding is buggy?

is it?

>> mold newline
== {#"^^/"}

i really don't think so :)

Peter: about your ticket -211 about GET... GET has nothing to do 
with that :)

>> print :source
?function?

that's the difference between FORM and MOLD:

>> form :source
== "?function?"
>> mold :source
== {func [
    "Prints the source code for a word."
    'word [word!]
][
    prin join word ": "
    if not value? word [print "u...

oh, misreaded your {#"^/"}. thare are string-parens around.. you 
are right :)

what do you think about http://www.rebol.net/cgi-bin/rambo.r?id=3363&

a number of bugs have been fixed. please check out the "Waiting for 
testing" tickets to see if you favorite bug has been fixed, so that 
you can test it and we can switch to tested. :)

3130 Bug: On Linux, CALL interferes with TCP port wakeup, 3159 Bug: 
Linux: system port interferes with TCP ports

using it for some hours to do remote calls thru tcp, works. did not 
work with older rebol. IMO fixed.

3326 Bug: CALL should accept file! datatype
does it now (linux)

3576 Bug: browse doesnt open web browser (Linux)
and 3455 are the same.

Is there a way to see only the rambo entries one has made ?  I am 
"guest" and hope no body else was guest !

graham: i don't think you can search by submitter currently.

Pity .. I was wondering what the status of my submissions was.

Bug #3099: looks much better although I noticed this:
>> to-integer -2147483648.0
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value