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

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Gabriele
21-Jul-2005
[917]
does it have a GUI too?
sqlab
21-Jul-2005
[918]
no, just a plain console application accepting tcp socket connections 
and data
Gabriele
21-Jul-2005
[919]
is it doing anything woth noting during the awake? creating objects, 
or something like that?
sqlab
22-Jul-2005
[920]
When accepting a new connection, a new object is created.

After accepting new data there is mainly parsing, block and string 
creating, writing to the console and to files and sending a reply 
back
Gabriele
22-Jul-2005
[921]
did you check any other versions of command? (this is on the latest 
version, right?)
sqlab
22-Jul-2005
[922]
I did not see this with rebcmd2..55.3.1.alpha, but maybe I did not 
test with enough traffic from more than one sender at the same time.

I just remember that some of the interim releases were not stable 
enough regarding read/lines, so I was waiting for a (near) final 
release for intensive testing.


Now I am checking, if different behaviour of the sender has some 
influence.

Normally at least one sender establishes a permanent connection, 
but most sender open a connection, do their communication  and close 
the socket at the end.

That's the reason, why I know, that the crash happens after closing 
the socket.  The last message was always from one of the senders 
with a one time connection. He got his answer, but the receiver did 
not print the message, that the remote socket was closed.

Maybe it has to do with timing and or GC problems, as the crash happens 
mostly at a time, when there is more traffic, but never when there 
is always  continuous communication. When I play back the communication 
without interruption, there is no crash.
Gabriele
22-Jul-2005
[923]
my guess is that this will be very hard to figure out. please post 
all the info you can in a rambo ticket, then let's hope Carl will 
guess where the problem is. :)
JaimeVargas
22-Jul-2005
[924x2]
sqlab it will be good if you can do some pkt traces. Then later we 
can do some pkt replays to repeat the problem, and track it. We will 
need basically the server code. The client can be performed by the 
replay utility.
Server code and pkt capture. (pcap format is preferred this is done 
with ethereal).
sqlab
25-Jul-2005
[926]
Jaime: That will not be possible, as the data are subject to privacy.

i will try to narrow down the server and see if i can produce a crash 
with anonimized data.
sorry.(
Anton
26-Jul-2005
[927x3]
Right that does it. Feel/over is not always doing its documented 
job. "The over function is called whenever the mouse pointer passes 
over or off of a face."  (quote from http://www.rebol.com/docs/view-system.html
   )
view make face [offset: 100x100 pane: make face [feel: probe make 
face/feel [over: func [face action pos][probe action]]]]
The above example works but no longer works if you click and drag 
off the face.
JaimeVargas
26-Jul-2005
[930]
sqlab "anonimized data could work". We need to isolate the problem, 
and we all want a very robust rebol.
Anton
26-Jul-2005
[931x2]
So I will submit a bug report for that.

Also, I would like modifications to related ticket #3112 "How feel/over 
handles face vs subfaces":

- Type: should be changed from "Issue" -> "Bug"  (because I think 
it will be ignored otherwise)

- Importance: should be changed from "Undetermined" -> "Medium" at 
least.
Submitted the bug report.
Gabriele
26-Jul-2005
[933]
click and drag off
 -> that's the away action for the engage function.
