World: r3wp

works like a charm, returning several pages of txt formatted output 
- http://www.sno.phy.queensu.ca/~phil/exiftool/

parse/all buff [thru "Create Date" thru ": " copy EXIF-create-date 
to newline]

your value is in EXIF-create-date ....

Wow! Thanks for the help Pekr!

Dunno how fast it is going to be though, exiftool looks slow, when 
called from REBOL. Might take some time to extract info from xy files 
in directory ...

I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r

To sort files you can use for example:

dir: %/e/DCIM/100CANON/
t: now/time/precise
result: copy []
foreach file read dir [
	error? try [
		ctx-exif/parse-file dir/:file
		exifdate: ctx-exif/get-tag-value 306
		repend result [exifdate dir/:file]
	]
]

sort/skip result 2

print ["sorted" (length? result) / 2 "files in" now/time/precise 
- t]
result

;>>sorted 120 files in 0:00:00.153

(it could be probably optimized as the script is from year 2004, 
but I don't care too much)

Oldes, many thanks!  I can''t work on this right now, but as soon 
as I can I'll report back.

Any news about a new year version of REBOL ?

Carl is still not apparently available, or he would blog something.

Anyone knows of a simple way to get to the binary encoding of a decimal! 
using just REBOL/Core (i.e. no struct!, no /library)?

why don't you want ti use struct!, it simple enough ?

Ah! already left

Because it doesn't work on /Core.

don't want R3 neither ?

Nope, then I'd ask in another channel :) R2/Core it is.

Asked another way: anyone has decimal to binary ieee754 conversion 
routines that work on /core handy?

and you googled everywhere you could I suppose :-)

i checked the usual sources, yes :)

Nop, I just looked on Rebol.org, nothing around ;-)

rebol.org has a binary32 conversion function, but it only seems to 
be half-done (as far as i can understand)

http://www.rebol.org/view-script.r?script=ieee.r

(LGPL)

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.