World: r3wp

bug?

actually, i don't think on should be evaluated. mold would never 
produce it.

I wish there *were* an option to mold it. Sometimes I really want 
to use on/off or yes/no in files.

my bitset creation skills are a bit rusty. how do I create a bitset 
that means 'anything but #" "' ?

all-but-white-space: complement charset " "

forgot about charset... thanks

How can I prevent a window from popping up when I have set security 
to none?

Set it on the command line.

rebol -s args

Brian, thanks. I forgot to say that this is a script on XP operating 
system. I have the following line in the target field of a shortcut:

C:\.Alkitab\ftp-backup.r -s allow

But the window still pops up.

Hummm, I see that I have it after the script, instead of after rebol.

C:\Program Files\rebol\view\rebol.exe -s allow C:\.Alkitab\ftp-backup.r
 doesn't work either.

C:\Program Files\rebol\view\rebol.exe C:\.Alkitab\ftp-backup.r -s
  doesn't work either.

OK, I copied rebol to the same directory as the script, and now this 
works:

C:\.Alkitab\rebol.exe ftp-backup.r -s

Now, I have just one more problem to solved to be in business. I 
need the script to be run automatically in the background every 10 
minutes, then exit, but windows scheduled tasks can be run no more 
frequently then once a day.

What is the best solution for this problem?

-> Properties -> Advanced -> set to every 10 minutes..

inside the scheduled task..

give it a daily end time and you're away laughing :)

ICarii, thanks. This is my first time to use Schedule Tasks, and 
I didn't go far enough into the wizard to get to the advanced settings.

Does rebol function keeps its local variable (or the whole context) 
in memory, even after finished?

I want my screen to be removed from memory, and am thinking of putting 
the view code inside func as suggested, defining referenced widgets 
as locals ...

however, I am still not sure memory will be freed after function 
call is finished ...

I will continue in View group ....

I think that the memory is not freed in R2, but is in R3.

Use this function for memory cleanup:

after: func [a b] [:a]

According to Gabriele, REBOL never frees memory -- ie never hands 
it back to the operating system.

That means (I think) freed / garbage collected memory is kept in 
REBOL's grasp for reallocation, so subsequent allocations are faster 
than ones that need to go to the opsys. But the memory footprint 
of an application can be higher than you'd expect -- especially (say) 
if you do a lot of memory intesmive work at start up: that memory 
will stay allocated to REBOL throughout the life of the application.

One way to avoid that may be to use CALL to run parts of the application 
under another process. Or perhaps use a webserver and split the app 
into several non FastCGI scripts.
***

I've no idea if R3 does allow for opsys memory handback. It would 
be a useful option to have:
    recycle/for-real

From a fresh REBOL/View 1.3.2.3.1 :

>> system/stats
== 4236013
>> system/stats/recycle
== [1 2054 2054 183 183 1869648]
>> make string! 1'860'000
== ""
>> system/stats
== 6099084
>> system/stats/recycle
== [1 2054 2054 183 183 7088]
>> make string! 10'000
== ""
>> system/stats
== 3210049
>> system/stats/recycle
== [2 6385 4331 543 360 2999280]

Just guessing: 


REBOL triggers a GC when the "ballast" value (the last one in the 
block) reaches 0. Then the GC frees only the values that aren't referenced 
anymore. So GC are predictable if you know exactly how much memory 
is consumed by each evaluated expression. Remember that it very easy 
in REBOL to keep hidden references on values (like functions persistent 
context)...


So that way, it keeps a fast average time for new allocations. (I 
guess also that series! and scalar values are managed with different 
rules).


The above example also shows that REBOL gives memory back to the 
OS, but the conditions for that to happen are not very clear to me. 
The GC probably uses complex strategies. If the GC internal rules 
were exposed, we could optimize the memory usage of your applications, 
and probably the speed too.

Does R3 have R2 GC, or new implementation?

BrianH: could you please explain, how your 'after function frees 
memory? :-)

after: func [a b] [:a]

something: func [/local a] [a: make string! 10'000'000  after a a: 
none]


If you use after a lot, the next call will displace the memory taken 
by the last. If you don't want to wait, call
    after none none

Que? What's the point here?

Is it a way of cleaning up, so the local a doesn't point to some 
mem area, and so the garbage collector can do its job?

Otherwise (in R2) the function SOMETHING will retain the value of 
the word a until the SOMETHING function is called again, or is itself 
collected. If that value is large it could be a problem - hence the 
really large value in my example.

In R3 those words are cleared on function return, so that particular 
problem doesn't arise. There are other kinds of cleanup that AFTER 
can help with though.

I situations with strings (or series in general) like that, I use 
to put the function and the variable in a context and do
clear a

when it's needed. That way I reuse the mem area. Would I need the 
after function? hmm ...

I have never used such technique, but I'll consider it.

To make it clear, I would do something like:

context [
a: ""

something: does [clear a  ... ]     ; do something with a, maybe 
filling it with lots of data or whatever
]

There should of cource be some more code before the end bracket ending 
the context. It was just to illustrate.

doc, stats decreases, however size in task manager seems to stay 
the same, so i don't know if memory is actually deallocated or kept. 
maybe the os keeps it for the process.

if you play a little more with this example allocating big buffers 
then releasing them, you'll see memory used going up and down (I 
even could go back close to initial state after something like  a: 
make string! 100'000 recycle). So REBOL releases some parts to OS, 
but it's hard to predict how much and when...

(watching in task manager)

What is PATH used for?
>> ? path
USAGE:
    PATH value selector 

DESCRIPTION:
     Path selection.
     PATH is an action value.

ARGUMENTS:
     value -- (Type: any)
     selector -- (Type: any)

From RT Q&A:

Q: 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 or should be called directly at all?


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.

Some other discussion:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-display-posts.r?post=r3wp152x1804

http://www.rebol.org/cgi-bin/cgiwrap/rebol/aga-display-posts.r?post=r3wp157x7205

Thanks!

s: "Hi engkau. Mengapa kaulari? Topikau ada di sini dan jaskau ada 
di sana."


In string s above, is there an easy way to replace (with "engkau" 
all instances of "kau" that are not preceeded by  " " (a space) or 
immediately followed by a letter?

In other words, I only want "kau" to be replace with "engkau" when 
"kau" is preceeded by a letter and followed by a space or puncuation 
mark.

Do you want "engkau" to become "engengkau"?

One solution:


s: "Hi engkau. Mengapa kaulari? Topikau ada di sini dan jaskau ada 
di sana."
p: s

while [not none? p: find p "kau"] [either all [p/-1 <> " " find " 
,." p/4] [insert p "eng" p: skip p 6] [p: skip p 3]]

If you don't want "engkau" to become "engengkau", you can use:


while [not none? p: find p "kau"] [either all ["engkau" <> copy/part 
skip p -3 6 p/-1 <> " " find " ,." p/4] [insert p "eng" p: skip p 
6] [p: skip p 3]]