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

World: r3wp

[Core] Discuss core issues

Steeve
21-Jan-2009
[12166]
humm... what i said is not clear
[unknown: 5]
21-Jan-2009
[12167]
Static locals.  I love it.
BrianH
21-Jan-2009
[12168]
R3 has changed SET to allow [set-word:] arguments so that they can 
be used with functions like FUNCT and FUNCTOR. R2 not (yet?).
[unknown: 5]
22-Jan-2009
[12169]
Cool functions Brian.
BrianH
22-Jan-2009
[12170]
Yeah, I wrote them this evening (with helpful criticism from Steeve. 
I also wrote the R3 version of FUNCTOR.
[unknown: 5]
22-Jan-2009
[12171x3]
Excellent, maybe these need to be added to list in the 2.7.7 world.
forgot the name of that world.
r2-beta is that world.
Janko
22-Jan-2009
[12174x6]
Rebol looks totally consistent to me in Paul's example above, the 
key to that result is that rebol doesn't automatically evaluate (reduce) 
blocks -- which is the key properti of rebol that makes most of it's 
things possible. This is how I see it :
>> b: 'test   ;; line gets evaluated , b already holds a word!
== test
>> append a :b  ;; word get's added to serries
== [test]
>> type? first a
== word!

>> find a 'test  ;; 'test get's evaluated into a word again so find 
finds it in block
== [test]

>> c: ['test]      ;; 'test is in a block and of course doesn't get 
evaluated as any other thing in a block wouldn't so it stays lit-word!
== ['test]
if you want a block to get evalueated you should reduce it, then 
it will also find it
>>c: reduce ['test]
or >>c: [test]
BrianH and others : you made such great word (and ported it to mezzaine 
- I still have no idea what that is :) ) of the word map (as in functional 
programming ) ... did you maybe or is there any chance that its sister 
function reduce or fold or fold-left could be made in such a way.. 
I use your map a lot now but I have to use my poor fold word for 
folds :)
Will
24-Jan-2009
[12180]
on OS X and Linux, for every instance of rebol , 2 processes are 
launched, the second for dns, right? is there any known bug? I have 
an difficult to debug situation , when quitting cheyenne after some 
load, some handler process goes 100% cpu, but the dns process is 
no more there, this make me think it may be a problem with rebol, 
otherwise also if one process would go 100% CPU, the dns one would 
still be present, help!! 8)
Will
25-Jan-2009
[12181x2]
I'm not sure I understand what call/show introduced in 2.7.6 does?
got a partial answer from here http://www.rebol.net/cgi-bin/rambo.r?id=4113
is that window specific?
Oldes
25-Jan-2009
[12183]
When you did call, the black cmd window was always visible. Now you 
must do call/show to see the window (which you mostly don't want 
to see) And  I think this was just Windows change. I'm not sure how 
it worls on Linux or in other OSes.
Will
25-Jan-2009
[12184x5]
thank you Oldes, I may do nothing on linux/osx
have this 2 bugs been fixed in 2.7.6 ? are they bordercases, difficult 
to reproduce/debug?
http://www.rebol.net/cgi-bin/rambo.r?id=4153&
http://www.rebol.net/cgi-bin/rambo.r?id=4003&
both bugs have window as platform but I'm investigating a similar 
issue to 4153 on os x
I may -> it may ..
I'm on 2.7.6 os x , symtom is rebol just goes mad using up 100% CPU 
and never quits , using "ktrace -p processid" generate an empty ktrace.out
Oldes
25-Jan-2009
[12189x2]
And how do you start the script? Do you use -cs switch?
Because call is asking security question if you don't run rebol with 
at least -s switch
Will
25-Jan-2009
[12191x2]
-qs, the problem is when doing a ctrl-c on running cheyenne (not 
always, mostly after some load) traying hard to have a 100% repoducible 
code but nothing yet, hard
not even sure the problem is with call, what is sure is cpu goes 
full, the dns help process quit ok, ktrace on that process return 
nothing
Oldes
25-Jan-2009
[12193x2]
I'm testing it now with cheyenne and it seems not to be working... 
even if I do:
	print "Content-type: text/html^/"
	tmp: copy ""
	call/output/wait "dir" tmp
	probe tmp
CPU is fine here.. just the output is missing and there is error:
Error Code :  	300
Description : 	script error !
tmpnone has no value
Near : 	[probe tmpnone]
Where : 	protect-code
Will
25-Jan-2009
[12195]
sorry I may have been more clear, the code is in uni-engine.r, this 
line:

call/show join form to-local-file system/options/boot [" -qs " cmd]
not in a RSP, and not sure at all the problem is with call... 8/
Oldes
25-Jan-2009
[12196]
the above is not in RSP either.. it's as a cgi script. Cheyenne is 
not only RSP:)
Will
25-Jan-2009
[12197]
ok, thank you, now I need a guru with some tips on how to track down 
the issue.
BrianH
25-Jan-2009
[12198]
More backports: AJOIN

