AltME groups: search

Ok, I'll rambo it.

Rambo'd it.

It's not in RAMBO.

R3 doesn't have this problem, but it seems that clean-path doesn't 
do anything with tildes. (Maybe R3 clean-path is not using the operating 
system to do path expansion.)

Added to RAMBO.

ok, let's elaborate, so we can see if this is something that is in 
RAMBO.

(If one on RAMBO is not there already.)

put it on RAMBO. it is the safest place to catalog such bugs.

Gonna check Rambo.

If you think it is a bug Anton, then you should report it to Rambo 
assuming your talking about R2.

There are no tickets that match a search for "bind?" in Rambo.

I'm finding a bug in loop function.  Anyone know of a problem with 
loop.  Heading to Rambo...

Given RAMBO, the R2 bug database, is web available it should not 
be too much of a problem:
http://www.rebol.net/cgi-bin/rambo.r

got a partial answer from here http://www.rebol.net/cgi-bin/rambo.r?id=4113
is that window specific?

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&

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.

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.

Looks like its a RAMBO report then, rather than curecode :)

Max, I think that has been reported many times, eg. http://www.rebol.net/cgi-bin/rambo.r?id=4121&

I don't think you should report it to RAMBO. Keep it predictably 
unfixed and undocumented forever.

post it to RAMBO and I'll flag Carl on R3 chat

Henrik: how many native bugs have been fixed in R2 from RAMBO reports 
since 2 years? There's currently 959 open tickets in RAMBO, how much 
of the reported issues and bugs will ever be fixed?

Doc, how many R2 releases have happened in 2 years? One, and it wasn't 
a bug-fix release. But more releases are coming, and more often. 
So report stuff in RAMBO - it will do until we get those tickets 
migrated to CureCode.

Is RAMBO still monitored for R2-related bugs?

And you have said that you will help process the RAMBO tickets when 
the time comes, by assisting with migrating them to CureCode where 
they can be dealt with.

I expect that there will be a new R2 release relatively soon, but 
we can't schedule it yet due to external circumstances that affect 
the people working on it. That doesn't mean that work on it has stopped 
or should stop, and it doesn't mean that you should give up on reporting 
bugs. Please use RAMBO until we can retire it - the tickets should 
be there when we need them.

Reporting the wait bug documents it, even if it gets fixed or not, 
so other users can (as I do) browse through RAMBO to either confirm 
the bug or to see if someone offers a fix or a workaround. It would 
be a problem if RAMBO was a closed system where you could not freely 
study the reports, but you can, and Curecode is the same. Do people 
not ever take notes, when stumbling onto something unusual?

Brian: no problem for assisting in migrating RAMBO to CC, even if 
the tool is not the main issue IMO.

still rambo.

Someone should point Carl to this, I'm pretty sure he wants to know: 
http://www.rebol.net/cgi-bin/rambo.r?id=4398&

can someone rambo this?

http://www.rebol.net/cgi-bin/rambo.r

This is the bug database for R2 and before

http://www.rebol.net/cgi-bin/rambo.r?id=4018&

Only 4 years old.

Goog memory (and you were fastest than me at finding the RAMBO ticket).

I was betting there was a RAMBO ticket. Ran into this bug earlier 
this year.

http://www.rebol.net/cgi-bin/rambo.r?id=-4777&

Delete does not take a port spec

( Gabriele are you still reviewing Rambo submissions? )

I looked on rambo and saw no entries for encloak

I'd better log this to rambo

RAMBO Ticket #-4779

Hmm, rambo only goes to 4402 for me here. Most recent doesn't show 
your ticket.

Ah, I missed the negative sign, and forgot that Rambo did that.

Louis <What is the best way to submit this to RT?>
Add it as an enhancement request to Rambo:
http://www.rebol.net/cgi-bin/rambo.r

And thanks for testing the code -- glad it worked.......One enhancemnet 
suggestion: you may not need the individual "show face" lines if 
you have a show layout-name at the end.

Sunanda, it has been submitted to rambo. Thanks again!

this might predate RAMBO... maybe the fix never got included in the 
release, or its there and my latest code is just not trying to use 
the proper function within the multi object...

so will you RAMBO it? 1.3.3 is right behind the door... ;))))

I'll RAMBO it right away.

rambo it?

well, IMHO those also belong in RAMBO..

Hi, I just received reply from RT towards my following request:

----------

I have also suggestion towards View Desktop. IIRC there is also RAMBO 
entry about it - please, lower the timeout, because Desktop tries 
to connect to Internet by default, and if someone is behind the proxy, 
it is frustrating experience - you can't close blocked Rebol even 
by window close button. As for me, I would prefer not connecting 
by default, and changing "Local" to "Connect", "Disconnect" duo ...
--------------


On Viewtop, I agree.  Let's develop a good method for that, and put 
it in the
next release.


There are a few choices.  1) Shorter timeout, 2) popup request to 
connect,

3) connect on demand (after clicking on an icon that has no file).

Perhaps you know some users who have a suggestion?

