World: r4wp
[#Red] Red language group
older newer | first last |
DocKimbel 17-Sep-2012 [1909] | (I mean just #include %../C-library.reds) |
Kaj 17-Sep-2012 [1910x3] | By the way, I think we should eventually have a search path for includes, but that's for the future |
Yes, I use relative include paths of that form in all my bindings and examples | |
I need them to be able to install my Fossil repositories side by side in one main directory and then #include between them without changing paths | |
DocKimbel 17-Sep-2012 [1913x2] | I've pushed #system-include addition, but there's probably more path-related patches to apply I'm afraid. |
context-sensitive #define: seems to be a complicated change as it is the heart of the preprocessor...but context are created only during compilation (so after preprocessing). | |
Kaj 17-Sep-2012 [1915] | It would be easer if #system-include would be like #system so that you could wrap an extra context around Red/Sytsem code, without introducing an extra wrapper file. Would that be hard? |
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 [1958] | I'm trying to wrap my GTK dialect in a context, but I'm hitting more context bugs |
older newer | first last |