AltME groups: search

anton, ok. it would just be very nice to get this fixed properly. 
I've had complaints over this a few times now.

Ok, so it's not just a frivolous claim :) Don't worry, I won't forget.

give me a minute... I'll do a real test.

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.

Graham, CASE has always been a native. SWITCH needs to be native 
for the BREAK problem I mentioned (otherwise /ALL makes the function 
rather inefficient)

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?

help/secure a/handler/set-modes
    there is a function inside an object or port
USAGE:
    A/HANDLER/SET-MODES port modes

DESCRIPTION:
    (undocumented)
     A/HANDLER/SET-MODES is a function value.

ARGUMENTS:
     port -- An open port spec (Type: any)
     modes -- A mode block (Type: any)

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

that's a very tall window. it doesn't fit on my screen :-)

Hmm.. that's a bit annoying. Is there really no way the bilinear 
filter can work also on the alpha channel ? That would be a feature 
request to submit to AGG then wouldn't it ?

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.

REBOL/View 2.7.4.3.1 27-Nov-2006
Copyright 2000-2006 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM


Licensed to:  .... (commercial) <....>
License ID: ...

Type desktop to start the Viewtop.
>> get-modes s: open tcp://:87 'port-modes


-----------------
Rebol Internal Error: Corrupt datatype: 176 at 201

the crash does not happen if I read a web page or start e.g. the 
desktop beforehand

interesting. but i have a license.key too.

BASE-TEXT/init assumes that font/colors is a series, which means 
that this makes an error:

>> view layout [text "Hello" font svv/vid-styles/FIELD/font]

** Script Error: change expected series argument of type: series 
port
** Where: forever
** Near: change font/colors font/color
if none?

so... what to do about it ?

Is it the fault of FIELD font not having a colors block, or is it 
the fault of the INIT not being able to handle the NONE case ?

I had issues with a license key file at one point. I think Cindy 
said things changed, so it could be an issue with a specific license 
key.

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

i don't have ie 7. so there could be a change to the os that comes 
with ie 7?

hum, I seemed to have stumbled across a pretty mean VIEW bug... it 
seems openeing a popup within an even handler, will send off events 
to TWO feels !!

right now, I have a popup which receives events within its over function 
while the face which called the popup, still receives move (away) 
events within its engage func... funny thing is that I receive a 
steady stream of AWAY actions as I move the mouse!

obviously, since the events are triggered within a different WINDOW! 
  hehe  :-)

Please post a complete example which shows the buggy behaviour so 
we can check it.

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.

Anton, I'd actually prefer IN to work with functions; however, Carl 
says that he thinks accessing the context of a function is not that 
useful.

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.

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.

Gabriele, well then, I think we have a mandate to increase the importance. 
If Carl gets mad at you, you can point at 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.)

one of goals this year is to start using A calendar... period  ; 
-)

(Well, I currently use a paper-based diary.)

I used a mangled brain with continuous stack overflow...  ;-)

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

not sure, but maybe there is a cache listing ....

hi, did anybody notice, that sometimes

    a-value: make port! http://

works, while sometimes is end up as follows:

** User Error: No network server for HTTP is specified
** Near: a-value: make port! http://

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

I don't seem to have the option to create a Do command in WinXP SP1

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

ie. can you verify a set-net is being executed before that?

ok, so it's not really a bug; it's just that when you have a default 
network server, rebol uses that for any protocol. (set net does not 
actually set the smtp server; it sets the default server. since the 
send function does not specify any server, the default server is 
used to send email; that's why the default server is normally set 
to the smtp server)

this is a copy of a fresh REBOL interpreter console. Do you think 
it is covered by the documentation, or should I put it to RAMBO?

>> a: make string! 15
== ""
>> insert a "a"
== ""
>> a
== "a"
>> str: make struct! [s [string!]] reduce [a]
>> str/s
== "a"
>> insert/dup tail a "b" 14
== ""
>> a
== "abbbbbbbbbbbbbb"
>> str/s
== "a"
>> recycle
>> str/s
== "¸^D^G^A"

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

