AltME groups: search

Just noticed callback crash is fixed in rambo. So it should not be 
a problem soon. :)

make it a wish in RAMBO

however... search for this in rambo, and if not already there please 
add it. :)

Rambo'd it.

Rambo any requests

is that rambo'ed?

there are jpeg issues in RAMBO, but no crashes, AFAIK.

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

good catch, if it is not in RAMBO yet ...

in rambo it sais part of 2.7 release... I guess its Carl's reduced 
version?

anton, should we rambo it as it is?

Rebolek: if it really breaks important code, we will revert it back. 
The request for changes to SWITCH was in RAMBO.

Henrik, I published the TOG bug to RAMBO. (It didn't really need 
much cleaning. I just checked that the TOG feel was used only by 
TOG.)

I put it into Rambo and into the library at rebol.org, as Carl promised 
it already once to include it in one of the former realeses.

Cyphre, so I'll submit a ticket to RAMBO.

Anton, according to the author of AGG the filter calculations would 
be much more complex and thus expensive if done in plain color space. 
Anyway, please submit a ticket to RAMBO I'll try to make the best 
to solve this issue.

Ok, submitted bug report to RAMBO.

The crash does not happen, if the license.key is not available.
I submitted it to RAMBO.

Gabriele, I would like to raise the importance of 
http://www.rebol.net/cgi-bin/rambo.r?id=3571&


I patch functions quite often, and then I usually need to bind to 
the function context. If the original function was not written by 
me (or even if it was), then it's tricky to find a good technique 
to find a suitable word local to the function context. I have to 
look in the function body for a local word and write code to select 
it, which usually looks like spaghetti. I do my best, but if the 
function body changes for whatever reason, then my patch code is 
probably also broken. None of us likes to write code that is so brittle.

Could someone with RAMBO access update 4063 ("Garbage characters 
appear in molded strings sent to SQLite via routine!") to note that 
the problem does not occur if a periodic recycle is performed (and 
that the referenced driver now does this, so the recycle must be 
removed to reproduce the problem). I think this narrows down a whole 
class of problems related to unexpected results when repeatedly calling 
a routine.

Gabriele, well, Carl is just wrong :) He probably just patches source 
directly, rather than indirectly, like we have to. And, of course, 
Romano thought it was useful enough to post the rambo ticket in the 
first place.

Lad, I think it is sensible to add to RAMBO. But what is a sensible 
result. For that case?

I guess I should put it to RAMBO, because it is not covered by the 
STRUCT! documentation

(already in RAMBO)

(I added the [save] attribute note to RAMBO too)

aha, the add issue above is already in RAMBO as #3839 (by Jaime)

I created a new RAMBO ticket

I have already posted it to Rambo.

Going to rambo this ...

Bo, I didn't see a rambo ticket for your bug, or the fix posted.

I think that this is in RAMBO but I'm not certain...

Yes, I observed this behaviour long ago. It should be added to RAMBO, 
if it has not already.

Mmm.. see my note in --> RAMBO group.

has anyone already submitted bug to RAMBO, where View apps crash 
each time you change your desktop resolution?

For things that do exist:

Resources:

- http://www.rebol.com- corporate site, you will find docs linked 
there

- http://www.rebol.net- developer's central. Sadly site was much 
more rich, but there was a server crash some time ago. But - still 
valuable rources - test releases, Carl's blogs, RAMBO bug database 
etc.

geomol, that's a bug. i think it's in rambo too.

That's a known bug, see  http://www.rebol.net/cgi-bin/rambo.r?id=3902

I don't find URL support as described in http://www.rebol.net/docs/makedoc/md1.html#section-5.5
 in the released makeDoc version accessible at http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=makedoc2.r
   Rambo 488 raised for this.

For makedoc2.r input log 488 on Rambo which has morphed to Reviewed 
log 3955, this change deck provides =url support for anyone who wants 
it.  

The line changes are all inserts and the line number is the download 
version from the script library as of a few minutes ago

-ins 136

        | "url" url

-ins 169 


url: [
    some space copy text thru newline (
        emit url parse/all text " "
    )
]