-REBOL Support

Ok, maybe a rambo ticket then.

if you have a working example of multiple dash/stroke line-pattern 
which does not crash when shown many times, I'd also like to see 
it.  This way I might understand what makes rebol crash and have 
the RAMBO ticket updated !?

That bug is in rambo right ? Maybe send a feedback to raise its priority. 
It is a crashing bug, so it should be pretty high. It may just be 
fixed in this round.

yes its in rambo... I'll be sure to nag Carl about it when the alpha's 
start rolling out ;-)

(should move bug discussions to RAMBO group)

posted in rambo...

You might ask rambo group about it being a bug.

So I might make a RAMBO bug report on that.
Anyone have any comments before I do ?

I've put it in RAMBO.

I wonder if I should put my proposal in RAMBO now as well, but I'd 
like the code to be approved here first...

We should have checked RAMBO database - Romano posted this one three 
years ago
Do not detect hot-keys when a focal-face with caret is active
http://www.rebol.net/cgi-bin/rambo.r?id=3372&

There are some bugs in View that causes leaks when using networking 
and GUI events at the same time. That's only a very rough description 
of the problem. There are more accurate descriptions of this problem 
in RAMBO.

not other than trying to avoid the specific cases that are in RAMBO. 
that might be hard, though.

What I found was - RAMBO Ticket #3593.
Is it that case?

I have simple interfaces, that normaly is unviewed, but I have tray 
incon. And in background there is two database connections.

Yes, that's the one. There are other leaks as well:


http://www.rebol.net/cgi-bin/rambo.r?sort=1&limit=1&cmd=Search&id=&pattern=leak

http://www.rebol.net/cgi-bin/rambo.r?id=4269&

That works!

Thanks Anton, and Gabriele and Henrik for the help....Especially 
Anton for the fix!
I think the honor is yours in entering it into RAMBO :-)

I spent nearly as long reducing the problem to my 3-line bug report 
:-) It could have been any one of several other issues in the actual 
application.

Anton, it could and should also live on in RAMBO and the code base 
for REBOL3.
Do you want to RAMBO it, or will I?

Sunanda, Ok, I'll submit it to RAMBO as is. (I don't think it has 
much relevance with R3, though.)

Gabriele, Ah.. I forgot to look at the SDK, actually. I'm not in 
the habit of it.

Submitted "wake-event pop-face patch" to RAMBO.

anyhow, it should be RAMBO'ed, so others can see it as a known bug.

Still RAMBO AFAIK. Unless they've moved things to CureCode.

yep, I checked rambo, no ticket for this.

Can anyone confirm this is a bug in View (VID), so I will post it 
to RAMBO:

gui: layout [f: h1 100 "test"]
f/text: does [probe "testing"]
view gui


;click on the text, drag --> crash rebol.exe. Tested on XP Pro SP3. 
View 2.7.8.3.1.1

;function get called when the text clicked, crash happens when dragging.

posted to RAMBO as a low importance bug.

They'll be fixed when the RAMBO detect face bug referred to previously 
is fixed. In lieu of that I made two changes:


 1) Optimized tooltip checking (saves about 5-10% CPU in the case 
 of tour.r)
	2) Tooltips now default to off


I'd like to know how they seem to work for Robert as the code was 
a 100% cut & paste job from his. I suspect the key is to run it under 
windows and ensure that not only is Task Manager up but that the 
RebGUI app (tour.r in this case) is in the foreground. I noticed 
that clicking between a running tour.r and Task Manager (with tooltips 
on) makes a big difference between the reported CPU usage. Perhaps 
Robert is only seeing the later (or is running it on hardware that 
obscures the problem ... I'm on an old Pentium M 1.1GHz here).

commented out are links to lib:// ( rebol.org scripts ) and # ( to 
rambo ) as they were not needed for this script.

Borrow the same hack from VID and hope http://www.rebol.net/cgi-bin/rambo.r?id=3867&
is fixed!

I want to text the alpha to see if it still has a nasty bug that 
I couldn't post in Rambo because it reveals source code.

ICarii yes but that always been the case hihihihihi .... I remember 
rebo 1.3 .... Mwuhahahaha  full amator dev .... oups sorry. So it 
first start as 1.3 is only solving the loooooooooooooot of bugs posted 
on rambo by the community then it turns to Ho and how about adding 
AGG  to ViD ? and then it was Hey I  have a big new thing REbSERVICE 
!!!! and ASync  .... Bhuuuuuuuuuuuuuuuuu

Notes, yes, or at least RAMBO.

Yes definately Rambo those things.

I submitted the week's bugs to RAMBO.

http://www.rebol.net/cgi-bin/rambo.r?id=4314&

Talking about that : http://www.rebol.net/cgi-bin/rambo.r?id=4363
This one was a show-stopper for me recently. Seeing such bug scared 
me about using money! datatype in R2. I had to rewrote several parts 
of a customer product using integer!-based fixed precision instead, 
just to be sure that amounts in the product would be correct.

