AltME groups: search

<from !Cheyenne group>


I'll have a look emitting the executable in the working directory 
this afternoon.

Having the compilation in the working directory would still be nice 
for the release

Compilation in working directory: I'm adding it in the todo list 
for the release.

By the way, it's also about compilation source. If your source is 
in your working directory, you still have to provide the full path

I can start rsc.r from any directory, but then it fails to find the 
source file in that directory

For some odd reason, it does indeed work if I switch manually to 
the directory holding rsc.r

Working directory: sure we can do that.


DO is automatically doing a CD to the argument script's folder, it's 
not the %rsc.r script.

R2 has always been rather nasty with the working directory, fiddling 
with it. I think R3 is better

Ah, so calling rsc.r from someplace else was the trouble.


Isn't that a fundamental problem with the current R2 interpreters? 
I seem to remember that when a script is running the interpreter 
already change-dir'ed to the directory containing the script, thereby 
losing the original working directory.

We need two paths: one for locating red-system/ root directory and 
another one for the working directory.
So:
- system/script/path should give us red-system/ root
- system/options/path should give us working directory

Doc - the SW you suggest for Git is extremly nice, almost like working 
with tablet, but otherwise not much usefull to me. It does not add 
context menu to the shell, so no right click upon the directory. 
I also did not figured out, how should I add red in there? There 
is no place to paste the https://github.com/dockimbel/Red.gitURL 
... I will install back some other git client ...

You'll got it by tomorrow. 


And BTW, the generated Red binary is in the working directory by 
default. ;-)

Two notes:


- when in root directory, where %red.r resides, is there a need to 
specify it in compilation process? do/args %red.r - or do we expect 
more compilers here?


- executable is spilled out into the root too. I would probably use 
the way compatible to red/system, and create /builds subdir?


Or is all above intentional to allow to compile/link from working 
dirs?

I would prefer Red to compile either to the directory, where the 
source is by default or at least not to the system/options/home path, 
but to the path I get with pwd

On Linux, the executable ends up in the directory of the compiler, 
instead of the working directory

I need them to be able to install my Fossil repositories side by 
side in one main directory and then #include between them without 
changing paths

Ah, see, you're mixing up files. The common.reds file in Red has 
nothing to do with my bindings. It also has nothing to do with Windows. 
You should leave that alone and put my bindings in the subdirectories 
I mentioned in a parent directory of your choice

I would like to ask about the architecture of Red. I am looking into 
datatypes directory, e.g. string. Those functions don't have any 
arguments, they seem to work with the stack directly? Strange concept. 
Are those real Red functions? But what I don't understand is e.g. 
'back function, its body contains block/back. Where does "block" 
come from? It is not passed as an argument, so is that any kind of 
system wide value?

Needed 6 programs to do that! Schermafbeelding (screenshot?) to make 
the picture, Spotlight to find it, Imagewell to change tiff to jpg 
Preview to check Finder to put it in the right directory Filezilla 
to transfer Safari to check (clipboard to transfer the url to here)

HI Kaj, I download Your Gtk Bindings and and GLib too, put it in 
red-system directory (it's a write place ?) and I have too problems:

Kaj: I have a problem with #381. I have reconstructed a similar directory 
structure relative to Red/System root folder (on Linux). My issue 
is that #include directives specified from Red or specified from 
embedded Red/System should have the same base folder from the user 
perspective, but that's not the case currently. So, my question is: 
do you see any drawback in fixing this inconsistency? (Also from 
the implementation perspective, it is a nightmare to handle otherwise)

https://github.com/dockimbel/Red/issues/381

The Red directory in my example has nothing to do with the compiler 
tree. It's just the parent directory in which I keep my projects. 
I want include paths to be relative to the source file, not the compiler, 
be it Red or Red/System

I have completed the set of fixes for various path issues for Red. 
They are available from the `fix-issue-277` branch and they should 
cover the following issues:

#251 (Red doesn't find source in working directory)
#252 (#system cannot find #include)

#277 (Include system doesn't handle well files with same name in 
different directories)

