AltME groups: search

My bug mentioned above may not actually be a bug, but a misunderstanding 
by me in how to pull values from pointers.  It's listed at https://github.com/dockimbel/Red/issues/496

I should have that as a quick reference card on my wall. :-)

In the meantime, appreciating all thee help really, I cannot still 
make choclats from the routine and #system* examples given. Kaj's 
from friday and Docs example from 11 may and explanation from Sat 
5:11/13. 

I now understand that the way I did things the process includes my 
Red/System source into my Red code and than compiling starts on the 
whole thing leading to the error I get. What my intention is, is 
not done, namely leaving Red/System code to be Red/System code and 
place this within the Red/System code generated from the Red compilation.

What I think I also understand is that in order for the Red compilation 
to know a function is not found in the Red source because it is not 
know at that time, because it is defined in the Red/System source 
there should be some action as to make it known. That the blancs 
will be filled in at a later stage.

So first I include a reds source in my Red program. 
#system-global [#include random-taocp.reds
;-- and now this?
#export [random-taocp/ran_start
random-taocp/ran_arr_next] ;-- + all my functions needed
] ;-- and close the block of system-global

In this Red/System code i use a context and functions within that 
context.

I want to use a function from the Red/System code so I make a ROUTINE 
in my red source and from this routine I call my Red/System function

get-random: routine [n [integer!] return: [integer!]][ random-taocp/ran_arr_next 
] ;-- don't need the input here strictly speeking
Is this in the right direction now? Thanks.

Not so easy. I'll have to resort to building a really simple example 
and try making that work.

Thank you Doc! Now it is a lot clearer how to use it!

They have an announcement somewhere, giving a few reasons for the 
change. Slowness was part of that :)

Thanks. The right position for the menu is a bit annoying, but I 
guess we'll get used to it...Still I prefer the previous layout.

In the above example, dirs.txt is a text file of size 524 bytes.

Just in case it had a problem with me not picking up the return c-string 
from copy-string-part, I added a line and changed the last line, 
so the end should look like this:

return-string: as-c-string 1024

return-string: copy-string-part first-line dirs as-integer eol - 
dirs ;Access violation.  Why?

gives you a pointer to memory address 64, which is invalid

Is there really a [size!] datatype in Red/System?  Is that the same 
as [integer!]?

It's just a #define I use, mirroring the practice in C. Yes, it's 
an integer

Pekr, I used Quicktime on OS X from 5.6, For windows there should 
be a pretty good freeware alternative

Doc, thanks. Compilation description? Next step is to make a Red/System 
script and compile and test this. Then a Red script same storybook. 
Then calling R/S from Red example.

Thanks all. Numbering: I'll add a number at the end in square brackets 
like this [1]

Will the code be reusable in a pure Red solution if one would do 
that? 

To be able to do all kinds of possible things using Red bindings 
to C-libraries is great, beats not being able to do things by infinite 
factors. Still having the functionality coded in Red feels better. 
Open sourcing R3 has reminded everyone that it is made using C. HostileFork 
expresses the lack of development by the community as being caused 
by the difficulty and abstraction level of this C codebase.

There is no pure Red solution. When Doc will make an I/O framework, 
file I/O will still use a binding to the operating system underneath, 
which almost always means the standard C library

In a framework with scheme handlers, code will have to be refactored, 
but pieces from the current code could still be used. They're already 
small pieces, anyway

ok. The same solution was made for adding time or now you provided 
earlier. Somehow the timer has to be read using a standard C library.

Yes, if you don't want to write a lot of different code for different 
operating system kernels

How do I know when to initialize a string or not?  I was just going 
to ask that question.  Take this function from ANSI.reds for example:

	append-string: "strcat" [				"Append string."
		target			[c-string!]
		source			[c-string!]
		return:			[c-string!]
	]

Can I just do this?

file1: make-c-string 128
file2: make-c-string 128
file1: "to-process/"
file2: "dir/"
append-string file1 file2
append-string file1 "file.txt"

OK.  So 'make-c-string isn't really needed?  Isn't it like Rebol 
where if you don't do:

	copy "to-process/"


that you will be linking to a static memory location with "to-process/" 
in it?

Yes, it needs to for appending. It's not a linked list of strings 
or something like that

It's a contiguous memory area, just like a block in REBOL

If 'file1 is initialized but hasn't been assigned a value, can append-string 
use it as the target?

How do you mean? Initialising means assigning a value

