[Gtk-sharp-list] 64bit Gtk# for windows
Ok, no one is interested, no one answered ... I made it alone. It wasn't as tough as I thought it'd be. I took *-sharp.dll libraries from ArchLinux and only compiled *glue.dll libraries against 64bit Gtk+ libraries using mingw-w64. 64bit Gtk libraries can be found at gtk homepage, 64bit GtkSharp for windows can be found at http://rapidshare.com/files/145727260/GtkSharp.zip.html (sorry, but I didn't know where else to upload it). Feel free to use, redistribute, repackage or whatever :-) ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] 64bit Gtk# for windows
BTW it's version 2.12, no cairo C# lib included (yet). Jaroslav Šmíd wrote: Ok, no one is interested, no one answered ... I made it alone. It wasn't as tough as I thought it'd be. I took *-sharp.dll libraries from ArchLinux and only compiled *glue.dll libraries against 64bit Gtk+ libraries using mingw-w64. 64bit Gtk libraries can be found at gtk homepage, 64bit GtkSharp for windows can be found at http://rapidshare.com/files/145727260/GtkSharp.zip.html (sorry, but I didn't know where else to upload it). Feel free to use, redistribute, repackage or whatever :-) ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
[Gtk-sharp-list] Crash when closing a gtk window
Hi I have a problem where closing a Gtk.Window (not the main) of a program crashes with mono 2.0 rc1 and gtk-sharp svn but not with mono 1.2.6 and older version of gtk-sharp. So problem in installation, mono or gtk-sharp? The error I get is: Marshaling button_press_event signal Exception in Gtk# callback delegate Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception. System.Reflection.TargetException: Object does not match target type. at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x0] at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x0] at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x0] at System.Delegate.DynamicInvoke (System.Object[] args) [0x0] at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x0] at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x0] at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x0] at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at Nemo.MainClass.Main(System.String[] args) -- Anders Rune Jensen http://people.iola.dk/arj/ ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] pinvoke and benchmarks
On Fri, Sep 12, 2008 at 11:22 AM, Martin (OpenGeoMap) [EMAIL PROTECTED] wrote: is it better used a library only created with C or the pinvoke is fast??? In my imagination i see the pinvoke system trying to find a funtion every time and if i have 10 million of lidar data perhaps this is really slowly I doubt that Mono is so dumb that it doesn't remember function entry points. More likely, it's taking some time to marshal data over the managed boundary. Without seeing any code it's going to be difficult to diagnose anything. Note that things like Gtk# make heavy use of p/invoke and seem fairly fast, so I don't think the use of p/invoke alone is the problem. (Also, this question would be better directed to the main Mono mailing list, as it has nothing to do with Gtk#.) -- Chris Howie http://www.chrishowie.com http://en.wikipedia.org/wiki/User:Crazycomputers ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] Crash when closing a gtk window
On Tue, 2008-09-16 at 18:01 +0200, Anders Rune Jensen wrote: Hi I have a problem where closing a Gtk.Window (not the main) of a program crashes with mono 2.0 rc1 and gtk-sharp svn but not with mono 1.2.6 and older version of gtk-sharp. So problem in installation, mono or gtk-sharp? The error I get is: I was seeing something like that on mono trunk and the 2.0 branch at one point, but there was an mcs fix that went in which resolved the problem. I don't know where that fix fell in the 2.0 branch related to rc1. If you have a sample that can reproduce the problem with gtk-sharp 2.12.3 or trunk and the head of mono2 branch, please file a bug and I'll look into it. Mike ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] 64bit Gtk# for windows
On Tue, 2008-09-16 at 13:45 +0200, Jaroslav Šmíd wrote: Ok, no one is interested, no one answered ... I made it alone. It wasn't as tough as I thought it'd be. I took *-sharp.dll libraries from ArchLinux and only compiled *glue.dll libraries against 64bit Gtk+ libraries using mingw-w64. 64bit Gtk libraries can be found at gtk homepage, 64bit GtkSharp for windows can be found at http://rapidshare.com/files/145727260/GtkSharp.zip.html (sorry, but I didn't know where else to upload it). Feel free to use, redistribute, repackage or whatever :-) The fact that nobody responded in under 24 hours doesn't quite equate to nobody being interested. ;-) Thanks for providing that. I'm interested to hear of any issues people might encounter running gtk-sharp on win64. It has some interesting type sizing issues. The way we've worked around some of them won't work if you just copy the dlls from a win32 build over to a win64 installation, unfortunately. It will be necessary to recompile the assemblies for win64, since we wanted to avoid creating a huge nest of duplicated pinvoke signatures and conditional execution of methods all over the binding. Note that the win64 platform is really the only platform this copying restriction applies to, because of their decision to break the LP64 convention used on other 64 bit platforms. Mike ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] 64bit Gtk# for windows
Mike Kestner wrote: On Tue, 2008-09-16 at 13:45 +0200, Jaroslav Šmíd wrote: Ok, no one is interested, no one answered ... I made it alone. It wasn't as tough as I thought it'd be. I took *-sharp.dll libraries from ArchLinux and only compiled *glue.dll libraries against 64bit Gtk+ libraries using mingw-w64. 64bit Gtk libraries can be found at gtk homepage, 64bit GtkSharp for windows can be found at http://rapidshare.com/files/145727260/GtkSharp.zip.html (sorry, but I didn't know where else to upload it). Feel free to use, redistribute, repackage or whatever :-) The fact that nobody responded in under 24 hours doesn't quite equate to nobody being interested. ;-) Thanks for providing that. I'm interested to hear of any issues people might encounter running gtk-sharp on win64. It has some interesting type sizing issues. The way we've worked around some of them won't work if you just copy the dlls from a win32 build over to a win64 installation, unfortunately. It will be necessary to recompile the assemblies for win64, since we wanted to avoid creating a huge nest of duplicated pinvoke signatures and conditional execution of methods all over the binding. Note that the win64 platform is really the only platform this copying restriction applies to, because of their decision to break the LP64 convention used on other 64 bit platforms. Mike I actually took them from ArchLinux x86_64 and they work. Maybe this is because I didn't call any gtk+ function having long as its argument. But what else should I do. I do not know how to compile assemblies for windows. I do not have cygwin and I do not want to install it as it is 32bit and I have 64bit OS (I know it works, but I just hate having 32bit application on 64bit system). .NET applications should run no matter where you run them. You could solve long size issue by using size_t C# equivalen (if there is no, IntPtr has the same size) instead (I know, this is not nice sollution, but it works - 32bit on 32bit systems, 64bit on 64bit systems). But it would require Gtk changes as well (they would have to use size_t instead of long/ulong or whatever it is typedefed in glib). So is there any possibility that we will have official GtkSharp release for 64bit Windows? I don't think so, you don't even have 2.12 build for 32bit Windows. To get back to compilation problems. SVN version has no longer win32 makefiles. Why? It can't be that hard to maintain them. I know they were for msys, but at least I could read them and write own for native non-msys mingw. I used makefiles from 2.12 source tarball available at novell's web to write my own. I compiled gapi-fixup and codegen using csc from dotnet 3.5 (I can't have 1 or 1.1, I'm using vista and there is no 64bit dotnet 1 or 1.1). Then I wrote those makefiles generating .cs using gapi-fixup and codegen in the same way as 2.12's makefiles and compilling *glue.dll files (I can't get, why you are creating another platform specific stuff, why don't you wrap it in .NET? This is what I don't like on GtkSharp and everything around it - million of platform dependend C wrappers in C). I have glue files and cs files. But I am unable to compile them. Always multiple definitions of blablabla or unknown type blablabla. So is 64bit version of GtkSharp going to be release in the near future? Is it worth waiting? ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] 64bit Gtk# for windows
On Tue, Sep 16, 2008 at 1:09 PM, Mike Kestner [EMAIL PROTECTED] wrote: On Tue, 2008-09-16 at 13:45 +0200, Jaroslav Šmíd wrote: Ok, no one is interested, no one answered ... I made it alone. It wasn't as tough as I thought it'd be. I took *-sharp.dll libraries from ArchLinux and only compiled *glue.dll libraries against 64bit Gtk+ libraries using mingw-w64. 64bit Gtk libraries can be found at gtk homepage, 64bit GtkSharp for windows can be found at http://rapidshare.com/files/145727260/GtkSharp.zip.html (sorry, but I didn't know where else to upload it). Feel free to use, redistribute, repackage or whatever :-) The fact that nobody responded in under 24 hours doesn't quite equate to nobody being interested. ;-) I think it's a *great* idea, I just didn't think I had anything useful to add :-) 2/3 of my windows dev boxes are 64-bit, and I've found it annoying not being able to use GTK# on Windows. -- Michael Hutchinson http://mjhutchinson.com ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
Re: [Gtk-sharp-list] pinvoke and benchmarks
On Fri, Sep 12, 2008 at 11:22 AM, Martin (OpenGeoMap) [EMAIL PROTECTED] wrote: Hi: Someone knows about the performance in a library used only with c# or used thanks to other C API??? I am working in a bindings to mono and .NET in c# for lidar data and i see my program really really slowly in relationship with the C API. We have created a C++ libvrary and a C API to used it with mono and python: http://liblas.org/ is it better used a library only created with C or the pinvoke is fast??? In my imagination i see the pinvoke system trying to find a funtion every time and if i have 10 million of lidar data perhaps this is really slowly The function lookup will only take place once for each function, so you don't need to worry about that. However, AFAIK P/Invoke will cost you somewhere around 50 cycles each time you cross the managed/unmanaged boundary (for handling the managed stack, exceptions, thread aborts etc), plus whatever it takes to marshal the data strcutures in the arguments/return values. For this reason, you should minimise managed/unmanaged transitions. It's often much faster if you reimplement smaller methods in C#. Another trick is zero-marshalling P/Invoke -- with a single call you can pass over an IntPtr to a struct, then use unsafe (but still C#) code to dereference and access the struct 's members directly. Note that this only works for value types, i.e. not classes. Looking at your LASPoint class, it looks like accessing every property's getter/setter would cause a managed/unmanaged/managed transition. If this is your primitive data type, it might be better to use a struct for the LASPoint in the C API. I imagine you'd get the best performance (and API) just by porting all of libLAS to C#... Perhaps the C++ managed language is better than c# to create bindings: http://msdn.microsoft.com/en-us/library/ms235281(VS.80).aspx , but i don´t see the c++ in mono http://www.mono-project.com/Languages There are a number of issues with implementing C++/CLI for Mono. Firstly, implementing a C++ compiler isn't easy. Also, C++/CLI normally produces mixed-mode assemblies that contain managed *and* unmanaged code. Unmanaged code, of course, is not portable across platforms. Mono can handle mixed-mode assemblies, but *only* on Windows (or Wine). Another option would be to use the MS C++/CLI compiler to generate verifiable managed assemblies: http://msdn.microsoft.com/en-us/library/85344whh(VS.80).aspx In theory these would run on Mono, since they cannot contain any unmanaged code. As with porting the C++ code to C#, this might well be the fastest option. You could even decompile it to C# using reflector ;-) -- Michael Hutchinson http://mjhutchinson.com ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
