Announcement

Collapse
No announcement yet.

[CLOSED] Closing the compiler circle

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    [CLOSED] Closing the compiler circle

    Hi,

    We are testing Bridge .NET for a quite extensive client-server application. So far extremely impressed with the concept, and happy to contribute with bug reports and soon investing in premium. Great work guys!

    Now to a question:

    I'm working on a highly user scriptable application. So far the plan been for client app to submit code to the server for compilation, then get executable ECMA code back. Pretty much like Deck.

    Challenge with that approach in my situation is that the server may run on a number of platforms, in some cases the server is a really simple environment with no understanding of .NET or C#. Been thinking about later trying to get Bridge.NET on Mono to run on that platform, but it will take much resources on a fairly limited system and will probably be a bit work to adapt.

    Then I got this crazy idea about compiling the entire Roslyn library and Bridge.NET on Bridge.NET to separate assemblies. It will probably generate huge. is files that take some time to load, but it would only have to be loaded in the rare cases where the user actually has changed a script, and the scripts are mostly really small so performance doesn't matter too much.

    Has anyone looked into that concept? Afaik Roslyn and Bridge does not have too many dependencies. Now a closed circle with a Bridge compiler actually running compiled on Bridge would be cool to see, and probably really cool to advertise on the Bridge website :).
    Last edited by geoffrey.mcgill; 2018-12-16 @ 07:36 PM.

    #2
    Hi. We have looked into this several times. Compiling the Roslyn source with Bridge would be difficult at this point. The System.Threading and System.Xml namespaces would need support first. Some holes in Bridge support for System.IO and System.Globalization namespaces would also require filling.

    Comment


      #3
      Thanks for reply.

      I suppose System.Threading would pose the biggest challenge dependent how it's used. Imagine that classes like Thread and BackroundWorker will be hard to emulate in a singlethread environment like Javascript.

      The other namespaces should be fairly trivial to implement partially, like XML and Streams. Globalization could probably be stubbed more or less for now.

      Good to hear it's been looked at and probably not impossible :). I might be able to help with System.Xml in a while. I need it for a shared module handling xml files. I have a partial implementation now to handle the methods I need.

      Comment

      Working...
      X