#366 (Compilation of code outside of the Red/ path fails under Windows)
#381 (#system-global doesn't detect equal #include paths)


Please let me know if there are remaining path issues to fix before 
merging this branch with master.

Kaj - You can find a rough and ready  red-string! to  c-string! function 
at:


https://github.com/PeterWAWood/Red-System-Libs/blob/master/UTF-8/string-c-string.reds


it #includes the UCS4 character to UTF8 convertor which you will 
need in the same directory as the string-c-string func.

I was in the impression that Red and Red/System scripts should be 
in a directory within the Red dir. Where the other (test)scriots 
are too.

I am now hesitant to put a new zip over the old one and lose my scripts 
(but maybe even that fear is vain).

I´m referring to the normal case of wanting to get the output in 
your working directory. Red does that now, but Red/System not without 
using that switch

I did some compiling today and found the resulting executable in 
the build directory.

Odd, I can´t use ./ paths from the working directory

From a quick look your commit has changed the default for red/system 
so that executablles are now built in the current working directory 
rather than the builds directory.

And w/o an explicit output path, builds are again stored in the builds/ 
directory.

I would still like the default output to be deposited in the working 
directory, instead of the builds directory

@Kaj, The Yen sign has disappeared here! Congratulations! :)

I would still like the default output to be deposited in the working 
directory, instead of the builds directory

 I think I agree with this. In the ideal situation you could specify 
 these things, maybe in a settings file or in a preference in a compilation 
 assisting program. (Started one once)  

The integration of rsc.r within red.r sounds as a logical step. (rsc.r 
Red System Compilation, not so bad and a clear difference from red.r 
for Red scripts)

Doc: "did you encapped Red compiler?" Nope, RedCompiler.exe is just 
calling the rsc.r or red.r according to the extension of given script 
file. It should be placed in the red-master directory.

I tried to make a encapped Red compiler but there are some problems 
with #include or other compiler directives.

I'd like to know what your development environment for Red/System 
is especially that used by Doc.
In the meantime...
	My development environment:
	OS: Windows 7
	Editor: Notepad++ v5.0.3
	  not the latest version but I prefer this one,

   using "Python" as the language for syntax highlithing and coloring

   (there is not a "REBOL" language) and used mainly for the folding 
   on indentation

   (I can not live without folding, and folding on indentation makes 
   life even easier)

   I have added a menu item with a keybord shortcut to run REBOL with 
   the currently shown file as argument.

   I have added also a menu item with a keybord shortcut to run my modified 
   version of REBOL-Word-Browser

 At the end of the r/s file I add these lines (mostly taken from Bruno 
 Anselme):
		#if OS = '???? [{
		REBOL []
		appname: "myprog"

  rs-dir: %../Red-master-0.3.2_Bruno/red-system                ; locate 
  here your red-system directory
		dest: rejoin [what-dir appname ]
		print [ "------ Compiling" appname "------" ]
		do/args rs-dir/rsc.r rejoin ["-o " dest " " dest %.reds ]

		print [ "Destination file:" dest ]
		call/wait/show/console dest
		halt
		;}]

 This way pressing the shortcut I can run REBOL that compiles the 
 program I am writing and than starts the program.
	Any suggestion is welcomed!

ok with me. I had some trouble with the compiler script last time 
I used it. Location of red or rsc compiler is changed by compiler, 
the active directory changes.

open a command prompt, change to the directory the .class is stored 
in, and run `java JNIdemo`

well, you have Rebol installed and linked to .r ..... I am so much 
used to work with Total Commander, that I launch Rebol from icon 
sporadically. The trouble for me, is the path. So from time to time, 
I place kind of empty run.r script in some dir, which serves for 
nothing more, than just pressing enter upon it, and being run in 
particular directory, which means, in certain directory path

