AltME groups: search

Also try to use the full path. Once I have faced a problem CALL with 
REBOL style file! value. It worked with a windows-style path.

And also have problem with /shell worked on my XP but did not on 
my customers W7.

O*O*n
  == a typo  :-)

I guess I really meant  something like O(n*n) 


Its the kind of dramatic  linear vs logarithmic scaling difference 
when we unfold our datasets into parse.


but its not exactly that kind of scaling, since the average topology 
of the sort tree will have a lot of impact on the end-result.  for 
example in my system, when I try to index more than the first 5 characters, 
the speed gain is so insignificant that the ratio is quickly skewed, 
when compared to the difference which the first 3 letters give.  


Its 100% related to the actual dataset I use.  in some, going past 
2 is already almost useless, in others I will have to go beyond 5 
for sure.  in some other datasets we unfold them using hand-picked 
algorythms per branch of data, and others its a pure, brute force 
huge RAM gobler.

Pekr: Registration (regsvr) is required only if they are ActiveX 
DLLs, but I think they are not because you cannot use ActiveX DLLs 
in REBOL.

Normally they should be somewhere in your PATH. Try to see what's 
happening with FileMon tool from Systeminternals.com.

it also looks in the current-dir... but that path will depend of 
how you launched rebol.


use WHAT-DIR just before you try to load your dll  to know where 
the current-dir is at that time and put your dll there.


you can also add a path in the user or system path environment and 
place the dll there.

Pekr, bool in C is usually of char type so you should try to set 
the returned value in your routine! spec to char.

Cyphre: thanks, will try that ...

let me try again :-)

My last try.
It doesn't work with decimals

If I was doing a full parser I'd try to cut down on the lookahead 
parsing of more than a single character or charset, so as to avoid 
repeating the parsing. Plus, for R3 there's a ticket to improve tag 
syntax that I'd like implemented (single-quote strings in tags). 
For an R2 parser I suppose that an approach that is more tolerant 
of design flaws would be appropriate, since its syntax is in bug-for-bug 
backwards-compatibility mode.

try this in R2
[a<] and [a<  ]

test-syn: func [
	chars [bitset!] sample [string!]
	/local c l t? ci
][
	t?: type? first to-block sample
	repeat i 256 [
		c: replace copy sample "?" ci: to-string to-char i - 1
		if find ci chars [
			if error? l: try [to-block c] [
				l: disarm l
				l: reform [l/id l/arg1 l/arg2]
			]
			if any [1 <> length? l t? <> type? l/1][
					print [i - 1 mold to-char i - 1 mold l attempt [type? l/1]]
			]
		]
	]
]

Ok I try to resume our concern.

The url! and email! syntax is more permissive than a valid URI. It's 
not a problem nor a design flaw.

The escape decoding should not be done at all when decoded as a part 
of an url! or email!. Right, but it will not be corrected until Carl 
does it.

DECODE-URL can be rewritten (used by schemes). The parser is too 
strict and can't deal with complex forms.

I try to resume my thought.
Is it valid to run some code in the rules using (...) ?