-ins 311 

            url         [emit-url doc/2]


-ins 512

emit-url: func [spec] [
    emit [reduce {<a href="} spec/1 {">} skip spec 1 </a><p>]
]

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

RAMBO it

RAMBO

DideC: thanks for the report, please add it to the RAMBO. This will 
be fixed in 1.3.1

The crash should be submitted to RAMBO as a bug. But would be nice 
if we could try to target the specific cause a little more as a group. 
I mean is it the integration of AGG and REBOL, or is it the interpreter 
or is it provoking an XP or intel or Graphics card instability?

I think it has something to do with timing/sync. Anyway please put 
it into Rambo so we can trace the crash. Thanks.

rebol [
	date: 24-Jul-2005 
	author: "Anton Rolls"
	comment: {

  Investigating why adding/removing 'merge from effect block seems 
  to change line-width on
		arc, circle etc.:

		ToDo:
		  - try to 

  - It looks like the AGG anti-aliasing is with the default window 
  background color ?

    When MERGE is added, then it's with the actual color that is merged 
    (seems ok and good to me).

    - so try to set b1/color so it's the same as the color anti-aliased 
    against in the merged version

    Perhaps default window background color (200.200.200) is close to 
    the default agg anti-aliasing color ?
		  (do not use custom window color)
		- try a simple LINE
		- report to RAMBO or AGG group
		- submit to RAMBO


  This shows that the addition of 'merge seems to add 0.5... (?) or 
  some scaled factor to the line-width:
	}
]

effect-blk: [
	draw [
		pen black
		line-width 0
		translate 25x25
		scale 1 1 
		circle 0x0 24 ;arc 0x0 24x24 0 270
	]
]
make-2nd-effect: func [/local result][
	result: copy/deep effect-blk
	insert result 'merge

 ;result/draw/line-width: result/draw/line-width - 0.5 ; <- even with 
 this they don't look quite the same

 result/draw/line-width: result/draw/line-width - any [attempt [correction-scr/data 
 * 0.1 + 0.5] 0]
	result
]
refresh: does [
	b2/effect: make-2nd-effect
	show [b1 b2]
	big1/image: to-image b1
	big2/image: to-image b2
	diff/image: xor big1/image big2/image
	same-txt/text: join "same? " big1/image = big2/image
	show [big1 big2 diff same-txt]
]
view/new window: center-face layout compose/only [
	across
	label 80 "scale"
	scroller 200x20 with [data: 1][
		change/dup next find b1/effect/draw 'scale face/data 2
		refresh
	]
	return
	label 80 "line-width"
	scroller 200x20 [
		b1/effect/draw/line-width: face/data * 4
		refresh
	]
	return
	label "line-width correction"
	correction-scr: scroller 200x20 [
		refresh
	]
	return
	b1: box 50x50 [refresh] effect (effect-blk)
	b2: box 50x50 [refresh] effect (make-2nd-effect)
	same-txt: text 200
	return
	big1: image 200x200
	big2: image 200x200
	return
	diff: image 200x200
]
refresh
do-events

Submitting to RAMBO

I thought I submitted a RAMBO ticket earlier for it, but now I can't 
find it

Thanks Kru! Put it into the Rambo. I'll fix that for next release.

BTW I'm currently working on some DRAW fixes from RAMBO. So I'd like 
to ask all DRAW users: If you have encountered a serious bug which 
is not in RAMBO, please put it in so they can be fixed in this round.

Wait guys ;) I was asking for bug reports not for new features :) 
But feel free to add those to RAMBO as  wishes to not forget on them.

Once the Rebol/View code merge will be at the level of View1.3.2 
we can add some bugfixes from RAMBO. I'm not sure how much new features 
would Carl like to add to R2 DRAW but I believe there will be at 
least improved and enhaced gradient support. What  else DRAW changes/features 
would you like to see in the upcomming R2 releases?

I noticed that View produces pixel artifacts on some letters on my 
PC, but I think that's RAMBO'ed. Those artifacts are not visible 
in DRAW text.

I'm posting it to RAMBO.

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

