AltME groups: search

yes, but it seems little bit strange, use find/case with pure binary 
data :)

But I though changing it only for char!, you can always use (find 
string "a") for case insensitive search.

Ladislav, I wonder if your task will be easier if you have an semantic 
model for the language instead of trying to create a coverage test 
set.

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.

actually, e.g. for decimal! values there *is* a way how to suppress 
the conversion errors

I am going to submit a request to implement para/margin/y

This is to allow a SCROLLER at the bottom, inside an AREA.

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....

I want a new View 2.7 build with the home/end/page-up/down keys fixed.

do load tail ['a] 

Actually this seems to be enough to crash it.

Nice one. I seem to remember a bug like this a long time ago, though.

This is a problem that has occurred since View 1.2.100 or before 
(but seems not a problem in View 1.2.48 or 1.2.54)
I see a difference between these two:
	request-file/keep
	request-file/keep/file %hello

The first one remembers the directory of previous invocations, but 
the second one doesn't.

I think when the /FILE refinement is used, it just ignores the previous 
directory, reasoning that the user is passing in the "current directory" 
via %hello
That seems simplistic.

I would prefer if REQUEST-FILE would check the /FILE refinement's 
NAME argument to see if it contains a path or is just a single file.
When it is a path, then it is OK to use it.

When it is just a single file, then it should use the previous directory.

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

Petr: first of all, we don't want 2.7 to introduce new bugs. (2.7 
is a merge of a number of branches of the code - Carl really needed 
to do this to simplify things - so there are many things that can 
break in such a scenario). Then, we want it to fix a few bugs too. 
:)

my preference is to have comparison work correctly

 - this may be a matter of preference, as it looks. Both versions 
 yield:

0.1 + 0.1 + 0.1 = 0.3 ; == true
zero? 0.1 + 0.1 + 0.1 - 0.3 ; == false

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 
 !

almost? #"a" "a"  
==true

which is why BCD exists.  these actually are a base-ten counting 
system.

I just posted a few bugs about the plugin being quite shorthanded 
with the event it receives from the various browsers.

There's a small but significant "bug" in prot-esmtp.r that for most 
users doesn't matter.

the protocol sends a terminating "." to signify the end of an email. 
 But this is not correct.  The RFC specifies that you should send 
crlf "." crlf

I think you can open a port with /lines in a way that specifies the 
line ending string.

took me a few days of puzzling what was going on.

BUT the default for ssl:// is LF! that is a bug i reported some time 
ago. (it created problems for https:// too)

you can workaround it by adding a  /with refinement to the open (it 
will not hurt tcp either)

my understanding is, that the usage of the /ONLY refinement is an 
error in cases like:

    a-string: ""
    insert/only a-string "ab"


currently REBOL just ignores the refinement, what are your preferences?

It should put  a string in the position of one char :D
Its an programmer-error. Do we  need a runtime-check?

Ok, I guess, I'm completely misunderstanding the problem. Volker, 
what do you mean by putting a string in the position of one char?

that is what insert/only a-string "ab" requests for, althought it 
cannot be done

Volker, I think I understood that, but I just fail to see the current 
behaviour with /only on strings as a problem, so I guess I have to 
vote for the current behaviour. :-)

Strictly iusing  it for strings is a bug. But not a problem.

ladislav, many funcs are intended to support all of a given set of 
types (numbers, series, etc).


we must not turn rebol into a "strict" language... the "looseness" 
in the case where some effects are irrelevent are not really bugs.

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)

I know its hard to put the line where loseness becomes a bug (like 
the few cases this kind of effect has been brought up before)

my idea was more in the sense: {insert/only "" "ab"} is a most likely 
a programmer error. therefore if the interpreter causes the error, 
it helps the programmer find the bug in his code. If the interpreter 
silently ignores the problem, then the programmer may be unable to 
find out there is probably something wrong

(so I saw it as a kind of debugging help)

but that depends where the "" comes from... your human sense sees 
this as a bug, but an algorythm merging a set of series of abstract 
types would not...  ;-)

