AltME groups: search

in traditional TV signals, the green color you see actually is the 
luminance of the signal, so if you separate the green red and blue 
and look only at the green, you will see exactly the same image as 
a BW tv.

red and blue are calculated as differences from the luminance and 
are how the color is added to images.   These other two channels 
of color information will in fact take a fraction of the signal bandwith 
that the luminance takes, and the green is calculated by the different 
both red and blue have from the luminance channel.


which is why the SAME signal is used for both color and black and 
white TVs

cyphre... use this as a basis:


view layout [box 200x200 effect [
    draw [
        push [
            translate 119x119 
            pen none 
            fill-pen black 
            box -50x-30 50x50 
            fill-pen blue 
            pen red 
            line-width 3 
            circle 50x50 25 
            fill-pen red 
            pen blue 
            circle -50x50 25 
            fill-pen blue 
            pen red 
            circle -50x-30 25 
            fill-pen red 
            pen blue 
            circle 50x-30 25
        ]
    ]
]]


adding new black, red, blue, black, circles in betwen colors may 
give very poor results.  sometimes 1 pixel width lines practically 
disapear horizontally!


playing around with the line width will also have a different visual 
impact, since the aliasing will spread the error more or less.


as I said, i know part of the issue is related to the screen's rgb 
sub-pixel channel components but I remember trying some of this in 
other softwares and the effects weren't as image degrading.


to me the main defect is that you will notice a WHITE ringing effect 
between the red and blue on one side and a black ring on the other.


I can understand the black ring, but can't explain the white one, 
which is why I think it coule be related to gamma issues.


also, the black ring seems to be wider than it should &  the effect 
seems the most apparent at ODD line widths, which is a bit strange 
too...


I'm wondering if AGG has an algorithm which is trying to compensate 
for pixel to pixel color defects and gets it wrong.  


maybe it could be enhanced to support subpixel aliasing (or gets 
it wrong if it already does so).

Max, I'm sorry I don't see any degrading 'ringing effect' when looking 
at your example. Even while looking at scaled screenshot the AA of 
the edges of circles looks perfectly symetric to me(did horizontal 
flip comparisons). I'm using average LCD display and also my eyes 
are getting older every day so I still might missing something.

AFAIK AGG is not using any 'compensation' code. It simply computes 
the covers of every pixel cell using 256 levels and ofcourse uses 
subpixel AA(try to translate by fractions of pixel..). So the AA 
result is still very high-quality(though there are very few special 
cases limitations of the used alogrithm). If you compare it to current 
FSAA abilities of gfx cards 256 levels is still way more than what 
the current  super/multisampling offers.

I'm not sure it this is the best group, but anyway, does anybody 
already has a script which would take block of images as an input 
and will layer these images into specified area (a new image). Possibly 
using as less space as possible.

Looks cool, and seem to be good result with the rectangle packing. 
I would like to see a PNG version without the artifacts though. :-)

and pairs are integers

And in R2 pairs are made up of integers.

And I don't like anymore that reuse too :-)

Maybe it would be better for someone more familiar with and interested 
in mathematical issues to do so. Ladislav?

advise on how to colorize individual countries in a worldmap?
take a worldmap, draw background borders between the countries
and then floodfill the country via a central coordinate. 
is this a effective approach?

My first though is to have a map (an image) of countries where each 
country has its own color (call it a color-map) and another map of 
the same size that you display (diplay-map).
Then you have a block of pairs [country-name country-color].
So like this you have a relationship in any sense.


Click the displayed map => find the corresponding pixel in the color-map 
=> find the country name in the block.

To know the edge of the country you want to fill, just find all the 
pixels of this same color in the color-map and poke the corresponding 
pixel on the diplay-map.

And, on the same topic. R2 and R3 have divergent opinions on how 
to handle this line....
    while [return 55][print 1]
....Neither of them convincing me that they are right.

It  fails in the intrinsic part of DO, I guess  (which is a mezz).
And as we know well, Mezz can't have [throw] attribute currently

Gabriele, I don't think that, which is why I recommended that it 
be declared not a bug. I was just surprised. I do think that unwinds 
should not be assignable though, as that is a security hole and part 
of a greater problem with their operation.

