AltME groups: search

foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style in obj 'color]]

foreach [style obj] svv/vid-styles [print mold to-lit-path new-line/all 
reduce [style in obj 'color] off]

foreach [style obj] new-line/all svv/vid-styles off [print mold to-lit-path 
reduce [style in obj 'color]]

and why you use [style in obj 'color]?  this will works as well: 
foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style 'color]]

foreach [style obj] svv/vid-styles [print mold to-lit-path reduce 
[style get in obj 'color]]

This is the reduction:
>> to-lit-path first new-line/all [word] on
== '
word

I think it is an error, since I am molding a lit-path which can't 
be loaded back, because of the newline between the ' and the first 
word.

TO-PATH is affected the same way.

TO-SET-PATH is also affected.

and you can move the word into other series datatypes like path, 
then back to a block and see the new-line has followed it.

Copy/part can't use a path! as its RANGE argument

>> path: 'svvc/color
== svvc/color

>> copy/part path back tail path
** Script Error: Invalid /part count: color
** Near: copy/part path back tail path

This is interesting because a path is a series, supposedly very similar 
to a block.

There is a bug in decode-url:
>> probe decode-url http://test/path/target?text/something
make object! [
    user: none
    pass: none
    host: "test"
    port-id: none
    path: "path/target?text/"
    target: "something"
]

the target should be: target?text/something

the bug is in the URL-parser of course... there should not be ? char 
in path-chars

never mind, you can delete it, I already have a solution... anyway... 
it would be nice to replace the clean-path function with the Anton's 
simple-clean-path

DocKimbel, #4288 looks to me like it inserts a molded object into 
the path.

Yes, it returns the object source and the point is is this useful 
to anyone ? I was hoping the behaviour of :b in a path! could be 
changed to something more useful, like acting as a pass-thru to /c, 
so that, in the ticket example, a/:b/c would results in %path/target.

slipping objects into a path...

>> a: %path
== %path
>> b: context [c: %target]
>> a/:b/c
== %path/c: %target%0A/c
>> a/(:b/c)
== %path/target

I wonder if there can be some refinement to 'read so that when it 
reads a directory, it returns the full path for each file rather 
than just the file name.

hmm, i see its a path. so [pad n ###.##] would work without quotes 
:)

its path -> is issue

Louis, in Core or View ? In View, you can read/write to the public 
cache.

This is VIEW-ROOT (the directory you selected during install, by 
default it is in a windows user profile directory).

When you click on an app from a rebsite, it is saved (by READ-THRU, 
PATH-THRU) into the public cache before running.
So, if it is your app, say at 
http://yoursite.com/app.r
then it could save prefs files to
path-thru http://yoursite.com/app-prefs.r
eg.
	save path-thru http://yoursite.com/app-prefs.r[my prefs data]

In Core, I define some of those useful functions from View (VIEW-ROOT, 
PATH-THRU etc..) in the user.r to allow the same functionality.

While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be called directly at all?

path seems to be a "clear find". Do not know about uses.

and fucks it up somehow, because if i change the unset!  to something, 
the path still stays in a strange state

!> a: [b 1 c 2 d 3]
== [b 1 c 2 d 3]
!> path a 'c
!> a
== [b 1 c]
!> length? a
== 6
!> a/4: 12
== 12
!> a
== [b 1 c 12 d 3]

Its a good idea to know about it. Seems its possible to path action! 
to protocol. at least i made a 'find in a  protocol once and got 
all the refinements.

to path -> to pass ..

At this point, I can't imagine what the path action! would be good 
for. Perhaps it is part of the object! internals?

Cant have a use, else i had heard of it :) Practical use: it blocks 
mold. Recursive data, Code-obfuscation?
!> a: context[b: 1 c: 2]  path a 'b  ?? a
a: make object! [
    b: end
    c: 2
]

I'm going to copy my path question to RT Q&A.

path is internal, and should probably not be exposed. my guess is 
that it has to do with path evaluation.

I mean, it says "Path selection." right in the doc comment so that's 
a good guess :) But how does it help with path selection? How is 
it used? Just for implementing set-path assignment?

For that matter, what types implement the path action?

Adding things like this to path notation hides a lot of compuational 
complexity. Sometimes that's a very good thing, and sometimes it's 
not. And consider what should happen in the case that "my-block/[2 
3]" refers to a two-dimensional array, or a block of name value pairs; 
what should the result be? Something like that fits very well in 
a dialect where the power is leveraged, and the domain is tightly 
constrained. That's where we get power and safety combined.

rebol []

theTOC: ask "Table of contents (seperate with <p></p> tags): "
theHeader: ask "Header: "
theNumOfBars: ask "Number of chart bars: "
outputPath: ask "Save path (with trailing / ie: c:/): " 


getTemplate: read http://o7o.org/files/aflax/examples/barchart/barchart.html

getSWF: read/binary http://o7o.org/files/aflax/examples/barchart/aflax.swf

replace/all getTemplate "$TOC" theTOC
replace/all getTemplate "$theHeader" theHeader
replace/all getTemplate "$numOfBars" theNumofBars

write to-rebol-file join outputPath "barExample.html" getTemplate
write/binary to-rebol-file join outputPath "aflax.swf" getSWF
browse to-rebol-file join outputpath "barExample.html"

No good ways. You can build a path and do that.

you lost me :-) but it's ok, I'll try something with build-path...

You can do this:

do to-path reduce ['do-a-function either condition ['ref][none]] 
<argument>
but if it's less clumpsy, you deside!

; Try this way, no reduce or to-path...

do either condition ['do-a-function/ref] [:do-a-function] <argument>

works with "path" ..

Nevermind.  
It turns out that if you use
FireName: to-file request-file/file "/C/Program Files/"
that it will split the path and name at the space.
OTOH if you use

Filename: to-file request-file/file "/C/Program Files/*" (note character 
after the path)

that this will work.  The character after the path can be any character.

can somebody give me a quick rule, why the pick-path notation evaluates 
it's picked value and pick does not (and first...) (as it should 
be a shorthand for pick)
as in:
bl: [] 
append bl func [a][print a]
bl/1 "hello" ;evaluates the function
pick bl 1 "hello" 
first bl "hello"  ; both do not

I have to do an extra 'do - I'm just curious for a reason ?!

The explanation might be, that it should be possible to get the function 
without evaluating it. You can do that with PICK or FIRST:
f: pick bl 1
f: first bl

Now if bl/1 worked the same way, you always had to add DO to get 
it evaluated. So my guess is, Carl desided, that wouldn't be too 
smart, and I agree. It's the same with objects. To call a method 
(a function) within an object, you just write:
o/some-func

No DO is needed in front of that. So using path notation to get to 
a function within a block or an object will evaluate the function.

Thanks for the answers. Maybe this should be noted somewhere especially 
- when I was searching for it, the only thing I found is in the documentation 
in the examples for unnamed functions. There only the path notation 
was used to extract and evaluate the functions immediately.

I agree that this evaluation is good to have and on purpose, just 
a bit too hidden for my taste (one again has to have quite some undestanding 
how Rebol works to have a resonable model for these things or a big 
memory) - as some other things in Rebol.

any notes on this?:

>> trim/tail/with "0100" "0"
** Script Error: Invalid path value: with
** Near: trim/tail/with "0100" "0"

question concerning 'get: First, why doesn't get support something 
like "get my-object/user-data"? Next, how to get a path word?

path word? such as

in my-object 'user-data

?

does anyone know what PATH is good for?

Henrik, PATH is a function used internally by rebol but probably 
accidentally exposed globally.

The first of the two examples above shows how to use path notation 
to select and change values in a block.

The second of the two examples above shows how to use a "throwaway" 
context to store new words in, then to reference these words from 
inside a block.
Both examples are showing how to use blocks instead of objects.

One of the advantages of objects is the convenient path syntax to 
get to a value. Hopefully, the above examples show how this can be 
done with blocks.

then I have a function that asks for a specific relation by diving 
down a path with a block like: [customers 1234 invoices 45 articles 
15] to find customer 1234 who has invoice 45 which holds article 
15

then there is a function to add and remove relations

this might be something dangerous:

write %test.r "hello"
path: what-dir
remove back tail path
write %test.r "hello" ; this fails


problem is: what-dir returns directly system/script/path what seams 
to be used in order to resolve relative file values

I just recognized it using the request-dir from didec which was in 
the rebgui distro -038 (he's doing this in the request-dir function 
in the line with


if all [not empty? path slash = last path][remove back tail path] 


so question is whether this is a bug and belongs to rambo, is ok 
(I don't think so) or what else ?

might also be that didec changed this in a later version (script 
was dated 2003 and maybe at this time 'what-dir had a different behavior), 
but this doesn't matter regarding what 'what-dir returns

yes that's what I mean, nothing wrong with rebol, but who guesses 
that this returns a really vulnerable path

MichaelB: about the path problem in request-dir, it's a bug in the 
code.


The simple solution is to patch this line (in request-dir func at 
the end of the script :
	if not all [keep path] [path: any [where what-dir]]
like this :
	if not all [keep path] [path: copy any [where what-dir]]

the 'path word is local to ctx-req-dir context and the Rebol path 
must not be changed by it. It's up to the "user code" to change it 
if he wants to.

But I agree that Rebol should check if path is "complete" (trailing 
"/") before using it in read/save/load/... functions

consider it a flimsy prototype. requires list-view.r to be in the 
same path as the script

Henrik - wrong link to list-view on the above reblog.html .... /reblog/ 
in the path should not be there ...

Graham, anamonitor can examine custom objects, not just the system 
object. You just need to type in a word/path which refers to the 
interesting object.

If you download the src code the paths is user-path/orca/trunk/orca/tests/

i think there are issues with ftp as a url path is not guaranteed 
to match the file system path

A URL path is _supposed_ to map to the file system path _if_ the 
scheme is ftp://
/
 has no assumed hierachical meaning in other URL schemes.
Hence the confusion at times.

I think REBOL is playing safe in not assuming the mapping. And, given 
how badly many FTP clients are written, that is probably for the 
best.

Why can't I find paths in a loadable block?

>> t: [x/y]
== [x/y]
>> type? first t
== path!
>> find t 'x/y
== none
>> find t to-path 'x/y
== none

Paths are structures like blocks. Find doesn't do structure analysis 
on block types like that - it just tries to determine if the exact 
same path is there, not another that resembles it.

You can also use the above patch to only create the path like this:

Sorry, that wasn't very clear..  Use my code snippet above just to 
create the path.
	port: make port! ftp-spec  ; only path, no target

 port/state/flags: port/state/flags or system/standard/port-flags/open-new
	port/handler/open port
	close port
; now try to open/direct ... etc..

Humm. I give up. Has somebody found a solution to the path capture 
problem?

#!/usr/local/bin/rebol -sq
REBOL []
print first system/options/args

What I need is to be able to capture the full path of the first arg 
passed to such script.

The reason is that the script is no of the same path of /usr/local/bin 
the script fails to find the file.

Hi Jaime,
I think you're looking for this

system/script/path

IIRC the shell-dir is somewhere there. Or try system/options/script/parent/path.

Thx, Ingo and Volker, what I was looking for is SYSTEM/OPTIONS/PATH

read-thru-to: func[url target /local data loc-path][
	either exists? target [read/binary target][
		loc-path: first split-path target
		if not exists? loc-path [make-dir/deep loc-path]
		write/binary target data: read/binary url
	]
	data
]

Oldes, Volker, I put into my rebol/core  user.r  file:
	view-root: dirize clean-path system/options/home/../view
	user-prefs: context [debug: none] ; fake user-prefs
	vbug: func [msg [block! any-string!] /local dbg][
	    if not dbg: user-prefs/debug [exit]
	    msg: head insert remold msg "view "
	    either file? dbg [write/append dbg msg] [print msg]
	]

along with the source to these functions:
	path-thru
	exists-thru?
	read-thru
	load-thru
	read-net

; Does this work for you Graham?

REBOL []

; GET-ENV is a standard REBOL function now

; environment variable APIs
; msvcrt.dll
; getenv _putenv _environ
; char *getenv( const char *varname );
; int _putenv( const char *envstring );

lib:  load/library %msvcrt.dll

get-env: make routine! [
	varname [string!]
	return: [string!]
] lib "getenv"

put-env: make routine! [
	env-string [string!]
	return:    [integer!]
] lib "_putenv"

remove-env-var: func [name [string!]] [put-env join name "="]

env-var-exists?: func [name [string!]] [
	either "^@" = get-env name [false][true]
]

tz-set: make routine! [
	return:    [integer!]
] lib "_tzset"

print get-env "path"
print get-env "lib"
print get-env "temp"
print get-env "test"

if 0 <> put-env "test=blah" [
	print "error writing environment variable"
]
print get-env "test"
remove-env-var "test"
print mold get-env "test"

print get-env "TZ"
tz-set

free lib

halt

Using a path like that is not safe if you want to pop a function. 
It will call the function. To avoid that use either FIRST or PICK 
my-list 1

So you get that weird looking error message when using path notation.

what's the easiest equivalent to:

>> set to-path [a b c] 7 ; doesn't work

Certainly not the most elegant sollution:
set-path: func [pth val /local rslt][
	rslt: copy []
	head insert/dup head rslt [in get] -1 + length? pth

 repeat i length? pth [append rslt to block! form to path! reduce 
 ['pth i]]
	set do bind rslt 'pth val 
]

>> a: context [b: context [c: 0]]
>> a/b/c
== 0
>> set-path [a b c] 7
== 7
>> a/b/c
== 7

do reduce [to set-path! [a b c] 7]

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

 - right, that is not supposed to do anything meaningful, it simply 
 keeps the context the word 'a had

>> a: context [b: context [c: 0]]
>> do reduce [to set-path! [a b c] 7]
== 7
>> a/b/c
== 7

load mold reduce [to set-path! ... ] seemed to work

rel-obj: make object! []

add-relation: func [path-block [block!] /local p v w] [
  p: to-block 'rel-obj
  parse path-block [
    any [
      [set w word! (
        unless all [

          find either object? do to-path p [first do to-path p][[]] w
          insert tail p w
        ] [

          do load mold reduce [to set-path! p make do to-path p reduce [to-set-word 
          w none]]
        ]
      ]
   ]
]

I'm not sure it's enough...

I'm rewriting my relations engine, if you remember that one.


I need to traverse rel-obj via paths, so I store the path as words 
in a block. This is in order to maintain the current position in 
a deep object.


The input can be any arbitrary path of words and values. If the values 
or words don't exist, they will be created on the fly. That's what 
I use 'p for.

No, it's additional. We've long planned the graphical Linux to force 
a migration path for Syllable Desktop

Right, otherwise you are adding a comparison nd a path decode to 
every conjoin/reduce call.

mybe allow datatypes too, join-as url![ "http://server/"rel-path]

but this tricky word usage usually breaks in situations like path 
notation

My suggestion is close to Ladislav's ++ function above and is something 
like:

>> inc: func [x] [either word? x [set x 1 + get x] [x + 1]]


But as Maxim point out, there are ploblems with paths. But what is 
the path representing? A block or an object or what? If it's in an 
object, it'll work this way:

>> o: make object! [a: 0]
>> inc in o 'a

It's harder to deal with values inside blocks.

; INC/DEC with regular arguments, must use lit-word! or lit-path! 
directly to get side effects:
increment: func [
    [catch] x "Value to increase"
    y [integer!] "Amount to increase by"
    /local t
] [
    throw-on-error [
        if path? :x [
            x: in do copy/part :x back tail :x last :x
        ]
        t: either word? :x [do :x] [:x]
        case [
            series? :t (t: skip :t y)
            number? :t (t: t + y)
        ]
        either word? :x [set/any x :t] [:t]
    ]
]
inc: func [[catch] x] [increment :x 1]
dec: func [[catch] x] [increment :x -1]
decrement: func [
    [catch] x "Value to decrease"
    y [integer!] "Amount to decrease by"
] [increment :x negate y]

Ladislav, I prefer the latter, but that's because I'm used to REBOL 
evaluation semantics and like metaprogramming. If you are incrementing 
a word returned from a function, other than in the most common case 
of the IN function for path access already covered by the code, you 
have to put the call to the function in a paren for it to evaluate 
properly. The latter functions will at least always behave the way 
you would expect REBOL to behave - no magic evaluation, pass-by-name 
for side effects, etc.


I think the lit-word argument form is a little awkward for anything 
other than interactive use, like HELP and SOURCE.

Sorry, I just realized that was a confusing answer (to anyone other 
than Ladislav :). To clarify:


By call-by-name, I meant passing a word or path value to the function, 
rather than passing the value it refers to. If you have 'a formal 
arguments then call-by-name is implicit - if you have regular formal 
arguments then you must explicitly express call-by-name by writing 
the 'a as the actual argument, at the time of the call.


When I was talking about having to put function calls in parens, 
I meant any function calls or expressions that return the values 
that would then be passed to the INC/DEC function in their first 
argument. The first version of the functions, with the 'a argument, 
would need to put any word or path generating expression in parentheses 
for it to work properly. The second version of the functions would 
not require such a hack - you could use normal REBOL evaluation patterns.


One of the normal REBOL evaluation patterns is that call-by-name 
is explicit for all functions, except interactive functions used 
for documentation like HELP and SOURCE. This is why I prefer the 
latter functions above, the ones with normal formal arguments: Their 
behavior is more REBOL-like.

There might be options to solve the path situation:
inc some/object/some/'value
inc some/object/some/('value)
or maybe
inc '(some/object/some/value)
Just suggestions.

If you think, "inc a" should change a, then think about these, that 
we have today:
negate a
- a ; unary minus
abs a

Also many math functions, like:
exp a
log-e a
etc.

Why don't all those change a?

I already solved the path situation. Read the code.