AltME groups: search

Oh, with path notation, you need to adjust the loop to start counting 
the index from 1

In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

You can also access locally defined enums from outside using path 
notation.

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

It's not lost, it should be stored in system/options/path.

So `change-dir system/options/path` at the top of rsc.r it is :) 
?

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

script/path & options/path: yes

Or try the full path to the DLL

i tried with full path too. same result

it is imo not definitely a path problem. Just check with exists? 
%temp.dll, and it returns true. Still library is not loading ...

I tried to put a msvcrt.dll > 7600 into the same path as temp.dll, 
into system32 or into the rebol home path. still no success

I'm wondering if this is "easy"? Is the development path laid out 
or do you really carefully need to think about each step?

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

I also need #include's to work the same as in Red/System: relative 
to the source the path is in

The path of the source file they came from is lost

By the way, I think we should eventually have a search path for includes, 
but that's for the future

I've pushed #system-include addition, but there's probably more path-related 
patches to apply I'm afraid.

Works with #include with an absolute path

Arnold - 'set example is one trick you can use in REBOL. Normally, 
when you enclose the function in the object/context, it is accessible 
via a path notation, e.g. context/make-profitable. When you use 'set 
aproach, it lives inside the context, but is exposed to the global 
context, so you can call it directly, or something like that :-)

No changes for Red plans, I continue on the same path towards a complete 
v1.0.

Brian: that last shortest path might be the first thing to try.

The situation at the moment certainly can be confusing, but the solution 
lies not in moving everything to a central repository.


The real solution is to improve Red(/System)'s mechanisms for locating 
and including other scripts ("libraries"). A simple "search path" 
would already go a long way, and will probably be added soon.

yeah but you could have different path containing different stages 
to allow fast or slow compilation (with full optimization)

Recent Red tweet: "All path datatypes (path!, lit-path!, set-path!, 
get-path!) implemented. "

Path notation preliminary support added: you can use it on any series 
with integer! or get-word! values as accessors (nested word! values 
need SELECT action to be implemented first).


See changes in demo script: https://github.com/dockimbel/Red/commit/88fd1ff1da855a383e91566903fe373ea4d41eca

Set-path notation support for modifying series added.

hm.. now I see, that even select and path notation is not returning 
error.. so I don't know where I came to this.

Don't forget also path notation: `series/-1`.

Path notation is somewhat rarely used with negative indices (and 
probably even rarer with computed components, which I think were 
only added as late as R2.6).

I did some investigation over the rebol.org library and a few other 
available R2 apps a while back, I think it's basically always /-1 
and /-2 for negative path indices.

Keep in mind though that another occasion when you use computed indices 
with PICK/POKE is when you do stuff like s/(x) or s/(x): val, since 
path references for series should be using PICK/POKE internally.

Here is a new proposition for solving the "PICK issue":

1) Forbid <= 0 indexes.


2) Add a PICK-BACK action that will take only positive integers, 
PICK-BACK series 1 would return the first element on the left of 
current series position.


3) As PICK-BACK is not a very nice and concise name (I like actions 
to be named with a single word), an op! alternative would be provided: 
<- (opening angle-bracket followed by a dash aka "ASCII arrow")

Examples:
    >> series: next [A B C]
    >> pick-back series 1
    == A
    >> series <- 1
    == A
    >> series <- 2
    == none			;-- to be consistent with out-of-bound PICK


For path notations options in such scenario, I'm open to propositions. 
So what are the pros/cons of such solution?

Part of the reason why I keep highlighting the ordinals aspect is 
that I think this is part of what many people really like about current 
R2 behaviour, and many fear to lose.


FIRST is convenient and nice, and having path notation for "first-to-right", 
"first-to-left" is nice as well.

I wouldn't allow negative integers in path in such case. I would 
either come up with an non-ambiguous syntax to handle path notation 
or forbid it too.

Because now one logical path component is split up into two actual 
path components.

SERIES/-1 is not even function evalutation in the DO dialect, it's 
path evaluation

