AltME groups: search

RAMBO is for technical issues, and not policy issues.

could you read twice, please? ;-) IIRC, rambo is also about reporting 
inconsistencies in documentation etc., and if I am not alone who's 
one of Win95 machines does not accept View 1.3 and website tells 
so, then I regard it being incorrect.

(no ticket appears in RAMBO, searching for "while")

I had done some enhancements to request-date in the days of "View 
1.3" project (2 years ago).

The result is in RAMBO, but not the code http://www.rebol.net/cgi-bin/rambo.r?id=3058&
So you can find it here with some demo code :
do http://membres.lycos.fr/didec/rebol/request-date-enhanced.r

whatever - Chat for e.g. - RAMBO is bug reporting related group ...

Gabriele, regarding 
http://www.rebol.net/cgi-bin/rambo.r?id=3918&

I found my patches still cause visual artefacts in certain circumstances, 
so this report should be cancelled.
Sorry about that.

(It does demonstrate, at least, how to iterate PROGRESS style in 
a usable way, but I'll better publish that elsewhere.)

Came across this at work today ....

REBOL/View 1.3.1.3.1 17-Jun-2005 Core 2.6.0

>> to integer! ""
== 0
>> to decimal! ""
** Script Error: Invalid argument:
** Near: to decimal! ""


Shouldnt that return 0 like to integer!   ??

Cant see anything in Rambo for it though ...

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

dont have access to rambo could someone submit an error in the word 
brower for me.  in the find box a down arrow errors with: ** Script 
Error: index? expected series argument
 of type: series port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first

RAMBO 3939: In response to your question, I propose an alternative. 
Instead of changing to-dec and to-int to handle decimal and integer 
(respectively) source values correctly (slowing down the common case), 
add as-dec and as-int opcodes that act as assignments when given 
source values already of the corresponding type, letting those opcodes 
have the overhead when you can't be sure the source is of the opposite 
type. Also, change to-int to assign 0 instead of 1 for invalid source 
values, to be consistent with to-dec assigning 0.0 then.

I don't have an account on RAMBO, so there is no other way for me 
to reply to the question asked of my submission.

For that matter, I just submitted another rebcode proposal to RAMBO, 
and then noticed some code in the fix section that I wanted to change. 
The submitted code still works, but I would still like to clean it 
up a little. If I had an account on RAMBO, would I be able to fix 
my own submissions?

Rambo needs "add comment" section ... I am not sure Carl checks regularry 
here ....

Send it to RAMBO :)

ah, I should read first ... dunno if Rambo allows you to edit your 
submissions ...

RAMBO 3939 still has a status of "Waiting".

