You can do cycle detection in reference counting, there are various papers on the subject.
Refcount is bad for small apps, but good when you have applications that use a lot of memory (since scanning even with generations is an expensive process).
There are various papers on Citeseer on the subject.
Re:Real-world examples of tangible benefits
on
Mono Beta 2 Released
·
· Score: 3, Informative
Not in the case of MonoDevelop.
MonoDevelop is focused on being a great Unix IDE which means integrating with the base OS as much as possible: use the underlying widgetry, use the Unix conventions (create makefiles, configure scripts).
It is a fork of an IDE from the Windows world, SharpDevelop: a fairly good tool, that integrates into Windows, and we did not want to run only a Linux version of a Windows tool.
We wanted a Linux tool for Linux.
Re:What applications are there
on
Mono Beta 2 Released
·
· Score: 4, Interesting
I agree that building on top of Wine is far from ideal, but it has some benefits. For instance we are able to support applications that want to embed IE, or use Direct3D.
Miguel.
Re:I'm an applications developer...
on
Mono Beta 2 Released
·
· Score: 5, Interesting
Yes, we are not able to fully support the Windows.Forms API on the 1.0 timeframe (you can get the previews, but they are not ready to ship).
Windows.Forms has a number of problems for open source software anyways: for instance, it does not do constraing-based layout, so for every language that you want to support, you must relayout your dialog boxes manually (or if you have a larger font size).
By using Gtk# you take advantage of the Linux-specific APIs and Linux-specific features (you can use Gtk# on Windows, Linux and MacOS).
On the other hand, there is a community of MacOS developers working on bindings to Cocoa bindings to give them the same flexibility and OS integration on the Mac.
Windows.Forms would give you a Windows-solution everywhere.
We are going to support it for the sake of helping Windows developers move to Unix, but it is not a particularly great toolkit.
We are using the Boehm collector in precise mode, so all we are missing is the compacting features. It does a fairly good job, and we can run large applications with good success.
Doing a compacting collector is in our radar, but we have to balance our resources: port to new platforms, support 2.0 features and improve performance.
Mono 1.0 will use Boehm, but after that we might consider using a different collector (in fact, we have some preliminary patches for doing refcount-based systems).
Mono is fairly efficient, but there is a lot of room to grow optimization wise. There is no clear answer to this question. Although Our JIT engine implements a fairly advanced SSA code optimization platform, and it also allows for pre-compilation in batch mode (we typically get a 20-25% performance on applications) it really depends on the software you run.
Typically we have been able to tune Mono when people have pointed out a major performance issue by profiling the problem: sometimes the fix is simple, sometimes it requires the JIT codebase to be improved.
Work on improving the JIT engine continues, we recently checked in better register allocation for some corner cases, better inlining of intrinsic functions, loop-based optimizations and removing array bounds checks.
If your program is I/O bound, a different set of issues arise, so am sad to say `it depends'.
miguel.
Re:Real-world examples of tangible benefits
on
Mono Beta 2 Released
·
· Score: 5, Informative
We do support two stacks of APIs today in Mono: the Microsoft compatible stack (ASP.NET, ADO.NET and Windows.Forms) but we have been investing heavily in taking advantage of our own set of libraries that Linux, Unix, Gnome, X, Mozilla, CORBA specific.
For instance, Microsoft uses XmlSchema, Mono supports it, but distributed RelaxNG support as well.
We are working on Windows.Forms, but we also have strong bindings for Gtk# to build native applications. In fact MonoDevelop (www.monodevelop.org) is fully written using this stack.
We support the Microsoft database APIs, but we ship providers for all the open source (Postgress, MySQL, Sqlite) providers and other third party databases (DB2, Sybase, Oracle).
Tao is a backend agnostic set of 3D graphic APIs (OpenGL, Cg, SDL) while we still plan on supporting the Direct3D managed APIs.
Our set of APIs is what has allowed us to build things like MonoDevelop: a fairly complete IDE for Mono for developing Linux-based applications.
Care to point to point two of such "wild claims" that Noam Chomsky might have made?
The last time I saw someone accuse Chomsky of not having a solid ground for his evidence (during a talk at the JFK school of government, video is online, and highly recommended) Chomsky came back with the exact quoation.
Very embarassing for the accuser;-)
When he does talks, you will notice that he has a small piece of paper with his references to back up his assertions.
That being said, I would agree that Moore's books are easier to crunch through than Noam's.
My personal favorite Noam book (because its easier to digest, its a set of interviews) is called `Understanding Power', is a book that you can pick at any point.
XUL is more of a standard: there is a specification which describes what things must do, and there are a couple of implementations (Mozilla's being the most popular one).
XAML on the other hand is a serialization format: every tag in the XML is looked up in the class libraries, and every attribute as an event or as a property to be set. So the resulting markup is just a way of creating instances of your classes.
The idea of XAML can be used with any class library really, its not limited to Avalaon (for instance, MyXAML is a XAML implementation for Windows.Forms). Like I said on the interview, what makes XAML/Avalon powerful is that it runs on a sandbox, and it has a set of fairly recent controls as opposed to those we have grown used to on the Web.
In 1994, the desktop was not a GUI desktop, the desktop was mostly a command-line universe both on DOS-based systems and Linux systems.
Linux did have an advantage: multiple virtual consoles, real multi-tasking, tcp/ip stack bundled, nfs, file serving capabilities, and DOSemu with compatibility with the past.
I have to say, way better than DOS + pile of device drivers and Windows was only starting to be used with very few applications. Windows 3.11 was out, with really few applications.
Stock Java is not an option because it lacks a few things: the easy-to-build functionality of a web page (XAML) and the advanced graphics and rendering of Avalon.
Sure, they can both be built on top of Java, but they need to be built, hence the `Come up with our own competitive stack'.
I happen to think that our stack should use the best technology available today, and since it must be a new stack, that stack should be built on top of the ECMA CLI. For plenty of technical reasons.
Now, if you disagree with my thought direction, nobody is stopping you from building your stack on top of Java, I know that am not spending a minute there;-)
I remember that particular case, because I had the marketing people calling me on the office.
What happened is that someone had scheduled Nat without letting Nat or his assistant know about this particular trip, someone forgot to follow up and Nat was in Boston when that happened.
The Mono JIT on SPARC passes all the tests that the Mono x86 JIT passes.
A lot of the recent focus has been on taking advantage of many of the SPARC v9 features (like branch prediction) and improving the code generation after the initial feature complete stage.
And at Brainshare we demostrated Evolution with Groupwise integrated, that team continues to move rapidly. But what do I know? I just share the office with them. You probably know better from your couch a few thousand miles away;-)
As Nat has posted elsewhere, the Heise article is wrong.
My team and other teams within Novell continue to develop and use Gtk as their toolkit (recently open sourced Simias/iFolder for instance) and all of the Mono GUI development tools.
The only use of Qt that am aware of today is SUSE's recently open sourced YAST.
Btw, if you have been following my posts on my blog and on the desktop-devel-list, you will know that my feeling is that all of the existing toolkits today (Gtk, Qt, XUL and VCL) will become obsolete and we need to start looking at the next generation toolkit system.
We are doing quite well, see our Mono Roadmap in www.go-mono.com/mono-roadmap.html, we are a bunch of happy campers, with a nice runtime, and a nice language to write code we enjoy.
I agree that going our own path is a more robust and better solution. And that is exactly what we have done with our own toolkit called "Gtk#".
Gtk# not only is very nice to program with, but it is also cross platform and people are using it in some cases instead of Windows.Forms on Windows itself.
That being said, our effort to support the Windows.Forms API is not driven by a need to have that API at all, we believe it is one ugly API. Our drive to support it comes from the fact that people are using it, and have made certain assumptions about it.
So to us Windows.Forms is a compatibility play, and one that we have to support to assist people who want to try Mono as a way of moving their apps to Linux.
The API we are recommending developers to use is the Gtk# API.
Slashdot Mirror
You can do cycle detection in reference counting,
there are various papers on the subject.
Refcount is bad for small apps, but good when you
have applications that use a lot of memory (since
scanning even with generations is an expensive
process).
There are various papers on Citeseer on the
subject.
Not in the case of MonoDevelop.
MonoDevelop is focused on being a great Unix
IDE which means integrating with the base OS as
much as possible: use the underlying widgetry,
use the Unix conventions (create makefiles,
configure scripts).
It is a fork of an IDE from the Windows world,
SharpDevelop: a fairly good tool, that integrates
into Windows, and we did not want to run only
a Linux version of a Windows tool.
We wanted a Linux tool for Linux.
I agree that building on top of Wine is far from
ideal, but it has some benefits. For instance
we are able to support applications that want
to embed IE, or use Direct3D.
Miguel.
Yes, we are not able to fully support the
Windows.Forms API on the 1.0 timeframe (you can
get the previews, but they are not ready to ship).
Windows.Forms has a number of problems for
open source software anyways: for instance, it
does not do constraing-based layout, so for
every language that you want to support, you must
relayout your dialog boxes manually (or if you
have a larger font size).
By using Gtk# you take advantage of the Linux-specific
APIs and Linux-specific features (you can use
Gtk# on Windows, Linux and MacOS).
On the other hand, there is a community of
MacOS developers working on bindings to Cocoa
bindings to give them the same flexibility and
OS integration on the Mac.
Windows.Forms would give you a Windows-solution
everywhere.
We are going to support it for the sake of helping
Windows developers move to Unix, but it is not
a particularly great toolkit.
miguel.
We are using the Boehm collector in precise mode,
so all we are missing is the compacting features. It does a fairly good job, and we can run large
applications with good success.
Doing a compacting collector is in our radar,
but we have to balance our resources: port to
new platforms, support 2.0 features and improve
performance.
Mono 1.0 will use Boehm, but after that we might
consider using a different collector (in fact,
we have some preliminary patches for doing
refcount-based systems).
Mono is fairly efficient, but there is a lot of
room to grow optimization wise. There is no clear
answer to this question. Although Our JIT engine
implements a fairly advanced SSA code optimization
platform, and it also allows for pre-compilation
in batch mode (we typically get a 20-25%
performance on applications) it really depends
on the software you run.
Typically we have been able to tune Mono when
people have pointed out a major performance issue
by profiling the problem: sometimes the fix is
simple, sometimes it requires the JIT codebase
to be improved.
Work on improving the JIT engine continues,
we recently checked in better register allocation
for some corner cases, better inlining of intrinsic
functions, loop-based optimizations and removing
array bounds checks.
If your program is I/O bound, a different set of
issues arise, so am sad to say `it depends'.
miguel.
We do support two stacks of APIs today in Mono: the Microsoft compatible stack (ASP.NET, ADO.NET and Windows.Forms) but we have been investing heavily in taking advantage of our own set of libraries that Linux, Unix, Gnome, X, Mozilla, CORBA specific.
For instance, Microsoft uses XmlSchema, Mono supports it, but distributed RelaxNG support as well.
We are working on Windows.Forms, but we also have strong bindings for Gtk# to build native applications. In fact MonoDevelop (www.monodevelop.org) is fully written using this stack.
We support the Microsoft database APIs, but we ship providers for all the open source (Postgress, MySQL, Sqlite) providers and other third party databases (DB2, Sybase, Oracle).
Tao is a backend agnostic set of 3D graphic APIs (OpenGL, Cg, SDL) while we still plan on supporting the Direct3D managed APIs.
Our set of APIs is what has allowed us to build things like MonoDevelop: a fairly complete IDE for Mono for developing Linux-based applications.
You might want to look at slides from Brainshare
/ pu blished/DL208/DL208.ppt
on System.DirectoryServices, and the expanded Novell.LDAP namespace:
https://secure-www.novell.com/brainshare/portal
Miguel
Care to point to point two of such "wild claims" that Noam Chomsky might have made?
;-)
The last time I saw someone accuse Chomsky of not having a solid ground for his evidence (during a talk at the JFK school of government, video is online, and highly recommended) Chomsky came back with the exact quoation.
Very embarassing for the accuser
When he does talks, you will notice that he has a small piece of paper with his references to back up his assertions.
That being said, I would agree that Moore's books are easier to crunch through than Noam's.
My personal favorite Noam book (because its easier to digest, its a set of interviews) is called `Understanding Power', is a book that you can pick at any point.
Miguel.
You could write the server-side of the protocol this client expects for instance. That should not be too hard.
Specially if you use something like Mono (plug, plug, plug, plug).
Love,
Miguel
XUL is more of a standard: there is a specification
which describes what things must do, and there are
a couple of implementations (Mozilla's being the
most popular one).
XAML on the other hand is a serialization format:
every tag in the XML is looked up in the class
libraries, and every attribute as an event or as
a property to be set. So the resulting markup
is just a way of creating instances of your classes.
The idea of XAML can be used with any class
library really, its not limited to Avalaon (for
instance, MyXAML is a XAML implementation for
Windows.Forms). Like I said on the interview,
what makes XAML/Avalon powerful is that it runs
on a sandbox, and it has a set of fairly recent
controls as opposed to those we have grown used
to on the Web.
Miguel.
I do not think you read my whole message,
because I stated that there were two options:
to implement Avalon, or to build our own.
We are in the process of specing out what
ours should be (the platform we call
"salvador").
Miguel.
Am not fabricating anything.
In 1994, the desktop was not a GUI desktop, the
desktop was mostly a command-line universe both
on DOS-based systems and Linux systems.
Linux did have an advantage: multiple virtual
consoles, real multi-tasking, tcp/ip stack
bundled, nfs, file serving capabilities, and
DOSemu with compatibility with the past.
I have to say, way better than DOS + pile of
device drivers and Windows was only starting to
be used with very few applications. Windows 3.11
was out, with really few applications.
Miguel.
Stock Java is not an option because it lacks a few
;-)
things: the easy-to-build functionality of a web
page (XAML) and the advanced graphics and rendering
of Avalon.
Sure, they can both be built on top of Java, but
they need to be built, hence the `Come up with our
own competitive stack'.
I happen to think that our stack should use the
best technology available today, and since it
must be a new stack, that stack should be built
on top of the ECMA CLI. For plenty of technical
reasons.
Now, if you disagree with my thought direction,
nobody is stopping you from building your stack
on top of Java, I know that am not spending a
minute there
Miguel.
As a happy user of a 2.4 kernel with backported
features from 2.6, I love the fact that Red Hat
went the extra mile to provide this feature.
We have been using NPTL extensively in the Mono
debugger. Without it, it would be much harder
to write the debugger for Mono.
Miguel.
I remember that particular case, because I had the
marketing people calling me on the office.
What happened is that someone had scheduled Nat
without letting Nat or his assistant know about
this particular trip, someone forgot to follow
up and Nat was in Boston when that happened.
Miguel.
The Mono JIT on SPARC passes all the tests that the
Mono x86 JIT passes.
A lot of the recent focus has been on taking
advantage of many of the SPARC v9 features
(like branch prediction) and improving the code
generation after the initial feature complete
stage.
I guess all those evolution hackers on the office
2 004-March/author.html
;-)
are ghosts, because they seem to be busy working
on it, the CVS mailing list seems to agree with me:
http://lists.gnome.org/archives/cvs-commits-list/
And at Brainshare we demostrated Evolution with
Groupwise integrated, that team continues to move
rapidly. But what do I know? I just share the
office with them. You probably know better from
your couch a few thousand miles away
As Nat has posted elsewhere, the Heise article is wrong.
My team and other teams within Novell continue to
develop and use Gtk as their toolkit (recently
open sourced Simias/iFolder for instance) and
all of the Mono GUI development tools.
The only use of Qt that am aware of today
is SUSE's recently open sourced YAST.
Btw, if you have been following my posts on
my blog and on the desktop-devel-list, you will
know that my feeling is that all of the existing
toolkits today (Gtk, Qt, XUL and VCL) will
become obsolete and we need to start looking
at the next generation toolkit system.
Miguel
You might want to look at Nemerle (www.nemerle.org) .NET and
a nice functional language that runs on
Mono.
We are doing quite well, see our Mono Roadmap
in www.go-mono.com/mono-roadmap.html, we are
a bunch of happy campers, with a nice runtime,
and a nice language to write code we enjoy.
Miguel.
System.Windows.Forms is not part of the Mono 1.0
release as you well point out.
But Gtk# 1.0 is part of the Mono 1.0 release, and
unlike Windows.Forms it is very mature and stable.
Love,
Miguel
Why would anyone run highly inneficient code written in anything but tightly written assembly code?
Discuss amongst yourselves
I agree that going our own path is a more robust
and better solution. And that is exactly what we
have done with our own toolkit called "Gtk#".
Gtk# not only is very nice to program with, but it
is also cross platform and people are using it
in some cases instead of Windows.Forms on Windows
itself.
That being said, our effort to support the Windows.Forms
API is not driven by a need to have that API at all,
we believe it is one ugly API. Our drive to support
it comes from the fact that people are using it,
and have made certain assumptions about it.
So to us Windows.Forms is a compatibility play,
and one that we have to support to assist people
who want to try Mono as a way of moving their apps
to Linux.
The API we are recommending developers to use is
the Gtk# API.
Hope that answers the question
In Mono we took a different approach, we created, integrated and built our own standalone stack ;-)
Look at: http://primates.ximian.com/~miguel/tmp/map2.png to get an idea of what we have to offer today