I really don't care about path syntax with computed indexes, it's 
ugly and awkward, and broken because of the 0 hole. I'd really rather 
use a function. As long as we get PICKZ/POKEZ, I'll be good. We already 
have SKIP to act as a non-broken AT. But at least plug the hole with 
a triggered error, so it won't mess people up silently. It's a huge 
failure, at least make not fail silently.

Which means that either Doc prefers path syntax over function syntax, 
or path syntax was implemented first, or both. Nonetheless, it's 
real code of any significant complexity, so it probably includes 
backward index use.

The preference then. So, at least 2 people like to use path syntax 
(PowerMezz was written by one guy). It was bound to happen that someone 
wouldn't find that syntax ugly :)

The above counts are not about path syntax, but specifically about 
_negative indices_ in paths.

People have been discouraged to use fixed path indexes because they 
are supposedly slower in R2 than FIRST and such, but I like path 
syntax because it is shorter and unambiguous

Brian, just for the record, I find your proposal reasonable and pragmatic.


If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices 
and falling into the 0 hole. Maybe a bit egoistic, but well.

If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices

 - if I know you well, you would actually explain to them the advantages 
 of the simple approach (especially when being asked about some index 
 arithmetic problem), and I am sure that the "reasonable souls" would 
 join you soon, and the others would either stop programming in the 
 language or follow suit as well.

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Doc, I can splint a broken leg but it doesn't make it less broken. 
Still, you're lucky thet you haven't been caught by this.


As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work. If PICKZ and POKEZ are available, those of us who need something 
that works will have something. I don't mind even making R3 work 
like this, but only with the error and the alternate working functions. 
Let the people who insist on using path notation bear the brunt of 
the problem, so be it.

Of course path notation should still work on maps and other things 
where it means SELECT, not PICK,

Instead of throwing error on pick 0, can I propose adding undefined! 
datatype? In ActionScript, which I use quite often last days you 
can distinguish not defined and null values like:
	var a:Array = new Array();
	a[1] = 1;
	a[2] = null;
	log(a[1], a[2], a[3]); //<-- would output: 1, null, undefined

Btw.. I think it was me who asked Carl to implement path notations 
with parens allowing to write b/(n) It's in REBOL since 2.6.. sorry 
if it's causing confusion.
http://www.rebol.com/docs/changes-2-6.html#section-8

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

The lexer is choking on get-word used in path...let me see that...

Steeve: I have fixed the lexer bug, so it should at least load correctly 
now. But paren! in path are not yet compiled, so you'll get a "feature 
not implemented" at compilation.


Also, passing a function as argument is not yet correctly handled. 
Also I'm unsure if s/:step: will be compiled correctly, as we haven't 
yet much tests for path accesses.

SELECT full support implemented for all series datatypes (including 
path access syntactic sugar).

Red 0.3.1 released: http://www.red-lang.org/2012/12/red-v031-functions-support-added.html

- function support
- path get/set notation support
- refinement support for native functions
- expressions in parentheses compilation

- new datatypes: function!, paren!, path!, lit-path!, get-path!, 
set-path!

- new actions and natives: find, select, copy, reflect, type?, halt,...

- extended mold, form and comparison operators to all new and existing 
datatypes
- many new mezzanines functions

- modulo and remainder operators on floats implemented for ARM backend
- Quick-Test testing framework ported to Red
- a truckload of new unit tests
- many bugfixes
- about 200 new commits to the Github repository
- updated Red/System formal description document

REBOL []

do/args %makedoc2.r 'load-only
doc: scan-doc read file: system/options/script
set [title out] gen-html/options doc [(options)]

file: last split-path file
replace file ".txt" ".html"
file2: copy file
insert find file2 "." "-light"
replace out "$DARK$"  file
replace out "$LIGHT$" file2

write file out
replace out "dark.css" "light.css"
write file2 out

I have a rather tortuous path using makedoc => asciidoc => pdf/epub

It would be very useful to have a search path for includes that could 
include directories elsewhere, possibly in the compiler tree, but 
it should start by checking relative to the source file

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.