and I can find red.r in the main directory. Whne I hit enter, it 
just launches the console. But maybe I am missusing it :-)

I am runing %red.r for %0MQ-request-client.red but failing on 
#include %../common/common.red
It looks like it would be from 
https://github.com/dockimbel/Red.git
but I don't find any common/ directory

I am probably mis-aligning my zmq directories but don't have anything 
but common.reds from clones.
Any hints to help me find my path?

However, as I've explained before, all repositories follow the same 
naming pattern. If a dependency is #included from a common/ directory 
it's in the Red-common repository

There is no way for Red/System to read a directory listing, is there?

Can Red/System read a directory listing?

james & kaj: I have JDK installed too, you should be sure, that you 
can call java, javac from whatever dir = it is in the system lookup 
PATH. And - Rebol was downloading supporting tools, then it hang 
in console, but in fact, there was a dialog box hidden in the background, 
asking me for write permission. Unless you allow that, the tools 
are not going to be saved into requested directory ...

My directory structure is:

build\tools:

\api\android.jar
jli.dll
aapt.exe
keytool.exe
zipalign.exe

The above mentioned script also fails at it tries to make a directory. 
Maybe it needs make-dir/deep %runnable/arm-tests, or simply to remove 
%runnable ....

The needed files can be found in directories like
http://red.esperconsultancy.nl/Red-GTK/timeline
http://red.esperconsultancy.nl/Red-common/timeline
http://red.esperconsultancy.nl/Red-C-library/timeline
http://red.esperconsultancy.nl/Red-GLib/timeline

Atm I do not have an exhaustive overview of these, unfortunately 
the directory listing is not available to the general public.
What file is linking to GLib.reds?

int-to-float causes a error. Or does it? I added some prints and 
inbetween steps
	genrand-real2: func [
		return: [float!] 
		/local result [float!] between [float!] intermediate [integer!]
	][  
	    intermediate: genrand-int32
	    print ["intermediate: " intermediate lf]
		;result: int-to-float genrand-int32
		between: int-to-float intermediate
        print ["between: " between lf]
		result: ((1.0 / 4294967296.0) * between) ;; divided by 2^32 
		return result
	]

ON the second value the program errs:
intermediate: -1734706621
between: -1734706560
-0.40389284491539 intermediate: -1052231088

*** Runtime Error 9: float invalid operation
*** at: 00002033h
logout

When I make my testprogram for user.reds tell me why int-to-float 
behaves like this:
intval: -1052231088
floval: int-to-float intval
print ["intval: " intval " lets floval become: " floval lf]
The output is not a runtime error:
intval: -1052231088 lets floval become: -1052231040

But the print line was not executed in my real program? I only have 
one user.reds file in my directory. Suggestions?

needs to be checked out in the subdirectory "common" for other bindings 
to find it. I use a parent directory Red:

The Red directory may be named differently, but the other bindings 
should also be checked out in it, in subdirectories corresponding 
to their names

Gregg Irwin has rewritten the redcompiler.r script on rebol.org and 
I now added a help screen, a check for a red.r compilerscript in 
the selected directory, support for Red source only compilation, 
the option --red-only Doc recently added. 

You can still find the new script here http://www.rebol.org/view-script.r?script=redcompiler.r

You should be able to compile the test driver with the latest Red/System 
development version, following the normal build procedure but adding 
the following parameter to the Red/System compiler command line:

rsc.r -t WinDRV driver.reds


This effectively replaces a makefile build script that the WDK uses 
that is almost 12,000 lines.


By the way, the WDK is unable to work in a path that contains spaces, 
so for example on older Windows versions such as XP, you can't develop 
drivers in your home directory, because your home path always contains 
spaces. I think Red will now allow you to do that.

We did a new Saphir / R3 Andoid release.

Changes:
-fixed input text renderin bug

-reworked misc internal threads synchronisation issues to fix possible 
dead locks
-added ACTIVE, INACTIVE events
-added horizontal native scrolling for layouts wider than screen
-fixed screen rotation
-updated demo script (just type DEMO in the console)
-fixed BROWSE bug

