AltME groups: search

you got me into a spin, I rarely do this kind of fun , here is my 
best and shortest solution:

(its also 3 times faster than Geomol's, using his block data ;-)

duplicates: func [serie /local word][

 remove-each word copy serie [same? find serie word find/last serie 
 word] 
]

>> duplicates [a b b c b a]
== [a b b b a]

you can add the 'unique call to clean up the block if you like 
>> unique duplicates  [1 1 2 2 3 4 5 5 6 7 8]
== [1 2 5]

And as a function:

find-dups: func [blk] [unique head foreach e unique blk [alter copy 
blk e]]

Funny how the same thing can be done in so different ways with REBOL. 
I think, it's good. Choose the way, you like. Not many languages 
are like that. Again REBOL is much like a spoken language. You can 
say the same thing in lots of ways. Some say it with many words, 
some is short and precise, etc.

some people where amazing.  using only rebol core words and valid 
syntax...

I had just found something via  search it looked like Carl was question 
about it and answered something along the lines of XOR.  Not sure 
if the function has evolved since then or not.

Encloak  -- http://www.rebol.net/cookbook/recipes/0023.html-- Carl 
says


Newer versions of REBOL include "cloaking" functions for encrypting 
and decrypting strings. These functions do not provide full strength 
encryption such as Blowfish, AES, or RSA as found in REBOL/Command, 
nevertheless they can be useful for hiding passwords and other values. 
(That's why we call it cloaking rather than encrypting.)

so basically, usefull for hidding data from familly and friends, 
but not from your neighbourhood (or company) hacker  ;-)

well, the safety of XOR is the safety of the passphrase. if it is 
random and same length as data, then it's the safest possible. :)

No, /direct just allows control of rebol's memory buffer. Rebol goes 
out to the host filesystem via host OS API calls. The host filesystem 
may still not actually write the data to disk immediately. To be 
sure of an immediate write, you would flush the disk cache, using 
a mechanism provided by the host OS and filesystem. (eg. in WinXP, 
if you disable one of the harddisks, it flushes the cache, then spins 
the disk down. There must be another way to flush the disk, but I 
never learned that.)

in principle, there should be little difference. since write always 
creates a new file, and immediately closes the file port, they should 
basically be the same. I also assume that /append implies /direct 
in some way.

Anton and Gabriele, thanks.

When I did a date-to-epoch func, I used ATTEMPT with DIFFERENCE and, 
if that failed, used subtraction to get the number of days, then 
multiplied by 86400.0.

time fot 64 bits ints.... and people asked... do we need them?

by all accounts, time is expressed in seconds internally .  and guess 
what! 600000 hours is 2.16 Gs..  just above 2^31 (2.14 Gs)..   so 
if we had 64 bits, then we could hold the date and calculate it with 
other values.

It will only break if you try to do it this way. I haven't heard 
of many places where this is an issue, and it isn't hard to work 
around if you really need to.

if I try to use the decimal and converting it to integer it will 
return the error.

to-integer  2147483648.0
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value

its an issue when you load data and make a dialect loader.  It just 
fucked up a week's work ... now I have to completely change the way 
I handle Integers...  had this broken early on, it would not even 
have slown me down.

the data is not of REBOL origin.  and has to be spitted out the same, 
cause it will break the external tool's understanding of the value...

many places this can be a total fuck up
imagine this:

as-integer: func [value][
	any [
		attempt [to-integer value]
		0
	]
]


here we end up with a broken logic and impending doom...not of our 
fault.

I don't know if I'd call it "horror", though it's obviously not what 
some people will expect. It just means having to deal with those 
cases differently; use LOAD or TO DECIMAL! and check the range, etc.

'MAKE already accepts strings and decimals for creating integers... 
maybe to-integer should be redefined as:

to-integer: func [value][make integer! :value]

looking into that discussions, I wonder, if Rebol could be EVER considered 
to be used for the NASA purposes, as e.g. Python was used for some 
things.  Unless things are really predictable and without side effects, 
I am not sure it is.

I guess, that you are able to articulate your preferences too, so 
go ahead and speak. What are your preferred behaviours?

Ladislav - dunno in that particular case. But I am just sensible 
enough to what others say. I reacted to the fact, that Rebol does 
have side effects. I don't know if it was Erlang or other functional 
language, where they claimed programmers like it, because of no side 
effects = predictable. But maybe it is just the case of documentation, 
but really - many novices just try in console by trial and error 
....

...and it is the highest performance solution, because you usually 
don't need to "check..."

basically, the interpretet at some points "chooses" what it thinks 
is the best behaviour when it finds something screwy... but really... 
the fundamental event is that something screwy occured.  so for correctness 
and intuitive consistency, screwy things should error, not try to 
recover.

if we don't know that input data is invalid within REBOL (like an 
integer specification which does not fit inside an integer) then 
I don't see why REBOL should try to cope.  its plain logic to me. 
 this decimal issue can drag around a LONG time before you realise 