ajoin: func [
    "Joins a block of values into a new string."
    block [block!]
] [
    head insert copy "" reduce block
]


AJOIN is native in R3 and doesn't generate an intermediate block 
(it reduces in place), but even in R2 it has advantages:

- It always returns a string, no matter what the type of the first 
value in the block is.
- It is faster than REJOIN.
[unknown: 5]
25-Jan-2009
[12199]
Might change the description a bit to say that is reduces the block. 
 "Reduces a block of values and joins them into a new string."  Reducing 
is a security concern so we might want to ensure whoever uses the 
function is aware of this.
BrianH
25-Jan-2009
[12200]
Since that is the doc comment of the R3 version I will submit that 
concern as a trouble ticket in CureCode.
Dockimbel
25-Jan-2009
[12201x2]
Brian, in AJOIN, why not prefer the use of [make string! 0] instead 
of [copy ""] so that REBOL don't need to allocate a literal string 
to be used only as a prototype? That would reduce memory usage by 
one string buffer allocation.
I guess that memory usage is a high concern in mezzanines.
BrianH
25-Jan-2009
[12203x2]
COPY "" is faster than MAKE STRING! 0 (amazingly enough), and you 
don't have to allocate a literal "" every time, just once at LOAD 
time
Speed is a bigger concern for mezzanines, but there has to be a balance. 
We are doing more advanced tricks in R3 to increase speed and reduce 
memory overhead, but R2 is in bugfix and backport only mode right 
now.
Gabriele
26-Jan-2009
[12205]
Brian, did you compare with make string! reduce ? It may be faster.
DideC
26-Jan-2009
[12206x2]
In R3  (R2 is a very small bit faster, but I guess its related to 
the console) :

>> t: now/time/precise loop 1000000 [copy ""] print [t - now/time/precise]
-0:00:00.203

>> t: now/time/precise loop 1000000 [make string! 0] print [t - now/time/precise]
-0:00:00.25
Not a big difference if you consider 1'000'000 loop !
Oldes
26-Jan-2009
[12208]
I'm using this version:
ajoin: func [

    {Faster way how to create string from a block (in R3 it's native!)}
    block [block!]
][to string! reduce block]
[unknown: 5]
26-Jan-2009
[12209x2]
It is better Oldes.
There might be a reason why Brian didn't go that route.
BrianH
26-Jan-2009
[12211x3]
Oldes, I can't find any compatibility differences, so that should 
be fine. Use MAKE instead of TO though - it's faster.
TO does weird conversion stuff so it is slower than MAKE (which does 
*less* weird conversion stuff).
Paul: I was tired yesterday, which was why I didn't do enough optimization 
- that's the reason :(
[unknown: 5]
26-Jan-2009
[12214]
I'm not complaining Brian.  I always do the same.  Which is why it 
is always best to present mezz type of functions ot the community 
for scrutiny before they go into any builds.  Just a wise way of 
doing things.
BrianH
26-Jan-2009
[12215]
That's why I posted it here before I posted it in DevBase :)