World: r4wp
[#Red] Red language group
older newer | first last |
DocKimbel 25-Aug-2012 [1416x2] | (.lib and .a reader coded in R2) |
So, next steps (next week), add PIC support to backends and implement shared lib support in Mach-o and ELF emitters. | |
Pekr 25-Aug-2012 [1418x2] | that's not a microcontroller, right? :-) |
OK, position independent code, got it via Wikipedia ... | |
DocKimbel 25-Aug-2012 [1420x2] | No, it's Position Independent Code: http://en.wikipedia.org/wiki/Position-independent_code |
PIC is mandatory in UNIX shared libs. | |
Pekr 25-Aug-2012 [1422] | so so far only Windows DLLs are supported, right? |
DocKimbel 25-Aug-2012 [1423x2] | Right. |
But that enables already to build a lot of things, like bridges with other languages or VMs. | |
Pekr 25-Aug-2012 [1425] | yes, generally we are now able to write low level binding using rebol like syntax, generate libraries for environments like Delphi, etc., which e.g. my friend still uses :-) |
DocKimbel 25-Aug-2012 [1426x3] | My personal favorite is Blender, I'd very much like to add Red/System support to it (and kick out Python later when Red will be there). ;-) |
But bridging with Android and iOS is high priority, so Blender will wait. | |
BTW, best option for bridging with Java can be discussed here (on the ML). I'm not sure anymore that the JNI way is the best one... | |
Pekr 25-Aug-2012 [1429] | What I still think is, that we need strong parse. It is very cool technology. Yes, I dare to call it a technology. We need r3 level parse. Then we can create dialects, and show other guys, that dialecting is a cool concept. Pity we were not able to capitalise on it more, mainly due to closed nature of R2 possibilities to bind to other environments .... you imo :-) |
DocKimbel 25-Aug-2012 [1430] | *(or on the ML) |
Pekr 25-Aug-2012 [1431x2] | you = just |
some kind of brige is required, if we want to get into an Android API. Ditto for .NET? | |
DocKimbel 25-Aug-2012 [1433x3] | Yes |
Same issue. | |
I have added a sample program for those who want to play with DLL generation: https://github.com/dockimbel/Red/blob/dyn-lib-emitter/red-system/tests/shared-lib.reds | |
Kaj 25-Aug-2012 [1436x2] | I've looked at the Blender interface, but it's rather big and complex |
Petr, I think we need Topaz level PARSE :-) | |
Pekr 25-Aug-2012 [1438x2] | you used -dlib option, does it replace -t one? Not skilled here, but - can I generate e.g. ARM executable/library from Windows Red/System? Or is target environment needed? |
Topaz has even better parse than R3? | |
Kaj 25-Aug-2012 [1440] | I don't know if it's complete, but it goes beyond REBOL |
Jerry 25-Aug-2012 [1441] | Doc, this page can be updated because of the support of DLL generation. http://www.red-lang.org/p/roadmap.html |
Kaj 25-Aug-2012 [1442x6] | Also, 4.8 in the documentation: |
As c-string! and struct! are already implicit pointers, the only pointed datatypes allowed are integer! and byte! (logic! pointer is not needed). | |
Outdated since float support | |
4.8.2: | |
Pointer declaration is only required for local pointer variables in functions' specification block. In such case, the datatype declaration can be omitted and left to the inferencer to guess. | |
This seems to contradict itself | |
DocKimbel 25-Aug-2012 [1448x7] | Blender: yes, API is huge and it's a lot of work, but I'm convinced that Red, with appropriate dialects, would do wonders there and it could be a great way to make Red known. |
-dlib option: it's just set the flag to produce shared library instead of executable. -t option: sets a target which is just a handy way to group several options together (most options don't have a specific command-line switch). | |
can I generate e.g. ARM executable/library from Windows Red/System? You can cross-compile ARM/ELF code from Windows or MacOSX, just use the appropriate target (https://github.com/dockimbel/Red). Currently there's only two ARM targets: Linux-ARM and Android. You can cross-compile to these targets from any platform Red/System compiler works on. | |
When Windows for ARM will be out, I guess we'll need a few modifications to PE emitter to support it. Does anyone know if Windows8/ARM beta versions are available somewhere? | |
Jerry: roadmap updated. | |
Re 4.8 in docs: I agree it's messy...improving that right now. | |
Done. | |
Gregg 26-Aug-2012 [1455] | I know I'm late to the game, but temp.dll works here (win7 x64). If needed, I can pull up an XP x64 box to test. |
DocKimbel 26-Aug-2012 [1456] | Gregg: thanks for taking the time to test it. I think it won't be needed for XP x64 as we know it works on XP 32-bit and W7 x64 already. |
Rebolek 27-Aug-2012 [1457x2] | Doc, I can confirm that the DLL works now. Thanks! |
Well that was too soon. If I compile your example (%shared-lib.reds), I cannot load it into R2 (R2 crashes). If I comment all the on-* actors, I can load the lib, but I cannot access any values from the lib (foo, bar, i has no value). | |
DocKimbel 27-Aug-2012 [1459x2] | Rebolek: I can reproduce the crash, looking into it.... |
(I'm pretty sure it was working last time I've tested shared-lib.reds script) | |
Rebolek 27-Aug-2012 [1461x2] | And are you able to use the exported values (foo, bar, i)? |
Ah, nevermind, I had an error in my test script, exported values work. | |
DocKimbel 27-Aug-2012 [1463] | It seems there are some remaining bugs in on-* callbacks, probably registers saving issue...still investigating... |
Rebolek 27-Aug-2012 [1464] | So I've got this working: >> foo: make-native [a [integer!] return: [integer!]][a + 1] >> equal? 124 foo 123 == true Still needs some work before publishing, but it shouldn't take long. |
DocKimbel 27-Aug-2012 [1465] | Great! :-) I'll push a fix for the on-* issue in a couple of minutes. |
older newer | first last |