World: r3wp

All I want to do is smooth it out, so sparing others these surprising 
error messages.

Anyway, now I should try to sink my ship; I don't think adding the 
above functionality (of load-path above) to LOAD would slow things 
down at all. But maybe there are some cases where such allowances 
would cause problems. I am thinking if such a loaded path was converted 
to a block, molded, then loaded again, it would cause the error then. 
That's just moving the load error - from the path to the block. I 
think this contrived case would not occur very often - less than 
using new path notation.

I need someone else to chime in here with any scenario which would 
cause a problem using this path notation, because I don't currently 
see any serious problems with it.

that could be solvable: convert the part to a string (or file). block 
then has a string. if you do to-path block, you get dir/"042", but 
that should be ok (with new pathes). its not more "buggy" than making 
42 from 042 IMHO. would be nice to get this, and pathes ending with 
"/" :)

Yes, ending with slash, too. Solve two issues at once.

i think that paths were and are not intended for file paths. that's 
what file! is about.

IMHO, Paths were definitely meant to be able to files you just have 
to realize that you are dealing with a path not a file datatype.

they CAN be used for file paths too but their PURPOSE is not that 
of being used for file paths :)

so, i don't really see where's the problem in using a file! instead 
of a word when a component is not a valid word

Their purpose is to simplify the referencing of values and since 
files are just values that are stored on disk then I'm sure it was 
intended to work that way. ;-)

but of course this is just MHO

Ah, so we are arguing the same point then. ;-)

i'm against adding special rules for paths, not against using paths 
with file values :)

Dido

IIRC in the bbs-project Carl prefered [data-file: dir/file] over 
[data-file: join dir file]. i prefer that too, but currently no "/", 
so [data-dir: dirize dir/file], ugly IMHO.. And now comes changing 
file-names when they are numbers. thats a bit risky to me.

The advantage of using dir/:file is that if dir has no ending /, 
it will be added.  JOIN does not have that feature.

Literal filenames within paths are a bit of an exception -- the standard 
method should be to use % or " around them.

Eg: dir/"123.txt"  or dir/%123.txt

Well, I'm sticking to my guns - I have some supporters, and the opposition 
is weak :) so I'm making a rambo ticket.

I've just noticed this:

o: make object! [type: 'face]
third o
; == [type: face]  ; <---- should be a lit-word!   ?

type? 'face == word!

because 'face gets evaluated.

Ah yes...

third face
;== [type: face .....

I guess I'm just pointing out the difference between THIRD and MOLD 
again.

(I wanted to clone FACE without the TYPE attribute)

OK, submitted a ticket "Load paths in a more relaxed manner".

Gabriele: sorry, can you add to the ticket  {refer also to existing 
ticket "Allow final slash on path - eg. 'hello/" http://www.rebol.net/cgi-bin/rambo.r?id=3637&}

callback

crash: "Root block overflow"

DLLIMPORT void test_callback(
	void (*pFunc)()
){
	pFunc();
}

loop 7  [
	test-callback: make routine! [
		c [callback! []]
	] lib "test_callback"
]

Open the library, make the routine 7 times, crash guaranteed on my 
system.

That as infinite loop isn't it. Why will this be an error? I am not 
sure rebol can catch that problem.

There is a limit on the number of callbacks available I think is 
16.

Not infinite loop, the function hasn't even been called yet. Only 
in routine making stage.

The limit maybe lower.

Other types of routines can be made thousands of times with no problem.

If one of the arguments is of type callback! then say hello to crash-land.

That is because rebol can only have maximum number of callbacks. 
It is a design decision.

I note that 7 is less than 16.

and it should not crash either.

Yes. It shouldn't crash. Post it to RAMBO.

Ok, probably tomorrow. Perhaps someone else has some comments. I 
simplified yet further to remove the    pFunc();    call.

How safe is catch?
	

I have some rebol applications serving message communication (around 
1000 to 2000 messages per day mostly) running for more than half 
a year on Windows2000 Server without interruption since the last 
update of the OS for security reasons.

Recently I had to add some message splitting:
one-message -->  [message-part-1 message-part-2 message-part-3]

I used a construct similar to this

forever [
	until [new-messages-available]
	foreach message new-messages [
		catch [
			if not important [throw]

   do-some-heavy-message-processing-and data-completion-using-odbc
			if some-tests [throw]
			message-parts: split-messages message
			until [
				catch [
					message: first message-parts
					do-more-conversions
					if other-tests [throw]
					deliver message
					emtpy? message-parts: next message-parts
				]
			]
		]
	]
]

Now I saw two crashes in one day.
I was somehow able to reproduce the crash 
Invalid data type during recycle
 

by playing again the history of one to two weeks. But the crash happened 
always processing another message.

As I had seen in the past instable behaviour with constructs like 
this
foreach ... [
	catch [
		..
		data: any [
			a
			b
			throw
		]
		..
		..
	]
]

I replaced the inner catch with statements like this
		if not other-tests [
			deliver message
		] 
and the crash went away.


Now I am curious if someone else encountered the same behaviour too?

I don't know, but if you have found instability there that would 
be a great bug report !!

By saying "by playing again the history of one to two weeks", do 
you mean that this removes all the network activity ? Is ODBC removed 
too ?
Is the crash always on the same message ?

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.