Re: [Mono-dev] [Mono-patches] r142362 - in trunk/gtk-sharp: . glib
Hey, When explicitly calling Dispose(), Remove() and Source.Remove () are called. Both will acquire a lock to access the same table and attempt to remove the same ID... Thanks for catching this. Fixed in trunk r142364 and 2-12 branch r142365. Best, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Suspected breakage with references in mcs trunk
Hey, I updated mcs and mono to trunk today (r142066) and noticed that gtk-sharp (trunk and gtk-sharp-2-12 branch) as well as other applications like Tomboy no longer build. Here's a snippet of what I'm seeing: /home/brad/mono/bin/mcs /out:glade-viewer.exe /r:../glib/glib-sharp.dll /r:../pango/pango-sharp.dll /r:../atk/atk-sharp.dll /r:../gdk/gdk-sharp.dll /r:../gtk/gtk-sharp.dll /r:../glade/glade-sharp.dll ./GladeViewer.cs ** (/home/brad/mono/lib/mono/1.0/mcs.exe:32210): WARNING **: The following assembly referenced from /home/brad/build/gtk-sharp-2-12-branch/glade/glade-sharp.dll could not be loaded: Assembly: gtk-sharp(assemblyref_index=2) Version:2.12.0.0 Public Key: 35e10195dab3c99f The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/brad/build/gtk-sharp-2-12-branch/glade/). It seems that mcs is now ignoring the referenced assemblies. I've traced it back to a commit between r141922 (BAD) and r141717 (GOOD). Nothing in the log between those two revisions smells like the culprit, so I'll continue my binary search. Is anyone else seeing this behavior, or is just my system? Thanks, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 2...
Hey Thomas, Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs Please add: Bug 473343 - [Regression] WebBrowser becomes unresponsive after Navigate (...) We just found it today. Thanks, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UIA Olive Reorganization at 1pm EDT
Hey, As far as I understand, you already have support for MWF, right? So far, we've implemented a portion of the UIA Provider specification (basically implementing UIA for MWF controls), and we've developed a Bridge between UIA and ATK, allowing GNOME Assistive Technologies to access a limited set of MWF controls. Would it be possible to use your API to build some sort of GUI testing tool on Linux? I worked with some students last two years on the university who build a windows testing tool based on UIA on Windows, I think it would be great to port it to Linux since I'm not aware of many tools to do GUI testing on Linux (ok, maybe there's a solution for GTK but I doubt there is for MWF) There are a few ATK-based testing tools, but as far as I know there isn't anything for UIA yet, so something to fill that gap would be awesome. I will mention though that any UIA testing tool or assistive technology will use the UIA Client API, and we haven't started work on that yet. Our tentative plans are to start work on that in February '09, and possibly have it complete the next calendar year, but I can't make any promises. If you have any further questions or want to contribute, feel free to pop in to #mono-a11y on Gimpnet. Best, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] UIA Olive Reorganization at 1pm EDT
Hey Folks,
[Apologies for not using my Novell address -- I'm not subscribed to
m-d-l there.]
The Mono Accessibility team will be moving our assemblies
(UIAutomation{Types, Provider, Client, Bridge}) from olive into our
uia2atk module at 1pm EDT today in preparation for our upcoming v0.9
release.
During this period, a bit of instability inside of olive and the uia2atk
modules should be expected, but we'll do our best to keep it to a
minimum.
Any questions, comments, etc can be directed to me (brad in #monodev),
or you can join #mono-a11y to watch the move in real time.
Best,
-Brad
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UIA Olive Reorganization at 1pm EDT
On Thu, 2008-11-06 at 19:13 +0100, [EMAIL PROTECTED] wrote: is UI Automation working on Linux!! :-) We're working on it! Check out http://mono-project.com/Accessibility Best, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins suppress console window showing
Hey Vlad, Recently I started using Mono.Addins in my application and it looks very good. But as the application is primary used under windows (should be working fine under Linux too) I get an annoying console window showing when I run: snip You can also compile Mono.Addins as a winexe target to suppress the console. You'll probably have to rename it to a .dll afterwards if you compile under Windows. Hope this helps, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.9.0 Preview 3 is out - mono 1.9 pre3 / gtk# 2.10.3 not working on Win32
Hey, I'm not sure if there is a bug for this or not. The gtk# 2.10.3 that comes with the mono 1.9.0 preview 3 windows installer is broken. In particular, setting or getting a value from a tree model. Weird, we at Medsphere haven't had any issues with this installer when running applications that make extensive use of TreeView. Do you have a test case you can provide for this issue? Best, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Wapi handle leaks problems
On Thu, 2008-02-21 at 08:53 +0100, Hubert FONGARNAND wrote: Le mercredi 20 février 2008 à 20:43 +, Dick Porter a écrit : On Wed, 2008-02-20 at 09:51 +0100, Hubert FONGARNAND wrote: - don't you thing that a 4096 limit for WAPI handles is too small for big production servers? (on windows the number of handles is often 6000)? The shared memory part of io-layer is currently being rewritten to avoid the hard-coded limit (amongst other issues.) There is no timetable yet for its completion. This is a great news... But for now our servers crashes each night... It could be good to track why the number of Handles grows on ASP.NET when there's no activity You're not the only one seeing this. Our Bridge application often crashes at night during a period of no activity. We're using a bundled version of xsp. Up until this point, we were unsure if it was something we were doing, or a bug in mono. #323666[1] could be related. -Brad -- [1] https://bugzilla.novell.com/show_bug.cgi?id=323666#c4 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.9.0 Preview 1+ is out!!
On Fri, 2008-02-01 at 13:40 -0700, Thomas Wiest wrote: Hey Everyone, We've just released Mono 1.9.0 Preview 1+ today! Please help us out by giving it a try with your applications. As always, you can get the preview releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs Can you be sure to get the fix for #357547[1] in for the next preview? It was committed right after the Preview 1+ was rolled. Thanks! -Brad -- [1] https://bugzilla.novell.com/show_bug.cgi?id=357547 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Win32 Gtk# Installers (Was: Re: C bindings VS C++ bindings (Gtk# vs. Kimono?))
On Tue, 2007-10-16 at 10:46 -0500, Jerome Haltom wrote: I spent a lot of time previously researching all this MSI stuff. No, you can't do that. Merge modules might have been an answer, but merge modules are not designed for dependencies. They are designed to repackage files for a private installation. I don't think we need to develop a hard dependency chain for our installers -- We can simply create Merge modules (.msm files) for each of gtk+, gtk#, and Mono, and enforce the dependencies manually in a .msi build that wraps all three. In WiX, this meta-installer is less than 30 lines. I'm making progress splitting out Medsphere's installer sources into .msm files, and currently have the Gtk+ Runtime module mostly complete. I'll update the list when I get my WiX files complete enough to be included into Mono SVN. -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Win32 Gtk# Installers (Was: Re: C bindings VS C++ bindings (Gtk# vs. Kimono?))
On Tue, 2007-10-16 at 13:51 -0500, Jerome Haltom wrote: You misunderstand how merge modules work. At this point, my knowledge about this whole MSI thing is just slightly above zero, and I've found the MS documentation to be incredibly lean on more complicated install practices, so you're most likely correct. Merge modules, when included in another package, lose their identity. They cannot install files which are shared by other packages. They can not be versioned against each other. Sadly this is the case, but it's no different than how we operate currently with every installer (Medsphere, Mono, Pidgin, etc) bringing in their own version of Gtk+, Gtk# and friends. It would be great if there was a better solution, but the main focus of merge modules *for Medsphere and Novell/Mono* is to share the maintenance responsibilities for developing installers. If this whole thing works out, Medsphere will be maintaining a Gtk+ merge module, and Novell would maintain the Gtk# one. Then, Novell and Medsphere will build their own installers that bring in the modules that they want without duplicating tons of effort. snip Microsoft recommends that you create a .msi file for each primary distributable (Gtk, Gtk#, Mono, etc) and have the application distributor build a bootstrapper which references these .msi files independently. VS2005 has a setup project built in which does this: it automatically generates a bootstrapper that installs .Net itself. Interesting -- I'll look into this approach. -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Win32 Gtk# Installers (Was: Re: C bindings VS C++ bindings (Gtk# vs. Kimono?))
snip This is a subject I'd really like to talk about. I had created some MSI files for the Gtk stack which I never saw through to completion. During that process I came across some ideas and best practices I thought would really make them polished. Are you available on some sort of IRCish medium or something? Sure. I'm available on various channels, including #mono and #monodev as brad. It might be good to involve Wade in this, as he is definitely an interested party. -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Miguel, You guys are maintaining the Gtk# installer for Windows, right? Yes -- I maintain the installer, and Cody does all the bug squashing with gtk+ and win32. (Full Disclosure: We're both employed by Medsphere) I wonder if we could merge the efforts? Are you talking about merging efforts with Wade's Gtk# + Mono Combined installer? We had discussed this about a year ago and decided that we had different interests, since we were focused on using MS .NET on Windows, and the Mono team wanted to (rightfully so) focus on Mono on Windows. That being said, I'd love to see our efforts combined into one Gtk# installer to rule them all. Maybe it would be appropriate to take this offline and discuss it when Cody and I are in Cambridge this Friday? Cheers, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Hey, We had discussed this about a year ago and decided that we had different interests, since we were focused on using MS .NET on Windows, and the Mono team wanted to (rightfully so) focus on Mono on Windows. Are the binaries for .NET and Mono any different, other than the GAC install directory? No, they're identical. I build gtk# on windows with vs .net for the sole purpose of eventually shipping gtk# for ms .net. Ah, we're building gtk# under cygwin (but with MS .NET). I think it's ok to have separate installers, but we may want to reconsider the overall picture if we move everything to .msi. (Ie: maybe have an .msi installer for gtk+, or use someone elses, one for core mono, another for gtk#, etc...) Yeah, I am intrigued at the possibility of using MSI merge modules so that we could have a Gtk+ MSI merge module, a Gtk# merge module, and one for Mono, and those could be removed/included at will, but I remember hearing (I think from Paco) that it wasn't possible because of issues with GACing. It's definitely something we can (and probably should) look into. Do you think it would be possible to have a single installer that could install the same assemblies into both GACs? Yes, I think this is possible, however it would force you guys to ship Mono in a separate installer. While we're chatting, if anyone is interested in getting their hands on the source for our installers, they're available on our SourceForge.net page[1]. Cheers, -Brad -- [1] http://openvista.svn.sourceforge.net/viewvc/openvista/gtksharp-win32-installer/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Hey Mirco, Ah, this is good to know who maintains that installer. I tried the 2.10 installer once and ran into real problems and could not find the correct contact for it. We're currently trying to track down some crashers we're seeing with PerformQueuedUnrefs () in Gtk# 2.10.2 with TreeModelSort, so I wouldn't recommend using the 2.10 series on Windows at this point. Our application is running fine with our 2.8 series of installers though. So here the problem I encountered (I have no idea if that applies to the current installer): The 2.10 installer seems to miss policy files for 2.4, IIRC only 2.6 and 2.8 where present. This made it a no go for us, as all applications where referenced with 2.4 at that time. We've never provided policy files for 2.4 since it seemed old enough to not be necessary, but if you'd like, I'd be happy to add those in the next version we release. So then we uninstalled gtk# 2.10 which didn't remove all installed policy files. That made it impossible to get paco's gtk# 2.4 or gtk# 2.8 working again with those stalled policy files. I could not find a way to remove the policy files by hand from the GAC, so we used windows recovery to let the gtk# 2.10 install unhappen. In the early Gtk# 2.10 transition, I accidentally forgot to ungac policy dlls, but as of 2.10.1-1, you shouldn't be seeing any problems. As usual, if you have any specific issues with installers, please direct them to me, and I'll help you out. But now I would reconsider testing the gtk# 2.10 installer :) I really wouldn't recommend it at this point due to the bug that we're seeing. However, it may just be our application doing something naughty. Cheers, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono summit, options.
Hey Miguel, snip Which probably means Do your conference in Boston, in mid February to guarantee attendance ;-). May I suggest scheduling the conference right after (or before) the GNOME Summit[1] in October? We might get higher attendance that way. Cheers, -Brad -- [1] http://live.gnome.org/Boston2007 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