-added .r3 suffix to be able open this type of R3 scripts automatically
-other smaller internal fixes


If you want to test it on your phone just run the console and type:

do http://development.saphirion.com/experimental/demo.r


ATTENTION: We changed the directory layout a bit. You find the Andoid 
release here:

http://development.saphirion.com/experimental/builds/android

We added other platforms as well:
http://development.saphirion.com/experimental/builds/

And the root is still:
http://development.saphirion.com/experimental/


Next Wednesday I will give a short talk about our porting efforts 
here via Web-Cast:  http://www.vksi.de/sneak-preview/17072013-android-qs.htm
(German)

In conjunction we did a new R3-GUI release as well.


added DETAB flag support
fixed TEXT-AREA issues
fixed TEXT init-size handling
fixed SIZE-TXT bug
built new R3GUI release (version 4897)
delete "experimental" layout-sizing-independent.r3
improve rouding
move docs/r3-gui/ to documentation/r3/r3-gui/

remove documentation/r3/r3-gui/license/ directory containing obsolete 
license
Copyright notice update
license update
typo fixed
Rounding correction
improved rotate event handling

improved drag handling code (removed duplicate gui-events/drag reference)
improved android text input handling
fixed progress resizing
improved text-able cell font handling
fonts are antialiased by default on android now

http://development.saphirion.com/resources/r3-gui.r

Ladislav, it's in the viewtop directory.

GTK is included in the MSDOS directory. Most dependencies for Windows 
are

No installation is needed. The libraries are simply there and are 
used from that directory. The graphical programs can simply be clicked 
on (although they provide extra output in the command line)

But you need the SQLite library from the Red/System directory:

Sqlab, do you have Fossil in the same directory as download.r? The 
script changes directories, so on Windows when Fossil is not really 
installed, this could have the effect of not finding it

Thanks. I've added code to download.r to test if Fossil is in the 
same directory. Can you confirm that this works on Windows?

It does not work.

There is the problem, that what-dir gives the rebol directory path, 
not the windows path.Even using a "to-local-file what-dir .."  does 
not help, as to local-file does not preserve the trailing (back)\slasjh

make directory

Yes, that would be a good reason. In my patches to port Python, for 
example, I solve it by looking if the /system/index/ directory exists, 
which would identify not only Syllable Desktop, but also Syllable 
Server

But I do seem to understand - if I would produce card into PCI slot, 
that would be different situation. Am I right, that under Linux, 
situation is kind of simpler? I have seen some scripts, which blinked 
leds on BeagleBone, by just writing to/reading from particular directory, 
so expect situation under unix systems being kind of - simpler? Or 
once again wrong?

You'd have to modify the WDK to do that. The use case is simply to 
develop a driver in your user directory