This is known bug, it's already in RAMBO - http://www.rebol.net/cgi-bin/rambo.r?id=4040&

It seems, a call to net-log failed, and that was the cause of the 
problem. It's because NetCache has extra header-lines, that e.g. 
Squid doesn't have. See RAMBO 3638.

so test it send bugs report to rambo and we will get a pretty good 
version

It's yet very good to have a working alpha version for MacOSX after 
only 1 month of the Win32 1.3  stable release. Even in the 1.3 stable 
version for win 32  we have remaining bugs like agg matrix key word 
or gradient effect converion from SVG

1) be sure that the bug is listed in RAMBO and that you have a clear 
way to show how to make it happen.

Rambo'd just now.

Anyway I rambo'ed it

Pekr, there was some problem with HTTPS in the SDK. I don't know, 
if it has been fixed in your version.

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

There is a SDK 2.7.8, it is just not publicly available. You need 
to ask RT for it (using the feedback form I guess) or stick with 
2.7.6 (which is the SDK version I am still using for production code). 
2.7.8 has its own issues, like the CALL/OUTPUT data corruption bug 
on Windows (http://www.rebol.net/cgi-bin/rambo.r?id=4416&).

Submitted to RAMBO.

I've written a patch to the assembler that implements a working OFFSET 
directive and label value fixups. I will submit it to RAMBO as an 
enhancement request.

Fair enough. The string cmp would be a good idea to suggest to RAMBO, 
although I would suggest it be renamed to compare.

I hadn't even looked yet. Some of my proposals have been made useless 
by the removal of the BRAW opcode (RAMBO 3942, 3924). There's no 
point to label offset values if you can't use them. Oh well, so much 
for that.

Posted to RAMBO:

; Equivalent of BRAS (RAMBO 3948):
sign a x
brab [l0 l1]
; x < 0
label l0
; x = 0
label l1
; x > 0

; Equivalent of CEILING
to-int x
sign a x
add x a

There is something in the rebcode docs about a special case behavior 
for BRAB that would enable calculated branches, but that special 
case hasn't been implemented yet. I have just made a RAMBO request 
that this behavior be implemented, so we'll see how that goes.

Here are some initial comments on the recently posted rebcode documentation 
draft:

- It has been suggested on the list that since the assembler's rewrite 
engine is a mezzanine, it might not be included in the final version, 
in favor of (to promote?) user-made rewrite engines. If not, you 
would need to change the documentation to match, especially section 
1.4.

- It needs to be made clear somewhere in the initial description 
of the rebcode dialect that rebcode is a statement-based language, 
not an expression-based language like the do dialect. Opcodes perform 
actions, but don't return anything per-se. The 2.1 or 2.3 sections 
would be a good place for this explanation to be.

- In the "Branches are always relative" note at the end of 2.6, there 
is a sentence "The branches are always relative to the current block." 
that could be removed. The whole note should probably be renamed 
to "Branches are always local" because the note doesn't really cover 
that they are also relative. Also the phrase "use a branch opcode 
to" could be replaced with "branch to" and be less awkward.

- A common mistake in specifying literal branch offsets is to miscalculate 
what location the offsets are relative to. This mistake would be 
less likely if the third paragraph of 2.8 were changed to "The argument 
to the branch opcodes is an integer value, representing how much 
of an offset you want the branch to perform. Branch offsets are always 
relative to the location after the branch statement, not the absolute 
offset within the block. Positive values branch forward; negative, 
backward. The branch target must always fall within the current code 
block." as this is the actual branch behavior (and more clear).

- The sentence in 2.8 "The brab opcode allows computed branch offsets 
to be created." isn't really true right now, at least in any practical 
way. The current behavior is more like "The brab opcode allows you 
to branch to an offset selected at runtime by an index.".

- The paragraph at the end of 2.8 "There is also a special case of 
operation. If the block argument to BRAB is an integer (created from 
a label), then the branch is made to that relative location plus 
the value of the index argument." would be a good idea to be implemented 
(I've submitted it to RAMBO), but is rather awkwardly phrased. This 
could be rephrased once the behavior is implemented, or left alone 
if you don't want most rebcode users to use this behavior.

- In section 2.9, the sentence "Result then refers to the value returned 
from the function." may be better said as "The word result is then 
assigned the value returned from the function.".

- 4.1.*: The phrasing of many of these entries is awkward. Also, 
remember that opcodes don't return anything, they modify operands.

- 4.1.1: I'm not sure "integral" means "the integer part of" as it 
is used here; the word may be more related to integrate than integer.

- 4.1.4: Lowercase the "Tail" word to be consistent. Otherwise, well 
phrased.

- 4.1.5: The descriptions of change, copy and insert don't describe 
how their amount parameter is used. You could describe change as 
"Changes part of a series at the current position to that part of 
a value (-1 for the whole value).", copy as "Set the operand to a 
partial copy of the series (-1 for all) from the current position.", 
and insert as "Inserts part of one series (-1 for all) into another 
at the current position.". Or, you could provide further explanation 
in some new 2.* section.

- 4.1.6: In the description of index?, change "Returns the" to "Set 
the operand to".

- 4.1.7: Does not reflect the renaming of the opcode get to getw 
and the addition of setw. Also, instances of "Result modified" should 
be changed to "Set result" or "Set operand to result".
- 4.3.3: The braw opcode has been removed.

Offsets relative to a fixed location are the (currently theoretical) 
"special case" of the BRAB statement. See RAMBO 3953 for details.

should I rambo-it? :-)

should I RAMBO it?

Thanks Petr! No need to RAMBO it. I'll look into it.

Added to Rambo (with bug in the example:( http://www.rebol.net/cgi-bin/rambo.r?id=-505&

Kru: I don't know, write it to Rambo as a wish if you wish:)

As I work with sound synthesis and 3d graphics I use lot of maths 
so I need rebcode imost of the time :) I had data structures using 
objects, so I rearanged them for now. I wrote it as wish to RAMBO.

Please write it to Rambo, better now, before R3

hmm, but nice anyway ... Steeve - if you find anything what could 
improve rebcode, discuss it with Brian eventually and put it in RAMBO 
:-)

Geomol, Rambo the suggestion for a vector datatype.

Graham, I've made a RAMBO proposal for vector and matrix.

It has been suggested before in the rebcode group (mostly by me) 
when rebcode was first being developed. I think there are RAMBO entries 
too.

That  return first reduce [value value: none]  is a nice trick - 
I hadn't thought of that. I did suggest on RAMBO that the unset native 
return the old value of the word it is unsetting, allowing a trick 
like  return unset value  but they haven't made that change yet.

For OSX users, if you experience "invalid compressed data" errors, 
see http://www.rebol.net/cgi-bin/rambo.r?id=4306&

Ok, so we can now fill a nice RAMBO ticket, with an example code 
:-)

