Re: back to .Net? lesser of two evils?

On 11/9/2011 6:30 PM, Arne Vajhøj wrote:
On 11/9/2011 9:21 AM, BGB wrote:
On 11/3/2011 5:52 PM, Arne Vajhøj wrote:
On 11/3/2011 3:01 AM, BGB wrote:
On 11/2/2011 3:06 PM, Arne Vajhøj wrote:
On 11/2/2011 10:58 AM, BGB wrote:
Mono also can't run C++/CLI code last I checked, which sort of screws
over my personal motivation to use it.

It should be able to run pure code. Obviously not mixed code.

yes, but banning mixed code sort of breaks C++/CLI's ability to...
actually work...

even if one compiles the code itself as pure CIL, then Mono rejects it
due to things like "can't load MSVCR80.DLL" or similar.

With:

/clr:pure

it should not.

Are you sure that it does not work?


I tested it.
the issue is, as soon as one uses and C or C++ runtime stuff, or calls
into C land, well, Mono is no longer happy.

If one mixes in native code (not pure CIL) then then it is not portable.

If one uses DllImport in C++/CLI or C# or VB.NET to load
native modules then it is obviously not portable either.

So if portability is a requirement then one should not do
these things.

I believe Mono has a little tool to examine code for
portability.


ideally, though, it should "just work".


the example would be, say, if Mono would make it automatically redirect dependencies to "MSVCRT" and friends to a glib-based wrapper (granted, all this would mean faking parts of the Win32 API, in addition to all of the .NET stuff...).

similarly, if the library is available on both targets, then ideally the runtime can figure it out, and map to the appropriate library.

otherwise, something like C++/CLI is not nearly so useful, as its main point is to, well, be C++ but with access to .NET stuff, in addition to the normal C and C++ libraries. if Mono can't make this work, then this is IMO a problem that ideally should be addressed somehow.


but, granted, Mono's deficiencies in this area generally led to me not using .NET:
if the main (personally relevant) selling points for .NET only work on Windows, why should I really bother with .NET?

I can make my own stuff work, and be portable across Windows and Linux, which is IMO good enough (in the past, I was also working some on an Android port, but this was not a high priority).



in my case (for my VM), I dealt with the issue partly by binding against high-level "library names", which are sometimes named after the library files in use (stripped-down DLL or shared-object names), and other times after the headers.

at the moment it is a bit crufty, but in the future I may devise "cleaner" ways of dealing with the issue.


note that the main (in language) import mechanism looks like:
"native import C.libname;"

note: the "C." is magic (it indicates the language target, and yes there may later be a "CPP.").

where the VM will itself try to figure out what "libname" means to import. it will check for "<libname>.dll", "<libname>.so", "lib<libname>.so" as appropriate for the target OS, or may import the associated metadata databases (loaded by the libname) and load any libraries listed as dependencies (such as the physical library name).

thus far it works on both Windows and Linux, so it is generally good enough (note: databases need to be rebuilt per-target though, but this is not a big issue). technically the database-building tool is a modified C compiler (with some annotations used to give special information to the tool).

technically, these annotations are mostly "__declspec" attributes wrapped in macros, with the macros being no-op to a standard C or C++ compiler.

in a header somewhere, there may be annotations like:
#ifdef _WIN32
dytlibdep("msvcrt");
dytlibdep("opengl32");
....
#endif
#ifdef linux
dytlibdep("glib");
dytlibdep("GL");
dytlibdep("GLX");
dytlibdep("GLu");
....
#endif
....


otherwise, it is left as the VM's responsibility to make it work.

this is much like gluing together the type-system and other things...

note: maybe I have it a little easier, as my language is somewhat different (WRT semantics) than either Java or C# (the language is late-bound, so the visibility or type of a declaration is not a huge issue when producing bytecode, the compiler will "take it on faith" that the declaration will be visible when the code runs).

maybe one could coin the term "eager late bound" (although semantically late bound, the VM may try to avoid run-time lookups where possible, such as by optimizing for known visibility).


yes, there is also a "native package" feature which allows exporting an interface to C (basically, this involves a tool to spit out a header and C source file containing a glue interface).

like (to export a package named "foo"):
"native package C.foo { ... }"

again a tool is needed as, sadly, C can't do late-binding...

.

Relevant Pages

  • Re: Learning Lisp in Linux?
    ... The Scheme fools started it and paraded it around as this Great Thing About Scheme, a measure of their obsession with The Wrong Thing when it came to language design. ... what was in the language standard and no more was in, ... Damn few libraries are actually written to be ... Their portability becomes my portability. ...
    (comp.lang.lisp)
  • Re: ANN: TinyTalk [Update]
    ... The end result has been a language in which it's easy, with some care, ... but that still lets various implementors extend ... DS9K Scheme would be very useful for discussing portability ... language into externally provided libraries. ...
    (comp.lang.scheme)
  • Re: "built-in" File I/O (was: PL/I, COBOL, Advantages, Equivalence, et al
    ... working the same across platforms. ... then I question that such portability should be expected. ... The libraries are implemented using the ... language so there is a consistency throughout the entire model. ...
    (comp.lang.pl1)
  • Re: "built-in" File I/O
    ... then I question that such portability should be expected. ... The libraries are implemented using the ... language so there is a consistency throughout the entire model. ... Wrong data input without warning. ...
    (comp.lang.pl1)
  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)