World: r3wp

use braquets

if (find tempLine "//Database ")  <> none [ print "Here" print line 
 ]

and remove (<> none), it's useless

argh , cant wrap my head around these damn precendence rules

if find tempLine "//Database "  [ print "Here" print line  ]

can you explain why the brackets work ?

because "//Database " <> none is first evaluated

return always true

so, in realty , you do a find templine true

and why is that evaluated first, I thought things were left to right 
?  YOu know where in the manual i can re-read this ?

no

all op! are evaluated first

i don't no for the manual

*know

thx for your help -- the manual desperately needs a search function

CharlesS, if you changed the equation to;

if none <> find tempLine "//Databases" [...] this would also work.

the find in this case would be evaluated first, prior to the op!. 
 Unfortunately I don't know where I read this but I know i've seen 
lots of code where the equation portion of the condition is followed 
by the condition itself  ie, if 2 = 5-3 [do this].  It's backwards 
to what you would expect, but follows with the right to left evaluation 
that occures.

PATH is just not supposed to be used :) it is there by mistake afaik.

it's there so we've got something to fiddle with and don't ask about 
new releases too much ;)

;)

I wonder what is 2.7 good for, as R3 official release is at DevCon, 
and it is less than 3 months? ;-)

i guess people won't start using r3 in production that soon.

Pekr it's official preview and not release

how comes? Official alpha was supposed to be out 3/4 year ago :-)

maybe R3 is little bit delayed because 3D Realms addopted it as a 
main programming language for Duke Nukem Forever? ;P

I think R3 is not really delayed... I think the plan has simply changed, 
and this time Carl is finally working at delivering what he promised 
at devcon 2004.  He might have realised that its a little bit more 
work to make something so open... you can't hide the ugly things, 
so I'm pretty sure he is doing a lot of cleaning up...  and we have 
been hearing about the fact that this time, view isnt' being left 
behind...

Rebolek :-)))

Maxim - hopefully you are right!

I'm OK with R3 release date, but just couldn't resist to make that 
dukenukem joke :)

rebpro does not contain core stuff? so no decode-cgi for e.g.?

you mean rebol/view pro?

or some sdk build?

no, rebpro I placed on server .... as I needed library access, but 
this time it does not contain decode-cgi, uh, I will have to generate 
my own rebol.exe with features I want?

I vote once again for pad function!

I just needed very simple function, which will return me 20070220 
... so I want to write something like:

join now/year [padl now/month "0" 2 padl now/day "0" 2]

Instead of writing some stupid 'either lenth? code ...

>> 0.0002
== 2E-4

It may be old, but how do you avoid this conversion_

we have other trivial mezzanines, why not something like 'pad? Who 
writes the simplest code for me ;-)

yes Henrik, that is just another "stupidity"

put it in challenge :)

pekr, I vote for pad too, only because I've written that function, 
oh, about 50 times now.

I had function somewhere, parsing E-+value, and generating string.

maybe it is how Jaime wrote - we need print/form dialect ....

Well maybe we do, but is that the REBOL way to do it? pad is very 
simple

simple, often needed, should be added - is that simple as that? :-)

simple might grow complex enough if you study it closer. I was completely 
surprised at the INC/DEC discussion. :-)

yes, e.g. padding in the middle of existing series - pad-left, pad-right 
:-)

one can say, what do you need to pad? it's usually only numbers, 
right? that would narrow down datatypes required to be handled.

pad can also be used to left, center, or right justify strings ... 
my fill (pad) functions allows all variations on string! & number... 
a zfill is just a preset using the "0" char as the pad.  it even 
has a truncate refinement when you need the output to be *exactly* 
the specified length, even if it would be larger than what you ask.

the scientific notation is a side-effect of window's use of IEEE 
floating point libs.  for some reason, on windows, the output is 
automatically converted this way... I have seen this in other apps 
on windows too.  converting to/from a nice decimal would probably 
take too much time.