World: r3wp

I give up. I have a routine that creates CSV files but I am stuck 
with how change what is an 0D 0A  to just an 0A  when it comes to 
setting up the actual CSV text file.  Anyone know?

write converts linefeeds to OS defaults unless you use /binary

if your source data actually has CRLF in them, just do:

replace/all datastr CRLF LF

Maxim, I'll try that. Thanks.

Are you kidding me? It was the write function the whole time! Thanks 
Maxim.

surprising you didn't know about this yet  :-)

Maybe I did at one time but at my age it's easy to forget! Real easy. 
I just took a look at the reb dictionary and aha! , there it is in 
black and white.

in R3 --> deline

>> num: 24
>> 1.1.1 * num
== 24.24.24

I need some help dealing with paths.

I have a block of sublocks and values refered by words.

I want to make a function that increment a value in a subblock based 
on a process number and a path. But adding subpath to a path seems 
to work only with file! type.

I hope that the code bellow obviously show what I want :

values: [

 1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [process path /local p] [
	p: select values process
	p/(path): 1 + p/(path)
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

The code below seems to do what you want......Just lacks the clever 
optimisation that'll turn it into a one-liner :)

inc-counter: func [process path /local p] [
    p: select values process
    path: parse mold path "/"
    p: select p to-word path/1
    p: find p to-word path/2
    p/2: p/2 + 1
]

Hmm, I see such expressions as

    parse mold path ...

as a very bad habit

It is puzzling me, how often it can be encountered, even though it 
is discouraged in the documentation.

Thanks Sunanda. I need any length paths, but its a proposal I can 
work  based on.

Ladislav: anything better to propose ?

inc-counter: func [process path /local p] [
	p: select values process
	p: select p first path
	change next find p second path 1 + p/(second path)
]

Thanks Ladislav and sqlab -- I was having a blindspot about being 
able to directly access the parts of a path.


DideC -- if you need to go to any depth, this version may help (subject 
to optimisation by the gurus):

inc-counter: func [process path /local p] [
    p: select values process
    foreach pp copy/part path -1 + length? path [
        p: select p pp
        ]
    p: find p to-word last path
    p/2: p/2 + 1
]

If you are happy to use issues instead of integers for your process 
ids, then maybe this would be ok:

values: [

 #1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 #2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [process path /local p] [

 do reduce [to-set-path p: join 'values/(to-issue process) path p 
 '+ 1] 
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

Wy issue ?

oups, forget that

I was thinking along the same lines as Anton. 

values: [

 1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [key path /local rec] [
	rec: select values key
	path: head insert copy path 'rec
	do reduce [to set-path! path  1 + do path]
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

It's a pity we can't select integer series members using path notation 
directly.

My first thought was to introduce a new datatype (like a "lit-integer!" 
(eg. '1) or an "index-integer!" (eg. @1), but it still means there 
will exist a datatype which, in a path, does not SELECT like other 
types, but is interpreted as a direct index PICKer.

So now I think there could be some "escape" path notation which changes 
the PICK-type functionality of integer path members into the SELECT 
type (which all the other datatypes have by default).

eg.  values/^1/dos/new   <-- The ^ causes the path to consider the 
following integer 1 as a series member to be SELECTed like other 
datatypes, instead of the PICK special treatment.

not a bad idea for path notation.

Except that ^1 is a valid word. :-)

Maybe, a lit-integer! could do the job.
'1

I don't know if we need a change. While having "one path notation 
to rule them all" is a nice goal, the cure might be worse than the 
disease.

It's true, I don't want to lose the current behavior.

And Anton gave an alternate solution that is good enough to my mind

but I think too, that SELECT and FIND should be able to process paths 
to look for nested structures.
via a refinement maybe.
Like select/path and find/path

I saw this request several times in the past, far far away...

My reasoning is that the effort to implement a lit-integer! type 
is not worth the value the notation provides, at least not right 
now. Once R3 is out, stable, and complete, ask me again. ;-)

In any case, write up a proposal, and RT will make the call. It's 
always good to write things down so we don't forget.

Don't know, I don't feel confident about the: "It has been requested 
many times in the past"
:-)

(And it's time to go to the chinese restaurant session of the week)

Is this a bug ?

>> a: make object! [ b: [ 1 2 3 4 5 ]]
>> probe a
make object! [
    b: [1 2 3 4 5]
]
>> forall a/b [ print a/b/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall a/b [print a/b/1]
>> forall word: a/b [ print word/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall word: a/b [print word/1]
>> word: a/b
== [1 2 3 4 5]
>> forall word [ print word/1 ]
1
2
3
4
5

no its always been like this... foreach needs to bind the word to 
the block

look closely

yes, you need to specify a word ... not a set-word.

it should be fixed

How can it be a bug, when it is documented?

statement: skip post -2
change find statement 'fixed 'changed

?

>> forall (in a 'b) [print a/b/1]
1
2
3
4
5

Looks more than sufficient for me.

The above is R3, though

The evaluation of these "partially evaluated arguments" has changed 
this way

Nevertheless, I do not like the header of the FORALL function, since 
the WORD argument is actually used to supply two values to the function, 
which is not a KISS strategy

(if this "two in one" method were that good, why it is not used by 
FOREACH, etc.?)

cause that's how they differ?

Cetera censeo, the "two in one" argument passing method is improper, 
and should not be used

#1653

would we be just using 

forall word word [print word/1] 

all the time ?