But you did assign a value there: a memory block of 128 bytes

The only problem with using it as a target is that it may not be 
initialised as an empty string. For that, it needs to hold a null 
byte marker

In my tests, it did not work.  How do I initialize it with a null 
byte marker?  Like this?

file1: make-c-string 128
file1: #"^(00)"
append-string append-string file1 "dir/" "file.txt"

There is also a pre-defined constant "null-byte" available:

file1/1: null-byte

Oh no!  Just found a bug in the Linux-ARM version of Red/System. 
 It has to do with string handling, but I haven't isolated yet.  
Will post here once I do.

Odd. The append somehow considers the string empty on ARM, but it 
doesn't close the appended part with a null byte, either

The append is done by the C library, so if it doesn't append a null 
byte, that would explain it

Here is a more complete snippet ending with what I posted above:

	file1: make-c-string 128
	copy-string file1 "to-process/"
	append-string file1 first-line

	file3: make-c-string 128
	copy-string file3 file1

	print-line [file1 " " length? file1]
	append-string file1 "/img00.bin"
	print-line [file1 " " length? file1]

The above works perfectly on Windows.

Yes, I think it's a more natural order. You copy or move from to

My official C book doesn't mention null ending for strcat, but it 
does for all the other string functions, so it would be a very malevolent 
C library that doesn't implement it

Is this a good way to add that null marker?

	tmp: make-c-string 1
	append-string file1 first-line
	tmp: file1 + length? file1
	tmp/1: #"^(00)"

Judging by the printing, that must be a CR

So you probably copied a Windows text file to Linux

Is first-line a literal or does it come from a text file?

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

Doesn't REBOL have a refinement to force it?

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

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!

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

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.

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

@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.

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?

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


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

Xie, read-file is a Red/System function that does much more than 
fread. It returns the file content itself as a string, not the number 
of bytes read

Remember that a c-string! is a pointer to a memory address. Much 
like a string! in REBOL is a reference to the storage of a series 
value that can be referenced by multiple string!s, each with their 
own index

Petr, the Red/System READ functions and the higher Red abstractions 
on top of it are already here. As I said yesterday, Doc is free to 
use parts of it when he makes a more elaborate I/O framework in Red

Thanks for the advice and comments, everyone!  I'm feeling really 
good about Red/System and the greater Red ecosystem now that I have 
a project under my belt.  Kaj's been an immense help and I thank 
others also for their input!

Kaj, you said that 'read-file in Red/System automatically defines 
a large enough memory space for the file.  How about 'read-file-binary? 
 That one has a 'size parameter.  How can one determine how big to 
make that 'size parameter before reading the file?

In the case of read-string you get a c-string!, so you can get the 
size with LENGTH?. For read-file-binary that's not possible, so you 
pass a pointer to an integer! to be informed about the read size

I guess more or less what is the major usuability items that are 
still lacking in each.  Maybe you can answer that towards what RED 
still lacks as a major need.

There a timeline on those?

Hehe.  Possibly but got a new job that is hitting me hard.

Basically, we have a minifilter driver in Red/System that can be 
installed through an INF file, but when started (using `sc start`) 
we get either error 1058 or error 2 (File not found).

Is the process created as a service?

The INF file installs the filter driver as a service, yes.

Hmm, I guess we should try then implementing a suitable callback 
to answer properly to SCM commands...

Yes, still not sure what SC seen as file not found though.  But a 
process monitor from systems internals might tell us that.

Run procmon.exe against it and see if it records a specific file 
not found.

When working with Windows debugging, I typically like to run a process 
through procmon.exe and dependancy walker profiling before tossing 
into the windows debugger.

However, the driver just has a skeleton success return entry point, 
it doesn't try to take any devices or anything yet

Is it a driver or system service?

A kernel driver, but it's started with the service infrastructure

So the system is expecting it to do more than it does. But a null 
driver should just work

Should be able to find a free download via Microsoft site.  I think 
it is include in the Driver Development kit.

I am trying to learn Red/System but I have a strange result. When 
I enter this code all works fine, the input line is printed correctly:

#import [
	LIBC-File cdecl [
		get-line: "gets" [
			line	[c-string!]
			return:	[c-string!]
		]
	]
]

foo: ""
get-line foo            ; when run I enter: this is a test
print newline
print foo                  ; Correctly outputs: this is a test


but if I do this;

