World: r3wp

>list-dir ;after the file crashes...aha, I could see the files before 
doing the main.r.
main.r  main.r  


My scripts work fine on Windoze.  I am now thinking from this...I 
do a change-directory to get the directory of where I am running 
and I write my data into the current directory.  In Windoze, the 
change-directory seemed needed to pick up the directory I am in. 
 I'll bet 'nix doesn't like that, and perhaps needs the full pathnamem 
from the root, or soemthing like that.

I think you got me off dead center, at least.

I think if 'nix, then don't change-dir might work.

Remember *nix is case sensitive also on pathnames.

My stuff is all lowercase, but good point.

my bad.  I wrote the script to automatically work for View or Enbase, 
but this 'nix is actually Core.  So it is using the encap branch 
of #include.


Sorry for the confusion.  going to extract the bullet from my foot....;-)

Ahhh, I did the same thing with Tretbase when I put on my webhost. 
 But my problem was different as I used a /view option in my script 
that I needed to change.

Good if you got it figured out! Often it helps to talk to others. 
All the time, I see the problem myself, the second I start telling 
others about it. :-) And then I get the looks. :-D

Yeah everyone does that at some point.

AltME therapy

yahoo, the seven script application is running remotely.  The errors 
were logic error on my part.

I don't believe Java can claim that level of cross-platform!

Cool! :-)

All my testing had been on Windows until yesterday.  Once I got the 
permissions and encap logic straight, it ran, on Redhat (crazy network 
stuff) so there was no Unix/Windows differences I had to deal with 
in the code.

my code is crazy network stuff.  You would think there would be at 
least one thing I would have to change due to platform, but no.

Is there a way to get the name of the drives besides just the letters.

>> list-dir %/
c/  d/  e/  f/  g/  h/  i/  j/

I want: Local Disk (c:), Removable Disk (G:) etc.

I suppose you need to visit the registry to do that.

Local Disk

 and "Removable Disk" are made up by Explorer when the drives have 
 no names.

I'm trying to auto update an exe.

My code worked for script version buy with the encapped version it 
seems to buzz through without executing some statements...

write/binary %NEW.exe read/binary http://website/client.exe
delete %captain.exe
rename %NEW.exe %client.exe
notify "Update Complete!"
call/show %client.exe


IT seems to start up the client before the new one has been dowmloaded 
and renamed..

Does it not wait for each statement to complete before moving to 
the next?

that would mean that R2 has async networking for normal 'read, which 
it does not have :-)

I would put small wait before the 'call.  What about call/wait? Hmm, 
that would wait before next function call. This is strange ...

'delete calls 'remove. The question is, if that native really waits 
for the result, or just submits the call to OS layer and returns. 
Then, especially with crappy sloppy Windows FS you might get some 
delay ...

I treid wait
I tried alert to stop it at certain points

I thought that was the problem  (too much delay with OS cleaing up 
deletes and writes etc...) but the waits and alerts seem to be ignored

your script is buggy anyway, no? You delete %captain.exe but you 
rename %NEW.exe to %client.exe, which you run in the end. So:

1) what is %captain.exe good for?
2) why not to directly write/binary to %client.exe then?

I write a batch script to do this .. ie. write the new file name 
as temp.exe or something.

Then do a call/quit to the update.cmd script.

Just pulled the bullet from my foot.


buffer: copy {} ;works better than buffer: {}   I was suspecting, 
then finally tried (fixed a random-looking problem)

Anyone know the efishantsea between these?

buffer: copy {}

vs

clear buffer

I think clear is faster but surprisingly seems to use more memory:
>> fastest [buffer: copy {}] [clear buffer]

The first code took 0:00:00.012196

The second code took 0:00:00.008569

>> fastest [buffer: copy {}] [clear buffer]

The first code took 0:00:00.011403

The second code took 0:00:00.008293

>> stats

== 63378943

>> loop 100000 [buffer: copy {}
]
== ""

>> stats

== 66979663
>> recycle

>> stats

== 63378971

>> loop 100000 [clear buffer]

== ""

>> stats

== 63379907

>> recycle

>> stats

== 63378971

wow, nice analysis, Peter.  Almost feel like AltME makes a good benchtop 
software scope...;-)   Where does 'fastest come from?

Peter, I read you example, as clear use *less* memory than the copy 
method.
>> 66979663 -  63378943
== 3600720
>>  63379907 - 63378971
== 936

I would expect
clear buffer
to be faster and use less memory than
buffer: copy {}

And it seems to be so.

there would be less GC with clear, too, wouldn't there?

yes

Thanks, John. I only looked at the last few digits. I must read more 
carefully. Now the results are as I'd expect.

eFistAnt, Ladislav has some timing functions here: http://www.fm.tul.cz/~ladislav/rebol/timblk.r
I just use:

time: func [:f /local t][
    t: now/time/precise 
    do f 
    now/time/precise - t
]

And then time many loops of some code, like:

>> time [loop 10000 [buffer: copy {}]]
== 0:00:00.245122

Fastest is a trivial script that I use. I think many people have 
better ones.

>> source fastest
 
fastest: func [

     f
 
    s
 
    /local
 
    st
 
    en
][

     st: now/precise
 
    loop 10000 [do f]
 
    ed: now/precise
 
    print ["The first code took" difference ed st]
 
    st: now/precise
 
    loop 10000 [do s]
 
    ed: now/precise
 
    print ["The second code took" difference ed st]

]

Making the GC (Garbage Collector) to as little as possible is a good 
thing! (TM) :-)

This looks strange to me:

>> a: [a1 b1 a2 b2 a3 b3 a4 b4]
== [a1 b1 a2 b2 a3 b3 a4 b4]

>> extract/index a 2 1
== [a1 a2 a3 a4]
>> extract/index a 2 2
== [b1 b2 b3 b4]
>> extract/index a 2 3
== [a2 a3 a4 none]
>> extract/index a 2 4
== [b2 b3 b4 none]
>> extract/index a 2 5
== [a3 a4 none none]

Why is NONE returned? I would expect just a shorter block.

I don't see any cause to fill up the returned block with "virtual 
values".

You can use my replacement for it

skip+: make function! [
    {Returns a series matching the skip sequence}
    series [series!] "Series to return skip values from."
    interval [integer!] "Skip interval"
    start [integer!] "Series index to start skipping from."
    /local blk
    ][
    blk: copy []
    if interval > (length? series) [return none]
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series
    if empty? blk [return none]
    blk
]

Can I limit the end as well? Something like a SLICE?

not sure what you mean.

I have a long series of fixed width and need to extract starting 
from a current position backwad/forward the x-th value.

Your verison runs until the end of the series. I just need to skip 
the next 10 entries.

just copy that part of the series into a new series.

copy/part