World: r3wp

which is not correct as well. As it would throw an error if the martker 
192 is not found... I should rather use open/seek instead of /direct

here is correct version using the /seek method... sorry for so many 
posts:

get-JPG-size: func[
	"Returns size of JPG image or none on invalid files"
	jpgfile [file! url!] "File to examine"
	/local stream bytes height width
][
	stream: open/read/binary/seek jpgfile
	;seek to jpg image start
	while [#{FFD8} <> copy/part stream 2][
		if tail? stream: skip stream 2 [
			;no Start Of Image marker found
			close stream return none
		]
	]
	stream: skip stream 2
	while[not tail? stream][
		bytes:  copy/part stream 2
		stream: skip stream 2
		if 255 = bytes/1 [
			either 192 = bytes/2 [
				stream: skip stream 3
				height: to-integer copy/part stream 2
				width:  to-integer copy/part skip stream 2 2
				close stream
				return as-pair width height
			][
				stream: skip stream ((to integer! copy/part stream 2) - 2)
			]
		]
	]
	close stream
	none
]

A few extra posts is no problem when you end up with a nice, useful, 
working func. :-)

that is fast! thank you Oldes 8)

How do you get Rebol from popping up 'public' folders everywhere 
(windows)?

I don't understand this question... byt maybe try to look at 'secure

terry, I posted a bug report on this once. I don't think you can 
stop it.

I'm not sure wether it works as advertised (esp. in all versions), 
but theoretically there's an option:
--noinstall (-i) Do not install (Link, View)
(to know about options: use 'usage)

On thnking about it, I think if you use --noinstall, that's when 
'public folders are created everywhere. If you install it, you can 
define the place where the public folder is to be created, and that's 
used then.

At least that's how it worked the last time for me.

I thought the newer releases stopped doing that. There were a number 
of builds that did it though. Very annoying.

it has never done it for me, but it has always done it for others. 
so, it's not clear yet how/when that happens. afaik the code does 
a make-dir view-root/public so in theory it should always be in view-root 
not in the cd.

I thought it only did it when you invoked the viewtop

... or any of the *-thru funcs

Yes very annoying, I use the following func to clean things up:

delete-public: func [dir [file!]] [
	foreach file read dir [
		if #"/" = last file [
			attempt [delete-public dir/:file]
		]
		if find [%public/ %Thumbs.db] file [
			attempt [delete dir/:file]
			print dir/:file
		]
	]
]

delete-public %/c/

Just thinking aloud (I would have to reboot into windows to test 
it, and I dont't waht to ;-) 
It it possible to set view-root in rebol.r or user.r ?

(You have to try, 'cause handling of these files differs between 
versions, too)

In the above func on a Mac you could replace %Thumbs.db with %.DS_Store 
;)

When it comes to decrypting, is it easier to hack an encrypted string 
if you know part of the string?

Ie:  If you knew that a stirng always started with   keys: [name 
"     could you decrypt it easier?

just thinking that if you encrypt an object, it probably starts the 
same for all.

I need to sort some French words but REBOL's SORT puts accented characters 
on the end (sorts just by ASCII). Has anybody got some enhanced SORT 
for French?

terry: it depends a lot on the crypt algorithm used and the length 
of the key. it surely helps to know any part of the plain text. however, 
just compression would reduce that a lot (since the result depends 
on the whole string); also good algorithms are usually smart enough 
to resist a simple attack like this.

Sorting: you may be able to adapt this hungarian code:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMWWJ

thanks Sunanda

a: make object [
  b: make block! []
  c: b
]

same? a/b a/c
== true ; OK

d: make a []

same? d/b d/c
== false ; how do I get this to be TRUE?

apparently I need to do it in the spec block, though i had hoped 
this could be done inside the object to encapsulate that entirely. 
cleaner code.

if your just looking for evaluating the value then use equal? instead.

Henrik: this may not be what you want, but it works:
    d: make a [c: b]

(your problem is, that cloning does not use much "intelligence", 
in the case of d: make a [], the cloning code just copies both a/b 
and a/c and therefore it is obvious, that two copies aren't the same 
block

ladislav, yes, that's what I had to come up with.

paul, d/b and d/c must be the same block, so equal? is not enough.

Is there any script for LZW decompression?

Oldes. These might help? http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=gunzip.r

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebzip.r

No.. these are based on zlib compression... I was interested in LZW. 
Here is just a compression http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=converter.r
... never mind... I don't need it . It was just for fun.

this is puzzling me ... it's a little loop to remove old files

foreach f read %./ [
			if f <> %. [
				inf: info? f
				probe d: inf/date
				if all [ inf/type = 'file (difference now d) > 1:00:00 ][
					attempt [ delete f ]
				] 
			]	
		]

** Script Error: difference expected set1 argument of type: series 
bitset
** Where: do-boot
** Near: difference now d

using  2.5.0.10.1

ok, fixed.  updated to latest Rebol for Solaris sparq.

Is this consistent? I don't think so:

>> a: make hash! []
== make hash! []
>> b: make block! []
== []
>> a
== make hash! []
>> b
== []
>>

The hash! property shouldn't be returned, instead just an internal 
flag.

I can use hash? to check for it.

well, I think returning the type in the console can be quite useful. 
if anything, it's block! that's being inconsistent.

In the console yes, but this longer stuff will be returned in code 
as well. And this makes parsing a bit complex.

>> reduce [a]
== [make hash! []]
>> reduce [b]
== [[]]
>>

how? parsing will immediately return whether it's a hash! or a block!. 
if you need to keep that information, the block of hash! blocks should 
be serialized first.

>> type? first reduce [a]
== hash!
>> type? first reduce [b]
== block!

>> c: mold/all reduce [a b]
== "[#[hash![]] []]"
>> load c
== [make hash! [] []]
>> first load c
== make hash! []
>> type? first load c
== hash!

No information loss.

I mean if you provide a reduce [...] to some parse rules and you 
have a "make hash!..." in the block you need to parse this. Hence, 
the parse rules change if you use block or hash.