World: r3wp

and henrik and anton would be asking to not convert it  ;-) 


 I always thought to-string should cleanup the decimal! datatype...


what do you think ladislav?  its not load or mold, its specifically 
asking for a string version of a decimal... and in any case the normal 
notation of  0.000004  is still a valid decimal, so I see little 
problems...

Seems a good suggestion - and it appears this formatting issue is 
not in the RAMBO database yet.

I never know... is it enough to unset block using:
some-block: none
or should I first clear it as well >>[ clear some-block ]

if you clear it first and there are other references to it, you will 
have better cleanup, but then, you could as well be trashing your 
tool!  so... clear carefully.

yes, it totally depends on your situation. What is the context ?

I have just block where I append string values. I use it in recursion, 
so when go down in recursion, I copy the block into stack clear it 
and reuse the variable. When I'm going back I restore previous block 
values if any or set it to none, when it's the last one (end of recursion). 
Don't know if my explanation is clear, but will still use the 'clear' 
on my block:)

And there should not be any references into string values in my block 
(I hope:)

Is your some-block local to your recursion function ?

No. If it would be local, I would not need to clear it and store 
myself, wouldn't I?

Does anyone miss a function that tells with true/false if a variable 
can be converted to a different datatype? I find myself doing lots 
of test on input from text fields with attempt blocks.

something like:

to-integer? 'test
== false

>> a: "6"
>> to-integer a
== 6
>> a: "u"
>> to-integer a ; script fails here so we need to handle it
** Script Error: Invalid argument: u
** Where: to-integer
** Near: to integer! :value

>> attempt [to-integer a]  ; useful, but less clear what fails. Is 
'a not a value or can it not be converted to integer?
== none

>> to-integer? a ; 'a definitely exists, but can't be converted to 
integer.
== false

>> to-integer?: func[a][ not error? try [to-integer a]]
>> to-integer? "1"
== true
>> to-integer? "a"
== false

to-integer?: func[a][ not error? try [to integer! a]]

yes, something like that, thanks

And I must say it again... I use ATTEMPT only in cases where I do 
not expect error. Many people use it just a shortcut for error? try 
which I don't lik. As I understand attempt as higher function for 
reporting not wanted errors (for example on server). If you use it 
in cases, where like attempt [to-integer "a"] it's not good as it 
would report many errors (in some bigger context)

And Henrik, I don't think Carl will add it into Rebol as it's too 
easy to implement yourself.

Oldes, probably not, though this is just one case. A more complex 
datatype like date! requires more complex checking schemes.

And I would not use it, as I usually use something like this:
if error? try [a: to integer! a][a: 0]

And date! does not behave like integer!:

>> a: 1
== 1
>> b: "2"
== "2"
>> c: "u"
== "u"
>> to-date reduce [a b c]
** Script Error: Invalid argument: 2
** Where: to-date
** Near: to date! :value

This is probably a dumb case since endusers don't determine the types 
themselves.

and if I would use it, I would probably use it like:
to-date?: func[a][ not error? try [a: to date! a]]

can the to function translate to user defined structures / objects 
? if  so how, is there a special method name in the object you want 
to convert to ?

If I understand your question, Charles, you may be looking for construct/with......It's 
a way of using an existing object as a template for a new one, eg:
 my-obj1: make object! [a: 99 b: 2 c: "string"]
my-obj2: construct/with  [b: 9999] my-obj

hmm... is it possible to find () elements in a block? they don't 
have a specific datatype.

find [a b c (code) d] ?? ; what type?

Is this a start?
 find [a b c (code) d] paren!

ah, precisely, thanks. didn't know there was a type for them

because:

type? () == unset!

And, perhaps worse:
    type? (1)
    == integer!

which is not what you might expect..... You have to do this to get 
type? to work:
     type? first [(1)]
    == paren!

The parens! triger evaluation so type? (1) = type? 1 ;== integer!

But parens inside blocks are not evaluated.

Is there a way to find out if a loaded file is encrypted with CLOAK?

Or do I have to read it and try to DECLOAK it?

As far as I know, an encloaked string is just a jumbled up, binary 
version of the original string: it carries no prefix signature so 
you can't tell at a glance it is an encloaked string rather than 
another bit of binary.

So, yes, as far as I knoww, you'll have to read and attempt decloaking. 
 Or, if you have control over the writing, ensure some sort of identifiable 
prefix is added)

>> do to-path reduce ['now 'none]   
** Script Error: now/none has no refinement called none
** Near: do to-path reduce ['now 'none]
>> do to-path reduce ['now none] 
== 25-Feb-2007/20:40:18+1:00
>> do probe to-path reduce ['now none]
now/none
== 25-Feb-2007/20:40:28+1:00
>> now/none
** Script Error: now has no refinement called none
** Near: now/none


I guess the difference is between 'none and none!, but I thought 
it was curious that the none! is accepted as a refinement.

>> now/#[none!]
== 26-Feb-2007/14:28:03+11:00

Actually it looks like you can put any issue!
>> now/#hello
== 26-Feb-2007/14:28:43+11:00

functions just ignore anything that is not a word in the path.

DECLOAK: I have the problem that a random char is added as the first 
char to a decloaked string. Is this a known problem?

Not to me it isn't. What version of rebol ?

It's not in Rambo.

encloak / decloak seem pretty stable to me. Be aware that these functions 
modify the string you pass it.

I only have the problem when not using read/binary but just have 
used WRITE and READ... strange.

Just don't use just WRITE with encloked data as these data are binary 
data.

I've never had a problem with encloak/decloak, but I would also avoid 
string ops that might translate the binary data somehow.

Yes, READ and WRITE are in text mode and translate line terminators, 
so LF can become CRLF and vice versa.

Is there any better way how to convert issue! to binary! than this 
silly one?

issue-to-binary: func[clr ][load head insert tail insert next mold 
clr "{" "}"]

and what do you want... the string or the value?

I want binary value

so four byte issue gives 32 bite value...

or is initial issue a decimal type integer?