It's like when carl opens RAMBO some years ago the goal was to get 
some tickets time to time to do some bug fie time to time but as 
teh community worked alot on tracking bugs and doing suggestion the 
number of tickets was massive do you think that's the same thing 
being alone to solve 10  bugs than being alone to solve 4000+ bugs 
?

Steeve, in may experience the Curecode reporting system is far more 
effective than RAMBO.

There is clearly a lot f effort (thanks, Brian!) put into analysing, 
categorising, prioritising and fixing issues raised via Cuecode.


Not everything, of course I've added issues that have languished 
a long time, and some that have been dismissed. But they are outweighed 
by the ones that have been fixed in a few days.

It may be a lottery, but it is winnable :-)

Pekr: "Steeve - your attitude is the same what DocKimbel showed here 
some two weeks ago. I thought that I am talking to adult ppl, and 
I really don't understand such childish behaviour". 


Are you sure you were thinking about me? I just re-read my old 2 
posts about money! datatype, I don't see what's childish in reporting 
a bug in RAMBO and warning about that?

That's why it will likely be replacing RAMBO too.

Peter once ( Rambo#3518 ) objected against some things being inequal. 
I could use more opinions on this.

(it is related to the Rambo#3518 ticket)

Ladislav: I reported bug #3518 in Rambo mainly because the behaviour 
of the '= function is not consistent. My thinking was if 1 = 1.0 
why doesn't  #"a" = "a"?


It appears that the '= function acts as the '== function unless the 
types are number!. 


I have come to accept that Rebol has been designed pragmatically 
and, understandably, may be inconsistent at times. I thing this makes 
the need for accurate documentation essential. I would hope that 
the function help for = can be changed to accurately reflect the 
functions behaviour.

[post removed by library team. (sunanda)]

same could be said for RAMBO :-)

I thought that RAMBO tickets wouldn't be indexed by search engines...after 
testing, it was a wrong assumption.

(i'm not saying it should be posted to rambo, i'm saying the cat 
may be out of the bag already. maybe a direct message to Carl would 
be a good idea, though i wouldn't hold my breath about R2 updates)

but yes I would say R2 lasted too long ... carl was glued in endlessly 
bug correction and few where the real improvements... the major addition 
in R2  was the AGG/draw dialect which since then have not evolved 
a bit... look at the number of tickets in old rambo. So yes starting 
with a ew base and bring alot of enhancement was a certain thing 
the problem is along the process we lost alot of people mainly interrested 
in rebol but not seeing it evolving fast anough and that how do you 
solve it ?

Geomol found a way to crash R2 with a C stack dump through self modifying 
code. It does not occur in R3, but it could be considered a security 
hole in R2, so the question was whether it should be made public 
in RAMBO. Since this group is already public, that's too late. But 
what would the official stance on security holes in R3 be? Should 
they unconditionally go to curecode?

We should RAMBO that one.

Still, I can't make Cheyenne work as non-root user : the HTTP log 
file keeps being written as root:root even if the main Cheyenne process 
is own by a non-root user. The culprit seems to be the REBOL helper 
process, forked by the main one during REBOL internal boot process 
(so before starting to run user code). I found no way to setuid this 
child process (seems forbidden by the OS?), so it keeps being owned 
by root...


Here's my typical test case under linux (Ubuntu 8.04, /enpro 2.7.6, 
latest SVN revision,using [user "dk"] in config file). I'm running 
the test from a root shell to avoid issues of sudo with REBOL binaries 
(RAMBO #4306) :

;--- launching  Cheyenne process  ---
[root-:-dknux]:/mnt/dev/Cheyenne# ./cheyenne &
[1] 20179


;--- notice the root process below (the only one that Cheyenne can't 
setuid( ) ---
[root-:-dknux]:~# ps aux
[...]

dk       20179  0.2  1.3   9028  6716 pts/0    S    22:21   0:00 
./cheyenne

root     20180  0.0  0.1   2360   600 pts/0    S    22:21   0:00 
./cheyenne

dk       20182  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20183  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20184  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20185  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20186  0.1  0.9   6264  4968 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20187  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20188  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20189  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

;--- no HTTP log file for now ---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 0

;--- I'm sending a request to http://localhost/---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 1
-rw-r--r-- 1 root root 77 2010-09-09 18:19 default-access.log


The log file belongs to root:root, so it must have been generated 
by process 20180. Killing that process prevents Cheyenne from outputing 
any new log file (but Cheyenne keeps serving all requests). I thought 
that the helper process was only used for enabling async dns requests 
when OS doesn't support it natively?...<vent>Like REBOL GC's rules, 
this helper process remains a mystery even after 10 years of reboling...I 
guess these secrets are worth millions of $ to be kept undisclosed 
so far...</vent>

Any ideas?

Since many of the 2.7.8 native fixes were done for Doc...

 Brian, where can I see this list of fixes? I guess on RAMBO, but 
 it's down since yesterday...

Those improvements sound good to me. This might be enough to start 
planning to make a REBOL 2 project and migrate the RAMBO tickets 
to it.