World: r3wp

so prefilling the string to 100 chars of anything, will at least 
allow you to acces the whole buffer afterwards...

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

that is strange a bit then .... feels like close to cause a crash 
:-)

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.

in this case, rebol never really manipulates the string...

well, that's true - doing make string! 100 does not mean length? 
should return 100 .... maybe we should have size-of?

all I need to do is :
value: copy/part  buf  find  buf  #"^@"

good idea!

wouldn't it be enought to just value: copy buff?

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

Max: to-logic "false" how about using something like to-logic "1 
+ 3 < 2" then?

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.

Note: TO LOGIC! is compatible with IF in cases like:

if "false" [...]
if to logic! "false" [...]

except for one case: to logic! 0 yields FALSE

another example: to logic! 'false

oh this last one is a bit dangerous IMHO.


since not using the /all refinement of mold easily create true/false 
words... (I  know you'll say use /all) but REBOL isn't always the 
data originator.

Anytime you pass a string buffer to the API, you have to pre-fill 
it. I have a little func called NULL-BUFF, that just inits a string 
filled with nulls. 

A DWORD is 32 bits. A WORD is 16.

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 agree that its only a valid case for the TO LOGIC!

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

Agreed. I'll have to look at my CAST func to see if I dealt with 
any of these issues there.

Nope. Maybe I should. :-\

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.

We can publish them, sure, but I don't know if they'll get into R3.

Carl is very open AFAICT.  this is specifically walking on one issue 
which needs improvement in REBOL in general.

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

revault  ;-)

Yup. :-)

I have been toying with the idea to add system environment variable 
support in slim for the path resolution  :-)

I have the getenv all done... I think I prefer this method by far.

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

As an addition, correct, not the only way to specify SL:IM paths?

I like "no install" solutions. :-)

nope, the 5th option  :-)

btw, this is my buffer init procedure for routines:

buffer: head insert/dup copy "" #"^@" 100

for a 100 byte buffer (99 max length C string)

Max, I think you'll find great difficulty in setting the environment

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

What's the best way to avoid / handle "Math or number overflow" errors? 
How can I ensure that if the user inputs extrem big numbers, won't 
crash my app?


Especially if I'm doing complex calculations. Do I have to wrap every 
calculation to catch this error? That would make the coding very 
cumbersome.

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

*check*

But as said, if you have formulars it depends on all input values 
if such an error can happen or not.

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.

Ok, but I have about 400 calculations in my app...

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.