Sunanda, we can't block non-trivial bad code without semantic analysis, 
which would have to include consideration of the programmer's intentions, 
which the interpreter *can't know*. And blocking trivial bad code 
would require similar analysis, but would not be worth the effort 
because people don't write trivial code.

And the while [return 55][print 1] behavior is because of bug#1509, 
it's not intentional.

Sunanda, we only have your word for it that do "while [] []" is bad 
code. You have done nothing to tell the interpreter that it is bad, 
and other programmers might be doing it on purpose. The interpreter 
can't tell the difference: It's all in your head. That's not an insult, 
it's an unresolvable communication problem between your intentions 
and the interpreter. The interpreter has to take you at your word, 
what you said to it is do "while [] []". Which it can, so it will.

I'm well aware of this, Brian :)
>> attempt [do "while [] []"] print 'true

And if i can trust my eyes,   it''s a DO string! in Sunanda's example

(and that it has to be corrected)

Steeve, I thought you were talking about the while [return 55][print 
1] code, which would be affected by the [throw] attribute because 
it has a return in it. The attempt [do "while [] []"] print 'true 
does get processed by the intrinsic, but doesn't fail (it works correctly) 
and wouldn't be affected by [throw] because it doesn't have a return 
in it.

Right. I just thought that you were talking about his other code 
because of the return. Interestingly, while [return 55][print 1] 
is buggy in both R2 and R3, but the bugs are different.

.....Sounds like it needs a RAMBO and a CC report :)

And named throw/catch should be easy to add as well, by just keeping 
a "stack" of handled names

I grepped through the R2/R3 mezzanines and some library scripts, 
and this seems to confirm your guess.

This would then leave us with the "classical" Common Lisp-style use 
of named catch/throw for non-local exits. And for this use-case, 
a definitionally scoped name would certainly be the right thing to 
do, imho.

Maarten and I used a named throw in a proejct for Qtask, but I don't 
use it much. The question is, *should* we use it more, and what are 
the scenarios? It does make some handling read cleaner to me. 

Maybe Carl can say what he envisioned when he designed it.

And I use names CATCH and THROW.

I never tried to catch a named throw without a named catch. If that 
is possible, that is a major bug and should be reported.

Steeve, you might be amused to find out that the DO intrinsic currently 
depends on bug#1509 and does need a [throw] attribute. Though it 
still wouldn't work with definitional RETURN because of binding issues. 
C'est la vie.

The advantage to that is because on those rare occasions when you 
actually need to catch all THROW and THROW/name unwinds, you most 
likely need to catch the rest too. You might note that the emergency 
exceptions - HALT, QUIT/now, errors - aren't proposed to be caught, 
because the cleanup code would likely interfere with error recovery 
code or the debugging process.

However, HALT is used for debugging (which is why CATCH/quit doesn't 
catch it), QUIT/now is supposed to always quit, and you want errors 
to get through so you see them, so those make sensible exceptions.

Though for file! literals it was like that before, afaik. #1443 extended 
that to email! and url! literals.

I understand your take on Carl's proposal for a change in RETURN 
and EXIT scoping, but it needs some work before it can do the job. 
For one thing, if you have dynamic as an option (or a default) there 
is still the need for something like R2's [throw] attribute. And 
if definitional is an option, not the default, then I'm having a 
lot of trouble justifying that option, especially since it doesn't 
solve the [throw] issue or bug#1506. It seems to me that the main 
reason for definitional is to make a simpler default for less advanced 
developers. If it's an option that the user has to chose, it doesn't 
serve that purpose. And if it's an option that gets conflated with 
the option to specify a typespec for the return value of the function, 
then this is going to get Fork furious about making REBOL more confusing, 
and he'll be right this time.

Only closures and FUNCT/with should define 'self; regular functions 
shouldn't.

