r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Pekr
21-Apr-2009
[13606x3]
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 ...
amacleod
21-Apr-2009
[13609x2]
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
Pekr
21-Apr-2009
[13611]
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?
Graham
21-Apr-2009
[13612x2]
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.
eFishAnt
27-Apr-2009
[13614]
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
PeterWood
27-Apr-2009
[13615]
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
eFishAnt
27-Apr-2009
[13616]
wow, nice analysis, Peter.  Almost feel like AltME makes a good benchtop 
software scope...;-)   Where does 'fastest come from?
Geomol
27-Apr-2009
[13617x3]
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.
Henrik
27-Apr-2009
[13620]
there would be less GC with clear, too, wouldn't there?
Geomol
27-Apr-2009
[13621]
yes
PeterWood
27-Apr-2009
[13622]
Thanks, John. I only looked at the last few digits. I must read more 
carefully. Now the results are as I'd expect.
Geomol
27-Apr-2009
[13623]
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
PeterWood
27-Apr-2009
[13624]
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]

]
Geomol
27-Apr-2009
[13625]
Making the GC (Garbage Collector) to as little as possible is a good 
thing! (TM) :-)
Robert
27-Apr-2009
[13626x2]
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".
[unknown: 5]
27-Apr-2009
[13628x2]
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
]
Robert
27-Apr-2009
[13630]
Can I limit the end as well? Something like a SLICE?
[unknown: 5]
27-Apr-2009
[13631]
not sure what you mean.
Robert
27-Apr-2009
[13632x2]
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.
[unknown: 5]
27-Apr-2009
[13634x2]
just copy that part of the series into a new series.
copy/part
Robert
27-Apr-2009
[13636x2]
I wanted to avoid the copy.
But OK.
[unknown: 5]
27-Apr-2009
[13638]
:)
Graham
27-Apr-2009
[13639x2]
Is there an easy way to break out of a nested loop?

eg.

forever [
	forever [ 
		if true [ break outside both loops ]
	]
]
use throw and catch I guess
PeterWood
27-Apr-2009
[13641x2]
You could try to convert one of your loops to a function and do something 
like this:

>> y: func [] [             
[    forever [                
[        i: i + 1                 
[        print i                  
[        if i > 3 [return [break]]
[        ]
[    ]
>> i: 0
== 0
>> forever [do y]                                               
1
2
3
4
In other cases where you want ot break out of the inner loop, just 
return an empty block:

>> z: func [] [return []]
>> forever [do z]        
(escape)
Steeve
28-Apr-2009
[13643]
Graham, catch and throw
Graham
28-Apr-2009
[13644]
hehe .. that's what I said
Steeve
28-Apr-2009
[13645]
ah... yes
Geomol
1-May-2009
[13646]
Continuing from Puzzle Answers. Isn't this a bit funny or strange?

First some failed attempts to make 2 a word of value 1:

>> 2: 1
** Syntax Error: Invalid time -- 2:
>> set '2 1
** Syntax Error: Invalid word-lit -- '2
>> set [2] 1 
** Script Error: Invalid argument: 2


So 2 shouldn't be a word. But then it's possible anyway with this 
trick:

>> set to-word "2" 1
== 1

2 is still a number:

>> 2
== 2

But 2 as a word exists:

>> get to-word "2"
== 1


I think, it's a bit strange. If it's intentional or not, I don't 
know.
ICarii
1-May-2009
[13647x2]
the first behaviour (the error) would be the expected behaviour if 
you assume that base symbols such as number are protected from modification 
- this protection in R2 at least is not complete.
consider trying to audit code with blocks made in word form.. another 
source of insecurity / bugs
Dockimbel
1-May-2009
[13649]
The only thing that blocks numbers to become word! values is the 
lexical scanner. When you type anything in console (or DO a file 
script), your input is first a string! value that gets LOADed (that's 
where the lexical scanner raises errors). TO-WORD allows to bypass 
the LOAD phase and force the conversion of any symbol to word! value.
Geomol
1-May-2009
[13650]
Maybe it would be a good idea, if constructors like TO-WORD etc. 
would do a lexical scanning of the result?
Dockimbel
1-May-2009
[13651]
Anyway, this gives us a probably unique method for strong code obfuscation. 
:-)
ICarii
1-May-2009
[13652]
heh indeed!
Geomol
1-May-2009
[13653]
heh, yeah! It's fun at times, but is it really a good idea?
ICarii
1-May-2009
[13654]
the set to-word "2 + 2" with spaces is a bit of a worry
Dockimbel
1-May-2009
[13655]
I agree, TO-WORD should enforce word! syntax rules on argument and 
raise syntax errors accordingly. That would be a more logical behavior. 
Maybe Carl had some design issues to workaround by allowing this 
(or maybe it's just an implementation flaw).