what is going on and by that time... its a hard thing to fix.

others will say that crashes are evil and should be circumvented 
whenever... well, this is sloppy IMHO, and where does it end?

do we then recover division by 0 errors and quietly return 0.0  ? 
 why not, then also convert unset words internally to lit-words and 
return that ... hey we'd have no more errors... and also no bearing 
of what is going on, and would have to check each and every operation 
to be sure its doing what its supposed to...

Max, this isn't necessarily "something screwy". It's entirely possible 
that you know how REBOL works, and you expect it to behave that way, 
so you're not surprised. REBOL *can't* know anything about how it's 
being used, so all it can do is behave a certain way, and the onus 
is on us to deal with it. The important thing is knowing how it works, 
so we know what to expect. 


REBOL is pragmatic. How many times have you seen this particular 
discussion, or issue, debated since REBOL was released? Obviously, 
not too many people have been hurt by it enough to make much noise. 
That said, I'm all for more consistency. WRT divide-by-zero, there 
are some langs that have a NAN (not a number) vals to represent infinity 
and things like that; again, it's just choices.

this is like to-integer and as-integer.  the later could ALWAYS return 
an error, even when the input is obviously wrong and return 0.  but 
to-integer should either return an integer, raise an error, or maybe 
none instead... which is gradually being accepted as a softer error 
value... llike the switch to first/second... etc.

I understand your arguments. But let's take a look at the following 
example:

    abs -2147483648


The -2147483648 is a result in the C language (using wrapping). Python 
uses a "larger" datatype and raising an error is yet another option. 
All three variants are "reasonable" in a sense, but we may pick only 
one of them.

If we accept 1 / 3 = 0.333333333333333 (which is mathematically sound, 
because all integers *are* real numbers too), then we should apply 
that to the ABS case as well and say, that abs -2147483648 = 2147483648.0

indeed within mathematical operations, there is acceptible leniency 
in a "pragmatic" language like REBOL, and I agree completely.

people who code in C are programmers.  there is no doubt about it. 
 and indeed, if they choose C, there are reasons, and they expect 
a harsh and unforgiving environment.

yes, Max, REBOL is and should remain more friendly, than C

we must just not forget the intent of the functions first and foremost. 
 if harsh and possibly faster algorythms are needed, I am all for 
it, but these should get specific names... pick and poke, ocome to 
mind as alternatives fewer of use use.

hehe, I might seem to contradict myself wrt the whole to-integer 
thing, but the fundamental function of to-integer and make integere 
are getting an integer out of some other possibly compatible values.

its a bit like the law, there is the letter of the law, and the meaning 
of the law.

procecution and defence will try to bend the judge or jury towards 
one or the other... using the same text.

well, but some code needs to be written and we cannot prepare all 
variants

My big issue with stuff like this is how people will use these kinds 
of examples to show how "stupid" REBOL is, and make them reasons 
not to use it, and to drive others from using it. e.g. "if it can't 
even return a positive value from ABS...". Doc'ing the behavior, 
even pointing out that it's more akin to how C might work, will go 
a long way toward that, but maybe not all the way.

I don't understand - there is no ideal way. The best possible way 
is to use one general principle. Such principle may be to let the 
arithmetic work like the C language arithmetic does (use wrapping 
for integer arithmetic). Another principle is to use the "Python 
principle" - use a "more general datatype", if the original datatype 
is unable to represent the result. And the third alternative is to 
cause an error if the original datatype cannot represent the result. 
I think, that the slowest is the "error causing principle". The most 
unsafe is the "wrapping principle". The "more general datatype" looks 
like the most comfortable.

BUT as I said earlier, this must not contradict the first principle 
of an expression's meaning.  if abs means "return a positive VALUE" 
then that's what it should first and foremost.

note I use the word VALUE, not int, not decimal... this lets the 
whole be consistent and precise.

and they only do so to interact with 'old people.

