World: r3wp

2. zakres -0.5 > x > 0.5 nie jest suportowany

gues that means "not supported" :)

yes :)

Has the esmtp code in rebol core been completely debugged?  Is there 
some documentation somewhere that discusses how to overcome problems 
is sending e-mail? A script that worked for years can no longer send 
e-mail, and I have no idea what the problem is. We are using a bluehost 
server.  trace/net on is not revealing the problem.

you may want to check this one as well: http://www.nwlink.com/~ecotope1/reb/decimal.r

Just cannot find the format.r script

Also Erick's script is only 64bit

Thanks Oldes, that script should help a lot.

I can try to fix the 32bit version if you want.. but later

I should be able to do that, looks easy enough. I'll call you if 
I get stuck. :-)

Got it working for single precision floating points.

Fine... I just updated the Eric's version: https://github.com/Oldes/rs/commit/37c6e8e8bc316b06bf8eef1638225551421199b2

But it sometimes returns results which are not exactly identical 
like with the struct! version... like: #{BDCCCCCC} versus #{BDCCCCCD} 
for -.1 
I guess it's because of rounding error in Rebol itself.

update: https://github.com/Oldes/rs/commit/19771ea6a7991dd6960ec8c9a1a2a2690c6cd527

fixed the rounding so now the result is same like in the struct! 
version and added real/from-native32

I've added a +1 in my version to compensate for that.

Hmm, you've transformed 'from-native, but as the real need was in 
fact to be able to get a binary! representation of a decimal! value, 
I tranformed 'to-native and 'split for that purpose. Has this IEEE 
library is quite rich, the need for the workaround of the intermediary 
string! representation is not needed anymore. Anyway, thanks for 
the update, I'm sure we'll need it at some point for float support.

I transformed both, to-native (the first link) and from-native (second 
one) although I know the binary to decimal version is not needed 
for the Red project... it was just to make it complete. Btw.. I think 
it could be optimised as logic operation are faster than pure math.

Thanks, I've missed that. In my version, I have removed line 389 
in 'split32 and added: fraction: fraction + 1 after 390. That fixes 
the "by one" inaccuracy.

block-of-objects: reduce [ make object! [ test1: 1 ] make object! 
[ test1: 1 ]]

foreach object-to-edit block-of-objects [
	object-to-edit: make object-to-edit [
	test-2: 2
	]
]

I'm trying to add a word to each object  in a block of objects with 
a foreach loop above but it's not working.  Can anyone help?

In R2 you can't add words to an existing object, you have to make 
a new object (as you are above) and change the reference in the block 
to that new object. FOREACH gives you the object, but not the block 
holding it. FORALL will work for this. e.g. 

blk: reduce [make object! [ test1: 1 ] make object! [ test1: 1 ]]

forall blk [
    change blk make first blk [test-2: 2]
]

probe blk

Thankyou!

Hi all, I thought that this one has already been solved... Apparently 
not:


The VALUE argument of the APPEND function is not defined as [any-type!] 
(in contrast to INSERT). I think that this should be corrected in 
R2, shouldn't it?

Wow. I think so. Not that I remember needing to append UNSET values 
but, if that's the underlying behavior, it seems APPEND should be 
consistent.

So there is a difference, if no type is specified and if any-type! 
is specified. Like in:

>> f: func [v][]
>> f
** Script Error: f is missing its v argument

>> f: func [v [any-type!]][]
>> f

HELP does display it differently. In the first case, it's:

ARGUMENTS:
     v -- (Type: any)

and the second:

ARGUMENTS:
     v -- (Type: any-type)


Subtle differences. And you're correct, Ladislav. Insert and append 
sould take the same kind of argument.

Is it possible to get function name from inside the function body 
while it's procesed?

In general, no, as functions need not be bound to a word.

So far I'm using this:
myfunc: func[
	"Defines a user function with given spec and body."
	[catch]

 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
	body [block!] "The body block of the function"
	/local desc
][
	if parse spec [set desc string! to end][
		insert body reduce ['log desc]
	]
	throw-on-error [make function! spec body]
]

However, In R3, you can use the stack inspection native STACK for 
an approximation:
>> foo: func [] [print stack/word 1]
>> foo
foo
>> bar: :foo
>> bar
bar

Hm... that would be enough, but I'm in R2 now.

In R2, use the catch-an-error trick

      a-function: func [][print ["i am named " get in disarm  try [0 / 
      0] 'where]]
      a-function
      i am named  a-function

ah.. good one:)

cool :)

Just remember that a function does not really have a name. Just the 
name, if any, by which you called it:

    b-function: c-function: :a-function   ;; one function, many names

    do reduce [:a-function]                      ;; one function, no 
    name

http://www.synapse-ehr.com/community/threads/rebol-on-windows-7-and-a-network.1424/#post-10560

Anyone?

Interesting. I remember some talk about it in the past, but I thought 
it was fixed, or it was a different issue. I will try tomorrow at 
my work, our share is called "L:" too :-)

Graham, gotta love that Win 7.  I was about to move all my belongings 
to a W7 machine and retire my XP but not now.

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

Also try to use the full path. Once I have faced a problem CALL with 
REBOL style file! value. It worked with a windows-style path.

And also have problem with /shell worked on my XP but did not on 
my customers W7.

I just tried:

do to-rebol-file "L:\some\path\here\test.r"


and everything went OK, Win Vista here. Console is being launched 
form the shortcut on start bar, pointing to renamed to rebol.exe

note: the reason I used to-rebol-path was, that directory names contained 
spaces ....

Ok, I'll suggest this ..

When I use FIND with CHARSETs it ignores the /TAIL refinement. Is 
this a bug?

;with charset
>> find/tail "abc" charset "b"
== "bc"
>> find "abc" charset "b"
== "bc"

;with string
>> find "abc" "b"
== "bc"
>> find/tail "abc" "b"
== "c"

I think /last and /tail only apply to string values. Perhaps a feature 
that hasn't come to pass yet? :-)

be aware, that find with charsets behaves differently in more ways
>> find "abc" charset "db"
== "bc"

Combination of find/tail and charset looks like a bug to me.

sqlab, a charset is not a string its a bitset, so it will search 
for ALL the characters in the charset at each byte...   also note 
that when using find, charsets are case sensitive (and very fast).
the bug with /tail is pretty surprising, I never noticed it.

sorry for the color... It got stuck, I didn't realize I was in yellow 
 ;-)

I know that charsets find the first occurance of any of the chars, 
but maybe Endo knows that too. So I should probably not remind.

Thank you guys. I know the behaviour of charset in FIND. But I expect 
to skip the char that found, if I use /TAIL refinement as in using 
string.
Same for /LAST as Gregg said. It ignored for charsets. 
And also;
>> find/reverse "endo" charset "d"
== none
a bit confusing..