The hardest part was to tell apart REBOL path issues from Red and 
Red/System own path issues.

I've done a full build run with the path fixes, without regressions

You first define a CONTEXT, then you can use it with WITH, or path 
notation

You can't use path notation on types. I've been trying to coerce 
Doc into implementing that, but he doesn't want to. :-/

Preliminary path! and set-path! support added to Red interpreter.

https://github.com/dockimbel/Red/commit/53f87ff81822e81c5ddf56245e68f8e6255c698b


Works only on series! so far, function calls with refinements are 
next on the todo-list.

The most optimal path is to shed the legacy of R3, as well, and bootstrap 
straight into Red

Kaj in !RebolBot: "I think that only works in Red, refinements starting 
with a number :-)"


Refinements that start with a number work in R2 and R3 as well. Path 
elements aren't refinements though, they're regular words or other 
values. If you find any basic data syntax differences between Red 
and R3 in datatypes that they have in common, report them: they're 
either a bug in R3 or in Red, or possibly in both.

I meant path elements. Of course, when they're used in a function 
call, refinements are written as paths

The error seems to have something to do with path interpretation 
again, as it happens when a / is present

Ka, there's no file! type yet in Red, even if some parsing rules 
are already included in compiler's lexer. So the path error for %/x 
is currently correct.


However, adding file! is not a big deal and as you already have provided 
some file access functions, I think I'll add it for the 0.3.2 release.

About the path composition for files, I might give it a try tomorrow.

OS libraries and R3 libraries are both libraries. However, with GPL2 
they make an exception for linking to OS libraries even if they're 
closed source. With GPL3 they extended that exception to libraries 
that come with a runtime or VM, like Java, .NET, or closed-source 
REBOL. The exception doesn't go the other way though: It's not allowed 
to link to GPL'd libraries with closed code.


Ladislav, the runtime library is used to implement the interpreters, 
and includes the interpreters for that matter, but it's still a library. 
The DO interpreter really doesn't do a lot; it resolves the op and 
path syntax and dereferences words, but everything else is done by 
the functions of the runtime library, which your code is bound to 
at runtime. But for the good news, it's at runtime, so afaict the 
GPL doesn't require you to release your source because of that binding, 
as long as you load the source at runtime, which you pretty much 
have to do at the moment for scripts.


Encapping is a trick, but you can handle that with some limitations. 
Extensions will need to be GPL 2, and that means that they can't 
be used to wrap closed-source libraries unless they were included 
with the operating system you're running on. Encapping regular scripts 
and modules is semantically iffy, but you could handle that with 
a FAQ entry that explicitly says that loading a R3 script doesn't 
count as linking, even if you bind the words to GPL'd values. The 
same FAQ entry would apply to scripts in files, databases, whatever.

I have to put it on my $PATH. Downloads is not in the $PATH Ooops!

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

But if you define a routine in a Red script, and then DO it, it will 
work. You can also build a custom console by writing a Red script 
and adding at the end an %include %<path-to>/console.red.