On RAMBO 3942 in the fix code, in the either statement please change 
the test to empty? labels and swap the code blocks, thanks. It'll 
work the same but will be cleaner. Like this:
        either empty? labels [rule: opcode-rule] [
            label-rule: make block! length? labels

            foreach [key val] labels [insert insert tail label-rule to-lit-word 
            key '|]
            clear back tail label-rule

            label-fixup-rule: [there: label-rule (there/1: 2 + select labels 
            there/1)]

            label-error-rule: [label-rule (error/with here "Cannot use label 
            here:")]
            rule: fixup-rule
        ]

Submitted my proposed alternate to 3939 as a new RAMBO entry. Maybe 
that will work.

Should I make RAMBO entries for the other rebcode enhancements we 
came up with in the Rebol Enhancements group?

Bug 3486 has status PENDING but seems to be already fixed. Maybe 
other bugs are fixed too, but RAMBO says otherwise. Adding comments 
to RAMBO should be really great.

Why do we write this under "RAMBO"? :-) It's not a bug!

Doesn't seem to be reported in rambo anywhere.

You should RAMBO it

Ok, submitted to RAMBO.

Ah, just reading through rambo tickets, looks like this one is fixed 
already for View 1.3.2

kru, probably what you see in RAMBO :-)

Henrik in RAMBO I can see only bugfixes, but no informations on what's 
going to be added (if anything will be added).

(IIRC that was posted as a bug in RAMBO because there was a crash 
in some case...)

OT. AFAIR in previews AltMe REBOL worlds, there was a "WISH" group, 
could be created again? or is correct to post wishes in the RAMBO 
group?.

Yes, there is a wish category for rambo submissions. (Be sure to 
also list the reason you wanted it.)

It does not appear to be in Rambo.

I suppose the work-around is just to use face/text instead of value.

RAMBO it !
Accessors where made a bit to quicky OMO.

field are special case due to password input, and the accessors does 
not managed this well OMO.

Maybe looking to it and proposing correction into RAMBO would help.

Anyone else see the problem that I see with 'alias:  http://www.rebol.net/cgi-bin/rambo.r?id=3986&

(Submitted my bug above to RAMBO.)

Apparently REBOL doesn't like set-paren!s  http://www.rebol.net/cgi-bin/rambo.r
 This is a really ugly bug that needs fixed ASAP, kills the interpreter 
no questions asked and no information given.

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

RAMBO #3460. It's come up before.

mymistake please delete RAMBO Ticket #-556

Will, might be better to submit a new rambo ticket to ask to remove 
the old one. Then it's not forgotten, and you know the people actually 
capable of closing the ticket will have to review it.

I posted two new tickets concerning UDP to RAMBO:
- "no-wait UDP ports and blocking COPY"
- "no-wait UDP ports and READ-IO"
I see the blocking problem as critical

added a new 1.3.2 bug to Rambo:
b: head insert copy [] make list! [1] produces an invalid block

RAMBO Ticket #-578
Exists? corrupts http protocol.

Are Rambo tickets now negative ??

Mmm, don't see it in RAMBO already. Anybody can confirm ?  By the 
way, SAVE or SAVE/ALL doesn't make a difference, but it must be LOAD/ALL 
to show the inconsistency.

Hi, i just posted a new bug on rambo: When calling 'request-file 
and clicking on Cancel, the value returned is %none instead of none 
--> makes more complicated to test the returned value. I tested under 
Windows XP

Just send a feedback to RT to ask them to disregard the rambo ticket

Anyone had problems with 'switch and datatype! I've reduced the problem 
down to:

t: func [v] [
	select [
		#[datatype! integer!]	["A"]
		#[datatype! decimal!]	["B"]
		#[datatype! block!]	["C"]
	] type? v
]

>> t 1
== ["A"]
>> t 1.0
== ["B"]
>> t []
== decimal!

Unless there's an obvious explanation, I'll RAMBO it.

RAMBO it, please, they will dismiss it at max, if it is not a bug, 
but I think it is ...

It's in RAMBO #4040 http://www.rebol.net/cgi-bin/rambo.r?id=4040&

RAMBO #3650 "crc32 function added to checksum" - I have just contributed 
a crc32 function to the rebol library. It's quite slow, but the rebcode 
version is fast enough. CRC-32 is still used by common tools (archivers...), 
and an implementation in the 'checksum native would be useful.

crc-32.r with gigabytes files: [don't do it] - it works, the memory 
used isn't size relative - but on a 1GHz PIII, the speed is < 300 
kbytes/s! 
rebcode version is a lot faster (>2Mbytes/s), but 
1) rebcode isn't part of official releases 
2) the rebcode version of 'crc-32 needs whole file in memory.

so, back to RAMBO: #3650 - I vote for 'crc32 as another 'checksum/method, 

and maybe a RAMBO ticket for a port aware version of 'checksum would 
be a good idea.

I understand, thanks. Anyway, I submited it into Rambo.

Gab or some RAMBO editor, can you update RAMBO ticket #4087

there is a workaround from Edgar which is to so system/ports/serial: 
[ttyS0 ttyS1] to patch the ubuntu port of REBOL.  I suspect that 
can be done in a future release for ubuntu, but at least for now 
I have a workaround.

ChristianE: put it into RAMBO please.

Should I put these to RAMBO or not? (question for Gabriele):

Ladislav, yes add it please. i remember seeing a report about this 
but maybe it never got into rambo.

the above quirks posted to Rambo

