World: r3wp

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.

If a few ppl can confirm this rapidly, I'll post a ticket in RAMBO 
and will knock on Carl's door to fix that asap.

confirmed os x 10.5.6/intel /core 2.7.6

Doc, iirc there was a same sort of isseu with system ports in pre-2.7.6 
and TCP and Gabriele got around it in the Detetcive project. He also 
wrapped up the async-call and made it available for linux then. I 
have it, he has it, but I suspect Gabriele can fill you in on the 
details. Let me know if (and how) you want it.

Are you thinking about the async event TCP issue ('connect event 
IIRC) when used with the system port?

Well, thanks for the offer, having Gab's Call script would save me 
some useful time. Anyway, I would rather prefer Carl to fix this 
issue. Carl maybe forgot, but all RT's customers are running on R2, 
not R3. The priority should be clear.

Yes, but not sure what it was anymore. I know Gabriele ran into something. 
Anyway, we have an async-call - basically the working linux version 
of your libv

Where do you want it, mail in this profile?

Yes please.

Are you in Qtask REBOL SIG? Then I'll post a link to the file there

Ah, ok, mail

I receive emails from Qtask's lobby.

Done

United we stand
 ;-)

I agree...does that mean that we will all get some shares of RT once 
R3.0 will be released? ;-)

LOL

You mean open source it...

Well, I thought about that for a few seconds...

More seriously if Carl doesn't plan to support R2 anymore, he should 
state it clearly so we all can decide upon that.

anyone else on non window os can test and confirm please?

I made a post about 2.7.6 being near the end of life of the REBOL 
2 line.  I was told by Carl that I was mistaken ... completely.  
That was oh, 8 months ago or so.   At that time; REBOL 2 is still 
very much an RT supported product line and there are no plans to 
change that stance.

Does anybody has a script which for example prints out all REBOL 
actions or natives?

Oldes;  one-liners can be had with
help action!
help native!
or were you looking for more?

actions: copy []
natives: copy []
word-names: first system/words
word-types: second system/words
while [not tail? word-names][
	switch type?/word first word-types [
		native! [append natives first word-names]
		action! [append actions first word-names]
	]
	word-names: next word-names
	word-types: next word-types
]
?? actions
?? natives

I'm almost ready with the lexer for Python's Pygments syntax highlighter. 
Just need to define the keywords.. All the time I do it I don't know, 
which one to choose:)

Yes, but what does SUPPORT of R2 mean?

The only support I expect is R2 C-level bugs fixing.

Oldes, confirmed on Kubuntu 7.10 rebview2.7.6.4.2

After 5 seconds, client.r and foo.r are present:

$ ps aux | grep reb[v]iew

anton     9006  0.0  0.4  13268  9656 pts/1    SNs+ 00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9007  0.0  0.0   6084   536 pts/1    SN+  00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9008  0.0  0.0   6084   464 pts/1    SN+  00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9072  0.3  0.3  11952  8228 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws client.r

anton     9073  0.0  0.0   6128  1084 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws client.r

anton     9074  0.0  0.0   6084   468 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws client.r

anton     9079  0.5  0.3  11828  8068 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws foo.r

anton     9080  0.0  0.0   6084   536 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws foo.r

anton     9081  0.0  0.0   6084   464 pts/1    SN+  00:35   0:00 
/rebol/rebview2.7.006.4.2 -qws foo.r

After foo.r finishes waiting:

$ ps aux | grep reb[v]iew

anton     9006  0.0  0.4  13268  9656 pts/1    SNs+ 00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9007  0.0  0.0   6084   536 pts/1    SN+  00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9008  0.0  0.0   6084   464 pts/1    SN+  00:33   0:00 
/rebol/rebview2.7.006.4.2 -s -- do-anton-user?: true

anton     9072  0.4  0.0      0     0 pts/1    ZN+  00:35   0:00 
[rebview2.7.006.] <defunct>

anton     9079  0.4  0.0      0     0 pts/1    ZN+  00:35   0:00 
[rebview2.7.006.] <defunct>


And when close port is done before call in the awake function, then 
client.r becomes defunct while foo is still waiting.

Sorry, that was a bit large.

Doc: "The only support I expect is R2 C-level bugs fixing."


Don't forget mezzanine bug fixing and the backports, which are community 
support. No new C-level features are likely, except for backported 
tweaks to the natives. New mezzanine-level features we can add ourselves, 
but remember that R2 is in compatibility mode right now. We shouldn't 
break the existing R2-compatible code if we can avoid it, since that 
compaatibility is the main advantage of supporting R2.


Future releases of R2 will have even more backported functions from 
R3, but these will be in a separate file of the source. It is likely 
that this separate file will need to be loaded if you want to use 
its functions, so there will be no new predefined words by default. 
You can load the file if you want to make your code more R3 compatible. 
This is likely the best way to ensure compatibility.

Anton: thanks for taking the time to test it.

Brian: I should have precised "from Carl". Obviously having mezz 
backported from R3 is a good thing to make the transition smoother. 
But it's not like R3 will become really usable in a month or two. 
We're talking about years before reaching 3.0. In the meantime, R2 
C bugs (not new C feature) have to be fixed one way or another in 
order to support those that use REBOL to run businesses since years.