World: r4wp

or anyone else... in fact.

oh... sorry... wrong group!  what heresy!

Well done Bo! Yes those pointers and memory retrieving can be tricky, 
you can actually retrieve values from outside your boundaries, negative 
or too big, no problem.

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.

Arnold, #export is not related to Red with Red/System interfacing, 
it's simpler than that:
http://pastebin.com/Dddf57eH

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

Works fine now, except for overload on printed messages and some 
minor other issues introduced in the debugging process!

uploaded new Red version of the random script in folder Red random.

Damn, Github once again changed their layout...What was wrong with 
the old one?? It really looks like they change it for just the sake 
of change...

They admitted the old site was slow :-)

The new design makes much better use of the available space.

I got used to it quickly.

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

https://github.com/blog/1529-repository-next

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.

Not every change is an improvement

OK.  I have this snippet of Red/System code that is giving me an 
access violation.  I can't seem to find why:

dirs-file: as-c-string 64
dirs-file: "to-process/dirs.txt"
dirs: as-c-string 1024

dirs: read-file dirs-file	;'dirs now contains the contents of %to-process/dirs.txt
eol: as-c-string 1024
eol: find-char dirs #"^/"	;Finds the first end-of-line character
line-len: as-integer eol - dirs

print-line line-len	;In my example, this returns 24, which is correct

first-line: as-c-string (line-len + 1)	;An extra byte for #"^(00)" 
to be safe

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

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?

Same results.

Same thing as before with binary pointers

as-c-string 64

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

I see I have the argument order inconsistent between copy-part and 
copy-string-part. I've corrected that in the binding, so you now 
have to swap the arguments

Thanks, Kaj.  Sometimes it feels like it will be forever before I'm 
comfortable with Red/System.

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

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.