zero: charset [ #"0" ]
digit: charset [ #"0" - #"9" ]
digits: [ some digit ]
local-number: charset [ #"3" #"4" #"6" #"9" ]
not01-number: charset [ #"2" - #"9" ]

national-rule: [ zero local-number not01-number digits]
local-rule: [ not01-number digits ]
emergency-rule: [ "111" ]

; toll free numbers are 0800 and 0508
toll-free: [ zero [ "800" | "508" ] digits ]

; directory assistance 018, 0172,
directory-assistance: [ "01" [ "8" | "72" ]]
 
; faults 120, 125 and business 126
faults: [ "12" [ "0" | "5" | "6" ]]

; cellular are 021, 022, 027, 028, 029
cellular-rule: [ "02" digits ]

; international 00 - country code - number
international-rule: [[ "00" | "+" ] digits ]

allowed-phone-rule: [
	local-rule |
	national-rule |
	emergency-rule |
	toll-free |
	directory-assistance |
	faults |
	cellular-rule
]

all-phone-rule: [ allowed-phone-rule | international-rule ]

Arnold, for the dir issue:

>> ?? dirize
dirize: func [
    {Returns a copy of the path turned into a directory.}
    path [file! string! url!]
][

    either #"/" <> pick path length? path [join path #"/"] [copy path]
]

>> ?? undirize
undirize: func [
    {Returns a copy of the path with any trailing "/" removed.}
    path [file! string! url!]
][
    path: copy path
    if #"/" = pick path length? path [clear back tail path]
    path
]

In the original script I use a change-dir to get into the right directory. 
Then renaming is just the rename filename newname. I stuffed the 
renaming into a function and changed the variable names. Everywhere 
but in this place where I wanted to rename the file for real and 
I forgot to change old to new.... so here I tried debugging it while 
using the complete path and filename, because I was afraid there 
could be an issue there.

Today I experimented with calling a REBOL script from my php script. 
Thanks to previous contributions of a.o. Ralph Roberts of abooks.com 
from 1999(!) and an entry on the PHP site I found out how to do this 
on my apache driven site.

It was not quite as straightforward as Robert said like: include 
("rebolnow.r");
Nor was it as simple as: system("rebolnow.r 2>&1", $myout);
echo $myout;

But it worked when I called out for the REBOL program first. Both 
two of the next examples worked for me:
system("/path/to/cgi-bin/rebol -c %rebolnow.r 2>&1", $myout);
echo $myout;
AND secondly
echo system("/path/to/cgi-bin/rebol -c %rebolnow.r");
Work!

The REBOL script must be in the same dir as your PHP script (Not 
in your cgi-bin directory)(I didn't test sub dirs and other dirs 
but I suppose they work like usual)
The script does not need the #!/path/to/rebol line at the top.
The script should not print http-headers and

When printing stuff the last line should read print "" because the 
last printed line will be repeated.

Hope this helps more people to switch from php scripting to REBOL 
scripting for their websites.

so i copied the files over to a new directory, then when i try
>> do %uni-engine.r
>> uniserve/boot
...i get a bunch of errors saying cheyenne is not defined


using the old (0.99) sources on the softinnov website, i can use 
the starter.r script just fine. However, i set up a simple service 
and a module to process tasks, but get:

** Script Error: Cannot use path on none! value
** Where: process-task
** Near: if shared/pool-max > shared/pool-count [
    fork
    if verbose > 0 [log/info "launching new process"]
]

Thanks for getting back to me on this Doc...
So if i have this correct, I should:
1. Use the latest version from Cheyenne (have made a copy)

2. Remove all services and protocols from the %services/ and %protocols/ 
folders, except for task-master.r (which i need!)

3. Now hopelessly confused - the UniServe directory tree of the latest 
Cheyenne version I have is as follows:
     Uniserve
     ---clients
     ---libs
     ---protocols
     ---services
         ---task-master.r
         ---task-master
             ---task-handler.r
     I don't see a %UniServe/handlers folder...

now getting this:


./rebol: error while loading shared libraries: libX11.so.6: cannot 
open shared object file: No such file or directory


any experience running rebol-view on aws? looks like some libs/headers 
are missing...

Thanks for the welcome back message.
 

 I left off asking about the mySQL driver. So I want to insert into 
 a database a random number the code already generated and associate 
 it with an email address that was provided by a CGI form. Have yet 
 to create this in the real world but for now let us assume I will 
 call the database "customers". The people who process the credit 
 card and collect the email address advised me that the address will 
 be labelled "trnEmailAddress".


 After finding the mySQL driver Here is what I figured out using placeholders 
 for things like password, etc. Would appreicate knowing if this is 
 correct.

; Loads MySQL driver
do %mysql-driver/mysql-protocol.r
; Opens connection to MySQL server
db: open mysql://[[user][:pass]@]host[:port]/database


; Send query to database server. Enters random number from above. 
customers is probably the name of the database I will create

insert db ["INSERT INTO customers VALUES (?,?)" "trnEmailAddress" 
"token"]



 Next I need to insert an existing PDF file (an e-book) into a directory 
 created by the script. The directory will be named after a random 
 number that was earlier generated by the script. I am astounded that 
 I can not find the command to copy a file. So the variable assigned 
 to this random number is called "token".

 So I have the following.

make-dir %token/


 How do I copy a file into this new directory? Also, is that the corecct 
 way to make a directory?

it should be in the <sdk>/source directory

If you did a grep on your source directory you'll find it ... in 
prot-setnet.r

In R3, I want to be able to request a specific directory quickly 
and easily.  The easiest way I've found is to use REQUEST-FILE since 
it allows the user to quickly "navigate to" the desired directory. 
 Thing is, it requires the user to pick an existing file , even though 
I don't care about the file itself.  In most cases, this is fine 
since the user can pick any one of the files, but in cases where 
a directory is empty of a file, I have a problem.  

example code:

request-file/file to-file join "/" second parse what-dir "/"   <-- 
I use this to default the directory at the highest level is   ie 
 %/c  

Is there a better way to do this in R3?

I am trying to troubleshoot a peculiarity in   R3    2.101.0 from 
Saphirion

>> print type? what-dir

file!				<-- Ok, it's a file, even if has an end slash instead of 
a specific file path
>> print type? request-dir	; select any directory
file!				<-- Ok, Same thing


So it stands to reason that passing the value returned by WHAT-DIR 
and by REQUEST-DIR  will be FILE!

So here is my code that is giving me some trouble:

file-list:	[]

read-dir:	func	[
	dir	[file!	]
	] [
	foreach file read dir [
		file: either dir = %./ [file] [dir/:file]
		append file-list file
		if dir? file [
			read-dir file
	]	]	]

inp-dir: request-dir/path	what-dir 

unless inp-dir [ask	">>> No directory selected, cannot proceed  (Enter)" 
 quit ]
cd :inp-dir


read-dir inp-dir		; <-- does not work as expected, must use cd and 
what-dir instead
;read-dir what-dir
new-line/all file-list on
print mold file-list

Patrick, simple fix: if you expect INP-DIR do be a file refering 
to a directory, sanitise it through DIRIZE: `read-dir dirize inp-dir`.

The underlying problem indeed is related to a bug in R3. Both directories 
and files are represented by file! in R3. R3 uses a heuristic that 
a trailing slash discernes file file!s from directory file!s. Now 
when you pass a file! without a trailing slash but which actually 
refers to a directory to READ, READ crashes. (Bug#1675)

Back again.  Thank you Andreas,


I had realized that FILE! was used for both directory and files, 
but I didn't realize that REQUEST-DIR was NOT sending it back as 
a directory, but as a file (without trailing slash).  I was able 
to confirm by adding a print of WHAT-DIR and INP-DIR and compare, 
as per your comments.

I did not know about DIRIZE


Using READ DIRIZE INP-DIR does fix the problem -- though I wonder 
if REQUEST-DIR should return it with a trailing slash?

Thanks again to all!

Then you don't have to chmod, you just have to put it in the right 
directory.

Create 2 files. Call the first one e.g. cgi-test.html, and upload 
it to your server. The only thing you have to change is the link 
to your .cgi script in there:

<HTML>
<TITLE>Simple Web Form</TITLE>
<BODY>
<b>Simple Web Form</b><p>
<FORM ACTION="http://www.xidys.com/cgi-bin/cgi-test.cgi">
<INPUT TYPE="TEXT" NAME="Field" SIZE="25"><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>
</BODY>
</HTML>



Create a second file, called cgi-test.cgi (it has to align to how 
you name it in the above source file). Upload it to your cgi working 
directory. Remember to change the first line to contain the path, 
where your REBOL executable is placed:

#!/usr/local/bin/rebcmd -sqc

REBOL []

print join "Content-type: text/plain" newline
start: now/time/precise

submitted: decode-cgi read-cgi
values: construct submitted

prin "Submitted: " print mold submitted
prin "values: " print mold values
prin "values/field: " print mold values/field

print now/time/precise - start
print newline
 

Now go to your URL, and try to submit some values. You can test it 
on my site at: http://www.xidys.com/cgi-test.html

I certainly see a read/args as being quite distinct in purpose from 
write.  I use it with my sandbox scheme (http://reb4.me/r/wrt) to 
filter directory contents.


 read/custom wrt://system/ [thru %.r] ; shows only rebol scripts in 
 this folder
	write wrt://system/ [thru %.r] ; means something else entirely

Adrian, I would guess the directory was just uploaded to git

I've always thought of QUERY as requesting metadata. READ is for 
content. If you, say, READ a directory (which I suppose I have no 
idea if it's still the way it works (tm)) to get all the files in 
that directory -- why would you use a different keyword to get a 
filtered list of, say files beginning with 'a'?

The ZIP format is supposed to be like a directory/file structure. 
I would rather have it supported as a zip:// port scheme, like file:// 
is for files and directories.

One problem with the existing implementation is that xdg-open and 
x-www-browser are searched for in the PATH, so executables with the 
same names in a PATH directory that takes precedence will yield different 
behaviour.

Andreas, I have an interesting Git problem related to R3 and the 
new version of VS2012. Git both in Github and now in VS are both 
detecting a couple files in the build directory you helped me make 
as having changed or being new. I thought that whole directory was 
ignored in .gitignore, so it seems weird.

if the argument was a directory

what do you mean with an empty target?  %./ just means the target 
is a directory, the actual directory

I haven't had the time to follow all the discussion in detail, but 
to me, the second part of split-path should NEVER return a directory 
path. 


when doing   set [dir file]  I should be able to count on the fact 
that the second part is either a file or none.  The same for the 
first part which should always be none or a dir.  I have my own implementation 
in R2 which makes this strict and it simplifies a lot of code.
so we can do with absolute certainty:

if second set [dir file] split  path [   ]


IIRC some of the versions of my split perform a clean-path to simplify 
and add robustness to the result.

Regarding the split-path behaviour in the %foo case. I stongly object 
against the proposal to obtain [%. %foo], since for example INCLUDE 
whan obtaining %foo with empty path uses INCLUDE-CTX/PATH to find 
%foo (which may even exclude the %./ directory if it is not in INCLUDE-CTX/PATH), 
while when obtaining %./foo it just finds the file in the current 
directory (which is not equivalent)

I prefer

split-path %foo
== [%./ %foo]


The reason is because I believe split-path shouldn't require an extra 
check if all you want to do is read the base directory that a file 
is in.  I think this is a common use of split-path.

And while I understand that a file with no path implies the current 
directory, we lose information by assuming it. For example, if I 
let a user specify a path or filename, and I split it, now I can't 
tell if they gave me just a filename, or if they gave me %./<file>.

we have got quite a few combinations to consider:

missing path:

* yielding %.
* yielding %""
* yielding #[none] 

missing file

* yielding the last directory in the path
* yielding %""
* yielding #[none]


In total that is 6 variants but only some combinations make sense, 
I think

Maxim, the problem with requiring that SPLIT-PATH should _never_ 
return a directory as second component, is that SPLIT-PATH cannot 
decide that based on a file! alone.

Isn't a convention that %foo/ is a directory while %foo is not?  
That's one way to tell if a given file! directory or not...  It's 
what I generally expect, and I agree with Maxim that it makes the 
most sense for split-path to return #[none] if there is no file.

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

if you give me split-path %"" I'd return [none none]  if you want 
a meaningfull default for the dir, then just use clean-path before 
supplying the value to split-path, then you'll be assured of always 
getting a directory.

Following this thought, maybe all the mezzanine functions in %cortex.w 
(in World) should be separate files in a directory? And the shell 
commands should be separate files in a %libs/shell/ directory.


Reminds me, that I should pick up my database again. It has records 
as separate files.