World: r3wp

Oh sorry, your second example. Ok.

Does anyone have

a function to sort jpeg files from a digital camea by exif date?

IIRC, someone did EXIF reader. Have you tried looking into rebol.org?

Pekr, thanks for responding. I'll look there.

There are two scripts from Piotr Gapinski, related to EXIF. IIRC 
Oldes did ImageMagick wrapping,maybe it can do some EXIF stuff too 
...

or you can use command line tool like Exiftool, and wrap the result 
using CALLL in REBOL and parse the output?

>> buff: copy ""
>> call/wait/output "exiftool img_0033.jpg" buff

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