AltME groups: search

Ok I looked at the performance from a trace perspective of three 
switch implementations - mine, Gabriels and Chris's.  Out of all 
of them mine was least efficient, while Chris's was the most efficient. 
 So if all of them do what is needed then I would say go with Chris's 
implementation.

hmm.... a bit inflexible, I think. It would be nice to bypass console 
output, and store the output in memory for later scrutiny. this would 
avoid needing to popup a console to an end user.

wow I just looked at stats on the latest view 2.7.1 and never noticed 
all the options for it before.

do we even need 'all - I mean I think we should just make that the 
default for switch and leave select to do the light lifting.

switch: func [
    "Finds all choices and evaluates what follows each."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    
][  
    default: copy []
    while [cases][
        if cases: find cases value [
            append default first cases: find cases block! 
        ]
    ]
    if not empty? default [case: default]
    do case    
]

It's an issue if you're building a script incrementally and want 
an empty placeholder...

So do we want to approach switch then as being /all by default?  
To me it seems to make much more sense and I liked Chris's implentation 
of that switch.

anton, do you remember this one:


view layout [text "Push and drag out. The highlight should go away 
when the mouse exits, but it doesn't." tog "Test"]


I remember you talking about that you made a fix for that, which 
didn't work. Do you think we could make a proper fix for View 2.7.x?

Yeah and now that it is native it is faster than select for single 
selections.

Essentially, the ENGAGE 'away and 'over events are called when dragging 
off, and back onto, the face, and I redirect the events to the existing 
OVER function, which normally doesn't get events with the mouse pressed.

How does Carl decide what goes native and what does?

Why switch, and not case ?

anton, I tried TOGs, BTNs and overlapping TOGs and they all work 
without this problem now. looks OK to me.

Which I don't know if that is very desirable either as some may want 
just the block returned and not evaluate as it would now if in your 
example the b were in build in the case such as [1 [b]]         But 
in any event you can get the effect you want with the current switch 
by doing this:  do switch 1 [1 [b]]

ok I just looked at the above example and yes it makes sense now... 
 I thought it didn't evaluate the content of the block.

so since it does evaluate, yes my code seems to work pretty well 
under 2.7 GLayout presents no artifacts, and liquid will run a little 
faster with newer switch.

I have a slightly modified help, that does not evaluate functions 
in objects and ports and that also dumps ports like objects.
>> a: open http://www.rebol.com
connecting to: www.rebol.com
>> help a
A is a port of value:
   scheme          word!     HTTP
   host            string!   "www.rebol.com"
   port-id         integer!  80
   user            none!     none
   pass            none!     none
   target          none!     none
   path            none!     none
   proxy           object!   [host port-id user pass type bypass]
   access          none!     none
   allow           none!     none
   buffer-size     none!     none
   limit           none!     none

   handler         object!   [port-flags open-check close-check write-check 
   ini...
   status          word!     file
   size            integer!  0
   date            date!     6-Nov-2006/21:26:44
   url             string!   "http://www.rebol.com/"

   sub-port        port!     make port! [ scheme: 'tcp host: "www.rebol.com" 
   po...
   locals          object!   [list headers querying]

   state           object!   [flags misc tail num with custom index 
   func fpos i...
   timeout         integer!  30
   local-ip        none!     none
   local-service   none!     none
   remote-service  none!     none
   last-remote-service none! none
   direction       none!     none
   key             none!     none
   strength        none!     none
   algorithm       none!     none
   block-chaining  none!     none
   init-vector     none!     none
   padding         none!     none
   async-modes     none!     none
   remote-ip       none!     none
   local-port      none!     none
   remote-port     none!     none
   backlog         none!     none
   device          none!     none
   speed           none!     none
   data-bits       none!     none
   parity          none!     none
   stop-bits       none!     none
   rts-cts         logic!    true
   user-data       none!     none
   awake           none!     none

Is there interest in including in the new release?

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.

scaling info.gif (which has an alpha channel) gives funky red and 
yellow stripes when specifying 2 or 4 points (but not 1 point).

This bug seems to have been introduced in View 1.3.2 and is still 
present in View 2.7.4
	  

 window: layout [b: box sky effect [draw [image info.gif 0x0 49x48]] 
 mag: box 600x600] 
	mag/image: to-image b 
	view window

anton, testing both on XP and OSX. the bug does not appear on OSX, 
though colors are odd there due to a known bug.

Try the above image-fit.r program, set it to 2-points and then play 
with the SIZE pair-edit.

On XP you see red and yellow stripes in the alpha channel.

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.

>> trace/net on 
crashes Rebol too and wants to send an error report to microsoft

( and various text styles inherit base-text's INIT )

it' not my first license.key. I had also problems and got a new key 
some time ago.

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.

I second Anton's request, I do the same myself, and for example, 
am using it within VIEW stuff to modify some event handlers... its 
often easier than trying to re-bind the body which comes from several 
contexts...

There should be a way to vote for tickets, to help RT put a measure 
of weight on them. I also think the same person should be able to 
revote more than once, lets say once per month, this helps weed out 
issues which are long standing and are a big issue for one person. 
 otherwise, you cannot really differentiate what is continually causing 
concern for you over time.  persistent bugs are the most important 
ones IMHO.

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.

IN working with functions would be nice, but getting the function 
context is more fundamental and more useful for patching in the way 
I have described above.

Maxim, voting for tickets: I support that idea. I would like to add 
a moderation points system. Members names and moderation points are 
listed, eg:
	Romano  +3   ; <- total of Romano's mod points
	Gabriele  +2
	Ladislav   +1

 Clueless  -3   ; <- this person didn't like it but they have little 
 experience, so, if we like, we can filter their contributions out 
 by name, here.

and me  :-)

Hmm.. I've often considered whether to immediately submit a post 
of dubious importance. It would be nice to reliably delay my submission 
by six months or so. Maybe by that time the submission would become 
irrelevant because of a fix or new rebol version etc, and by not 
posting it I am keeping others free from distraction. But I am not 
using calendar software to remind me. (One of my goals this year 
is to start using calendar software.)

Jaime: since all other negative values yield [1], it seems like the 
intended result and the least surprise. Any other opinions?

Since tail? next [1] ;== true and next next [] ;== []

the first result can be obtained e.g. by starting a fresh REBOL console 
first and then type in the expression

the second one can be obtained in Windows by defining a Do action 
for .r files as follows:

    C:\Rebol\sdk-2-6-2\tools\rebview.exe "%1"


and then right-clicking on a file containing just a REBOL header 
and the above mentioned expression and picking the Do command

ladislav, could it be that the second way skips user.r and thus does 
not set a default network server?

if the format was something like 10h12m3s, then you could write 0h0.1m 
and it could be taken as 0:0:6.

I'm not sure I'd change the time... the above, as explained by Gabriele 
is what is happening, and its very logical... the dot is consistent. 
and fixes the inconsistency of  0:10:0 and  0:10 being the same thing.

if we wanted to support decimal minutes and hours, I'd suggest that 
time then support using decimal values in all parts of a time like 
so:

0:.1:00
0.2:00
0:0.25:0.124


then we'd be forced to write 0:0:0.124 and the inconsistency would 
disapear.  a part from the above discrepancy in that you don't have 
to supply seconds

my interpretation: a is relocated to be able to grow and STR does 
not "protect" the old memory while still referencing it

and in any case, the reduced "a" is separate (copied) and in ram 
is probably equivalent to a: make string! 1...  so I guess the real 
bug is that structures do not properly identify regions of ram they 
point to.

I have written 4 replies to the above, and everytime, I remember 
another detail about struct which is not obvious... and in all cases, 
I come back to this being a GC bug IMHO.

(and you are right, the reduced "a" is not copied. if you change 
the first letter, then str/a is also changed)

I looked quickly at the code... and tought I'd seen rejoin somewhere 
;-)

we may need a new attribute... i wonder what happens if you set the 
pointer manually though. either way you might get bugs. (though, 
your example is more common than setting the pointer manually, so 
i'd prefer to have that fixed.) we can also just state, that this 
is a documentation problem, and that the programmer should take care 
of keeping the string valid (it's for C interfacing after all, although 
we use structs for other things too)

Yes, in the first case, the words IM and SIZE are sure to be evaluated 
outside the layout dialect, whereas in the second case, there is 
a fear that they might be interpreted as dialect words. They could 
be interpreted as dialect words if you added an IM style earlier 
and forgot about it, or the layout dialect was extended with an IM 
word and you didn't notice. In your little example, I see no difference, 
except that the first example could survive changes to the layout 
dialect better. I don't think the layout dialect will change much 
(in View 2.x  versions anyway).  I've been tending to write variables 
in parens, so I need to worry less about the possibility of misinterpretation.

I observe this slowing down and GROW-FACETS is slowly molding larger 
and larger.

view layout [area mold system]

the text would include this  area the  next time, then include a 
text  which inlcudes the lastlast text and so on?

and, Gabriele, what do you think about the to integer! -2147483648.1 
issue? (it may be related!)

I understand the complement and the reason why this is returned (cause 
I've done C before...) but ask any novice and he'll just say this 
is nonsense!

yes the internal type switch really is annoying, especially when 
you are parsing blocks and types are assigned specific values.

opening a ftp port using the scheme: 'ftp and port: 4559 still opens 
up port 21 according to trace/net

I used 
read ftp://user:[pass-:-host]:22
and
read ftp://user:[pass-:-host]:4567
in fresh instances
and it worked

Looks like a bug in same -- it comes up even if you add a copy
a: charset ""
b: charset ""
same? a b ; == true
But insert something into one of them, and the same is now false.

means the are same, even when created by mutiple inserts. Makes sense 
 to  do that  and  share an internal pointer.

I would vote for a bug too. Although charset uses the same source 
"unbound string", result of 'charset evaluation is stored to the 
same memory location, and referenced by two words?

Bug. Fix:   a and b share something which then has a pointer  to 
the bitset.  The pointer to that something should be  compared, notthe 
pointer  to the string.

I show you something from my article:

a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical?: func [
    {are the values identical?}
    a [any-type!]
    b [any-type!]
    /local var var2
] [
    ; compare types

    if not-equal? type? get/any 'a type? get/any 'b [return false]
    ; there is only one #[unset!] value
    unless value? 'a [return true]
    ; errors can be disarmed and compared afterwards
    if error? :a [a: disarm :a b: disarm :b]
    ; we need to be transitive for decimals and money
    if any [decimal? :a money? :a] [
        return found? all [same? a b zero? a - b]
    ]
    ; we need to be transitive for dates

    if date? :a [return found? all [same? a b same? a/time b/time]]
    ; we need to be able to compare even the closed ports
    if port? :a [return equal? reduce [a] reduce [b]]
    ; our function has to work for structs
    if struct? :a [return same? third a third b]
    ; we can have something stronger than SAME? for bitsets
    if bitset? :a [
        unless same? a b [return false]
        if 0 = length? a [return true]
        unless equal? var: find a 0 find b 0 [return false]
        either var [
            remove/part a 0
            var2: find b 0
            insert a 0
        ] [
            insert a 0
            var2: find b 0
            remove/part a 0
        ]
        return var <> var2 
    ]
    same? :a :b
]
identical? a b ; == true
identical? a c ; == false

then it needs to be fixed, and we need precise definition, of what 
actually 'same compares and decides upon

hu? a and b have the equal content. so  they would point to  the 
same  data. so  'same? would return true.

then a and b point to that structure. the pointer in the structure 
is  changed. but a and b return the same still  the stuff.

You modify the  a-node and  b points to the same node. if you check 
b you see the same changes.

yes, I found out, that A and B share data

in the same way I found out the A and C don't share data

Not a bug.

DESCRIPTION:
     Returns TRUE if the values are equal.

>> equal? #"a" #"A"
== false

and

>> to integer! #"a"
== 97
>> to integer! #"A"
== 65

Definitely not equal.

Another question worth asking: I can agree that it is useful to obtain 
TRUE from equal? 0.1 + 0.1 + 0.1 0.3, although zero? 0.1 + 0.1 + 
0.1 - 0.3 cannot yield TRUE due to the limitations of 64-bit IEEE754 
floating point format. On the other hand the STRICT-EQUAL? and/or 
SAME? functions may be stricter. E.g. my IDENTICAL? function (see 
above) is the most strict possible in that respect and yields FALSE.

AFAIK equal? in rebol is relaxed and does a range-check. For close-to-zero. 
And 'equal?  is the  relaxed version. 'strict-equal? should not. 
IMHO.

AFAIK this  periodical things may clash. like 1/3. There  are values 
which work perfectly with one base and have periods in another. and 
then there are never enough digits. But i may thinking wrong.

.. and so scrollers can be placed in the margins.

I suppose the View font rendering system does not render and more 
lines of text after the bottom edge of the face has been reached, 
and the result is clipped to the size of the face. I propose clipping 
the text back a bit more by para/margin/y, so that there is a visible 
gap between the last line of text and the bottom edge of the face.

Ah I remember now. It's a bugger. 

I keep reaching for an "inner-gap" to provide space for scrollers 
and then trying to bend the para/margin functionality to accomodate 
this. But my changes would probably break text-size calculation and 
other things....

dunno if RAMBOed, but there is a difference in callback! vs callback 
between 2.6 and 2.7

and I hope timezone gets fixed finally after all those years

Gabriele, yes it does apply to 1.3.2 and also 2.7.5

Dang, I'd have to refresh my math memory to know what the answers 
to those should be. Still, my preference is to have comparison work 
correctly, and if it didn't before, break backwards compatibility 
and fix the code that depended on the bad comparisons. There can't 
be much of that...

Because 0.1 is a floating-point value in REBOL, and for that matter 
one that can't be represented exactly, much like 1/3 in decimal.

anton, this is a problem in all floating point... I had serious issues 
in compiling earthquake data over a 30 second period... adding each 
change over and over could amount to moving a building a foot away 
 !

>> 0.1 + 0.1 + 0.1 - 0.3
== 5.55111512312578E-17

That's not zero! Anyone can see that! ;-)

I think, it's ok, because the way floating-point works. One could 
just do
>> 0.1 + 0.1 + 0.1 - 0.3 < 1e-10
== true
and that's almost zero, right? :-)

in high-end 3D and games you live with this imperfection daily.

Right! I haven't studied floating-point closely, but it's something 
about powers of 2 added together, and that'll never end up for some 
values.

ICarii, no, generally double in other languages is the same exact 
type as decimal! in REBOL - for that matter, REBOL uses C double 
internally for decimal! values. BCD is fairly rare outside of programming 
libraries and languages made for financial use, like COBOL.

for example, I just discovered that the "enter/return" key is not 
trapped within fields (so by extension isn't sent to the plugin) 
within Internet Explorer.  This specific case is not an issue within 
firefox... but then, neither receive scroll-wheel events... and others 
have posted that the alt+ctrl+shift keys are not detected, and there 
are other event issues too IIRC.

this is quite serious IMHO.

Are these events handled by other plugins, like Flash and Java applets?

and what is actually being sent is  .. lf "." lf

but all the internet protocols use crlf and not lf

This seems like an easy fix to someone who has the time, the SDK 
source and the inclination.

I'm just missing the time (and the need).

Someone at RT should really go thru the old bugs and make sure that 
they are all fixed

I'm looking at the http protocol source, and I find no indication 
of any fix to the default line ending of ssl:// - do I have the right 
source? It is dated 5-Dec-2005...

ok, sorry, I understood it as if you had the answer and wanted to 
hear others first. :-)

ah, so it would replace the character at the position and then insert 
the string from there?

...and how it is described in its doc string

I know how it works with blocks, but I can't see how this would work 
with strings? You can't make strings inside other strings, unless 
you mean {"string"} or "{string}". And it's AFAIK not possible to 
control when to use one or the other?

And ignoring silly refinements  is done everywhere in natives.

as opposed to calculus which has a definite and single true output 
value.  REBOL should give an error in those cases, cause then, the 
process of calculus is an error (like out of bounds, etc)

{the "looseness" in the case where some effects are irrelevent are 
not really bugs} - yes, I understand this POV and respect it. that 
is why I am not enforcing my POV in this case and prefer to ask you

I see both possible behaviours balanced close to equally, except 
that keeping the "loose" behaviour is already here and has the benefit 
of not needing any changes.