World: r3wp

See how it performs for a little while, first... :-)

this might be something dangerous:

write %test.r "hello"
path: what-dir
remove back tail path
write %test.r "hello" ; this fails


problem is: what-dir returns directly system/script/path what seams 
to be used in order to resolve relative file values

I just recognized it using the request-dir from didec which was in 
the rebgui distro -038 (he's doing this in the request-dir function 
in the line with


if all [not empty? path slash = last path][remove back tail path] 


so question is whether this is a bug and belongs to rambo, is ok 
(I don't think so) or what else ?

might also be that didec changed this in a later version (script 
was dated 2003 and maybe at this time 'what-dir had a different behavior), 
but this doesn't matter regarding what 'what-dir returns

dangerous in the sense hard to get why suddenly some 'write doesn't 
work anymore

its another form of change-dir IMHO

So there is no problem. except of the usual "easy to forget copy" 
in Dides case. Hmm, maybe this effect is really hidden, with what-dir 
beeing a function. Easy to expect it copies.

yes that's what I mean, nothing wrong with rebol, but who guesses 
that this returns a really vulnerable path

Everyone who knows Carls ways of ssaving space. Although, i agree 
:)

:-)

but then Carl should write something about stylerules to add to every 
function documentation which states whether it's copying things or 
not - sometimes it's mentioned but like in 'what-dir 's case not 
- so either better styleguide or these things should be implemented 
the safe way

its easier to write when its copied..

what do you mean ? (you don't need to copy yourself - thus saving 
a word?)

No, if there isnt mentioned "it returns a copy" better expect it 
does not..

WHich is rarely, so it is easier to add the few "it copies" then 
the lot "it does not"

ok, only problem I have is that in real world situations one can't 
think about everything and starting to copy everything everywhere 
just to be safe is no solution

I'm thinking more in terms of some normal person (if there is something 
like that) and to me it seams quite a burden to think even about 
such tiny details

Dont take me serious, i am sarcastic! Although i don't know a good 
general solution for this copy-thing.

and in my case it was even worse as I didn't know what happend until 
I stared to examine a outside script pretty closely and step by step 
following what it does

yes I understand - I just don't know a good solution either

maybe it should really be a docu-rule. Forth has some flag-letters, 
like M: multitasking-impact etc. We could have C: copies/not, calls 
wait, what else?

( i am away, cu)

bye

This is what I called gotchas.

how do you test for a function that returns nothing? I want to DO 
a script, and check if there was an error, but the script might sometimes 
not return anything

!>>error? [()]
== false

!>>unset? ()    
== true

!>>attempt[() true]
== true
!>>attempt[1 / 0 true] 
== none

if error? set/any 'err try [do %script.r][print mold disarm err]

MichaelB: about the path problem in request-dir, it's a bug in the 
code.


The simple solution is to patch this line (in request-dir func at 
the end of the script :
	if not all [keep path] [path: any [where what-dir]]
like this :
	if not all [keep path] [path: copy any [where what-dir]]

the 'path word is local to ctx-req-dir context and the Rebol path 
must not be changed by it. It's up to the "user code" to change it 
if he wants to.

But I agree that Rebol should check if path is "complete" (trailing 
"/") before using it in read/save/load/... functions

I have got question from Bobik, to which I don't know answer ... 
I tracked the problem, but dunno why it is as it is :-)

blk: [1 false]

if blk/2 [print 123]

he was wondering, why it is true .... I found out after checking 
the type? blk/2, which is - word! .... my question is why it is word! 
and not logic! ?

blk/1 is integer!, why false here is not logic! ? anyone? thanks 
:-)

blk: reduce [1 false]   ;; to correctly evaluate the block contents

I guess it's analogous to:
  blk: [1 make object! [a: 1]]
  print blk/2
      make

blk: [1 #[false]]

ok, thanks ... I think now I understand ... yesterday I read about 
Haskell and functional languages ...

Bobik used str: "[1 false]" val: load str ... so basically, he "executed" 
(evaluated) string, he got block, but he forgot to do the same for 
block content - so here reduce comes in the play ...

It can be annoying because reduce does not have a /deep refinement 
-- so if you load nested blocks, you may need to do a lot of reduces 
to make it work:
   xx: reduce  load " [ false [ true]]"
   == [false [true]]
   type? xx/1
   == logic!
    type? xx/2/1
   == word!

I wonder if not being strongly typed (as Haskell claims they are), 
does not lead to almost untrackable bugs ... yesterday, working with 
debugger with our Ubicom CPU, I started to wodner, how we can live 
without the debugger in REBOL :-(

I''ve been caught-22 on that many times since I like to set my ini 
file definitions to be readable blocks and don't follow why other 
data types are correctly recognized e.g. blk: [1 12-feb-2006 $30.00] 
 but not true or false or Yes or No  without a reduce.  If you use 
blocks for the ini file settings you get caught by the reduce  e.g. 
if want this ini: [	clean-up-target-directory? Yes start-at 10:30:01 
first-day-to-run 12-dec-2006 last-day-to-run 31-dec-2006] reduce 
requires me to flag the words as 'words.

I tend to use nested objects as records stored in files. They suffer 
the same problem.

My solution is a single read function hat runs through reducing things.

Petr: having only 'trace or inserted 'print for debugging is like 
going back to the dark ages.
Better debugging would be a great step forward.

debugger? does a tool like this exist for REBOL? http://www.hmkdesign.dk/rebol/reblog/reblog.html

it's practically automated testing and probe on serious steroids 
:-)

Looks great!
Any release date?

I could release it now, but it's very, very buggy and it's not shielded 
from the program context

You need to decide if you have the time now to deal with the bugs 
people will issue.  If not, wait til it is more stable.

http://www.hmkdesign.dk/rebol/tester/tester.r