World: r4wp

Here's the troubling bit of code:

	dirs: make-c-string 1024
	dirs: read-file "to-process/dirs.txt"

	eol: make-c-string 1024
	eol: find-char dirs #"^/" ;Finds the first end-of-line character

 line-len: as-integer eol - dirs + 1 ;Add one byte for the end-of-string 
 character
	first-line: make-c-string line-len
	copy-string-part dirs first-line as-integer eol - dirs ;reversed
	first-line/line-len: #"^(00)"

Shouldn't 'find-char dirs #"^/" return the first newline byte?

Yes, you're looking for the LF, so you're including the CR

On Windows, the C library that executes the read-file converts DOS 
newlines to Unix LF format. I've had trouble with that before in 
the binding

The C library on Unix just assumes it's a native file, so if there 
are extra CRs in there, it doesn't touch them

It's best to standardise on LF format, even on Windows, with a capable 
editor

The dirs.txt file is being written to the Pi using Rebol on Windows.

Yes, it uses local Windows convention

You must do the conversion somewhere in the chain

So, I'd have to form the file in Rebol, convert it to binary (in 
Rebol) and remove the CRs from the binary, then use write/binary 
to write it out.

Doesn't REBOL have a refinement to force it?

The other option is to convert it in Red/System

write/with

R2 only

I'll just use write/append/binary with #{0A} as the terminator.

It's working now.  Thanks for all your detective work!  I don't know 
how you can find bugs so fast.

I didn't think it was very fast. :-) I had a hunch in the direction 
of corrupted printing all the time, but didn't think of CR

What I meant was "fast compared to me."

:-)

It still sucks to loose hours to this issue fourty years after it 
was perpetrated

I suppose it would be useful if I made read-file more like REBOL, 
like it already behaves on Windows. I'll look into that tomorrow

You're awesome!

Thanks

For anyone interested, I just published a JPG in the Files section 
under Misc called MotionDetect.jpg showing real-time motion detection 
performed by the Raspberry Pi running Red/System.  The top two frames 
are the actual camera video (shot at dusk) and the bottom frame highlights 
the areas of motion.  Thanks in huge part goes to Kaj for helping 
me finish this first project!

Cool to see it displayed like that

What do you mean by "displayed like that"?

By the way, the bottom image is completely built by Red/System.

Well, displayed at all. :-) So far I had only seen isolated code 
snippets

Have to protect my intellectual property. :-P

I really can't thank you enough, Kaj, for all your help!

Yes, but that's not what I mean. It's all very abstract and seems 
like any other code, but now it comes to life

I love the feeling that I get when I see my software working!  Especially 
something I've been struggling with for days/weeks/months.

My original prototype written in R2 was started 3-Aug-2012 and finished 
9-Sep-2012.  It's taken this long to get it running on the Pi natively.

Was that fast enough?

The development cycle?  Or the speed of the software?

R2

R2 couldn't do it nearly fast enough on the Pi.

However, it was fast enough on a powerful workstation.

R2 could even handle several cameras simultaneously on a powerful 
workstation (maybe 4 cameras at 1.3 megapixels @ 8fps).

Not bad, but not available on ARM

Right.

So can you do without the Broadcom specs now?

I've found a way around it for now, but I've had to make some concessions 
that I'm not very happy with.  My goal is to still get my hands on 
those Broadcom specs so I can get better performance and flexibility.

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).

Yes, the ARM instruction set is optimised for speed at the expense 
of size

I've got plenty of room on the Pi, but not a lot of processing power.

So I'm thankful for that.

Another thing I've never tried in Red/System and can't seem to get 
to work:

	min-pixel-area-text: make-c-string 16

 min-pixel-area-text: read-file "config/motion-trigger-min-pixel-area.txt"
	print-line ["Minimum Pixel Area = " min-pixel-area-text]
	min-pixel-area: as-integer min-pixel-area-text
	print-line ["Minimum Pixel Area = " min-pixel-area]

Output:

	Minimum Pixel Area = 1
	Minimum Pixel Area = 3358672

@Bo 'read-file' will call 'fread' in libc, so it will return the 
total amount of bytes read.  I think 'Minimum Pixel Area = 3358672' 
is the number of bytes read from your file, but I have no idea why 
it print a '1'  in the first output.

Thanks for the suggestion.   I had the number "40" in the file before, 
and it printed "40", but gave me the same long number in the second 
'print-line.  So I don't think that is it.

I am with Arnold here, but I admit that it might be a psychological 
aspect, nothing more. Simply put - we have some low level stuff available, 
and I fear bulding higher (Rebol level) commands will be waste of 
time, as Doc will most probably rewrite it differently?