Anton
26-Jul-2005
[934x2]
OK, so the above document needs to be changed to say something like: 
"... and not in the middle of a drag, whose events can be trapped 
with the engage function..."  ?
Thanks Gabriele, I am going to investigate some more. Perhaps you 
can add a comment to the report to change the doc instead (or at 
least).
Gregg
26-Jul-2005
[936]
In the works Anton. Thanks!
Anton
26-Jul-2005
[937]
Thank you, Gregg.
Graham
26-Jul-2005
[938x2]
well, the new rebcommand finally crashed on me too though took much 
longer than previously.  Usage jumped to 50% as before and stayed 
there.  I guess on a non hyperthreaded cpu, it would have jumped 
to 100%.
It's looking like I need to ditch odbc and move to using doc's mysql 
instead.
Anton
27-Jul-2005
[940x5]
Thanks again Gabriele. Even though I've read that document several 
times over the years, and styled many widgets, somehow I kept getting 
confused by OVER. It was that particular phrase "The over function 
is called whenever the mouse pointer passes over or off of a face." 
Every time I re-read it I believed it :)
Anyway, now the doc is fixed I feel a lot better.
Gabriele, #3112 shows a different issue and should not be dismissed. 
(I admit my last bug report was a little bit crazy, and I'm sorry 
about that.)
Ach! too hasty again. That issue can be solved by using OVER in combination 
with DETECT.  That misunderstanding was caused by the same wording 
in the documentation of OVER. I will make an example for that too.
Actually, maybe I am not too hasty. I am struggling to come up with 
an example that works as I want with the help of DETECT.
sqlab
27-Jul-2005
[945]
Jaime: Unfortunately I will not have so much access to the data and 
the time to anonymize it the next days for familial reasons.
When I am back, i will go on.
Gabriele
27-Jul-2005
[946x2]
#3112 was dismissed by Carl, so I guess he knew what he was doing. 
:-)
(or he was too quick too, i'll ask him anyway.)
Anton
28-Jul-2005
[948x4]
Thanks Gabriele! This is actually a burning issue for me!  I felt 
a bit ignored by that.
Anyway, I have been researching, and I found the bug note:
	http://www.rebol.com/docs/view-system.html

 "Bug Note: On current versions of REBOL, the event/face within the 
 detect function

 is not set to the proper value. It should indicate the target face 
 of the event, 
	not the face in which the detect event is used."


 If that is fixed, then it should be possible to filter conditionally 
 to face or subfaces,
	eg.

		detect: func [face event][

   if face = event/face [event] ; return event for this face, but none 
   for subfaces
		]


 and hopefully if a face does that, then it should get all 'over and 
 'away events, 

 regardless of subfaces. That is, to be able to know at any time whether 
 the mouse
	is in its rectangular area or not.
So I'm just going to check, but there should be a bug tracker item 
for this bug.
I searched for "detect" and did not find a ticket. So I will make 
one.
Ok, submitted a ticket.
Volker
28-Jul-2005
[952]
i think then detect should get both faces? also, isn't the source-face 
somewhere in the event? (asking, i am no expert there)
Gabriele
29-Jul-2005
[953x2]
about #3112: "BTW, the reason I dismissed it is because his test 
example seems invalid. He needs to add an over feel to the face in 
the pane.


There may be one issue however... which is that when moving from 
blue back to red, a FALSE over action does not occur.  However, have 
him submit with short and precise description and an example that 
does not use VID. (He can cut and paste the similar over example 
from the doc then modify it.)"
(quote from Carl
Anton
29-Jul-2005
[955x3]
OK, excellent feedback. I have been doing just that the last couple 
of days, following the style of the new documentation.
About the example being invalid. The subface has no feel intentionally 
by me. It is my opinion that the box face should not care about faces 
lower down in the chain in order to detect if the mouse is over itself 
or not.
OK, I'm going to do more preparation so I have the clearest example 
ever. :)
Volker
29-Jul-2005
[958x5]
binding problem when making objects from objects:
probe system/version
c1: context [dmy: 0 v1: 1 f: does[v1]]
c2: context [dmy: 0 v2: 2 f2: does[v2]]
c3: make c2 c1
probe c3/v1 probe c3/v2 probe c3/f probe c3/f2
print"other way round"
c3: make c1 c2 
probe c3/v1 probe c3/v2 probe c3/f probe c3/f2
2.6.0.4.2
1
2
2
2
other way round
1
2
1
1
the results of the functions are wrong. they take always the first 
value in the object, where the word was on construction. not the 
index the word has after the make.
rambo?
Gabriele
29-Jul-2005
[963]
seems a bug to me.
Volker
29-Jul-2005
[964x2]
i go reporting.
done
Anton
31-Jul-2005
[966]
Yep, looks that way.