World: r3wp

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.

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..