Not unless the closure has no arguments, but it doesn't hurt enough 
to get rid of it. On the other hand, we should probably get rid of 
'self binding from FOR, REPEAT, FOREACH, MAP-EACH and REMOVE-EACH 
(it's already been reported).

And closures don't bind 'self anymore either (I now vaguely remember 
a ticket related to that).

Note: The duplicate variable 'self bug in function and closure specs 
might be dismissed (not by me). It could be necessary for the implementation 
to have an internal 'self in the function contexts; only Carl could 
say for sure.

and how about #447, do you consider it solved?

No, it's solved. The bug was binding 'self in the code block, which 
it used to do and now doesn't (as of alpha 50).

OK, checked, and you are right

R2 and R3 do the same.

By example, the refinement /index has absolutly no interest.

The obvious and regular way with rebol, is to use SKIP or AT as a 
prefetch.

see.
extract/index [a b c d e] 2 2
vs.
extract at [a b c d e] 2

the second one is faster and even shorter to write :)

Henrik, the /index option of EXTRACT assumes that there will be something 
there at the index (record length specified is assumed), and that 
the R3-style treatment of series bounds is in effect. That means 
that the programmer is expected to do their own bounds checking, 
or to not care. The none value is a placeholder for missing data.

As for the reason for the inclusion of the EXTRACT function and its 
/index option, it is because of how much they are used, even in mezzanine 
code. There are a lot of functions there for our convenience, even 
if they would be easy to remake if missing. This doesn't make them 
less useful.

Actually, I used it on a table header with arbritrary data and simply 
wanted every second element in the block, regardless of the block 
content, so the block was not a db record of any known length. Perhaps 
it should be emphasized that extract/index works best on, or is intended 
for database records.

To me this is a case of a method that exists for specific use, but 
is implemented in a general way. That's OK, I suppose, as long as 
you know Steeve's way to produce an optimized and more correct result.

Added an unrelated (at least slightly) comment #55 to the error handling 
blog discussion; are there other opinions, than mine and BrianH's?

Internally, there is none. Ladislav is proposing that the internal 
'self field in the beginning of all contexts be made optional, with 
that option taken by MAKE object! (and as a side effect, modules), 
but not taken by contexts created by functions, closures and binding 
structural functions. As opposed to allowing the field to be overriden 
for that other stuff, and not doing the BIND trick with 'self in 
those cases (as we demonstrated we can do when that problem was fixed 
for closures).

There are two problems we are trying to fix here:
- bug#1528: 'self seems to be reserved in closures and funcs

- bug#1529: 'self is being bound by For, Repeat, Foreach, Map-each 
and Remove-each

Now bug#1529 is basically the same thing as bug#447, which was for 
closures: BIND is doing the special treatment of 'self where it shouldn't. 
And as bug#447 proves, you can shut that off with no difficulty (internally).

And functions and closures don't do the BIND trick with 'self, so 
that's not a problem.

I am suggesting that this ability to turn off BIND's special treatment 
of 'self be made available as a BIND/no-self option (or whatever 
else we decide to call it). This would allow us to write mezzanine 
functions that act like FOR and such, not necessarily in the sense 
of looping, but in the sense of not treating 'self weirdly.

The only problem that might need Ladislav's proposal is that you 
can't use the word 'self as a parameter of functions or closures: 
A duplicate arg error is thrown. And since you can't use that field 
as a function argument, Ladislav is suggesting that it shouldn't 
be there at all. While I am suggesting that MAKE function! can just 
skip that field when checking function arguments at function creation 
time - a solution that wouldn't require any changes to the internal 
data model of all contexts.

and why this reserved word bother you ???
can't you just avoid to use it ?

What if you want to emulate another language's OOP model? Or not 
do OOP at all? Or use functions like FOR, FOREACH, MAP-EACH, REMOVE-EACH 
and REPEAT in functions that are defined in an object, module or 
script? (That means every single time, btw)

If you are writing code in a script, module or object (which means 
all code) then the way that you refer to the script, module or object's 
context is with the word 'self. And if that word is overriden, you 
can't use it. And those context references are used often.

The use case for allowing 'self as a function argument is less pressing, 
but since the fix is easy (at least my fix is) there is little problem 
with fixing this. And it will save a lot of support headaches, or 
at least a FAQ entry: "Why can't I USE [self] [...]?"

Ah, but that is when you are *expecting* to override the context. 
Only advanced users expect FOR and such to override the context. 
And I don't see the problem: It's an easy fix, as was proved when 
the exact same fix was applied to MAKE closure! in bug#447. There 
don't need to be any structural changes; just flip a flag in BIND.