like teachers, parents and employers.

try to convince non REBOL users why this is logical... and well, 
I think you are on the bad side of the discussion  ;-)

I think this whole mess needs to be explicitely dealt with and exhaustively 
documented, in R3 in the least.  right now, I'm realizing that  these 
issues permeate REBOL and they are probably the only real inconsistency 
in the language.  Each type seems to have its own understanding of 
how to treat an input value... its probably quite frustrating for 
novices, IMHO.

I cannot INCLUDE script with that line (to lit word! first [ < ]). 
'include uses LOAD/ALL and LOAD/ALL changes the line to (to lit word! 
first [<]). While the first line works OK, the second one crashes.

Ok, Rebolek and anyone else, Syntax errors should not be called "crashes". 
A crash is something more serious which takes down the interpreter.

cause If I send a string filled up with 100 spaces, I actually get 
some chars overwritten and a 0 char where it should...

hum... I think I understand something... because the call, is not 
returning a string!, but filling up a buffer, REBOL has no means 
to know that it should fix the string! and resize it to the zero 
terminator, right?

it would be good to see original C function spec. Because - e.g. 
when I was wrapping one function (trying to investigate red-icons 
problem IIRC), the function was clearly expecting chars (certain 
amount), but it did not work, untill Ladislav came in and changed 
it to struct for that part of function.

pekr:  its actually a word pointer  and  MS example look like so:
GetUserName( infoBuf, &bufCharCount )

sorry, mixed bytes and bits :-)

I think that is more a problem with the use of int and long.

yesss... I do more and more... computer sciences are very well explained 
on it.

string! have an internal size and an external size.  using a string 
within rebol, will always update the size, so that it returns the 
current amount of the string! which has been "filled"

now the external call dumps chars directly in the string and add 
a null termination.

there are two cases - when external function returns string and expects 
your struct for it, and second, when external function allocates 
its own buffer and provides you with a pointer

yep, but in a case where rebol returns the value, its smart enough 
to look it up and find the null terminator for you  :-)

and adjust the external size counter.

hum... nope, tried it, it copies the whole string past the terminator... 
and it actually should, otherwise we could not parse binary data...

I know we have to draw a line... but true and false literal string 
representations of boolean values... should be a valid representation 
of input just just like literal integer, decimal, dates, urls, files, 
issues, words, etc values .  no?


we already accept 0 and 1,  why not the string equivalent (obviously 
also support on, off)

LOAD and DO are a more flexible second level.

but true and false literal string representations of boolean values... 
should be a valid representation of input just just like literal 
integer, decimal, dates, urls, files, issues, words, etc values . 
 no?


Only in the case of TO LOGIC!, not as general substitutes anywhere. 
Of course, it's easy enough to patch TO-LOGIC to do that if you want.

I think I actually did that at one point, and also did a func to 
allow FORMing logic values to their alternate words (on/off, yes/no).

I really think we must separate general evaluation and value creation/conversion 
in our heads.

I had also done as-decimal, as-integer which had an expanded input 
format... maybe we should publish a set of functions, one for each 
datatype and submit to the community for peer review?  maybe then, 
this can find itself within R3.  if the work is all done, I don't 
see why Carl wouldn't want a consistent, and already documented set 
of functions.

and if he wants, he can just re-implement them natively, if the speed 
gains are worth it.

part of why R3 is going to be so incompatible... I'd say its the 
perfect time to address this and actually propose stuff instead of 
just whine that they don't work  ;-)

the speed is secondary at this stage... what we really need is to 
layout the logic and demonstrate a consistent path to conversion 
for all datatypes.  two or three guiding principles will emerge out 
of the implementation... no need to try and define them too early 
on IMO.

Agreed, but we don't have a community effort ogranized to propose 
and submit ideas, in general, for R3. Something *else* I keep meaning 
to do. :-)

although the current "no install" solution will always stay... and 
works very well for testing and simple distribution of scripts.

humm no I just want to read it.  so that install can be setup by 
IT dept.  instead of obsure and inconsistent user.r file

I guess, you'll need a validation routine to be called after each 
entering of a number by the user, and chech with something like
if error? try [...]

After validating the input, you should also put all calculations 
inside one big if error? try [...] and tell the user about overflow. 
It's not that strange! If you get an overflow, you get an error from 
REBOL, and you have ways to handle that, so it doesn't crash.

So need to go through the complete code and wrap them all.