have an issue:
>> fact1: 'a/a
>> num1: 99.0
>> blk: [greater? to-decimal obj/:fact1 num1]
>> objs: []
>> o: make object! [a: make object! [a: "100.0"]
>> append objs o
>> o: make object! [a: make object! [a: "99.0"]
>> append objs o

>> foreach obj objs [if equal?  do bind blk 'obj true [print obj/a]]
**Invalid path value: a/a

>> foreach obj objs [print do blk]
** Script Error: Invalid path value: a
** Near: a/a

>> foreach obj objs [print do bind blk 'obj]
** Script Error: Invalid path value: a
** Near: a/a

Henrik, I am experimenting with your code.

Here is  my code:

view layout [
	testo-id: h2 
]

update-window: func [ttesto-id] [
	testo-id/text: to-string ttesto-id
	show [testo-id]
]

I have the following error:

Error: Invalid path value: text

What does PATH function?

It's internal, exported as a side effect of it being an action, used 
as part of path evaluation. Don't use it.

BrianH: Thanks for the info. It corrupts when I try it on objects. 
And wierd effects on blocks.. I've added "unset 'path" to my rebol.r 
file, so I won't be confused anymore.

Let us know whether you find that it's safe to unset 'path and reuse 
it for other stuff. There's no reason to think that the action! mechanism 
would call the function through its name (that's more of an R3 intrinsics 
thing), but any unpredictable behavior you find would be good to 
know.

Found the answer to my first task:

Had to read the documentation a little further and needed a function 
localize-file: func [file] [
    rejoin [{"} to-local-file clean-path file {"}]
]

Now call reform [player localize-file to-file thissong] does play 
the song!

A slightly shorter version that does the same, I think:
        localize-file: func [file [file!] ][
            mold to-local-file clean-path file 
        ]

I added [file!] to the parameter.....You get the parameter type-checked, 
hence a better error message if you pass it something that is not 
a file name.

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.

I also added path support for the mod so that you can use the same 
domain for web and api services.

sorry maxim - not having any luck with the sort function

>> sf: func [a b][o: select a/attribs "1991-1992" m: select b/attribs 
"1991-1992" o/m > m/m ]
>> sort/skip/compare/all comps 2 :sf
** Script Error: Invalid path value: attribs
** Near: o: select a/attribs "1991-1992"

if i do:

>> sort/skip/compare/all comps 2 func [a b][length? a/mcapz > length? 
b/mcapz ]
i get an invalid path error

>> reverse comps sort/skip/compare/all comps 2 func [a b][length? 
a/mcapz  > length? b/mcapz ]
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

reverse comps sort/skip/compare/all comps 2  func [a b][probe type? 
a probe type? b length? a/mcapz  > length? b/mcapz ]

block!
block!
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

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.

Two rules it is then. This doesn't crash, and is optimized for strings 
while we're at it. It's probably slower when doing blocks than Doc's, 
but it handles all datatypes:

rle: func [s [series!] /local out emit pos1 pos2 cont][
	out: make block! 1
	emit: [(repend out [offset? :pos1 :pos2 first :pos1])]
	parse/case/all :s pick [[
		any [pos1: skip (cont: first :pos1) any cont pos2: emit]
	] [
		any [
			pos1: unset! any unset! pos2: emit |
			pos1: skip some [
				end pos2: emit break |
				pos2: unset! :pos2 emit break |
				pos2: skip (

     cont: unless strict-equal? first :pos1 first :pos2 [[end skip]]
				) cont |
				pos2: emit break
			]
		]
	]] any-string? :s
	out
]


It also works around the strict-not-equal? bug in pre-2.7.7 R2, and 
using FIRST instead of path access is another speedup in R2 (path 
access is faster in R3).

The reason I use :output there isn't to prevent function hacking, 
it's to prevent converting lit-path! values to the path! type.

These values are already processed by REBOL when it is started in 
CGI mode. I'm using
	cgi: system/options/cgi
The request URI is then in cgi/path-info

Hi Kaj, wish it was that simple. I have put some strings into action 
and you can view the result here http://arnoldvanhofwegen.com/rebol/doesnotexist.html
Well as you can see path-info is none.

Not really fair, you redefine the throw word and expect it to work 
as is ?

Your function got the same problem on my pc, except it occurs at 
the execution time.
** Script Error: Cannot use path on integer! value
** Where: tail-call
** Near: throw/name none 'tail-cal
or maybe you have a new version right now

(Actually I have problems with Altme to synchronize with some recent 
posts I can't see all of them currenly)

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"]
]

>> do %compare.cgi
Script: "Untitled" (none)
Script: "MySQL Protocol" (12-Jul-2008)
MySQL protocol loaded
connecting to: localhost
** Script Error: Invalid path value: oneone
** Where: map-rebol-values
** Near: result/oneone
>>

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

Does anyone know if there is any problem with using a ":" within 
a http URL, for the *target* part of the path.   

as such, the URL doesn't have any relation to physical disk paths.

ex:

http://mydomain.com/stuff/group:resource