AltME groups: search

Here's the R2 version of TO-CSV and TO-ISO-DATE (Excel compatible):

to-iso-date: funct/with [
	"Convert a date to ISO format (Excel-compatible subset)"
	date [date!] /utc "Convert zoned time to UTC time"
] [

 if utc [date: date + date/zone date/zone: none] ; Excel doesn't support 
 the Z suffix
	either date/time [ajoin [

  p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2 " "  ; or T

  p0 date/hour 2 ":" p0 date/minute 2 ":" p0 date/second 2  ; or offsets
	]] [ajoin [
		p0 date/year 4 "-" p0 date/month 2 "-" p0 date/day 2
	]]
] [
	p0: func [what len] [ ; Function to left-pad a value with 0
		head insert/dup what: form :what "0" len - length? what
	]
]

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	[catch]
	data [block!] "Block of values"
] [
	output: make block! 2 * length? data
	unless empty? data [append output format-field first+ data]

 foreach x data [append append output "," format-field get/any 'x]
	to-string output
] [
	format-field: func [x [any-type!]] [case [
		none? get/any 'x [""]

  any-string? get/any 'x [ajoin [{"} replace/all copy x {"} {""} {"}]]
		get/any 'x = #"^"" [{""""}]
		char? get/any 'x [ajoin [{"} x {"}]]
		scalar? get/any 'x [form x]
		date? get/any 'x [to-iso-date x]

  any [any-word? get/any 'x any-path? get/any 'x binary? get/any 'x] 
  [
			ajoin [{"} replace/all to-string :x {"} {""} {"}]
		]
		'else [throw-error 'script 'invalid-arg get/any 'x]
	]]
]


There is likely a faster way to do these. I have R3 variants of these 
too.

I did head down the path of trying to handle all the things REBOL 
does wrong with quoted fields and such, but I have always found a 
way to avoid dealing with it.

Just tweaked it to add any-path! support to the after parameter in 
the R3 version, since R3 supports SET any-path!.

BrianH, testing csv-tools.r now.

Is this a bug?:

>> to-iso-date 18-Dec-2011/14:57:11
** Script Error: Invalid path value: hour
** Where: ajoin
** Near: p0 date/hour 2 ":" p0
>> system/version
== 2.7.8.3.1

Be careful, if you don't quote string values then the character set 
of your values can't include cr, lf or your delimiter. It requires 
so many changes that it would be more efficient to add new formatter 
functions to the associated FUNCT/with object, then duplicate the 
code in TO-CSV that calls the formatter. Like this:

to-csv: funct/with [
	"Convert a block of values to a CSV-formatted line in a string."
	data [block!] "Block of values"

 /with "Specify field delimiter (preferably char, or length of 1)"
	delimiter [char! string! binary!] {Default ","}
	; Empty delimiter, " or CR or LF may lead to corrupt data
	/no-quote "Don't quote values (limits the characters supported)"
] [
	output: make block! 2 * length? data
	delimiter: either with [to-string delimiter] [","]
	either no-quote [
		unless empty? data [append output format-field-nq first+ data]

  foreach x data [append append output delimiter format-field-nq :x]
	] [
		unless empty? data [append output format-field first+ data]
		foreach x data [append append output delimiter format-field :x]
	]
	to-string output
] [
	format-field: func [x [any-type!] /local qr] [

  ; Parse rule to put double-quotes around a string, escaping any inside

  qr: [return [insert {"} any [change {"} {""} | skip] insert {"}]]
		case [
			none? :x [""]
			any-string? :x [parse copy x qr]
			:x = #"^(22)" [{""""}]
			char? :x [ajoin [{"} x {"}]]
			money? :x [find/tail form x "$"]
			scalar? :x [form x]
			date? :x [to-iso-date x]

   any [any-word? :x binary? :x any-path? :x] [parse to-string :x qr]
			'else [cause-error 'script 'expect-set reduce [

    [any-string! any-word! any-path! binary! scalar! date!] type? :x
			]]
		]
	]
	format-field-nq: func [x [any-type!]] [
		case [
			none? :x [""]
			any-string? :x [x]
			money? :x [find/tail form x "$"]
			scalar? :x [form x]
			date? :x [to-iso-date x]
			any [any-word? :x binary? :x any-path? :x] [to-string :x]
			'else [cause-error 'script 'expect-set reduce [

    [any-string! any-word! any-path! binary! scalar! date!] type? :x
			]]
		]
	]
]


If you want to add error checking to make sure the data won't be 
corrupted, you'll have to pass in the delimiter to format-field-nq 
and trigger an error if it, cr or lf are found in the field data.

Such projects might be a good testbed for some new or different ideas, 
but I am carefull in becoming too excited about them. What is the 
purpose of "clone", e.g. Orca, which has something like 50% of natives 
available only? Other thing is the project potential - dunno why 
- maybe because we trusted in RT, or because our community was too 
small, there was not much of a progress with any clone we ever heard 
about. Unless that changes, I want finished R3, because that is right 
now the shortest path to having "new powerfull REBOL" ....

hum I found a link to version 0.9.8 but on execution I get an error: 

** Script Error: Cannot use path on none! value
** Where: repend
** Near: system/script/header/version

that's with v1.3.2 of REBOL.

AFAIK Linux has the DRAW text support added(using fretype2 library). 
The only problem is how to get path to a font on Linux.(as there 
seems to be no 100% 'standard' way how to get it on all distros we 
need to use yet another dependency :-/ )

regarding your example in R2-Beta - Bugs (Problems that need solving.)

This seems to be a windows behaviour. It works with the complete 
path;
 call "%windir%\explorer.exe C:\"

>> help "thru"
Found these words:
   do-thru         function! Do a net file from the disk cache.

   exists-thru?    function! Checks if a file is in the disk cache. 
   Returns: no...

   launch-thru     function! Launch a net file from the disk cache.
   load-thru       function! Load a net file from the disk cache.

   path-thru       function! Return a path relative to the disk cache.

   read-thru       function! Read a net file from thru the disk cache. 
   Returns ...

All of the new functions in 2.7.7 and 2.7.8 (except THROW-ERROR) 
are backports from R3 - that is the development path for new R2 mezzanine 
functions. The rest is fixes and/or improvements to existing functions.

I'm building a simple dialect around it. I'm not sure I can make 
it 1:1 capable with CONVERT, but at least you would then be able 
to pass a standard REBOL block directly to CONVERT.

Example:


process [path %/z load %image.jpg blur 3x6 negate resize 50x50 save 
%image2.jpg]

hey, if the executable can reliably read rebol.r, then that's cool. 
 its also MUCH simpler for networked install, since you can lock 
down the permission on rebol.r so that every one launches the same 
way.   if we really need user.r... then just provide its path within 
rebol.r and load it from there.

yes I know all about that, and its really fucked up in vista/7.  
for an application not being able to write in its install path is 
ridiculous.

folder aliasing is new vista, and its a very stupid idea.  using 
the same path you end up at one file for read another for write? 
 wtf!

Folder aliasing is there to make up for silly people who still write 
apps that try to write to their application path without sufficient 
rights. If people had paid attention to the rules in 2000, we wouldn't 
have this mess now - Windows apps would be acting like Linux or Mac 
apps, and putting their files where they should be.

Anton: regarding the DRAW fonts on Linux. The font redering is supported 
(at least it worked on all distros I had to use in recent 3 years 
or so). The essential problem is how to automatically get the paths 
to your Linux truetype fonts so you don't need to specify the font/name 
with absolute path as it is now....

If anyone knows about any efficient method how we could get path 
to the font files on Linux so it works on all distros let me know. 
Solving this issue would definitely improve the DRAW font usage a 
lot.

I mean like each application is forced to put its dependecies into 
specific folders within its install path.  this way you can very 
easily verify that things are wath they should, and can make OS lib 
calls which act with confidence.

Sorry, there's no user-specific folders under the install path, not 
without separate user folder permissions maintenance for each application, 
or those aliases you mentioned. Is it really so hard to put user 
files in user folders? You have to do that on Linuc and Mac...

its hard when the damn paths are so obscure that you need to call 
the OS using libs to get the paths confidently.
its hard when those paths change all the time.
its hard where there are more than one path per application.


its just really complex when the darn paths could be simple... even 
on linux, they keep changing the paths almost every release on some 
distros.. it gets ridiculous.

I wish they had gone the OSX path and started fresh, with a built-in 
VM for XP/win2k support.

Cyphre, can't the user set up an environment path for linux fonts?

another thing which is missing is explicit font path.   The Os might 
not know, but at least if we could configure it manually then we 
could script independently of linux install.

as a reboler, I don't want to write system specific and environment 
 resolving code.  


my script should be able to ply itself to whatever system its installed 
on and still read/write its files in proper OS expected places.


This is what we are talking about Andreas... viewtop specifically 
has nothing to do with this.  this is for ALL scripts to be compliant.


if I had a command which allowed me to build a system-compliant "application 
data path" then it would write stuff in ~/application/ on linux and 
whatever profile/app data/application   path is being used by your 
flavour of windows.


right now, I'd have to write a library which determines this and 
it probably will screw up on ubuntu, or Mac Or the latest windows.

adrian, when I edited the shortcut on vista, and added the arguments 
it wouldn't save it, telling me the path to the executable didn't 
exist  :-(

Perhaps DECODE-URL should dehex the split-out parts, but after it 
splits them out. And since it doesn't fully decode the path section, 
it shouldn't dehex it - and probably not dehex the rest, just for 
consistency. If the reconstructed url doesn't rehex the parts then 
it shouldn't dehex them in the first place.

Well, DECODE-URL should probably not dehex the username and password 
unless the (unknown to me) code that reassembles the url! can be 
changed to rehex them. As it should, but I don't know which code 
to fix. The scheme, host and path should not be dehexed in any case.

Only the path is hex-encoded when passed to the server.

On Mac 2.7.8.2.5:

>> ls
** Script Error: path has no value
** Where: ls
** Near: switch type?/word :path [
    unset! [] 
    file! [change-dir path] 
    string! [change-dir to-rebol-file path] 
    w...

>> source speed?
test
test
... (fills console)
test
test
<code>

I think Peter might be asking about this sort of usage case:
     o: context [test: 3]
     a: 'o
     b: 'test

    o/:b   ;; this works
    == 3 
    :a/:b  ;; this fails
    ** Script Error: Cannot use path on word! value
    ** Near: :a/:b

    get in get a b   ;; this works, but it is hardly elegant
    == 3

I thought :a/b is a get-path! as a whole?

Here's my issue though I'm still running 2.7.5

>> f: func[][1]                
 
>> o: make object! [my-func: :f
]
>> b: reduce ['my-func :f]     
 
== [my-func func [][1]]

>> :o/my-func
== 1

>> :b/my-func
== 1


As you can see the value is being evaluated when using a "get-path!". 
Rebol3 simply presented the unevaluated value which is what I had 
expected.

No I didn't so let me rephrase my question. Is the  get-path! type 
supported in 2.7.8?

Roughly summarising: an extension search path (preferred) + os loader 
search (fallback) + a cross-platform mechanism to load extensions 
via abstract names.


Could be as simple as reusing system/options/module-paths and load-extension, 
allowing the latter to take a word! parameter and also search the 
former. The possible extensions themselves are already in place (system/options/file-types). 
Loading is already done via dlopen, so loading a lib only by name 
(w/o any path component) will use the OS loader's search mechanisms.


And alternative would be to add a system/options/extension-paths 
(block!) option, and a dedicated loading primitive, say, import-extension, 
which searches the extension-paths and tries all possible platform-specific 
extensions (as per system/options/file-types).

You want an optional search path for extensions, and that's fine, 
but Andreas and I are pleased with the OS managing them

An extension-paths setting and searching this path would be a good 
option (esp. on platforms with weaker loaders). But more about this 
later, gotta run :)

all path access is slow...but I woudn't have thought that using a 
series function and multiplying both values in the pair would be 
twice as fast!

so, claims that the path access is faster in R3 seems to be true 
across the board

I tried now, the problem with import was that I didn't set the absolute 
path to load-module/from before.

Module path searching only works with non-file! module names. I.e.
import 'foo

will search the system/options/module-paths for a file name %foo.reb. 
This search is a _very_ useful feature which we shouldn't rid ourselves 
of by stupid wars over which suffix to use.


As a module author, I want to use a suffix which I know will make 
using the module easiest for my target audience.


As a module distributor, I also want to make it easiest for my target 
audience to use the modules _and_ I need to enforce consistency within 
my distribution.


The only one who does not really care about the suffix is the actual 
user. The user just wants to use third-party modules without having 
to homogenise their suffixes first. But the burden of choosing a 
sensible suffix is currently imposed on the user. This does not make 
much sense.

Pekr: Interpreted as well and written in C, so no possible code re-use 
for Red. But I must admit that if I hadn't choosed the compilation 
path, I would have jumped into Boron to contribute. There's some 
good potential there for a serious R2 open source clone.

R3 also does not have a 64 bit path mapped for it

OK, this is freaky:

>> system/version
== 2.7.8.2.5
>> a: list-env
== [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 
    "TMPDIR" "/var/folders/6O/6OnXy9XG...
>> help a
A is a block of value: [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 

    "TMPDIR" "/var/folders/6O/6OnXy9XGEjiDp3wDqfCJo++++TI/-Tmp-/" 
    "Apple_PubSub_Socket_Render" "/tmp/launch-BrITkG/Render" 
    "TERM_PROGRAM_VERSION" "273.1" 
    "USER" "Ash" 
    "COMMAND_MODE" "legacy" 
    "SSH_AUTH_SOCK" "/tmp/launch-HlnoPI/Listeners" 
    "__CF_USER_TEXT_ENCODING" "0x1F5:0:0" 

    "PATH" {/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin} 
    "PWD" "/Users/Ash" 
    "LANG" "en_AU.UTF-8" 
    "SHLVL" "1" 
    "HOME" "/Users/Ash" 
    "LOGNAME" "Ash" 
    "DISPLAY" "/tmp/launch-U0Gaqw/org.x:0" 
    "_" "/Users/Ash/REBOL/rebol"
]
>> length? a    
== 18
>> select a "USER"
== "Ash"
>> select a "HOME"
== none

The chat interface uses numbers as a deliberate design choice because 
it is easier to memorize and refer to a number than it is to a path 
or message ID. You can even write a message number in #8008 form 
in another message and it can be followed like a hyperlink to the 
message of that number. You can also do the hyperlink trich to CureCode 
tickets using the bug#539 form, which will take you to http://issue.cc/r3/539
(that R3 bug I mentioned above).

Hm, maybe what I call integer refinements shouldn't be allowed at 
all, as I see no point in them. I can't get the desired path using 
integer refinements as in:

>> to-path [blk /2]
== blk//2

The correct way is:

>> to-path [blk 2]
== blk/2

So if integer refinements are useless, what's the point?

John, I'm not sure I understand. Aren't you confusing path with refinement?

It works, if you don't give NEW as full path.

new -- new name (not a path)

John, refinements that can't be translated to path use can be used 
for other reasons in other dialects. REBOL isn't just DO.

I also think that refinements are sort of meant to be path parts, 
so it makes sense to make them compatible with paths directly.  though 
I guess one can give examples of path incompatible refinements.

We are still making tickets related to word and refinement inconsistencies 
for R3 (or at least I am, when I find bugs in the syntax while I'm 
trying to reverse engineer the syntax docs). While the numeric refinement 
issue is settled, there are other issues that haven't yet been discovered. 
Most of the syntax problems are related to scanner precedence. All 
of the word and path datatypes can be constructed with characters/contents 
that don't really scan the same way in literal syntax, but it is 
not really considered an error. Datatypes are meant primarily for 
in-memory use - their syntax is secondary, and in many cases the 
literal syntax only covers a subset of the possible values.

A bug?

>> cur: what-dir

== %/Users/peter/

>> cd %Code/Rebol

== %/Users/peter/Code/Rebol/
>> cd cur

** Access Error: Cannot open /Users/peter/Code/Rebol/cur/

** Near: change-dir to-file path

>> change-dir cur

== %/Users/peter/
Though this works:

>> cd :cur
== %/Users/peter/

What does the PATH function do?

>> blk: [a b c]
== [a b c]
>> path blk 'a
>> blk
== [a]
>> blk: [a b c]
== [a b c]
>> path blk 'b 
>> blk         
== [a b]
>> blk: [a b c]
== [a b c]
>> path blk 'c 
** Script Error: Invalid path value: c

Maybe for some internal use?

From group Core-old:


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of 

side-effect" from how REBOL is structured.  Datatypes are implemented 
as a sort of object class, where the interpreter "sends messages" 
to the class to evaluate expressions. The PATH action is a message 
that tells the datatype to perform a pick-like or poke-like internal 
function."

Looks like SORT uses this datatype map internally:


[unset! datatype! native! action! function! object! word! set-word! 
get-word! lit-word! refinement! none! logic! integer! decimal! money! 
time! date! char! pair! event! tuple! bitset! string! issue! binary! 
file! email! url! tag! image! block! paren! path! get-path! set-path! 
lit-path! hash! list!]

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

lit-path is a series, so I think the argument is sound for the latter 
result.

It gets rid of a workaround, where I must store a path, where some 
values in the path can't be determined until storage, the moment 
where COMPOSE needs to act. The workaround is to create the path 
as a block, and then TO-PATH it on use.

>> f: [b d e f]
== [b d e f]

>> i: 2
== 2

>> my-path: rejoin [to path! [] 'f i]
== f/2

or, in R2:

    my-path: rejoin [#[path! []] 'f i]

or
>> append to-path 'f i

But yes, Henrik, COMPOSE should maybe work on path too, as it is 
a series. And maybe also on parens (also a series), where COMPOSE 
should work on parens inside.

REBOL handles parens in paths today. I can see the usefulness of 
having that evaluation return a composed path.

Related is using POKE on e.g. time!:

>> t: 10:20:30
== 10:20:30
>> poke t 2 42
== 10:42:30
>> t
== 10:20:30

But we can change a time using a set-path!:

>> t/2: 42
== 42
>> t
== 10:42:30

So the set-path! way doesn't do the same as POKE in this case.

In R2:

>> type? first [:sine/radians]
== path!

in R3:

>> type? first [:sine/radians]
== get-path!

It is a potential security hole, but not more of one than assigning 
a function to an object field. It requires the same ASSERT/type call 
to screen for it. Still, it would be nice if it triggered an error 
on evaluation, especially since newbies would benefit from that error 
when they naively try to do a get-path for a function call instead 
of using APPLY or a direct call.

James, ASSERT in R2 is not yet as good as ASSERT in R3. There are 
some limitations, most notably that you can't use ASSERT/type to 
validate a path. A proper native ASSERT is on the top of the list 
to add to R2 in the next version, whenever that comes.

That "Too abstract code" section... With type inferencing you could 
manage abstract code. It might require declaring the types of function 
arguments before path syntax can be used, but that isn't as big a 
deal as it sounds.

I guess you're looking at IA32.r/emit-path code?

When I see how Carl fights with various libc versions...I wonder 
if syscalls are not an easier path even if it can have some minor 
porting costs here and there? Anyway, a libc mapping will be possible 
soon, so all options are open.

Although I'm running into a bit of a wall when I try to import functions 
under cdecl. I'm getting undefined symbols (path values into the 
emitter symbol table) all over the place

Cross-compilation is now supported from the command-line: do/args 
%rsc.r "[-vvvv] [-f PE|ELF] %path/source.reds"

btw, when allocating arrays, the use of /value should not be required. 
 just like in C and REBOL's use of path notation, it should adapt 
to what is being pathed. 

using: 
p: &[array! [20 integer!] 0]

should be used with 
p/4: 123 

in fact:

 p/4/value: 123 

would be used for:
p: &[array! [20  &[integer!]] 0]

compiler gives "Invalid path value: stdout" error after first error.
my script is:
print x ;gives *** undefined symbol, thats ok
then I change the script to
print "x" ;gives *** Invalid path value: stdout

you are on rebol's track you already did a dead born clone of rebol 
and red is going the same path but with R-sharp at least there were 
4 people working for it no 1 with 2 bug trackers

** Script Error: Cannot use path on none! value
** Where: check-arguments-type
** Near: if all [
    not empty? spec: entry/2/4 
    block? spec/1
] [
    spec: next spec
] 
foreach

The error is: 
Error: sys_open() failed to dup path

Not yet, but Andreas should add it soon. Taking the output path/name 
from script header is a good idea.

Compiling /users/administrator/Red/test.reds ...
*** Compiler Internal Error: Script Error : Invalid path value: 1
*** Where: comp-either 

*** Near:  [emitter/branch/over/adjust/on c-true negate offset expr/1]

Kaj: I have added in the last commit a new virtual path for querying 
aliases unique ID value: system/alias/<name> 


The system/alias/... paths are replaced during compilation with a 
unique ID that should match the one passed for "typed" functions. 
So now you basically have RTTI on aliases too.

I also plan to add a SWITCH function soon, maybe before the SFD. 
It should be able to resolve alias names without the system/alias/ 
path prefix.

As long you as you use system/alias/ path accessors.

Compiling /resources/Red/tests/empty.reds ...

*** Compiler Internal Error: Script Error : Cannot use path on none! 
value 
*** Where: build-debug-lines 
*** Near:  [records: job/debug-info/lines/records 
files: job/debug-info/lines/files 
rec-size:
]

A shorter, but less efficient path, could be to use TCP sockets (or 
a lib like ZeroMQ) to setup a communication channel with the generic 
Java bridge.

I put alla files in red-system/tests, including Red-48x48.png. I 
got GTK-widgets.reds running, but with "Window: skipping missing 
icon.". Where do I put the PNG? As far as I see there is no path 
defined for this file in GTK-widgets.reds. Using Win7 (x64). I thought 
the icon would be built in the exe. I tried now to put the PNG in 
the same dir as the built exe and the icon shows, but I still got 
that DOS terminal to open. Sorry for stupid newbie questions.

Alternatively, you could add a path to the icon in the program

On Mac, the math library path may have to be adjusted

I removed run-test.r as it was becoming difficult to get working 
once we needed to have tests not only in the red-system/tests dir. 
(I now use a script in another language which seems to be more flexible 
in it's file path handling.)

I've emailed a copy of the run-test.r to Oldes.


I'll take another look at getting run-test.r to run a test from any 
directory. If I can I'll restore it, if not I'll chane the docs.

Paths are made up of tokens, yes, just like the other block types 
except with more restrictions about what types of data may go in 
the paths. I don't (currently) know what subset of path syntax and 
semantics that Red/System supports though.

In some other REBOL-like languages there are some inherent conflicts 
between some path element types (notably dates) and the path separator 
/ itself, plus the final : on a set-path is considered part of the 
path instead of being a set-word element contained in the path, and 
the same for a leading : in a get-path not being part of a get-word 
first element (in R3). There's a fairly well-defined set of precedence 
rules, but for REBOL-like languages other than Red those rules are 
not very well documented, and they can therefore sometimes vary from 
language to language.

I can agree with Oldes, that when wrapping some C stuff, things like 
series would be handy - namely - a block! type, to have an array, 
plus accompanying series handling functions. But - where would that 
end? :-) Wouldn't we then want also a path, etc. to work?

I am able to disrupt R2 compilation session to the state, where its 
restart is needed. Not a big deal, but maybe you will see something 
obvious. The code causing it is as follows:

print ["led-set-language: " led-set-language 3 lf]


The trouble is, that led-set-language does not return any value (void). 
This is understandable, that 'print has problem with such a clause. 
The error returned was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


Correcting the issue (moving function call away from the print block, 
I get another error:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


This error repeats, untill I restart the R2 compiler session, which 
is a proof, that I corrected the source code, as aftern the R2 restart, 
I can get clean pass ...

the problem is, that now it throws this error if C is used in enum:
*** Compilation Error: type mismatch on setting path: char/1
*** expected: [byte!]
*** found: [integer!]
*** in file: %runtime/utils.reds
*** in function: prin-byte
*** at line: 29
*** near: [
    char/1: c
    prin char
    c

Using the SQLite driver from Ashley, connect %any-folder/sqlite.db 
does not work, whereas connect %/c/any-folder/sqlite.db or (in any-folder) 
connect %sqlite.db works. I could swear that the first one with relative 
path worked until yesterday :-)

And is the former path accessible under rebol?

It should work just fine Awi. Are you sure your current path didn't 
change before trying to access the relative path?

World seems to be fussy about which directory it is launched from


Is there a way to figure out, what directory a command launches from, 
which will work across platforms? I could check argv[0] in main(int 
argc, char **argv) , but that wouldn't work, if world is put in a 
bin, which is part of $PATH.

So it seems, I made a good choise with gcc, because 1) it was easy 
to make World compile with LLVM and clang (if I choose that path 
now) and 2) it seems, some code doesn't work as intended with LLVM 
and clang.

Personally I have a great private project in mind and a skilled developer 
for it.

The project is blocked because he want to make money now and someone 
who finances the project.

I told him that First of all we must show a concept application. 
This will sell the application itself and we start fundraising.

Until something usable won't be ready I will not be able to sell 
the idea. He refuses this view and we are blocked.


As you are writing a programming language you are in a worst scenarion 
than us.

You need to have a commercial class programming language ready for 
the mass to sell it and this is not the case.

Commercial Class mean: IDE, Solution for interfacing SQL Databases, 
Solutions for communicating, Solutions for interfacing to other projects.

This is too much for one man to accomplish. You need to live, you 
need money and World is your Hobby project (Isn't it ?)


Open sourcing and delegating is the solution for creating a mature 
project: you seth the path, the specifications, the rules, the others 
will help.


I won't give a Penny and Time to REBOL Tech. because its source is 
closed and this model is wasting my precious life waiting for Carl 
to resurrect.

Open Sourcing solves this problem. Don't you think that if REBOL 
was open sourced many developers would have inproved it in Carls 
absence ? Do you think that someone, like an university will donate 
money to a private held project ? I don't think so.


When we (you) will have a mature project and you will be able to 
show to the world the advantages of your solutions money will come.

Think of SQL lite. There is a consortium behind it. Other open source 
solutions have the same consortiums behind them.


There are many ways to raise money: You can produce vertical solutions 
for your baby.You can give consulency to companies and other institutions, 
you can create products with World. These are few that comes into 
my mind.