well, if that algorithm really *needs* the string to occupy just 
one "place" in another string, then it may contain a bug, which may 
be revealed by testing, but not by evaluating this suspicious code

(Ladislav is the one thinking this to be suspicious ;-)  I have a 
merge func which could not care less, all it wants is to make sure 
that equal things get inserted equaly, string into string, blocks 
into blocks...  so in that sense, the above is not suspicious at 
all.  but if only reacted differently for string, then I'd have to 
add an ugly escape route for that case ;-)

this behaviour of tags differs from string behaviour:

    a: <0> 
    b: make tag! 0 
    insert b a 
    a == b ; == false

do you like it?

>> a
== <0>
>> b
== <<0>>

Ok for me. datatype is translated to string, a tagto"<something>". 
and then inserted.

An issue raised by Joe in Core group 26-Nov-2006:
	launch {my-script.r param}

Joe wanted param to be parsed out and appear in system/script/args, 
however, it looks like instead the whole string is converted to a 
file and rebol tries to DO it.

Hmm.. there seem to be a few other LAUNCH issues in the Rambo database. 
I guess it's not as important as it used to be, now we have CALL.

hmm, /as-is could be a /Link thing maybe.

Hmm, so is it worth posting a ticket (given that CALL is for free 
?) I suppose we still need LAUNCH for some of those options...

I guess I should post a ticket asking for clarification of LAUNCH 
options, especially argument handling.

Ok, so I'll be putting in a rambo entry.

so, is launch just a short hand form of call ?

Ok, submitted a ticket.

I also recall reading that a launched script cannot launch a script 
of its own.  something about preventing scripts from the desktop 
to launch other scripts, as a security measure, IIRC.

That restriction was removed fairly recently (about a year ago ?).

>> make date! [0 0 0]
== 30-Nov-65535
>> make date! [0 0 1]
== 30-Nov-0000
>> make date! [75 0 1]
== 13-Feb-0001
>> make date! [01 0 75]
== 1-Dec-0074


sorry, but these make dates are just funny. 0 becomes a negative 
offset in time in some instances... like the last.  should I RAMBO 
this?  I would expect make date to accept only one 0 value, being 
the year... any other 0 makes no sense.

Negative offsets can actually be very useful, when creating relative 
dates. The thing I don't like about the zero behavior is that it's 
non-intuitive. i.e. using zero produces a negative result, where 
you would think -1 would be what you want to use. Other than that, 
it's just something to be aware of, not a bug IMO.

oh.... you've just stumbled on something which might be related to 
something I  discovered last week on command!


but strangely, this is new behaviour for me... so it might be related 
to server swap. and the fact that now, an URL does not exist anymore! 
 you might just have resolved a clueless issue.  especially since 
the exists? command seemed to work on new console issues.  


I will make other tests and confirm is I just discovered the same 
bug than you!

Oldes, you're a year late with that bug report :)

well, it's likely to be a mezzanine .. ?

the fix for that is what "caused" the read/binary bug in 2.7. (rather 
than "caused", it exposed a native bug when calling handler functions.)

I realised when mimicking the behaviour of DO EVENT, that the reason 
the target face is not given is because its impossible to know at 
the time DETECT is called. Events travel down through the face hierarchy 
through the DETECT functions, the evaluation of which could have 
an effect on the result. The DETECT function can block events or 
allow them through, depending on the result they return, which is 
programmable and therefore dynamic. So a DETECT function higher up 
in the face hierarchy which is evaluated before a DETECT lower in 
the face hierarchy cannot know which is the target-face, because 
the result of the lower DETECT may change the target-face.

Therefore, I now see this as either a major design issue or a documentation 
error requiring some clarification. I don't think it is likely to 
be implemented (not in R2, anyway) because that would probably require 
an overhaul of the event system, and would likely break a lot of 
stuff.

In most cases it is sufficient to know which face is under the mouse 
cursor at the time of the detect event. Coded as a mezz this is pretty 
slow.

why dont RT add a captcha?  ... it easy with rebol and the draw command.

A guess: the web site is probably running a /core version -- /view 
versions used to not work well in CGI environments (though that may 
have changed).
/core has no draw ability.

A math based captcha doesn't require draw

