World: r4wp

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

I'm defining many extra types in the bindings

I hope after returning from ReCon, Doc is back on IO, we really need 
it to make more usefull stuff. Reading/writing files via some libraries 
is nice, but I want my read/lines :-)

Watching your video Arnold, great work!


http://www.youtube.com/watch?v=qx-4K8F3VMM&list=PLr1rbtkaZDGDKtExuz8Q0nFDtDtUyyOHz

Pekr: you might want to FB-it? ;-)

Ah, was expecting to see also the first compilation description...have 
to wait for the next episode! :-)

Maybe Pekr could do an Android Red app compilation + execution on 
the online emulator short video too? If it includes one of your nice 
models from the photo studio, that would be even better. ;-)

No SW to record screen, so maybe later :-)

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.

@Arnold nice ;-) Might be useful to add sequence numbers to video 
titles

Nice work Arnold!

I like your video, Arnold!

Cross-posting on SO Chat.

Ah, second video already online:

https://www.youtube.com/watch?v=7YPbEtG8mf0&list=PLr1rbtkaZDGDKtExuz8Q0nFDtDtUyyOHz

Good initiative, Arnold

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

Petr, you can implement read/lines right now on top of READ

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

One day I will understand and make the video ;-)

Koel :-)

Having to add all #include for many of these kind of common functionality 
(time random i/o etc) is less friendly than having these integrated.

Sure, that's why they're in separate repositories. When Red takes 
the pieces it needs, it won't be bothered by the full bindings, but 
they can still be used in Red/System programs

In the meantime, if you want everything included, use the interpreter 
builds

'make-c-string is my friend. My Red/System scripts are so much happier 
now that I'm not assigning c-strings to arbitrary locations in memory 
like I was doing with 'as-c-string. :-)

:-) Note that most of your string initialisations were unneeded. 
Several allocations are done by the functions you're calling

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"

I'm trying to track down an access violation.

You're allocating both file1 and file2 double there. The two 128 
byte strings immediately leak away when you assign the literals

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?

linking = pointing

Then when you append to file1, you're overwriting the string literal 
inside the executable, so you're destroying your program in memory

So how would you write the above?

Allocations are very much needed, but once made, you have to guard 
them like your most precious posession :-)

The problem is exactly that you're not doing the COPY of the literal. 
Very much like REBOL

Is this the right way?

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

Yep

I'm assuming that 'append-string copies the source parameter.  Right?

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

OK.  The mental picture grows clearer.

So file2 is unneeded in there, because appending the literal copies 
it, anyway

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

OK.

append-string returns the result, so you can chain them just like 
in REBOL

append-string append-string file1 "dir/" "file.txt"

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