• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Arnold
29-Jun-2013
[9052x2]
And because I am compiling in this two-step rocket Red - Red/System 
and viewing Red/System as the low-level Red program ....
add 1 1
2
DocKimbel
29-Jun-2013
[9054]
What you describe is not #include directive, it's #system. Including 
Red/System code into Red (means mixing both Red/System and Red source 
codes) is simply not possible.
Maxim
29-Jun-2013
[9055]
coudn't it be done with the jit, if given a block to compile on demand? 
 (not saying its implemented, just thinking about how it could be 
done).   sort of like inlining ASM code in C.
Kaj
29-Jun-2013
[9056]
You'd wrap ASM in C with an ASM marker, wouldn't you?
Maxim
29-Jun-2013
[9057]
yes, in the compilers which support it.
Kaj
29-Jun-2013
[9058]
Same thing. You need to wrap Red/System code inlined in Red with 
a Red/System marker
Maxim
29-Jun-2013
[9059]
ok, so isn't that what Arnold is asking, basically?
Kaj
29-Jun-2013
[9060]
No, he wants Red to read his mind. That's a common request among 
people :-)
Maxim
29-Jun-2013
[9061]
I think its a common request in all languages ;-)
Kaj
29-Jun-2013
[9062]
One could think of some constructs to integrate Red/System and Red 
even more closely than through a ROUTINE, but it's questionable whether 
it would be worth it
DocKimbel
29-Jun-2013
[9063]
Android APK build script now works fine on OSX too.
Bo
29-Jun-2013
[9064x3]
Finished my first crack at recursion in Red/System.  Works great! 
 Uncovered a bug (not in recursion, but in pointer indexing), but 
found a way to work around it for now.
My Red/System script (through some technical wizardry) can now process 
10 seconds of video from an HD source at 30fps and isolate motion 
areas of a particular size in a fraction of a second on a 700MHz 
Raspberry Pi.
:-)
PeterWood
29-Jun-2013
[9067]
Impressive !!!
Bo
29-Jun-2013
[9068x2]
Thanks!
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
PeterWood
29-Jun-2013
[9070]
In Red/System:

p: declare int-ptr! 				;; pointer 

i: 1                                                             
             ;; integer

p: :i						;; set p to address of i
print as integer! p				;; prints the address of p

      ;; the cast (as integer!) is to allow print to treat the value as
						;; an intteger
print p/value					;;  prints the value of i
						;; no cast needed as i is already an integer!
print p/1					;; equivalent to print p/value

Hope this helps.
Bo
29-Jun-2013
[9071]
I should have that as a quick reference card on my wall. :-)
Kaj
29-Jun-2013
[9072]
Congrats, Bo
Maxim
29-Jun-2013
[9073x3]
kaj, can you help me get R3 sources compiling?
or anyone else... in fact.
oh... sorry... wrong group!  what heresy!
Arnold
30-Jun-2013
[9076x4]
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.
DocKimbel
30-Jun-2013
[9080]
Arnold, #export is not related to Red with Red/System interfacing, 
it's simpler than that:
http://pastebin.com/Dddf57eH
Arnold
30-Jun-2013
[9081x3]
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.
DocKimbel
30-Jun-2013
[9084]
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...
Kaj
30-Jun-2013
[9085]
They admitted the old site was slow :-)
Andreas
30-Jun-2013
[9086x4]
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
DocKimbel
30-Jun-2013
[9090]
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.
Arnold
1-Jul-2013
[9091]
Not every change is an improvement
Bo
1-Jul-2013
[9092x4]
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.
Kaj
1-Jul-2013
[9096x4]
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
Bo
1-Jul-2013
[9100x2]
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!]?