foo: ""
boo: ""
get-line foo          ; when run I enter: this is a test
boo: foo
print newline
print boo

then I get             ; "thisX @"

or if I enter: hello
it prints out: hellX @


It seems that something in the process of binding foo to boo is messing 
up, but I have no clue what it might be.
Any ideas?

gets() requires you to allocate a buffer of adequate size. Empty 
c-string! literals ("") will statically allocate an empty string, 
unsuitable for use with gets(), resulting in buffer overflows ('boo 
is allocated just after 'foo). Try rather: 

foo:  allocate 100
boo: allocate 100


This will dynamically allocate 100 bytes for each c-string!. You 
need to ensure that gets() won't overflow those buffers (which in 
practice is impossible, so one should just avoid using gets() in 
production code).

The allocate did not work because of a type mismatch but using long 
empty string literals did.

Have a look the Red/Sysme parts of Red's console:

https://github.com/dockimbel/Red/blob/master/red/tests/console.red


These are not the only ways to securely read inputs from user, fgets() 
is the main safe alternative:

http://stackoverflow.com/questions/4309746/safe-alternative-to-gets

Type mismatch: you can fix it easily with a simple type casting and 
proper string initialization.

foo: as c-string! allocate 100
boo: as c-string! allocate 100

Great, thanks Doc, worked a treat!

Here is the first Red/System driver, a minimal Hello World kernel 
driver for Windows:

So, I gave my new BeagleBone Black (BBB) a quick test. With latest 
Arngstrom Linux, I was able to upload Red ARM tests (generated using 
%build-arm-tests.r). All tests pass, except %function-test, which 
crashes with Runtime Error 1: Access violation ....

The above mentioned script also fails at it tries to make a directory. 
Maybe it needs make-dir/deep %runnable/arm-tests, or simply to remove 
%runnable ....

I have a technet subscription so I'm combing the database right now.

Function-test: it's a test that rely on unimplemeted feature that 
cause the crash, it should be disabled until  we get that supported.

Does look to be a bit closely guarded but here are some links that 
may get you going for PDB output  -> http://ccimetadata.codeplex.com/wiki/search?tab=Home&SearchText=pdb

Is there a RD

Sorry a RED Facebook?

As for news channels - if there is anything new, and my time and 
skills permit, I do post. It is a pity, it is not reposted to your 
blog, it looks really dated with latest 0.3.2 Repl release :-( I 
find it a bad strategy, the project seems a bit stalled, at least 
Git get propagated there ....

Paul: no much usable info there it seems. What I really need is a 
PDB file specification.

Well, it works, no? Not sure what other blogging sites/domains are 
available. Twitter kind of removed possibility to freely display 
content via JS code. You can do it, but inside your twitter profile, 
in Settings/Widgets, you can create new display widget. But customisation/design 
options are limited - basically dark/bright theme, number of tweets, 
some other formatting, and that's it. It spits out a little code 
you add to your site, and done ... maybe worth the effort, dunno 
- not sure about minimal width though - more info here https://dev.twitter.com/docs/embedded-timelines

Pekr: if you don't have a Twitter account, it would be a good idea 
to make one and post news about the Rebol and Red world from there. 
We need a stronger presence on Twitter.

Tried to write a tweet on Red Lang, it disappeared, maybe waiting 
for your approval? You can eventually remove it, not good at referring 
to other sites, etc.

You should rather use @red_lang, so it will appear directly. With 
a simple hashtag, I won't notice it unless  I search for it.

Sorry for the double post, I'm on 3G in a bus. ;-)

I'm travelling to the capital to get my plane tomorrow morning for 
Montreal (wih a short stop in Paris).

also this - both articles reference the book "Undocumented Windows 
2000 Secrets: A Programmer's Cookbook":
http://www.informit.com/articles/article.aspx?p=22685

Kaj: good idea, I'll make a montenegrin version of that page, with 
*only* Red! ;-)

AdrianS: thanks, it's reverse-engineered, so, maybe not fully accurate 
and complete, but it  looks like a good start.

debugging driver priority

 Not sure if you're mixing things here or not. First PDB has nothing 
 to do with drivers, it's a general-debugging help for Red and Red/System. 
 Second, I never said that drivers or PDB support was prioritary. 
 If I worked on adding driver support for Windows, it was just to 
 help Kaj and Bo use Red in their project, nothing else. The priorities 
 are clear, but I won't be able to resume on them until I get back 
 from Montréal.