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.

I just tried:

do to-rebol-file "L:\some\path\here\test.r"


and everything went OK, Win Vista here. Console is being launched 
form the shortcut on start bar, pointing to renamed to rebol.exe

note: the reason I used to-rebol-path was, that directory names contained 
spaces ....

can anyone explain a single use for this R2 path conversion?

>> to-string first [path/item]
== "pathitem"


I know I can use mold... it's just that I wonder why to-string doesn't 
use the molded string equivalent as well?

Something inconsistent in the way paths are handled:
    to-string load "path/item"
    == "pathitem"
     to-string to-path "path/item"
     "path/item"

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.

My observation is, that if there are one or more dependant DLLs, 
REBOL will load first one, but then the path is somehow not taking 
into account a present directory. Here's few pointns:

- you can't do: do %my-dir/my-dll-script.r
- nor you can do so after: change-dir 


But it works, when you launch REBOL from the directory where those 
DLLs are present.

- Added native function: TRY
- Added set-path! notation to set values in structs (POKE)
- Added support for: to string! handle
- Added context: system/words
- Added helper function: ROUTINE
- Added mold support for routines (SOURCE)
- Added debugging function: ??
- Bugfixes

And the culprit - the licence - the old song .... RT's path ...

http://issue.cc/r3/1477- however, the slash-words can have neither 
the refinement-syntax nor the path-syntax; because of that they remain 
"problematic" anyway

>> hh/
** Syntax Error: Invalid path -- hh/
** Near: (line 1) hh/

Yes, but that is not a problem for the word, it is an invalid path

yes, load "aaaa/" reports an "invalid path". However, the word is 
valid.

but I think it should be detected inside the path-syntax not in the 
word-syntax or not ?

Actually, inside the path-syntax you need to detect the word...

that is not a valid path, but this one is:

>> type? second load "a/1.2.3/b"
== tuple!

The tuple *is* valid, what is invalid is just the path in your example

no, it makes the PATH invalid.

it may be valid but it has nothing to do with a path anymore

path-syntax shall be something like path-syntax: [word-syntax some 
[#"/" value-syntax]]

yep.  so the above is not a path   :-)   its a tuple, followed by 
a refinement.

Argh sorry
>> [a/1.2.3/a]
== [a/1.2.3/a]
valid path

I still think there is a problem with that form [aaa/]

It will be checked like 2 separate valid words although it's an invalid 
path

path! set-path! lit-path!

no, afaik,  just paren!, word and its own additional format quirks. 
    as the global block definition expacts, so too will parens, and 
thus the path.

yeah, just have to find the values which are valid in a path (not 
all types are valid, at least in R2)

tag! yes, string! no.   for example:

>> block: [55 "abc" [test] <tag> [test]]
== [55 "abc" [test] <tag> [test2]]
>> block/"abc"
** Syntax Error: Invalid path -- block/
** Near: (line 1) block/"abc"
>> block/("abc")
== [test]
>> block/<tag>
== [test2]