I also find that all types should be described within a convertion 
matrix.

Ladislav, why is the str/a corrupted after a recycle?

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

ybut the size is within the 15 bytes you asked at a's outset no?

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.

reduced "a" is not copied...

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 think it should be considered a bug, the old string should probably 
not be GCed or there should be some way to tell struct! what to do. 
(wasn't there a "save" attribute for structs?)

this leaks on 1.3.2.4.2  Is it a bug ?

does this grow to hundreds of MB of RAM if you do this in a loop?

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)

We need an explicit malloc/free IMHO. maybe with copying the string. 
How  about  a little dll for such stuff?

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 think the second one should also produce an overflow error, since 
a correct result is too large for an integer!

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?

...if I evaluate an expression supposed to yield -2147483648.0 but 
obtain a "slightly different" result, then the conversion may still 
not be possible due to the fact, that the overflow is a bit "premature" 
in this case, because -2147483648.1 actually *can* be converted to 
-2147483648 without any overflow

but because it cannot stored in a loaded block, should we allow it 
anyways?

hum... I didnt' think -2147483648  was a valid int value... sorry.

>> -2147483648  + -2147483648
== 0

this is a bad bug!

I created a new RAMBO ticket

today I found small bug - well, did not know it is a bug, Cyphre 
just confirmed it - pre 2.7 Rebol versions require callback!, whereas 
2.7 version accepts only callback, but not callback! - the bug was 
probably introduced with string change for 2.7 ....

Is there a bug in the ftp protocol?  I tried opening a different 
port viz 4559, but it still opens up on port 21.

Well, there is _at least_ one bug in the FTP protocol.  I haven't 
run into the one you are talking about, but I think I did solve the 
one that I was having a problem with (425 response from the server 
causing Rebol to wait infinitely).

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

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

Yes, I've installed Hylafax which uses a modifed ftp protocol on 
port 4559.

a: charset ""
b: charset ""
same? a b ; == true

do you find it a bug or a feature?

mmm... more of a bug, I think.

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.

thanks, I personally tend to think it *is* a bug, because they are 
only equal

Nice catch, by the way!
That should have been:
a: copy charset ""
b: copy charset ""
same? a b ; == true

of course, it fits integer! handling ...
>> a: 1
== 1
>> b: 1
== 1
>> same? a b
== true

in the  middle. Tried a bit. Same charsets  are compacted.

Thought that wouldbe hard to fix. If it can be fixed easily its  
a bug.

Hmm, Volker -- maybe it is subtle undocumented behaviour:
a: charset ""
b: charset ""
same? a b
== true

insert a 1
same? a b
== false

insert b 1
same? a b
== true

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?

>> a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b"  probe 
same? a c  insert a #"c"  ? a ? b ? c
true
A is a bitset of value: make bitset! #{
0000000000000000000000000E00000000000000000000000000000000000000
}
B is a bitset of value: make bitset! #{
0000000000000000000000000E00000000000000000000000000000000000000
}
C is a bitset of value: make bitset! #{
0000000000000000000000000600000000000000000000000000000000000000
}

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

identical? a copy a ; == false

can you make a simpler example, so i can analyze code? My tests say 
 yes, what  do i miss?

I have proven, that there is a function (IDENTICAL?), which has got 
the following property:
a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical? a b ; == true
identical? a c ; == false
identical? a copy a ; == false

nothing is re-samed, if it were, IDENTICAL? a b would have to yield 
FALSE

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.

I rather state it in a positive way: since my IDENTICAL? function 
correctly compares bitsets (can be tested), the model I am using 
is correct

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

They still  share the same data  if you point  a pointer in the node 
to something else. But - here is  rambo, move somewhere else. Your 
 version seems more  plausible from the  implementation effort, i 
want to makemy point  for  academical reasons.

I am still not sure, whether this can or cannot be called a bug:

    #"a" = #"A" ; == false

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.

it is related to:

    difference [#"a"] [#"A"]