i've just been in bed with a flu for the last few days, so noone 
has been deleting spam :)

Wouldn't it be a little easier to add a captcha to the script ?

I really don't know, why everybody must be forced to rewrite some 
letters or do basic math only because of a few idiots. Just block 
their IPs or give the captcha only to some of these IP ranges (if 
you think, that there still can be someone innocent). That's what 
I would do.

how can you possibly be sure that the IP does not contain a zombie 
spam bot that posts to the site as well as real posters?

better to have a captcha test

in my experience... blocking ips can block 90% of spam, but not all. 
of the remaining 10%, a good amount is actually posted by humans, 
so there are no easy way to block it.

Gabriele, could a captcha be added easily and timely to RAMBO... 
as well as a "preview" step... hitting the "enter" is easy to do 
involuntarily.

Could someone update RAMBO ticket 3455 with info that Linux (at least 
Debian) supports a

sensible-browser

command.

Gabriele: so there is a script that I can use with mandriva to set 
browser path ? if so can you send a link ? Thanks !

no, i have just added brian's info to the ticket. Debian has a command 
(a bash script I assume) that will launch the user defined browser.

Re: 4268 - Gregg, do you think it really should return %/a/ %/c/ 
etc?

when you do a read %dir/   and you get %subdir/   as a result, you 
know that the path to subdir is %dir/subdir/  so it seems consistent 
to me that a read %/ gives %a/ and the path is %/a/ .

eg if i make a function like:  func [dir /local block] [block: read 
dir forall block [block/1: join dir block/1] block]

i expect it to work with any input, %/ included. but it would break 
if read %/ returned %/a/ .

I've considered it a long-standing bug, because it didn't do that 
before, and I think Carl acknowledged it as a bug at one point. There 
are two ways to look at it, but the consistent-path model may be 
best in REBOL, meaning it's not a bug. Under Windows, where there 
is no concept of a root above the drive letters, it's more comfortable 
to think in terms of the drive spec being a top level entity. Not 
sure what's best for UNC usage.

i'll leave it in as a bug, but i personally prefer it to be consistent 
with other operating systems.

oh.. that is a mean bug!
crashes in 2.7.2 also.

(The first one produces lit-paths starting with a newline - looks 
weird.)

I think it is an error, since I am molding a lit-path which can't 
be loaded back, because of the newline between the ' and the first 
word.

I agree Anton. I imagine it's because paths are a block type. So 
we want to make sure it doesn't mess up other block types when fixed.

I thought it was an attribute of a block, but maybe it's an attribute 
of a word ?

new-lines are attributes of value slots. values do not exist without 
value slots. rebol is always copyiing the 16 bytes of a rebol slot 
around... so it copies the new-line marker too

Excellent -- attributes of a value slot; that's clear.

So there must be at least one bit devoted to a new-line marker.

I tested by extracting a word, then inserting into another block.

and you can move the word into other series datatypes like path, 
then back to a block and see the new-line has followed it.

It's interesting I stumbled the same way twice. Will I do it again 
in a year or so ?

It would be a good guru tech-note to post somewhere, The Singularity 
of Bindings.

:-) I don't know. I kept notes in a file, but don't feel it's developed 
enough to publish. I have a vague desire for a new function which 
handles this case (as well as other, more general, set operations).

I see. Unfortunately it seems I hit it close to every time I do a 
specific operation, but I have no time to debug it...

it's actually a showstopper for me and exactly this code needs to 
be working in front of a customer in about 5 hours....

sunanda, repeated clears of a block perhaps?

I had adopted the techinque of clearing a block before reusage instead 
of using a new make block! [] Maybe that's a bad idea.

Clear -- It's probably a good idea for this reason: the block will 
grow to its maximum size after repeated uses, and so saves time in 
memory allocation / block extension.
May be a bad idea if that max size is causing problems :-)

i had such a problem with massive gui and async. Workarounded the 
following way: recycle is off permanently. there is a thread (do-every 
or such) which checks how much memory was allocated and when it is 
to much it recycled. crashing stopped.

Its only for demo, and 3:30 left. better waste memory than a contract..