OpenEuphoria

2. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 24, 2008
• 1223 views

Um,

Never mind, user error, it works.

Jeremy

4. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 24, 2008
• 1220 views

Ok, so it's not really user error. The code works on Windows, but not Linux. So that we can have the full code (typed the other one in), I'll paste the code here that works in Windows but not in Linux.

-- hello.e 
global procedure hello() 
    puts(1, "Hello, WOrld!\n") 
end procedure 
 
-- myprog.ex 
include std/dll.e 
 
atom lib = open_dll("./hello.so") 
atom fHello = define_c_proc(lib, "hello", {}) 
? {lib, fHello} 
c_proc(fHello, {}) 

Note: the .so in the above code is .so on the Linux copy and .dll on the Windows copy.

The output of the windows version is:

{9043968,12} 
Hello, World! 

The output of the linux version is:

{135587536,-1} 
 
myprog.ex:6 
c_proc/c_func: bad routine number (-1) 
 
--> See ex.err 

Jeremy

6. Re: Creating and using a .DLL/.SO?

• Posted by ghaberek (admin) Dec 24, 2008
• 1125 views

Since we're doing all this work on the version 4.0, couldn't we make the translator automatically output a wrapper file for the library? Say, all global constants and routines, then build the simple wrapper routines? That's always been a pipe dream of mine...

-Greg

8. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 25, 2008
• 1118 views
• Last edited Dec 26, 2008

I do think that global/public/export functions/procedures should be created in the dll/so as is, right? w/no name mangling?

Jeremy

10. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 25, 2008
• 1119 views
• Last edited Dec 26, 2008

How will this work when I want to load multiple dll/so files that have the same function names? For instance:

dbi_pgsql.so, dbi_mysql.so, dbi_sqlite.so, dbi_eds.so:

dbi_open(), dbi_query(), dbi_close()

In code, I could do something like:

public function dbi_load_driver(sequence name) 
   atom driver_id = open_dll("mod_" & name) 
   return { 
       driver_id, 
       define_c_func(driver_id, "dbi_open", ...), 
       ... 
   } 
end function 
 
public function dbi_open(driver, ...) 
    return c_func(driver[FUNC_DBI_OPEN], ...) 
end function 
 
... 

Thus, a Euphoria program could connect to multiple database servers/files at the same time, varrying, and have no idea what the actual underlying database would be. A common interface, loaded at runtime. The application could be extended for database support far beyond what the original author ever knew. Simply develop a new, conforming DBI driver and the application would be able to then access that database.

So, in this case, I would not want the contents of the mod_pgsql.so and mod_mysql.so automatically available to the runtime. I would think this type of thing would happen frequently. For instance, any type of pluggable module. Say you have a modular system to load a file: mod_text.so, mod_rtf.so, mod_html.so, mod_xml.so, etc... All of them would include a function called: open_file()... and would return some type of common data type for your application. I may want to open/parse html files, xml, rtf, etc... all at the same time, so all modules would be loaded, but all have the exact same function names.

Jeremy

12. Re: Creating and using a .DLL/.SO?

• Posted by bernie Dec 26, 2008
• 1085 views

Why not just allow a user to create include files that are compiled
to IL code that just expose their PUBLIC functions/procedures names.
Then the interpreter or translator could easily use them in DLLs or
programs.

14. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 26, 2008
• 1093 views

For now (today, tomorrow, 4.0a3), wouldn't it be best to just fix the name mangling problem? i.e. this code:

-- mod_hello.e 
public procedure hello() 
    puts(1, "Hello, World!\n") 
end procedure 

When compiled to a .dll, produces a .dll that has the procedure "hello" exported. When compiled to a .so, produces a .so that has the procedure "_1hello" exported.

Jeremy

16. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 26, 2008
• 1117 views

include dbi_mysql.so as mysql 

That seems like a nice way to simply include compiled code, however, it does not allow any type of dynamic module loading. For instance, take eudoc. It has source code parsers, each parser has a function called parse(sequence filename) and it returns a sequence structured property for eudoc. Here's how I would envision something like that working:

enum PARSER_FEXT, PARSER_FUNC_ID 
sequence parsers = {} 
 