And those calcs are not one after the other. Scattered throughout 
the program.

I have the same problem with networking operations. programs will 
halt to console if there is a networking error. the only real solution 
is to wrap your calculation code in a function. you could call it 
'calc, and have that return a disarmed error on failure or a number 
or whatever fits to the situation.


This way calc [2 / 0] wouldn't crash to console and it's fairly clean 
to insert.

should read: The only real solution is to wrap your calculation code 
in a block and use that as a function argument. The function could 
be called 'calc.

Max, I will but this will need some test and a major rewrite of my 
app. So not for the 1.0 release.

more demos and tutorials comming shortly

robert, depending on your code, there may be an easier way than put 
try in every calculation; for example if you have a window and do 
the calculation when the user presses a button, you could just use 
try in  the button's action; or, you could wrap the do-events (i.e. 
view) in try, and so on. it also depends on how easy it is to recover 
from a given point (the farther you are from the location of the 
error, the harder it is to recover, usually).

Maybe we need rebxml2obj.r and obj2rebxml.r scripts!?

Another solution could be, that attributes and content are treated 
the same, but then something like:
<tag type="mytag"><type>mycontent</type></tag>
will produce:
tab: make object! [type: "mycontent"]
and the attribute is lost.

Another problem is, that this is valid XML:
<tag1>string 1<tag2>content</tag2>string 2</tag1>


If you made that to an object, how would to refer to "string 1" and 
"string 2"? So of course it's possible to make XML to REBOL objects, 
but then you have to make restrictions to what kind of XML, you can 
handle.

is there a difference between valid xml and that which is in common 
use?

Maybe something can be made from the builtin REBOL parse-xml and 
xml-language?

Graham - I found Gavain's Mckenzie's scripts usefull some two years 
ago. I had also some chat with him, and it seems his work covers 
80% of usual programmer needs. You could build object with his code 
...

There's a HUGE difference between dealing with simple, well formed, 
XML, and trying to implement the XML specification. A good deal of 
XML our there is just well formed; no namespaces, no attributes; 
easy to deal with. I did a loading (XML to blocks) that just makes 
a minor change to parse-xml; it reverses the content and attribute 
values--since attributes are often NONE--so you can use path notation 
on the resulting block.

So, if you want to be sure to clone your object and every field, 
you will have to check every field to see if it is an object and 
clone it too.

x: [ 2 4 6 ]
y: [  x/1 ]

how do i get the value from y/1 ? I know this is perhpas very newbe 
but once every year I always run into this and can figure it out...

reduce y/1 gives me x/1 but I want 2.. Im missing somekind of  'eval 
y/1 ...

try a fresh console, I've done it successfully on mac with view 1.3.2 
and winXP with view 2.7.0

...and what you expect in case:

a: 1x2 a/x: (a: [x 4] 3)

well, there is a possibility to use the strategy to "partially evaluate" 
the set-path before evaluating the argument, but then e.g.

a: 1x2 a/x: (a: 3x4 5)

should yield a == 5x2 and

a: 1x2 a/x: (a: [x 4] 3) should yield a == [x 4]

Ladislav, I would go for the fastest implementation. So double-check 
is out of the question. Then post-check must be the best and safest 
way (I guess!?).

unset 'a a/x: (a: 1x2 3)
should then make a holds 3x2.

a: 1x2 a/x: (a: [x 4] 3)
should make a be [x 3]

a: 1x2 a/x: (unset 'a 3)
should give an error.

I think, this is correct. I'm not 100%.

This is a strange corner of REBOL. And one not often explored. A 
good developer would probably not do something like:
unset 'a a/x: (a: 1x2 3)

But we can't be sure. Maybe it's a really good trick sometimes to 
write something like that.

In general it's good practise to only set internals of values, IF 
it's valid up front (, so I understand, that Gabriele would expect 
an error). But of course REBOL should be able to handle it, if someone 
wrote such tricky code. It shouldn't be undefined, what would happen. 
I feel, the post-check (that Ladislav is talking about) is the safest 
(and fastest) way to handle this, and then maybe in the documentation 
notice, that it's bad programming practise to do this.

decimal unfortunately wont work without large slowdowns as I need 
to do AND/XOR/OR operations on the result

Geomol: I agree, but to have it complete, here is a more complicated 
expression:

    a: [1 2 3 4 5 6 7 8 9]
    i: 2
    a/(i: i + 1): (i: i * 2 0)

What should i and a look like?