or is Rambo being kept for R2 stuff

Nope, R2=>RAMBO, as far as I know.

doc, were you going to rambo this 'no-delay issue?

Gosh ... rambo is full of spam submissions.

RAMBO ticket filled (#-4313)

Rambo is always full of spam submissions. I clean it up daily. :)

www.rebol.net and mail.rebol.net are different machines. it's not 
the rambo spam that's filling mail :)

I see I reported other issues with launch

http://www.rebol.net/cgi-bin/rambo.r?id=4205&
That one is makred TBD

Re HTTPS: there's a ticket opened in RAMBO since October 2006 from 
Maarten asking for that : http://www.rebol.net/cgi-bin/rambo.r?id=4170&
. If Carl could fix it for 2.7.7, that would be a great new feature.

On a related note, do you think it would be possible to export from 
RAMBO to CureCode?

RAMBO to CC: sure, it shouldn't be very hard, RAMBO data model is 
pretty simple.

Doc, we'll need a RAMBO migration to a new CureCode project some 
time next month, after the new R2 release. Open tickets only should 
be fine. Afaict we won't need to delay the first R2 release until 
the migration happens. The first release should be emergencies (like 
installation) and low-hanging fruit only.

Carl, could you chime in here about the RAMBO migration process? 
Dataset migration is better than web scraping :)

If I recall, RAMBO is just a big REBOL file.