World: r3wp

Since that is the doc comment of the R3 version I will submit that 
concern as a trouble ticket in CureCode.

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.

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.

Brian, did you compare with make string! reduce ? It may be faster.

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 !

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]

It is better Oldes.

There might be a reason why Brian didn't go that route.

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 :(

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.

That's why I posted it here before I posted it in DevBase :)

Wierdly enough, the make string! reduce block version of AJOIN is 
slightly faster in R3 than the native AJOIN, though it does have 
that intermediate block overhead - AJOIN could use some optimization. 
Who said mezzanines had to be slow?

heh

Yeah, I would think we would want to change that then in R3 so that 
a mezzanine is not performing faster than native code.

Side effect of slow interpreter loop and fast natives.

The other way around, Doc. Mezzanines are not slow. It all depends 
on what the function is doing. Most of the time any interpreter overhead 
is dwarfed by the work the code is doing. This is why REBOL can be 
so fast when do much of it is written in REBOL.

Right for R3 AJOIN exception, other way around.

BTW DideC, if you use now/precise instead of now/time/precise and 
use difference instead of - then you don't have a problem around 
midnight.

...or just avoid benchmarking arround midnight ;-)

Thanks for the advice anyway.

good tip Gabriele, thx

about my problem (a couple of messages above) I can confirm that 
the problem doesn't exist with 2.7.5.

2.7.6, supposedly fixed [call] but did it introduce a new bug? has 
it maybe to do with hevy cpu, timing, rebol dns helper process?

I'm having a hard time producing code that reproduce the bug, if 
anyone can provide a piece of code that could stresstest [call] I'd 
be gratefull! 8)

or a problem with the GC upon quit when there are many words ?

I posted a new function in the mezzanine thread at the Tretbase REBOL 
forum http://www.tretbase.com/forum/viewtopic.php?f=8&t=30&p=130#p130

Nice start,  Paul, to pulling the teeth of code you do not want to 
execute

I think you need to handled action!s too, otherwise some executable 
code can slip by:

>> defunction [abs trim change make select remove sort]   ;; etc, 
anything that is an action!
== [abs trim change make select remove sort]

It is an easy modification but I actually made it to allow actions 
as I was using it briefly for that purpose.

Posted the get-block function to the mezzanine thread on the Tretbase 
forum http://www.tretbase.com/forum/viewtopic.php?f=8&t=30&p=131#p131

Is there a simple way to convert a char number to the actual integer? 
(i.e. to-integer #"5" giving 5 as a result)

I usually go with:  to-integer to-string #"5"

Thank you

>> to-integer form #"5"
== 5

Saves a couple of chars :-) (but profile it, it might be slower)

to-integer #"5" - 48

-48 + #"5"

>> 0 + #"5"
==53
Usually, i use the the following tricks:
you can add several chars with integers in that way.
If the first value is an integer! it's returning an integer!
If the first value is a char! it's returning a char!

>> 0 + #"5" - #" "
== 21
>> #" " + 21
== #"5"

i mean, it was what chris tried to explain..

Here's another way which is arguable cleaner, but more verbose and 
less efficient: p: "3" (index? find "0123456789" p) - 1

arguable => arguably

Thanks again, guys.

Someone had played around with doing huge integers in REBOL a while 
back, right?

I have a partial string-math library. Not all ops, but no size limits.

I have a 24 bit math implementation to do RSA  but never converted 
to or from other bases. It is from before Holgar did  encryption 
with thebignum library  nativly in  core/view which renders mine 
moot

and it isarbitrry precision as well

I've just hit a serious issue in 2.7.6 on UNIX platforms today.


Briefly: CLOSE on TCP ports doesn't work anymore if CALL is used 
before CLOSE, in a AWAKE handler.

To reproduce this bug, get the tests scripts here :

write %server.r read http://softinnov.org/tmp/server.r
write %client.r read http://softinnov.org/tmp/client.r
write %foo.r read http://softinnov.org/tmp/foo.r


Then, read the comment section in %server.r and launch it to see 
by yourself : do %server.r

Notes:
     o Windows is not affected by this issue.

     o I consider this a major issue for all REBOL server applications 
     working in async mode and spawning processes.

     o I'm posting first here before RAMBO, so that people can test and 
     point out any possible bad interpretation from me.

Using LAUNCH instead of CALL shows the same issue.