Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This isn't the first, or even the tenth, time something like this has been invented. It's been standard operating procedure on many systems, from IBM's big iron systems to midrage platforms like VMS. Amusingly, or sadly, it's been Unix machines where this has been horribly lacking due in large part to a historical lack of good calling conventions. Each language had their own, and you couldn't easily link libraries together from different languages. Hell, courtesy of some interesting fsck-ups on the part of
    • That's a really astute observation. With all of the hoo-hah about cross-language compatibility within a single VM, I never saw it as a rehashing of calling conventions.

      Surely there is more to CLR and .NET than just that. Or has the idea of a "compatible calling convention" simply been upgraded to include method calls, object definition, versioning, cryptographic signatures and reflection? And do you really need to have a VM for all of that?

      • It's a little more than calling conventions--there are exceptions as well. But that's about it, and getting cross-language exceptions isn't that big a deal either.

        All the other stuff is either upgraded calling conventions (method calls, reflection) or fancy dynamic loader stuff (versioning, crypto signatures). And no, you don't need a VM for it at all. You can do it entirely as normal, compiled code.

        The single biggest hurdle is the initial definition of the conventions, and that's as much engineering tr