World: r4wp
[#Red] Red language group
older newer | first last |
DocKimbel 17-Sep-2012 [1916] | No, trivial, I would then just remove #system-include and add an option to #system to have the code loaded outside of 'red context...but semantically, it will be a bit inconsistent with barebone #system, as it means "inline the Red/System code here"...Maybe I should just rename #system-include to solve that. |
Kaj 17-Sep-2012 [1917x3] | It works as it is now, but then I run into the #define problem |
This form of #system-include is probably still handy | |
Why does it require a block? | |
DocKimbel 17-Sep-2012 [1920] | I've changed it to #system-global, work exactly as #system but loads outside and before 'red context, should I push it? |
Kaj 17-Sep-2012 [1921] | Please |
DocKimbel 17-Sep-2012 [1922] | Done. |
Kaj 17-Sep-2012 [1923x3] | Works with #include with an absolute path |
There's an extra problem when I wrap the C binding in a context, but that seems unrelated | |
An #enum isn't prefixed with the context | |
DocKimbel 17-Sep-2012 [1926x2] | For the defines, I think the best option (and cheapest) would be that I prefix the one I use internally for Red. |
It should IIRC. | |
Kaj 17-Sep-2012 [1928] | It's worse than that. The first error I get is on one of my #define's that's a struct! later in Red |
DocKimbel 17-Sep-2012 [1929x2] | I guess you'll have to prefix (or suffix) them. |
Which one is conflicting? | |
Kaj 17-Sep-2012 [1931] | That would really butcher all my bindings. And it's too much work just to do temporarily for the demo |
DocKimbel 17-Sep-2012 [1932] | I can maybe change some on Red side, if there are not too many conflicts. |
Kaj 17-Sep-2012 [1933] | It's NONE, but I really wouldn't want you to change that in Red. And it's just the tip of the iceberg |
DocKimbel 17-Sep-2012 [1934x2] | Added new actions: AT, SKIP, BACK, NEXT, LENGTH-OF. You can now do a bit more than just PRINT 1. ;-) See: a: 123 a: a + 2 print a * 6 - a b: [4 7 9 [11] test /ref 'red] print pick b 2 print pick pick b 4 1 print pick next b 1 print pick next next b 1 print pick back next b 1 print length-of b print length-of next next b print length-of pick b 4 print pick at b 2 1 print pick skip b 2 1 print pick at next b -1 1 print pick skip next b -1 1 |
I'll extend FORM tomorrow so we can print more types. | |
Kaj 17-Sep-2012 [1936] | #233 is back |
DocKimbel 17-Sep-2012 [1937x2] | Looking into it. |
Fixed it. Going to rest now, will process other tickets tomorrow morning. | |
Kaj 17-Sep-2012 [1939] | I'm busted, too. Night |
Pekr 17-Sep-2012 [1940] | Reading all the discussion about R/S source inclusion in the Red - it seems pretty complicated and confusing at best. Apart from the three options discussed on friday, it is the "least powerfull" one. It is not any kind of inlining R/S code into Red from the runtime point of view, hence I wonder, why it is not simply called an #include? I know you might want to two cases now: #include %some.red #include %some.reds But that's distinguishable, and unifies the naming, as well as it does what the name suggests - it is just preprocessor kind of directive for including either the red, or r/s source into Red .... |
DocKimbel 18-Sep-2012 [1941] | About your proposition: - #include is for including files, not for inlining literal code, which is precisely the purpose of #system* directives. - you can't use #include to include directly two different languages, that would be confusing for everyone and it's a semantic mismatch (making users think Red/System code can be directly used in Red with no clear separation between the two). - #include is a preprocessor directive, #system is a compiler directive (processed during compilation) - #system* directive are not complicated nor confusing, they are pretty simple and should look intuitive to C users (having the habit to inline ASM code into C). Those users are the target users for Red/System (remember that most Red users will never program in Red/System). |
Rebolek 18-Sep-2012 [1942] | Will there be possibility to use inlined ASM code? |
Pekr 18-Sep-2012 [1943x2] | Well, not coming from C kind of languages, I actually used code inclusion rarely. The preprocessing stuff in any language looks arcane to me, but that's just my feeling, as it is REALLY a long time ago, since I used code -> compile -> link technique (CA-Clipper - 1998 :-) So I better wait for more "clean" way - the other method you described - simply what I am expecting is kind of Rebcode - writing any function in Red, using Red/System or C or ASM, whatever :-) But most probably I am confusing and create a mishmatch even in such case :-) |
one small question though - what "secret project" are you guys talking about? :-) I expect you will not want to tell, otherwise it would not be secret anymore, right? :-) | |
DocKimbel 18-Sep-2012 [1945x2] | Inline ASM: we might add that at some point, but you can already access some low-level CPU/FPU features (like stack manipulation). I will extend that in the future to support CPU in/out commands and direct registers reading/writing, so ASM support will be less necessary. Also, there's a cheap way to support it, adding the option to inline machine code directly in Red/System code flow (you would have to use an external ASM for generating the machine code). Something like: inline #{....machine code...} |
Secret project: that's a secret! (there's actually two secret projects, one by Kaj, one by me ;-)) | |
Pekr 18-Sep-2012 [1947] | ok, cool, so looking forward to the reveal of the secret projects ... which is going to happen cca ... when? :-) |
Rebolek 18-Sep-2012 [1948x2] | Is Red ging to have something like R3's vector! datatype? |
ging=going | |
DocKimbel 18-Sep-2012 [1950] | Yes. |
Henrik 18-Sep-2012 [1951] | looking forward to seeing people writing operating systems in Red/System :-) |
DocKimbel 18-Sep-2012 [1952] | Well, when CPU I/O instruction will be added, you'll be already able to make kernel drivers for Windows or Linux....and an OS is typically 90% made of hardware drivers. |
Rebolek 18-Sep-2012 [1953] | Pekr, if you are interested what action!s and native!s are currently available, I wrote simple parser that goes thru %actions.reds and %natives.reds and outputs list of all implemented functions. |
Kaj 18-Sep-2012 [1954x2] | I've added Red versions of Fibonacci and Mandelbrot to my C library binding, but they're just the Red/System code inlined in Red, with the timing code stripped out because I can't import the C binding, and Mandelbrot doesn't compile yet |
Is there any meaningful Red code I can show tomorrow? | |
DocKimbel 18-Sep-2012 [1956x2] | Only the examples I posted above yesterday night. |
We don't even have proper string! support yet. I plan to implement it this week. | |
Kaj 18-Sep-2012 [1958x2] | I'm trying to wrap my GTK dialect in a context, but I'm hitting more context bugs |
So it's going to be a traditional Red/System presentation, with little Red and contexts | |
DocKimbel 19-Sep-2012 [1960x3] | I've been very busy since yesterday on a new tool for Red: I've built a proper REBOL code profiler! (I wonder why I haven't done that since a long time...). I went through the profiler scripts on rebol.org and couldn't one suitable for my needs or that works with complex code, so I wrote one. It is able to deal with complex code, all datatypes, recursive calls and it's very simple to use. Here's a demo profiling Red compiler (output is properly aligned when monospace font is used): -= Red Compiler =- Compiling red/tests/test.red ... ...compilation time: 40 ms Compiling to native code... ...compilation time: 10189 ms ...linking time: 60 ms ...output file size: 37888 bytes >> profiler/report/time Function Count Elapsed Time % of ET ------------------------------------------------------------------------ compile 1 0:00:10.249 100.0 comp-dialect 205 0:00:09.659 94.24 fetch-expression 7505 0:00:09.628 93.94 comp-word 5668 0:00:08.209 80.09 fetch-into 427 0:00:07.519 73.36 comp-assignment 597 0:00:07.049 68.77 run 3 0:00:06.492 63.34 comp-context 21 0:00:06.398 62.42 comp-with 1 0:00:05.565 54.29 comp-expression 3172 0:00:04.479 43.70 ns-find-with 24277 0:00:03.962 38.65 finalize 1 0:00:03.327 32.46 comp-natives 1 0:00:03.274 31.94 comp-func-body 180 0:00:03.271 31.91 comp-call 2775 0:00:02.732 26.65 comp-func-args 2861 0:00:01.862 18.16 find-aliased 9650 0:00:01.86 18.14 resolve-type 8032 0:00:01.799 17.55 get-type 10758 0:00:01.546 15.08 ns-prefix 21765 0:00:01.518 14.81 check-enum-symbol 7509 0:00:01.241 12.10 comp-block 283 0:00:01.05 10.24 comp-variable-assign 417 0:00:01.034 10.08 |
The overhead of the current implementation is about 5-6 times the program execution time, so it's very usable. I will publish it today, and I hope someone will pick it up to improve it and add features (like a GUI front-end for the reports, with sortable columns). | |
BTW, as I was thinking, the above compiler profiling confirms that aliases and namespaces support are quite costly currently (ns-* functions). So now I know where to improve the code for better performances (not that it matters for the users currently, but it matters to me as I need to run the whole test suite dozens of time each day, and with the addition of now Red compiler, it (and will) adds up to a lot of waiting time at the end of the day). | |
Gregg 19-Sep-2012 [1963] | That's great Doc! |
DocKimbel 19-Sep-2012 [1964] | REBOL code profiler released: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r Should work with any REBOL app. Documentation, comments and example included in file header. Hope someone will pick it up and improve it (like adding functions sub-tree stats and a GUI). This is github, so feel free to fork then fix/improve. |
Pekr 19-Sep-2012 [1965] | Doc - your twitter account got spammed? |
older newer | first last |