Submitting an ebuild for free (open-source) plotting library for .NET framework. Tested and works well (both ebuild and the library) with mono. Didn't give it a try under pnet.
Created attachment 49782 [details] nplot-0.9.8.3.ebuild ...I propose dev-dotnet/nplot...
I'm very hesitant to add this library at this point, largely as a result of those missing classes, as well as the still immature System.Windows.Forms implentation for mono. Installing the pre-compiled library doesn't really fix things, as people trying to use the classes that touch the un-immplemented bits will just have things go KABOOM on them. I know that the monologue blog aggregation has had a few posts regarding using NPlot with the mono-1.1.x managed SWF implentation, so i'm sure soon this will be viable. Planning to mark this LATER in a day or two, feel free to respond if you feel otherwise, and I'll take that into consideration.
You're probably right... ...but what about adding it with hard mask set? I bet there are people who'd appreciate it... Anyway, when talking about SWF (or Gtk#), it's just a minor part of NPlot. Me, for example, I use neither. The most important part of NPlot is the plotting routine which works fine so it's 100% working if you need to output just to files (I think most plotters do).
It's really not a good idea to add a package to portage, package.masked from the get-go, and leave it that way for some as-yet-undetermined time til some other package matures. It's about 3 or 4 more steps for someone who really wants to use NPlot to check bugs, add it to an overlay, and go. I'd prefer to leave it at that, as opposed to polluting the tree with known-bad new ebuilds. Regarding not using the parts of NPlots that use SWF, I definitely see where you're coming from, but *innevitably* some user will try using those classes and open a bug about it. Call it karma. I'll leave this open as a reminder to revisit when more of SWF is working, and also so people can more easily find this if they want it.
One alternative would be to compile this, but move the files/classes that use System.Web.UI, and System.Windows.Forms out of the way when we compile the library. You could also make up a simple makefile to handle only compiling the sources we actually want. I'm a bit hesitant to do this though, as we'd have a non-standard version of the library, and people expecting those other classes might be miffed. If we did do that, I'd prefer contacting the NPlot developers, explain to them the goal, and the proposed fix. Thoughts?
OK, I'll try to contact the author and find a "vanilla" solution so there won't be anything gentoo-specific... The ebuild is here for people who want to play. Feel free to mark the bug as LATER, I'll reopen it when the mainstream thing is packaged better...
Ok, marking LATER, feel free to re-open at your disgression.
Hi Guys, Matt, author of NPlot here. Miguel has written a GTK# control for NPlot. You can get the tarball here: http://www.gnomefiles.org/app.php?soft_id=639 It includes a makefile. It's not included in my distro yet because I haven't tested it. I intend to in some future version. When I get mono and linux up and going... matt.
Created attachment 83373 [details] nplot-0.9.9.2.ebuild
Created attachment 83374 [details, diff] strongname.patch
