DotGNU is proud to announce support for XML Path Language, and IO communication ports, as mentioned on GetDotGNU homepage. Also on GetDotGNU there are new introductory articles to KDE DCOP and .NET integration, writing .NET applications using C language, and an overview of securing the XSP ASP.NET server.
DotGNU announces support for XPath, IO ports, and more
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What is the difference b/w these two? (technical differences only)
DotGnu has its own intermediate format that sits between IL bytecode and native code (its called, uh, CVM, I think).
DotGNU is also more portable by virtue of architecture.
Mono has a JIT, DotGNU does not.
The differences were as wide as the sky was blue back in the day, but time has passed and now the differences have been widdled down into less than a handful of options.
There are many differences, and whether DotGNU Portable.NET or Mono are best for you depends on the application (i.e. what you intend to do). It used to be that if you wanted to run GUI applications (i.e. with System.Windows.Forms), you’d use Portable.NET, and if your intention was to run an ASP.NET server you’d turn to Mono (with the small but powerful XSP server), but at this point Portable.NET can do both.
There are things which can be handled only by either Portable.NET or Mono, and the best way to find out which one is right for you is to test and evaluate both.
DotGnu has its own intermediate format that sits between IL bytecode and native code (its called, uh, CVM, I think).
Why add another layer – surely this has an effect on performance?
DotGNU is also more portable by virtue of architecture.
How is that so? Are mono’s libraries not C#, hence compilation on any supported platform/architecture is dependent on the compiler support?
The differences were as wide as the sky was blue back in the day, but time has passed and now the differences have been widdled down into less than a handful of options.
Like completeness, a decent IDE, a thriving active community etc…
It’s my understanding that the CVM is somewhat in-between just a interpreter and a full blown JIT (I could be wrong). Writing a full blown JIT for an architecture is not trivial and the interpreter for Mono (Mint) was much slower than Pnet’s interpreter. Running on an interpreter always gives you an advantage in portability.
The problem that dotGNU now has is that Mono is reworking SWF into a fully managed implementation and when that’s done, there might not be much of an advantage running Pnet – except maybe an easier install from source process or if you’re interested in understanding the runtime, cleaner code.
> CVM is somewhat in-between just a interpreter and a full blown JIT
CVM is a JIT , it’s just not a native JIT. IL is JIT’d into a format that contains a mixture of GCC compiled code and dynamic compiled code (both of which *are* native code). It ends up with a few extra register flushes and can’t optimise the gcc compiled code on the fly … But it’s a hell of a lot portable than a raw JIT.
Have a look at http://t3.dotgnu.info/code/pnet-engine-2.jpg
> problem that dotGNU now has is that Mono is reworking SWF into a fully managed implementation
Nice to see Mono fixing their designs (after a couple years of Gtk#/Y#/P#/M#)
Nice to see Mono fixing their designs (after a couple years of Gtk#/Y#/P#/M#)
You’re confused. Gtk# has nothing to do with SWF. Their whole problem, which they were told was going to be a problem by many people over and over, was on the WINE dependency.
Although I’m from the UK where we spell initialise with an ‘S’, I’m not sure if it’s a good idea to have methods in an api spelt Initialise(). I think we should really try and standardize on US/American spelling and call it Initialize(). Although it sounds as though the intention is to do away with that call anyway.
Why do you need to cast to a DcopRef here? And shouldn’t be called DCOPRef like the original C++ api..
DcopRef konquerorWindow = (DcopRef)dr.Call(“DcopRef openBrowserWindow(
QString url)”, “http://www.getdotgnu.com“);
I guess being able to emit DCOP signals would be nice to. And how do you declare a DCOP slot – any plans for doing that?
— Richard
> You’re confused. Gtk# has nothing to do with SWF
He might have been refering to their attempt to write SWF wrappers around GTK#
> Although it sounds as though the intention is to do away with that call anyway.
There is a very old patch in Savannah (https://savannah.gnu.org/patch/?func=detailitem&item_id=3087) that does away with the Initialize things by auto-generating stub classes.
I’m still waiting for some time to clean that up from
it’s current collection of WriteLines into a decent CodeDom
based implementation.
> I guess being able to emit DCOP signals would be nice to. And how do you declare a DCOP slot – any plans for doing that?
I’ve no idea – the guy who started doing this had a rough
time (learning Dcop *and* C# at the same time is very hard).
Currently it’s almost frozen , because ilyak is busy with
life in general (the sad reality of volunteer projects).
So well .. patches and help are welcome
Thanx for your comment. InitialiSe will go off API in a week or so, so don’t care
Will change this weirdness with factory in DcopClient.
I called it DcopRef not DCOPRef ’cause rhysw, who started doint this work, caled DCOP Dcop all the way along. And he might know something about C# naming conventions.
What are DCOP signals? async calls?
Dcop slots == being able to receive calls from other DCOP clients? I will implement it soon.
And i have weirdness that libICE crashed if i discover DCOP opcode right way so i had just to force it to be 2.
May i ask you in mail?
I had to cast Call() result to DcopRef ’cause DcopRef.Call() is declared as returning Object.
The SWF-gtk# wrapper was never a serious project. The whole idea was some side project that was basically abandoned before it got started, but was left in CVS for people to monkey around with if they wanted to.
He wanted technical differences only, or else I would’ve been a douchebag.
Mono’s harder to port because you have to port the runtime, and the runtime uses the Boehm GC library, which has to be ported to every system you want Mono to run on… along with Mono itself.
DotGNU was written in a relatively agonistic way with pluggable interfaces (slap in your own GC, in other words), so its easier to port.
Let me know when you “slap in your own GC” and get it
working. Until then, its pure vaporware.
Miguel
It has an another pluggable GC called NoGC
No garbage collection at all – weird, but needed sometimes, like on my QNX box.
So just like Mono, duh.
I called it DcopRef not DCOPRef ’cause rhysw, who started doint this work, caled DCOP Dcop all the way along. And he might know something about C# naming conventions.
Fair enough, but I think I’d leave everything the same apart from starting the method names in upper case.
I had to cast Call() result to DcopRef ’cause DcopRef.Call() is declared as returning Object.
I see – I suppose it either returns whatever the DCOP call returns or null if it fails. But it wouldn’t normally return a DCOPRef..
What are DCOP signals? async calls?
They’re synchronous, but you can broadcast a message to multiple clients. For example, in ruby:
class SenderWidget < KDE::PushButton
k_dcop_signals ‘void testEmitSignal(QString)’
def initialize(parent, name)
super
connect(self, SIGNAL(‘clicked()’), SLOT(‘doit()’))
end
slots ‘doit()’
def doit()
emit testEmitSignal(“Hello DCOP Slot”)
end
end
Connect to it in another app like this:
result = slottest.connectDCOPSignal(“dcopsignal”, “SenderWidget”, “testEmitSignal(QString)”, “mySlot(QString)”, true)
May i ask you in mail?
Yes, please do..
I had to cast Call() result to DcopRef ’cause DcopRef.Call() is declared as returning Object.
Richard:
I see – I suppose it either returns whatever the DCOP call returns or null if it fails. But it wouldn’t normally return a DCOPRef..
I’m talking rubbish – of course a DCOP call can return a DCOPRef! I see what’s going on now.