Can you show me a use case for doing the special treatment of 'self 
in FOR and such? Keep in mind that R2 doesn't do this, so it's only 
worth doing if it's a definite improvement in some significant way.

and sometimes i use this trick too.

context [
  a: construct reduce/no-set [
     parent: self
  ]
]

re your question, Steeve: if you ask for the code to be evaluated 
by For, do you expect, that For binds some words in the block it 
evaluates in addition to the words you specify? I doubt it, and it 
makes a problem.

this may be considered a real use case, compare the results in R2 
and R3

and, it is not a huge problem, I would call it just a gotcha, but 
do not like it

the problem is, that such a situation cannot be "hidden" by any number 
of hacks, but there is an easy and clean solution: just allow the 
majority of contexts to not contain the word 'self

honestly , i would never do such thing (to be forced to use a path/var 
just to avoid name collisions) because i know paths are slower to 
evaluate than immediate words.
And I don't do that in R2 too for the same reason.

this does not have anything in common with paths, and it is a surprise 
for me, that you do not see it

What's the point to have d: self in the foreach loop ?.

As a not bad connoisseur, I would apply the constant propagation 
rule and remove the d: setting from the loop.

Just arousing you, but honestly it's a worse example than the previous 
one.


It would not harm  to not have self anymore in FOR/REPEAT loops, 
I agree.

I simply doubt of the usefulness and the urge of such change, because 
i simply can't imagine use cases that outmatch the usual way of doing 
things.
(.And I think you neither until now)

This reminds me a good and funny local novel. Just to paraphrase:

S: "draw any triangle"
L: "here you are"
S: "this is not any triangle, it has a right angle!"
L: "here is another one"
S: "this is not any triangle, it is an isosceles triangle"
...etc, ad infinitum

as I said, I do not claim that I know, what is "real-world for you", 
and I do not see any point in your trying to convince me I am right

this problem cannot be 

cured" by bind/no-self, since it requires the user to always know, 
how he wants to bind the words in the block, while such an information 
is already "automatically available" (as can be proven in R2)"


This is not true. In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH 
and REMOVE-EACH we don't want the hidden 'self to be bound to the 
code block, but we *do* want the hidden 'self to be there in the 
context. In case the context persists beyond the execution of the 
function, it should be like a normal object context. The same goes 
for closures. Only for functions do the contexts not have indefinite 
extent (in R3) - they are stack-relative, so don't work beyond the 
return of the function.


However, in the case of your proposal to not have the 'self in some 
contexts, there is no way to specify that option in MAKE object! 
syntax, so the user can't tell whether it is the case or not. This 
is similar to the map! case-sensitivity option - we can't do it because 
we don't have the syntax. And we don't want to have anything that 
affects behavior on non-blackbox types that we can't see in MOLD 
or MOLD/all.

Now BIND/no-self is just a proposal to make *an internal option that 
BIND already has* usable by mezzanine code (like USE). And we know 
that BIND has that option because MAKE closure! already uses it. 
And we also want that internal option to be used by REPEAT, FOR, 
FOREACH, MAP-EACH and REMOVE-EACH, the same way that it is used by 
MAKE closure!..

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

Ah, but that's the problem. When that context is used by FOR, I want 
'self to not be bound. However, if the context persists after the 
FOR returns then I want BIND to do the 'self trick with any subsequent 
use of that same context; this is what I mean by "like a normal object 
context". That inconsistency is "the right thing". Having BIND not 
do the 'self trick based on some hidden quality of the object is 
*bad*. It means that I can't predict the behavior of BIND unless 
I know the originator of the object, and in many cases that wold 
mean dataflow analysis.

This is another example of trying to make the interpreter second-guess 
the user and try to do they they "mean to do". That inevitably ends 
up in disaster. I don't want REBOL to do what I "mean to do", I want 
it to do what I *say* to do. I want its behavior to be utterly predictable 
given the same input (except deliberate indeterminacy functions like 
RANDOM). If it isn't then it's not as useful to programmers.

I would prefer a name other than /no-self for the refinement, if 
it comes to pass.