I just posted a RAMBO entry (currently #-663), accidently before 
I was finished writing it. There are errors. What do I do?

I got the example code wrong, and the description should have referenced 
an older RAMBO entry (3575) that was wrongly prioritized.

I backed up, fixed it and resubmitted. Whoever is watching RAMBO, 
please disregard #-663, it is superceded by #-664.

OK - submitted to RAMBO.

OT: Is there are Rebol based RAMBO editor available that works on 
the web version's database?

I wonder what happened to the AltME Bug Tracker. I thought it was 
way cooler than RAMBO.

It was used in the Old View 1.3 project world 2 years ago.
All its content was put in RAMBO when RAMBO was up and running.

oh... I already see it in RAMBO as #4086 :-)

Ladislav, while it nice to see APPLY being put on the front burner 
(RAMBO 3575), I have a problem with Carl's proposal. His examples 
clearly do not evaluate their function argument (like HELP or SOURCE), 
but this would prevent using APPLY with anonymous functions. It would 
be preferable to require the function to be specified with a get-word 
like this:
    f: func [a b] [a + b]
    a: [1 2]
    apply :f a

the clipboard bug mentioned in AltME is not rambo'ed? it would be 
easy to fix, wouldn't it?

Is there any simple way to add a screenshot upload function to the 
RAMBO script? Or has anyone done it already?

No, and the RAMBO source is not open, as far as I know.

I will rambo it if there are no objections.

No objections on anything that causes a segfault (unless, of course, 
it's already in rambo somewhere.)

anyways... I'm getting OT... (rambo list)

Submitted the above crash code to RAMBO.

user poll: what do you think about RAMBO #3518?

WRT the rambo #3518, I think these just expose "not yet implemented" 
equalities.

rambo'ed

I want to improve the esmtp:// protocol to fix a few bugs reported 
to RAMBO... and make it more conformant to the RFC

RAMBO'ed

oldes, rambo the documentation problem.

older versions did not evaluate paths. since newer version do, we 
need 'a/b to work. dunno if this is in RAMBO... but it needs to be 
fixed.

it's not a bug that they are evaluated (in fact it was requested 
in a rambo ticket). it's a bug that - since now they are evaluated 
- lit-paths are not used to match paths.

i would have to discuss what follow before posting it in Rambo

So that looks good. Unless anyone has any objections I will post 
it to RAMBO as a feature request.

OK, I posted a RAMBO ticket for this.

Geomol, that is a known bug in ssl, see RAMBO #3532, it is interesting 
to know that it affects HTTPS with proxy

Graham: I'm not sure, if the copyright on prot-http.r prevent me 
from posting it, but I can tell you, what I added to it. My work-around 
consists of 2 extra lines after line 46, which in my version is:

append http-packet "^/"

My extra lines are:

replace/all http-packet "^/" "^M^/"
remove back tail http-packet	; Because a newline will be added.


It's not a nice solution, but it works. A better way would be to 
open the port with a /with refinement and CRLF. See RAMBO #3532.

This may be the problem. http://www.rebol.net/cgi-bin/rambo.r?id=3532&

Gregg, yes, if I do a compose as in:

compose [pen none fill-pen (FillType/grad-mode) (FillType/startpos) 
...

then it work correctly. So that is a possible work around. It must 
be a bug, and I'll report it to RAMBO.

I guess this would be good to post in RAMBO for the future.

maybe it's still in rambo... (if not, please add it max)

not related to this leak is it .. http://www.rebol.net/cgi-bin/rambo.r?id=3593&
 which is apparently fixed in the latest releases ( according to 
Gab )

though I still see it as per  this http://www.rebol.net/cgi-bin/rambo.r?id=3557&

It does sound like a bug.

Best way to get it looked at / resolved is to add  a bug report to 
RAMBO (the R2 bug database):
    http://www.rebol.net/cgi-bin/rambo.r

Here is Gabriele's response to my bug report (RAMBO ticket # 4411)


This is not really a REBOL bug. The SQLite driver is doing a WAIT 
1 in the DO-STEP function; calling WAIT inside an event handler (such 
as a face's timer event) is not really supported by REBOL and should 
be avoided. If you can't avoid it, you must be prepared to handle 
other events happening during that WAIT call, and you need to be 
very careful with blocking requesters (SHOW-POPUP, INFORM etc.) as 
they're likely to mess things up (they call WAIT as well).

My suggestions are:


1) File a bug report with the SQLite driver. There needs to be a 
way to avoid the WAIT, though I guess this is going to be complicated 
in R2.


2) Disable other events while you're using the SQLite driver, eg. 
clear SYSTEM/PORTS/WAIT-LIST and restore it afterwards.

3) Use a "global" flag like you're doing.

-Gabriele

I'll submit a rambo ...

post a RAMBO and see what happens. at least on the size difference 
between fonts in VID and fonts in DRAW

Posted a rambo on the subject.

Interesting .. should we Rambo it?

it's been rambo'd ages ago

http://www.rebol.net/cgi-bin/rambo.r?id=3447&
I mentioned this in 2004