World: r3wp

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.

I agree.

But you already mentioned C-level bug fixing - I didn't see the need 
to repeat what you said :)

Well, that was just to be sure there's no misunderstanding :-)

:)

I plan on putting cheyenne web-app in usage (on linux vps) this week 
... does this mean that until the bug is fixed it won't work properly?

I've workaround it. It was only appearing on resetting workers using 
USR1 signal. Now I've fixed it and it seems ok. I'll release the 
fix tonight, so everyone can test it.

great thanks :)

janko: will that be on linode?

yes, probably it will be... I have to decide if I should put this 
on some local vps that I already have for some local project (in 
my country), or if I should reactivate the linode server. I still 
have the account there but I removed the servers at linode so money 
is preserved waiting to start again :)

Anyone know what a decompress script Error problem -3 means?

>> decompress to-binary data
** Script Error: Invalid compressed data - problem: -3

like, where do I look for a "problem -3" meaning? (maybe it means 
a bad compressed crc, or maybe data out of range or ???)

perhaps the decompression length? AFAIK, REBOL needs to know how 
much needs to be decompressed before it will do it.

Carl? I don't think Rebol checks for CRC. Whatever it is, the data 
are not decompressable from REBOL

but problem is maybe on your side... it's strange that you do to-binary 
data. If you read the data as text, REBOL changes line breaks so 
it modifies the content.

It is gzip data, and the to-binary was a hack.  It doesn't work either 
way.  I thought the REBOL script in the library, gunzip.r might work 
for me, but it is a rather crazy script that I don't quite understand, 
but the GUN in GUNzip.r shot me in the foot.

decompress wants a string, and binary is a string, so that's what 
made me think to do to-binary...