procedure load_parser_modules() 
  sequence files = dir("parser_*.so") 
  for file in files do 
    atom lib = open_dll(file[FILENAME]) 
    atom init_func = c_func(lib, "init", ...) 
    sequence parser_info = c_func(init_func, ...) 
    parsers &= { parser_info[PARSER_NAME], parser_info[FILE_EXTENSION], 
        c_func(lib, "parse", ...) } 
  end for 
end procedure 
 
-- Now later in code: 
 
function parse(sequence filename) 
  atom parser = find_parser_in_parsers_sequence(filename) 
  return c_func(parser, {filename}) 
end function 

That of course is not all legit code, but could easily be. So, in this case we may have a parser for Euphoria, C, Makefile, Text files, Creole files, HTML files, or whatever. EuDoc could be used for *any* language, as long as a parser is written for it. In this example (a very viable and common use of loadable modules) the user of the loadable module does not want the functions embedded, nor does he/she want to handle them by namespaces. Further, they want to load them dynamically (i.e. not knowing what they are at the time of writing the code).

Jeremy

18. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 26, 2008
• 1109 views

Yes, with some trivial solution to the _1hello vs. hello bug, this would run just fine today. I guess my whole point to this thread is, why don't we fix the _1hello vs. hello bug before 4.0a3 instead of focusing on a new automated system right now. I have not looked at the code yet producing the _1 bug, I'll do that shortly. I thought that some may know exactly where that problem is. The translator is an area that I have spent hardly no time in.

Jeremy

20. Re: Creating and using a .DLL/.SO?

• Posted by mattlewis (admin) Dec 26, 2008
• 1102 views

-- mod_hello.e 
public procedure hello() 
    puts(1, "Hello, World!\n") 
end procedure 

Yes, this is something that we should fix.

Matt

22. Re: Creating and using a .DLL/.SO?

• Posted by mattlewis (admin) Dec 26, 2008
• 1097 views

Yes, true dynamic module loading is going to require an eval-like capability, I think, though I suspect that some of the stuff that will need to be developed for the transparent use of translated code will probably be useful for eval stuff, too.

Matt

24. Re: Creating and using a .DLL/.SO?

• Posted by mattlewis (admin) Dec 26, 2008
• 1122 views

There's also the issue of possibly conflicting names. And I believe that gcc prefixes an underscore (though maybe not in all situations). Perhaps the best thing to do is just to output the .e wrapper that handles the imports correctly. We could also do a regular C header (.h) fileprobably optional.

The wrapper could be possibly multiple files with a "lib" prefix. The multiple files would allow us to replicate the namespaces. Or we could change the default namespace to be changeable within a file.

Matt

26. Re: Creating and using a .DLL/.SO?

• Posted by jimcbrown (admin) Dec 26, 2008
• 1098 views

In regards to reserved words in C but usable names in eu, I like the approach that CName() takes. At least it is well defined.

In regards to "reserved" words (like fopen() or dlopen() ) I'm not sure should be done. Mangling (as above) is probably the safest option though.

In regards to conflicting names within the eu code itself (public function ftakes() in file ftakes.e conflicting with public function ftakes() in file outtakes.e for example, included in a.e and b.e respectively and used only there and then a.e and b.e are included in main.ex) this is a tricky situation. Back when we had only global it was a lot easier, but having namespaces makes even this hard. In this case, we need a way to have the user (the one translating the code into a dll/so) specify what to do. There's no way to "do the right thing" and have everybody be happy.

This is only an issue when mixing and matching compilers. This is actually an ELF standard (meaning all C compilers for all Unix platforms that output ELF binaries will name the functions in the same way), so I believe an issue would only ever arise when using gcc and Windows (e.g. mingw to translate eu to a dll).

I guess by .e wrapper you mean outputting a .e file that has the correct open_dll() and define_c_func()/proc() calls to call the dll from within eu code?

How would one call the dll from C code without a .h wrapper?

I'm not sure I follow. What would this mean?

28. Re: Creating and using a .DLL/.SO?

• Posted by jeremy (admin) Dec 26, 2008
• 1100 views

EXPORTS 
hello = _1hello 
hello = _2hello 
hello = _3hello 

Not that I know of, I was just saying that we do not guard against such a thing, so naming a C function "hello" twice would err out either way.

Jeremy