World: r3wp

It would help if GOB alpha was calculated per pixel as an effect 
and then we could do real alpha masks, but it isn't.

So - where do we write down our wishes for Cyphre to implement? :-)

Somewhere in rebdev. We have a high level GUI thread there. Might 
as well create a low-level one too.

I was thinking about CureCode for a while, as a "wish" requests, 
but not sure if we should "flood" it with such a stuff. Maybe a RebDev 
is better place, but Cyphre might not read it, because of its, well, 
"comfort" :-)

Just wanted to look-up some info about ReBin, as it is mentioned 
in recent March R3 plan, and found out following article:

http://www.rebol.com/article/0044.html


Pity it is almost 4.5 year old one. Hopefully we get it in upcoming 
months, as some features were really planned for ... sooooooo long 
;-)

Ah, damn, another big restructure of DocBase? :-) While Docs become 
more readable and graphically nicer, the person doing restructuring 
does not even distinguish Gabriele's GUI to Carl's one, so it really 
becomes an organisational mess and he ruined Carl's initial Docs 
for GUI ...

Can we somehow contact Kr bacon?

Is that _the_ Kevin Bacon editing R3 docs?

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

because of how path is defined (as parameter) in list-dir.

func [ 'path ...] instead of  func [ path ...]

don't know why this choice

Thank you Steeve, for checking into this

perhaps to allow this semantic:
list-dir c
instead of list-dir %/c
but it doesn't work

sh

sh

Steve, I'm trying to "capture" the source of LIST-DIR in a separate 
file, but I don't have the syntax quite right.

R3	>> SAVE %listdir.r SOURCE LIST-DIR	<-- donsn't work, I'm not sure 
how to sturcture this command

I got it
SAVE %listdir.r  :LIST-DIR

Try
  mold :list-dir
to get the source in a usable form

yep

Interesting,  MOLD :LIST-DIR returns the results inside of { }, where 
:LIST-DIR doesn't

:xxxx -- gets you the value of xxx
mold -- makes it a string

or you can use the clipboard
IN R3:
write clipboard:// to-binary mold :list-dir
(similar in R2)

I noticed that under HELP LIST-DIR, the arguments state 

    path -- Accepts %file, :variables, and just words (as dirs) (file! 
    word! path! string! unset!)

I get the first two ie  %/c and  :VAR-DIR, but what about "just words..."
Can anyone give examples of the third type of argument?

it doen't work currently, i think it's a bug, ask Brian before to 
post a new bug

it should work as-is to my mind
list-dir c
(same as list-dir %/c)

The relevant portion of the LIST-DIR source is this:
    switch type?/word :path [
        unset! []
        file! [change-dir path]
        string! [change-dir to-rebol-file path]
        word! path! [change-dir to-file path]
    ]
You should try SOURCE MORE for a simpler example of this method.

LIST-DIR is one of the console interactive functions, so it is acceptable 
for it to have an optional parameter without a refinement - otherwise 
you should avoid that method. The function you should use inside 
code, rather than interactively, is READ.

LIST-DIR currently needs work (mostly better formatting), but the 
behavior you describe is by design.

In R3, have we a function to replace a list of values by anorther 
one currently ?
(don't remember)

in a string

Can someone enlighten me: Will we have the Wiki and Carl's R3 docs 
side-by-side? Isn't that a double effort? I don't get it.

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

Thanks for your comments Brian, Steeve and Geomol

Geomol, refinement support sounds like a good idea, but it was left 
out on purpose because /c would work but /c/d would not. It is better 
to get people out of the habit now than it is to have to explain 
why /c/d doesn't work, over and over again.

Steeve, try REWORD - it is not a modifier though, it builds a new 
string.

There is a plan to add this as an option to REPLACE as well, and 
that is a modifier.

Robert, the R3 docs are a manual, while the wiki is community-generated 
articles and such. Not the same thing.

hmmm... reword doesn't fit well in my case.

i want to replace sequences of replace/all on the same string. I 
saw this scheme in many scripts (not mines of course:)

replace/all data ... ...
replace/all data .. ...
replace/all data ... ...

Cirst attempt could be:

foreach [this by] values [
	replace/all data this by 
]

but it would be slow.

hmm... it works with reword with an empty escape option:

>> reword/escape "Hello you" [#"l" #"L" #"o" #"O"] ""
== "HeLLO yOu"

In fact, i don't see the need of  an escape caracter by default ("$"), 
it should be the reverse.

For the case of only replacing chars by another ones, reword build 
to much overhead

Like I said, there are plans to make a modifier version of REWORD 
as an option of REPLACE. The escape character makes sense for template 
word substitution use, the main purpose of REWORD - it was Carl's 
idea.

Brian, makes sense with the refinement and ls. :-)

Steeve, one of the problems with multiple value replace is that there 
are basically two ways to do it:

- One value/replacement pair at a time (like your FOREACH loop above).

- In order using either an inner loop of FIND/match calls, or PARSE 
rules and alternation.

Neither of those are very efficient, but the PARSE rules tends to 
be more so, at the expense of building the rules. REWORD uses the 
compiled PARSE rules method. Most of its overhead is working around 
bugs in map! or going away with new REBOL features. If we do an inplace 
replacement, we'll have the same overhead. The only solution is to 
optimize the runtime, or hand-write the PARSE rules.

I've basically decided to bite the bullet and optimize the runtime. 
The feature requests and bug reports that came from implementing 
REWORD will be much more valuable than REWORD itself. That's why 
I wrote it :)

i make a proposal:

Most of the times, we use the same rules several times on different 
data.
reword should be able to not reconstruct the rules if so.

I used the similiar tricks in some scripts, for example:

map-chars: func [
	{replace/all pair chars in a string}
	data [string!] values [block!]
	/local chars pos
][

 ;** if the first value in values is a bitset, do not reconstruct 
 the bitset
	unless bitset? chars: first values [
		chars: make bitset! 256
		forskip array 2 [append chars array/1]
		insert values chars
	]
	pos: data
	values: next values

 while [pos: find pos chars][pos: change/part pos select/skip values 
 first pos 2 1]
	data
]

data: "Hello You"
map-chars copy data values: [#"s" "SS" #"t" #"T"] 
;** the second call is faster
map-chars copy data values

Cool Steeve.  You should be a way bigger part of the REBOL team.

Replacing single characters is all you need? That isn't general enough 
to make it into REBOL, but it might be a good library function.

bah, to be here and in Rebdev is good enough for me

You do help already :)

Brian, it was just an example to show reusable rules