1. Euphoria.NET?

Is there ever going to be an Euphoria.NET?

Regards,
bugmagnet

new topic     » topic index » view message » categorize

2. Re: Euphoria.NET?

bugmagnet said...

Is there ever going to be an Euphoria.NET?

Regards,
bugmagnet

Isn't the .NET platform a Microsoft only platform? Rather the .NET platform only runs under windows. I know there are clones like Mono and stuff, but I don't really see why you would need a euphoria.NET, I guess if you wanted you could make some wrappers for the .NET in euphoria.

new topic     » goto parent     » topic index » view message » categorize

3. Re: Euphoria.NET?

bugmagnet said...

Is there ever going to be an Euphoria.NET?

I imagine that something like IronPython might be possible. The .NET runtime is very strongly object-oriented, so Python meshes well with the .NET system. But Euphoria is not object oriented, and that would make things quite difficult.

Lone_EverGreen_Ranger said...

Isn't the .NET platform a Microsoft only platform? Rather the .NET platform only runs under windows. I know there are clones like Mono and stuff, but I don't really see why you would need a euphoria.NET, I guess if you wanted you could make some wrappers for the .NET in euphoria.

Mono is technically a binary-compatible version of the .NET runtime. There are some caveats regarding Microsoft-specific libraries, and so generally an application written for Mono will run fine under .NET, but not the other way around.

Unfortunately, one cannot simply "wrap" the .NET runtime as one would "wrap" other libraries. It would have to be done with a "shim" like we're doing with wxEuphoria. I've considered building a C++/CLI shim myself, but I'd rather direct my attention to things like wxEuphoria instead.

All things considered, I'm pretty sure Euphoria is a faster interpreter than the .NET runtime anyway. Not to mention that Euphoria applications can be bound or translated-and-compiled to executable files with no other dependancies (aside from any libraries the application may use directly).

-Greg

new topic     » goto parent     » topic index » view message » categorize

4. Re: Euphoria.NET?

Hmm, I thought that .NET (or more properly, the CLR) was just a virtual machine like Java. Shouldn't be any more difficult to port it to .NET/CLR than to any other processor like ARM.

Not that I'm volunteering, but still.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Euphoria.NET?

jaygade said...

Hmm, I thought that .NET (or more properly, the CLR) was just a virtual machine like Java. Shouldn't be any more difficult to port it to .NET/CLR than to any other processor like ARM.

Not that I'm volunteering, but still.

Well .. the fact that the underlying C compiler (gcc in this case) already supported compiling C code into binaries using the ARM instruction set was a big help.

The simplest way to do this (imvho) would be to modify the translator to output Csharp or something, but this already is more heavily involved than what it takes to add support for a new operating system, or support for a new C compiler (gcc vs openwatcom vs lcc).

We might be able to save effort by building the current runtime library into a dll and making calls to that from the Csharp code outputed by the translator. If we had to rewrite the runtime library in Csharp though, then ...

new topic     » goto parent     » topic index » view message » categorize

6. Re: Euphoria.NET?

Greg, you're right.

Euphoria is really 2 things: a language and a runtime environment. Porting the Euphoria language to .NET (or Java) or some other runtime should not be too difficult. However, porting Euphoria's runtime environment to .NET may not only be difficult, but might lose the very essence (and high performance) that Euphoria brings to the table.

From what I can see, the Euphoria runtime seems to have been built on a Forth-like model. For those familiar with Forth, you can get very high performance (and I'm simplifying a lot here) by replacing subroutine calls and returns with direct machine language jumps from one routine to another. If you get deeper into the internals of the Euphoria runtime, you can really appreciate the clever things Rob Craig did to make Euphoria really, really fast.

I'm not sure that any Forth model (Euphoria included) would port well to a .NET or Java virtual machine, and even if it did, you would likely lose a lot of the performance that Euphoria brings to the table.

The minor upside, however, is that Euphoria.NET would be able to take advantage of libraries and code written in other .NET languages. However, I've found that if you're going to use .NET, you're better off using C#, a language which was purpose-built for .NET.

I am sure the current Euphoria maintainers would be able to shed further light on this, and also correct any wrong assumptions I may have stated above.

KRG

new topic     » goto parent     » topic index » view message » categorize

7. Re: Euphoria.NET?

Euphoria is for real creative programmers.
.net is bloatware for mediocre programmers to enable them to create jazzy looking software which changes every 4-8 months because of bugs etc.

Craig is Craig and Gates is Gates and (hopefully) Never the twain shall meet.

new topic     » goto parent     » topic index » view message » categorize

8. Re: Euphoria.NET?

EUWX said...

Euphoria is for real creative programmers.
.net is bloatware for mediocre programmers to enable them to create jazzy looking software which changes every 4-8 months because of bugs etc.

Craig is Craig and Gates is Gates and (hopefully) Never the twain shall meet.

I don't really see a need to make a Euphoria.NET, although considering the XNA framework is on .NET platform, I wonder if it would be easier to create games using Euphoria, if such .NET wrapper is possible. I know Euphoria is already capable of making games by itself, but the XNA framework takes a lot of the hardwork out of it. Of course some may like the hardwork involved. Just saying, I'm not totally against a .NET for euphoria.

new topic     » goto parent     » topic index » view message » categorize

9. Re: Euphoria.NET?

bugmagnet said...

Is there ever going to be an Euphoria.NET?

I had a partial version working with ooeu. Basically (IIRC), you shrouded your code, then converted it into CLR assembler code, and then used the .NET assembler to get a working assembly.

It was a lot slower than normal eu, largely due to the way I implemented the basic euphoria datatypes. There's undoubtedly a better way to manage that.

Matt

new topic     » goto parent     » topic index » view message » categorize

10. Re: Euphoria.NET?

mattlewis said...
bugmagnet said...

Is there ever going to be an Euphoria.NET?

I had a partial version working with ooeu. Basically (IIRC), you shrouded your code, then converted it into CLR assembler code, and then used the .NET assembler to get a working assembly.

It was a lot slower than normal eu, largely due to the way I implemented the basic euphoria datatypes. There's undoubtedly a better way to manage that.

Matt

Exactly what I was thinking about, generationg CLR assembler code, or better CLI binary file instead of euphoria IL file. This is probably the easiest path to go. The CLI VM specification is available here.. only 574 pages to read... blink

Jacques

new topic     » goto parent     » topic index » view message » categorize

11. Re: Euphoria.NET?

I found this introduction to IL assembly language on codeproject

IL assembly

Jacques

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu