World: r3wp

Thats right I think:
>> shift 257 32
== 257

>> shift 257 32000
== 257

which is same result as:

>> shift 257 32000 // 32
== 257

Yes

>> shift 257 32001
== 128
>> shift 257 1
== 128

at first glance a bit confusing, but actually it's ok. >> shift 257 
65 == 128

I see potential application malfunction. It's ok to mod by 32 for 
a rotate function, as it gives same result, but not a shift, I think.

Think what will happen, if the application move from 32-bit to 64-bit.

And the mod by 32 for a rotate is only ok on a 32-bit system, on 
a 64-bit it's mod by 64. And only for integers, not binaries etc.

That's right, but only if your "interpreter" supports 64 bit integers.

As for R2, its no problem, but for others it is.

Hm, implementing SHIFT in World gives me second thought. The C operators 
>> and << works as doing internal modulus. So checking for number 
of shift will hit on performance. So it's probably better to just 
go with it and let it be up to the user to eventually check for this.

What's the idea with SHIFTing a binary! ?

>> b: #{80402010}   
== #{80402010}
>> shift b 2
== #{20100804}
>> shift b 2
== #{08040201}	; so far so good
>> shift b 2
== #{02010000}	; but now we're loosing information
>> shift b 2
== #{00000000}


So SHIFT of a binary! just shift each byte and don't carry bits over 
to the next. What is this used for?

Its no sense SHIFTing bytes in binary, we can simply use series functions, 
append #{00}, copy/part etc. Shifting bits in binary could be more 
useful for graphics operations (not so sure)

My example is doing bit shifting right (decreasing value) by 2 bits 
at a time. The bits falling off each byte isn't carried over to the 
next byte.

In your example above it shifts bytes not bits. Even shifting bits 
in binary without carrying bits over to the next bytes doesn't look 
useful.

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 :)