Ladislav's example is good, and I would like to see a similar example 
for Brian's FOR example above. It's not that I don't see the need, 
just that I think coming up with a half dozen or so "gotcha" examples 
for the docs is a good place to start. It is a tricky hidden behavior.

When that context is used by FOR, I want 'self to not be bound. However, 
if the context persists after the FOR returns then I want BIND to 
do the 'self trick with any subsequent use of that same context; 
this is what I mean by "like a normal object context". - yes, and 
that is, where our POVs differ - similarly as Brian, I do not want 
one thing: I do not want Bind to behave differently when used twice, 
since it is not the right thing in my opinion - it means, that I 
cannot predict the behaviour of Bind unless I know the originator 
of the context. are there any other opinions, than mine and Brian's 
on this?

Steeve, put that in a comment in bug#1529. It's a good argument for 
keeping 'self binding for FOREACH, MAP-EACH and REMOVE-EACH, and 
then consistency would make us keep it in FOR and REPEAT as well.

Credit where credit is due. I can add an explanation later if you 
like. And I don't want it to seem like only Ladislav and I have opinions.

Are there any other opinions

: I think this boils down to what you want SELF to be. And I think, 
once SELF is easy to explain, you have found a good trade-off.

Ladislav, your suggestion to have some contexts not have the hidden 
'self in them at all is not what you think. You are suggesting that 
we create object! contexts (for that is what all contexts are except 
for function! contexts) that *can't* be specified by MAKE object! 
syntax, ever. And thus these objects will have an attribute that 
doesn't show up when you MOLD it (because MOLD generates MAKE object! 
syntax) that affects one of the core features of the BIND function. 
And that attribute wouldn't be serializable even if you added it 
to the MOLD/all syntax, because MOLD/all serialization of objects 
doesn't work: MOLD/all syntax for objects doesn't restore word bindings, 
only DO syntax does.

Brian, I think Ladislav wants objects and contexts to be separate 
things. This would most directly be modelled as two different datatypes, 
I guess: object! and context!. The former having the hidden 'self, 
the latter not.

Or perhaps he hates the idea of a hidden 'self field, and the corresponding 
BIND trick :)

map-each [a b] [1 2 3 4 5 6] [copy bind? 'a] does the same and is 
more explicit about what you want.

I like the trick for conversion of records from fixed block spans 
to objects, both for Steeve's example and for passing along to functions 
that take object! records. However, as Andreas says we don't need 
the 'self binding trick to do it, we can use the bind? function.

It is rebolish, but the use case is more rare than regular usage 
of 'self to refer to the outer object context. And BIND? is also 
rebolish :)

Actually, the BIND? trick works for all loop contexts but not for 
object contexts, which might have no fields. And it wouldn't work 
for closures with no parameters, but there is no point to those anyways 
so who cares :)

There's too much here. He can't afford to read all of this crap. 
He needs someone to summarize for him, and to put it somewhere that 
won't scroll off the screen.

Ok, Andreas, I'll add it for you and attribute it to you. I'm working 
on this stuff now :)

All right, fine, I'll post your code in CureCode and attribute it 
to you. And Andreas' code too.

...I cannot predict the behaviour of Bind unless I know the originator 
of the context.

 This seems like a core question to me. And while Steeve's example 
 is really neat, I wouldn't say it is REBOLish per se. BIND? doesn't 
 say a whole lot more, so I don't think either example is something 
 to hold up as a best practice. :-)


Is it by design? If so, how is it intended to be used, and how should 
it *not* be used? If not, what warnings do we need to include in 
docs?

Well, when you consider that MAKE closure! also originally did the 
'self trick and now doesn't, it appears to be accidental.

Comments from Steeve and Andreas posted to CureCode #1529.

And look at #1543 as well.

So does INSERT and APPEND /only, the trick being inlining block values.

And "since the 'self variable will be bound, which was unsolicited" 
is the key. Binding the hidden 'self field is the bad thing here.

But that is contextual (in the real sense of the term, not the REBOL 
term). In this case it's the fact that this is a loop function, and 
we don't expect or want 'self to be overriden by a loop function.

The loop functions just aren't using that option yet. And we can't 
see the option since it's internal.

So I propose that the loop functions use that option (#1529). And 
I *separately* propose that the option be made visible to users (#1543).