From mh at elitedev.com Sat Nov 10 14:52:56 2007 From: mh at elitedev.com (marc hoffman) Date: Sat, 10 Nov 2007 20:52:56 +0100 Subject: [Cocoa-sharp] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <473607D0.5030207@elitedev.com> References: <200711082232.lA8MWJL0011587@alderaan.gsfc.nasa.gov><1194625013.4397.1.camel@limestone.sublimeintervention.com> <001601c822f5$1eb37b30$5c1a7190$@com> <002601c823c3$ba78c150$2f6a43f0$@com> <77ED317C-D524-4DEB-9128-2B20E7E34175@novell.com> <473607D0.5030207@elitedev.com> Message-ID: <47360C18.4070504@elitedev.com> Hi, this maybe (probably?) has come up before, but i couldn't find any reference to it, so here it goes: As i've found out myself, recently, creating the wrapper classes needed to access the Cocoa objects from managed code is a very tedious and error prone process, which in tuen explains, of course, why such a small portion of Cocoa is actually exposed, so far. It's mind-numbing runt-work that no-one wants to do. has anyone ever put any thought into creating a way to *automatically* or semi-automatically (ie with manual adjustments) generate these wrapper classes by, for example, parsing method headers from available .h files or the documentation? if not, does anyone think this would be a good idea and would like to work with me on investigating this? (i'm very interested in this myself (else i wouldn't bring it up ;), but my spare time is severely limited these days, so i wouldn't want to take this up all by myself - but i'd certainly be happy to put effort and energy into this, if someone else will help out as well). looking forward to your thoughts on this, marc hoffman RemOjects Software The Infrastructure Company http://www.rembjects.com From csomor at advancedconcepts.ch Sun Nov 11 06:17:27 2007 From: csomor at advancedconcepts.ch (Stefan Csomor) Date: Sun, 11 Nov 2007 12:17:27 +0100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <47360C18.4070504@elitedev.com> References: <200711082232.lA8MWJL0011587@alderaan.gsfc.nasa.gov><1194625013.4397.1.camel@limestone.sublimeintervention.com> <001601c822f5$1eb37b30$5c1a7190$@com> <002601c823c3$ba78c150$2f6a43f0$@com> <77ED317C-D524-4DEB-9128-2B20E7E34175@novell.com> <473607D0.5030207@elitedev.com> <47360C18.4070504@elitedev.com> Message-ID: <4736E4C7.7070201@advancedconcepts.ch> Hi > Hi, > > this maybe (probably?) has come up before, but i couldn't find any > reference to it, so here it goes: > > As i've found out myself, recently, creating the wrapper classes needed > to access the Cocoa objects from managed code is a very tedious and > error prone process, which in tuen explains, of course, why such a small > portion of Cocoa is actually exposed, so far. It's mind-numbing > runt-work that no-one wants to do BridgeSupport on Leopard has information on all APIs that can be used to generate bridging code, it is used for PyObjC and RubyCocoa AFAIK but I'd suggest takeing a closer look: http://trac.macosforge.org/projects/BridgeSupport Best, Stefan Csomor From mh at elitedev.com Sun Nov 11 07:30:44 2007 From: mh at elitedev.com (marc hoffman) Date: Sun, 11 Nov 2007 13:30:44 +0100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <47360C18.4070504@elitedev.com> References: <200711082232.lA8MWJL0011587@alderaan.gsfc.nasa.gov><1194625013.4397.1.camel@limestone.sublimeintervention.com> <001601c822f5$1eb37b30$5c1a7190$@com> <002601c823c3$ba78c150$2f6a43f0$@com> <77ED317C-D524-4DEB-9128-2B20E7E34175@novell.com> <473607D0.5030207@elitedev.com> <47360C18.4070504@elitedev.com> Message-ID: <4736F5F4.5060308@elitedev.com> > As i've found out myself, recently, creating the wrapper classes needed > to access the Cocoa objects from managed code is a very tedious and > error prone process, which in tuen explains, of course, why such a small > portion of Cocoa is actually exposed, so far. It's mind-numbing > runt-work that no-one wants to do. > > has anyone ever put any thought into creating a way to *automatically* > or semi-automatically (ie with manual adjustments) generate these > wrapper classes by, for example, parsing method headers from available > .h files or the documentation? work in progress: http://screencast.com/t/71yxRHUCI ;). top edit is pasted from a random Apple Doc PDF file, bottom is auto-generated from the parsed Objective-C header as either Chrome or C#. of course this is just the start; it needs to generate the body & handle a lot more cases then it currently does. Also, of course it only handles individual methods, for now... From rhind at mac.com Tue Nov 13 04:18:19 2007 From: rhind at mac.com (Russell Hind) Date: Tue, 13 Nov 2007 09:18:19 +0000 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <47360C18.4070504@elitedev.com> References: <200711082232.lA8MWJL0011587@alderaan.gsfc.nasa.gov> <1194625013.4397.1.camel@limestone.sublimeintervention.com> <001601c822f5$1eb37b30$5c1a7190$@com> <002601c823c3$ba78c150$2f6a43f0$@com> <77ED317C-D524-4DEB-9128-2B20E7E34175@novell.com> <473607D0.5030207@elitedev.com> <47360C18.4070504@elitedev.com> Message-ID: <29D06CBC-771C-4F8E-BF5F-93D5D9D4ECD2@mac.com> Just read a page at MacResearch.org (http://macresearch.org/whats_new_on_the_leopard_command_line ) that mentioned a new command in Leoopard gen_bridge_metadata Maybe that would prove useful for Leopard, anyway? Cheers Russell On 10 Nov 2007, at 19:52, marc hoffman wrote: > Hi, > > this maybe (probably?) has come up before, but i couldn't find any > reference to it, so here it goes: > > As i've found out myself, recently, creating the wrapper classes > needed > to access the Cocoa objects from managed code is a very tedious and > error prone process, which in tuen explains, of course, why such a > small > portion of Cocoa is actually exposed, so far. It's mind-numbing > runt-work that no-one wants to do. > > has anyone ever put any thought into creating a way to *automatically* > or semi-automatically (ie with manual adjustments) generate these > wrapper classes by, for example, parsing method headers from available > .h files or the documentation? > > if not, does anyone think this would be a good idea and would like to > work with me on investigating this? (i'm very interested in this > myself > (else i wouldn't bring it up ;), but my spare time is severely limited > these days, so i wouldn't want to take this up all by myself - but i'd > certainly be happy to put effort and energy into this, if someone else > will help out as well). > > > looking forward to your thoughts on this, > > marc hoffman > > RemOjects Software > The Infrastructure Company > http://www.rembjects.com > _______________________________________________ > Mono-osx mailing list > Mono-osx at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-osx From richard at xpro.com.au Sun Nov 25 08:57:39 2007 From: richard at xpro.com.au (Richard King) Date: Mon, 26 Nov 2007 00:57:39 +1100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automaticgeneration of Cocoa# wrapper classes In-Reply-To: <29D06CBC-771C-4F8E-BF5F-93D5D9D4ECD2@mac.com> References: <200711082232.lA8MWJL0011587@alderaan.gsfc.nasa.gov><1194625013.4397.1.camel@limestone.sublimeintervention.com><001601c822f5$1eb37b30$5c1a7190$@com><002601c823c3$ba78c150$2f6a43f0$@com><77ED317C-D524-4DEB-9128-2B20E7E34175@novell.com><473607D0.5030207@elitedev.com> <47360C18.4070504@elitedev.com> <29D06CBC-771C-4F8E-BF5F-93D5D9D4ECD2@mac.com> Message-ID: <1DA3862E214848E6B650BE5A9DF90B07@RichardDell> I have been having fun using RemObject's Chrome to build a native Mac app (it runs under Mono being a .Net program). It is a simple four function calculator and can be downloaded from www.vikingcomputers.com.au/download/CocoaCalc.zip. I am very impressed with Chrome and Cocoa-sharp so far. However, the main point of this post is to say I have also found it very tedious hand translating Apple's header files for the few extra functions I wanted and have made a start on a CocoaH2CS conversion program which can be downloaded from www.vikingcomputers.com.au/download/CocoaH2CS.zip You can see some examples of the .cs files resulting from converting the .h files in the bin/Debug directory. So far, I have only cut and pasted selected methods from the generated code into my 'master' files when rebuilding my cocoa-sharp dll; but it is looking promising -- many functions require no touching up at all and having getter and setter methods paired up as properties is in keeping with the C# and Cocoa sharp spirit, I hope. There is much to do to make it a more robust program, however. I also envisage having a file that defines the methods to convert (eg NSCell.h might have an associated NSCell.xlate file) until we get closer to being able to compile the full raw output of this program. This is the first time I have had anything to contribute to an open source effort -- how do I go about submitting this program and the fixes and extensions I have already made to the cocoa-sharp project? I have briefly releated my experiences over the last month with Chrome and Cocoa at www.vikingcomputers.com.au -- follow the bottom most link in the menu at the left. (Joomla is also new for me - so please excuse the web pages). Regards, Richard King ----- Original Message ----- From: "Russell Hind" To: ; Sent: Tuesday, November 13, 2007 8:18 PM Subject: Re: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automaticgeneration of Cocoa# wrapper classes > Just read a page at MacResearch.org > (http://macresearch.org/whats_new_on_the_leopard_command_line > ) that mentioned a new command in Leoopard > > gen_bridge_metadata > > Maybe that would prove useful for Leopard, anyway? > > Cheers > > Russell > > On 10 Nov 2007, at 19:52, marc hoffman wrote: > >> Hi, >> >> this maybe (probably?) has come up before, but i couldn't find any >> reference to it, so here it goes: >> >> As i've found out myself, recently, creating the wrapper classes >> needed >> to access the Cocoa objects from managed code is a very tedious and >> error prone process, which in tuen explains, of course, why such a >> small >> portion of Cocoa is actually exposed, so far. It's mind-numbing >> runt-work that no-one wants to do. >> >> has anyone ever put any thought into creating a way to *automatically* >> or semi-automatically (ie with manual adjustments) generate these >> wrapper classes by, for example, parsing method headers from available >> .h files or the documentation? >> >> if not, does anyone think this would be a good idea and would like to >> work with me on investigating this? (i'm very interested in this >> myself >> (else i wouldn't bring it up ;), but my spare time is severely limited >> these days, so i wouldn't want to take this up all by myself - but i'd >> certainly be happy to put effort and energy into this, if someone else >> will help out as well). >> >> >> looking forward to your thoughts on this, >> >> marc hoffman >> >> RemOjects Software >> The Infrastructure Company >> http://www.rembjects.com >> _______________________________________________ >> Mono-osx mailing list >> Mono-osx at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-osx > > _______________________________________________ > Cocoa-sharp mailing list > Cocoa-sharp at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/cocoa-sharp > From mh at elitedev.com Mon Nov 26 11:11:59 2007 From: mh at elitedev.com (marc hoffman) Date: Mon, 26 Nov 2007 17:11:59 +0100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <4736E4C7.7070201@advancedconcepts.ch> References: <47360C18.4070504@elitedev.com> <4736E4C7.7070201@advancedconcepts.ch> Message-ID: <002a01c83047$12bbadc0$38330940$@com> Stefan, Russell, Thanx for the pointers. Robert (Gieseke) and i are looking into bridgesupport, with the basic idea being that we should be able to generate entire class skeletons with stub methods from it (these classes could be partial, so they could then be extended with properties, events, helper methods, on top of the auto-gen code). We'll be playing with this over the next few days/weeks. On first look, it seems that xml files generated by gen_bridge_metadata don't really have *all* the info (for one thing, all parameter types seem to be defined as "B" (Boolean?), no ancestry information is given, etc. but this could be a matter of us not using the tool properly, yet ;). We'll investigate further. Unrelated, i will finish the "method converter" tool i posted a teaser screenshot for earlier this month; this should certainly help with adding individual method stubs, short term. I'm fighting with some last Cocoa#/Leopard issues (i'm hoping Geoff will have time to look at those soon ;) as well as with my own time constraints, but i can probably have something usable i can share, soonish. Yours, marc hoffman RemObjects Software The Infrastructure Company http://www.remobjects.com > -----Original Message----- > From: Stefan Csomor [mailto:csomor at advancedconcepts.ch] > Sent: Sunday, November 11, 2007 12:17 PM > To: marc hoffman > Cc: mono-osx at lists.ximian.com; cocoa-sharp at lists.ximian.com > Subject: Re: [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# > wrapper classes > > Hi > > Hi, > > > > this maybe (probably?) has come up before, but i couldn't find any > > reference to it, so here it goes: > > > > As i've found out myself, recently, creating the wrapper classes needed > > to access the Cocoa objects from managed code is a very tedious and > > error prone process, which in tuen explains, of course, why such a small > > portion of Cocoa is actually exposed, so far. It's mind-numbing > > runt-work that no-one wants to do > BridgeSupport on Leopard has information on all APIs that can be used to > generate bridging code, it is used for PyObjC and RubyCocoa AFAIK but > I'd suggest takeing a closer look: > > http://trac.macosforge.org/projects/BridgeSupport > > Best, > > Stefan Csomor > From andreas.faerber at web.de Mon Nov 26 13:35:29 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 26 Nov 2007 19:35:29 +0100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <002a01c83047$12bbadc0$38330940$@com> References: <47360C18.4070504@elitedev.com> <4736E4C7.7070201@advancedconcepts.ch> <002a01c83047$12bbadc0$38330940$@com> Message-ID: <9D458793-5D60-4260-9C86-ECD3B185CB34@web.de> Hello, If you carefully looked at the list archive you would find that we once had a code generator for Cocoa#, and it resulted in very ugly code. The newer manual version was much, much better but I agree it is tedious work and had/has design flaws; I tried addressing some of them but that has not been picked up. Also, fundamental differences between the two worlds cannot be fully bridged even manually, for instance inheritance of events was pretty problematic to implement as I recall. Whatever you decide to do these days, please keep it to the Cocoa- sharp list, there's no need to cross-post. Thank you. Andreas Am 26.11.2007 um 17:11 schrieb marc hoffman: > Stefan, Russell, > > Thanx for the pointers. Robert (Gieseke) and i are looking into > bridgesupport, > with the basic idea being that we should be able to generate entire > class > skeletons with stub methods from it (these classes could be partial, > so they > could then be extended with properties, events, helper methods, on > top of the > auto-gen code). We'll be playing with this over the next few days/ > weeks. > > On first look, it seems that xml files generated by > gen_bridge_metadata don't > really have *all* the info (for one thing, all parameter types seem > to be > defined as "B" (Boolean?), no ancestry information is given, etc. > but this could > be a matter of us not using the tool properly, yet ;). We'll > investigate > further. > > Unrelated, i will finish the "method converter" tool i posted a teaser > screenshot for earlier this month; this should certainly help with > adding > individual method stubs, short term. I'm fighting with some last > Cocoa#/Leopard > issues (i'm hoping Geoff will have time to look at those soon ;) as > well as with > my own time constraints, but i can probably have something usable i > can share, > soonish. > > Yours, > > marc hoffman > > RemObjects Software > The Infrastructure Company > http://www.remobjects.com > > > > > > > > >> -----Original Message----- >> From: Stefan Csomor [mailto:csomor at advancedconcepts.ch] >> Sent: Sunday, November 11, 2007 12:17 PM >> To: marc hoffman >> Cc: mono-osx at lists.ximian.com; cocoa-sharp at lists.ximian.com >> Subject: Re: [Mono-osx] Conceptual Idea: (Semi)automatic generation >> of Cocoa# >> wrapper classes >> >> Hi >>> Hi, >>> >>> this maybe (probably?) has come up before, but i couldn't find any >>> reference to it, so here it goes: >>> >>> As i've found out myself, recently, creating the wrapper classes >>> needed >>> to access the Cocoa objects from managed code is a very tedious and >>> error prone process, which in tuen explains, of course, why such a >>> small >>> portion of Cocoa is actually exposed, so far. It's mind-numbing >>> runt-work that no-one wants to do >> BridgeSupport on Leopard has information on all APIs that can be >> used to >> generate bridging code, it is used for PyObjC and RubyCocoa AFAIK but >> I'd suggest takeing a closer look: >> >> http://trac.macosforge.org/projects/BridgeSupport >> >> Best, >> >> Stefan Csomor >> > > > _______________________________________________ > Mono-osx mailing list > Mono-osx at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-osx From mh at elitedev.com Tue Nov 27 11:53:13 2007 From: mh at elitedev.com (marc hoffman) Date: Tue, 27 Nov 2007 17:53:13 +0100 Subject: [Cocoa-sharp] [Mono-osx] Conceptual Idea: (Semi)automatic generation of Cocoa# wrapper classes In-Reply-To: <9D458793-5D60-4260-9C86-ECD3B185CB34@web.de> References: <002a01c83047$12bbadc0$38330940$@com> <9D458793-5D60-4260-9C86-ECD3B185CB34@web.de> Message-ID: <003d01c83115$ffbd2800$ff377800$@com> Andreas, > If you carefully looked at the list archive you would find that we > once had a code generator for Cocoa#, and it resulted in very ugly > code. The newer manual version was much, much better but I agree it is > tedious work and had/has design flaws; I tried addressing some of them > but that has not been picked up. I was not aware of that, no. Could you point me to the relevant discussions? > Also, fundamental differences between > the two worlds cannot be fully bridged even manually, for instance > inheritance of events was pretty problematic to implement as I recall. Of course, yes. > Whatever you decide to do these days, please keep it to the Cocoa- > sharp list, there's no need to cross-post. Thank you. Sure thing, i'll remove Mono-OSX after this reply. To be honest, the main reason i cross-posted was that i've seen so little (read: none since i joinced) traffic on cocoa-sharp that i wasn't even sure it was an active list ;). Thanx, From mh at elitedev.com Wed Nov 28 12:53:19 2007 From: mh at elitedev.com (marc hoffman) Date: Wed, 28 Nov 2007 18:53:19 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> References: <474DA0FB.5040405@elitedev.com> <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> Message-ID: <000e01c831e7$901f5cc0$b05e1640$@com> Andreas, > Wrong list!!! You're very welcome, it's been my pleasure to make these fixes available. ;) Wondering: if "cocoa-sharp at lists.ximian.com" is the *right* list, then how come it is not even listed on http://www.mono-project.com/Mailing_Lists anymore (which instead now lists a third, google-group based forum)? I merely wanted to post those files in a place where people will actually *see* em. And judging from my subscription to both lists for the past few months, those few people that do seem to care seem to be hanging out in mono-osx...? Don't get me wrong, but with as little people being active on the Mono/OSX front in the first place, why artificially thin the community out even further? Just a thought. marc hoffman RemObjects Software The Infrastructure Company http://www.remobjects.com From andreas.faerber at web.de Wed Nov 28 13:46:46 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 28 Nov 2007 19:46:46 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <000e01c831e7$901f5cc0$b05e1640$@com> References: <474DA0FB.5040405@elitedev.com> <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> <000e01c831e7$901f5cc0$b05e1640$@com> Message-ID: <007BA8FA-1A37-406A-BAF0-E9413259CB66@web.de> Am 28.11.2007 um 18:53 schrieb marc hoffman: > Wondering: if "cocoa-sharp at lists.ximian.com" is the *right* list, > then how come > it is not even listed on http://www.mono-project.com/Mailing_Lists > anymore > (which instead now lists a third, google-group based forum)? Well, the MonoDevelop list wasn't listed there either last time I checked. If as you say it lists such another group, you might want to try posting there; that does still not imply that mono-osx is the most suitable place. > I merely wanted to post those files in a place where people will > actually *see* > em. And judging from my subscription to both lists for the past few > months, > those few people that do seem to care seem to be hanging out in mono- > osx...? > Don't get me wrong, but with as little people being active on the > Mono/OSX front > in the first place, why artificially thin the community out even > further? > > Just a thought. My point is, the Mono OS X community is not necessarily based around Cocoa#. You can write command line apps or daemons, ASP.NET projects, SWF apps, Gtk# apps, and embed Mono with or without Dumbarton. I can't comment on any Google groups but my personal impression was that its creation was a reaction to Cocoa#'s lack of maintainance. Unfortunately Cocoa# appears to be most attractive as an entry point for people new to the Mac, coming from a Windows background without Objective-C knowledge - thus it is problematic for such people to enhance Cocoa# because that requires a little ObjC understanding, and even less people dared to touch the inner workings of the bridge, so if things blow you're on your own. On the other hand those that do know ObjC will notice a certain performance and memory usage gap between the two, likely preferring the "real" one, which is managed in 2.0 too. So that is a structural problem for the code and the community. No idea how to tackle that, we forked our own version for a project and are no longer using it by now. I like the idea of a managed Cocoa# but in practice it does not scale well. Embedding Mono in native ObjC dramatically reduced memory footprint of our app and allows me to use the Xcode debugger. On the original topic, your String patch is not okay as such, you should not call Init for a given native object, that overrides the original object's contents or possibly even deletes and replaces the original object: init* instance methods are always a second-phase constructor whose return value needs to be respected and the original value must no longer be used afterwards. HTH. Andreas From mh at elitedev.com Wed Nov 28 14:55:08 2007 From: mh at elitedev.com (marc hoffman) Date: Wed, 28 Nov 2007 20:55:08 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <474DB69C.6020207@innerfuse.biz> References: <474DA0FB.5040405@elitedev.com> <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> <000e01c831e7$901f5cc0$b05e1640$@com> <474DB69C.6020207@innerfuse.biz> Message-ID: <474DC79C.6050507@elitedev.com> Weyert, > Curious, how do you guys compile mono under MacOSX? The mono package > that comes with macports doesn't work for me. i haven't bothered, so far. i've only compiled the Cocoa# dll, which builds fine from with Visual Studio with one minor change* in Mach.cs [*investigating that and will log a bug. in the meantime, remove the "(int)" cast from the line that fails]. -- marc hoffman RemObjects Software The Infrastructure Company http://www.remobjects.com From andreas.faerber at web.de Wed Nov 28 15:12:38 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 28 Nov 2007 21:12:38 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <474DC79C.6050507@elitedev.com> References: <474DA0FB.5040405@elitedev.com> <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> <000e01c831e7$901f5cc0$b05e1640$@com> <474DB69C.6020207@innerfuse.biz> <474DC79C.6050507@elitedev.com> Message-ID: Am 28.11.2007 um 20:55 schrieb marc hoffman: > i've only compiled the Cocoa# dll, which > builds fine from with Visual Studio with one minor change* in Mach.cs > > [*investigating that and will log a bug. in the meantime, remove the > "(int)" cast from the line that fails]. A better solution is to remove Mach.cs completely (if it still does what it did) because a native version of that code is now part of the Mono runtime. Andreas From mh at elitedev.com Thu Nov 29 07:08:20 2007 From: mh at elitedev.com (marc hoffman) Date: Thu, 29 Nov 2007 13:08:20 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <007BA8FA-1A37-406A-BAF0-E9413259CB66@web.de> References: <000e01c831e7$901f5cc0$b05e1640$@com> <007BA8FA-1A37-406A-BAF0-E9413259CB66@web.de> Message-ID: <001801c83280$88e30080$9aa90180$@com> Andreas > Well, the MonoDevelop list wasn't listed there either last time I > checked. > If as you say it lists such another group, you might want to try > posting there; Well; i've posted to said list a few times in the past, it's basically a big /dev/null. > that does still not imply that mono-osx is the most > suitable place. Given that even Geoff just told me he wasn't even aware of a separate cocoa-sharp list, i'd say that imho mono-osx comes pretty close to being the suitable place, as of now ;) > My point is, the Mono OS X community is not necessarily based around > Cocoa#. You can write command line apps or daemons, ASP.NET projects, > SWF apps, Gtk# apps, and embed Mono with or without Dumbarton. I see your point, and i would agree if this list would see 250 messages a day. However, given the few messages a week here and the virtually non-existent traffic in the other list, does it really make sense to have theme split? If anything, it seems to me it would *discourage* people from suing Cocoa#, as they don't see it here. Case in point: I've heard back from a couple of people via direct mail, which said "woah, i didn't even know there was mono-osx, i thought Cocoa# was dead coz nothing was happening on the other list". I think if we want to improve adoption of Mono on OS X (and improve Cocao#, too), the goal should be to consolidate supporters, not spread 'em apart. But that's just IMHO, of course. > I can't comment on any Google groups but my personal impression was > that its creation was a reaction to Cocoa#'s lack of maintainance. Ok, sorry if i need to be a pain and keep coming back to this but: so you're telling me you weren't even aware of the google group, and STILL above you recommend i should have posted there instead (where neither you nor anyone else relevant to the project would have even see the files)? Sorry, i don't get it. > On the original topic, your String patch is not okay as such, you > should not call Init for a given native object, that overrides the > original object's contents or possibly even deletes and replaces the > original object: init* instance methods are always a second-phase > constructor whose return value needs to be respected and the original > value must no longer be used afterwards. HTH. I assume you mean the Menu fix, where i added the ctor. Thank for clarifying, that makes sense. As a matter of fact, i see the latest version in SVN already has the empty ctor(IntPtr), so there's no action needed for the Menu... Yours, marc hoffman RemObjects Software The Infrastructure Company http://www.remobjects.com From mh at elitedev.com Thu Nov 29 07:09:40 2007 From: mh at elitedev.com (marc hoffman) Date: Thu, 29 Nov 2007 13:09:40 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: References: <474DC79C.6050507@elitedev.com> Message-ID: <001901c83280$b8105560$28310020$@com> Andreas, > A better solution is to remove Mach.cs completely (if it still does > what it did) because a native version of that code is now part of the > Mono runtime. Ah, that explains why there was code in SVN that didn't compile. ;) marc hoffman RemObjects Software The Infrastructure Company http://www.remobjects.com From andreas.faerber at web.de Thu Nov 29 08:36:21 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 29 Nov 2007 14:36:21 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <001801c83280$88e30080$9aa90180$@com> References: <000e01c831e7$901f5cc0$b05e1640$@com> <007BA8FA-1A37-406A-BAF0-E9413259CB66@web.de> <001801c83280$88e30080$9aa90180$@com> Message-ID: <6B5F8A10-304F-497E-B537-CA6006BE34E2@web.de> Am 29.11.2007 um 13:08 schrieb marc hoffman: > Andreas > >> Well, the MonoDevelop list wasn't listed there either last time I >> checked. > >> If as you say it lists such another group, you might want to try >> posting there; > > Well; i've posted to said list a few times in the past, it's > basically a big > /dev/null. > >> that does still not imply that mono-osx is the most >> suitable place. > > Given that even Geoff just told me he wasn't even aware of a separate > cocoa-sharp list, i'd say that imho mono-osx comes pretty close to > being the > suitable place, as of now ;) You will find Geoff has posted there many times himself. :) Andreas From mh at elitedev.com Thu Nov 29 12:20:18 2007 From: mh at elitedev.com (marc hoffman) Date: Thu, 29 Nov 2007 18:20:18 +0100 Subject: [Cocoa-sharp] Crash when sing Context Menu of a Text View - thread_get_state failed In-Reply-To: <1CF6B49D2CC77C4DA467EDFA84E3E3E4256944@lucien.dwarfland.elitedev.com> References: <1CF6B49D2CC77C4DA467EDFA84E3E3E4256944@lucien.dwarfland.elitedev.com> Message-ID: <474EF4D2.2070003@elitedev.com> I'm not sure if this is related to the Menu..ctor problem i reported earlier (which also happened in a Text View in a plain no-code app just loaded from NIB), but when i right-click a Text View and select any action from the context menu (such as "Copy"), i get the following crash. does this make sense to anyone? (i'll try to create a testcase and log an issue, later). This is on Leopard 10.5.1, Mono 1.2.5.1, latest Cocoa# from SVN (for all relevant purposes). thread_get_state failed Stacktrace: at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x00004> at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0xffffffff> at System.MonoCustomAttrs.GetCustomAttributesBase (System.Reflection.ICustomAttributeProvider,System.Type) <0x00021> at System.MonoCustomAttrs.GetCustomAttributes (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x00492> at System.MonoCustomAttrs.GetCustomAttribute (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x0001c> at System.Attribute.GetCustomAttribute (System.Reflection.MemberInfo,System.Type,bool) <0x00029> at System.Attribute.GetCustomAttribute (System.Reflection.MemberInfo,System.Type) <0x00015> at Cocoa.ObjCClass.TypeForClassname (string) <0x001f2> at Cocoa.ObjCClass.TypeForIntPtr (intptr) <0x001f7> at Cocoa.Object.FromIntPtr (intptr) <0x000d3> at Cocoa.ObjCInterop.Dispatch (intptr,intptr,object[]) <0x00044> at e22ebf6d-a2b8-4115-a0d0-a9b2026f9c00.Dispatch (intptr,intptr) <0x0002c> at (wrapper native-to-managed) e22ebf6d-a2b8-4115-a0d0-a9b2026f9c00.Dispatch (intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Void_System.IntPtr_System.IntPtr.objc_msgSend (intptr,intptr) <0x00004> at (wrapper managed-to-native) System.Void_System.IntPtr_System.IntPtr.objc_msgSend (intptr,intptr) <0xffffffff> at (wrapper runtime-invoke) System.Void_System.IntPtr_System.IntPtr.runtime_invoke_void_intptr_intptr (object,intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[]) <0x00004> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[]) <0xffffffff> at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <0x000ac> at System.MonoType.InvokeMember (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Reflection.ParameterModifier[],System.Globalization.CultureInfo,string[]) <0x003b6> at System.Type.InvokeMember (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[]) <0x00029> at Cocoa.ObjCMessaging.objc_msgSend (intptr,string,System.Type) <0x002c5> at Cocoa.Application.RunApplication () <0x00029> at Cocoa.Application.Run () <0x0001b> at MethodConverter.Program.Main () <0x0001f> at (wrapper runtime-invoke) MethodConverter.Program.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> Exited with exit code: 134 From wdb at innerfuse.biz Wed Nov 28 13:42:36 2007 From: wdb at innerfuse.biz (Weyert de Boer) Date: Wed, 28 Nov 2007 19:42:36 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <000e01c831e7$901f5cc0$b05e1640$@com> References: <474DA0FB.5040405@elitedev.com> <29D6CF7B-DE1E-4C03-84C2-E42FB9DF3BFF@web.de> <000e01c831e7$901f5cc0$b05e1640$@com> Message-ID: <474DB69C.6020207@innerfuse.biz> Curious, how do you guys compile mono under MacOSX? The mono package that comes with macports doesn't work for me. Yours, Weyert de Boe From mh at remobjects.com Thu Nov 29 05:15:24 2007 From: mh at remobjects.com (marc hoffman) Date: Thu, 29 Nov 2007 11:15:24 +0100 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: References: <474DC79C.6050507@elitedev.com> Message-ID: <1CF6B49D2CC77C4DA467EDFA84E3E3E429FB35@lucien.dwarfland.elitedev.com> Andreas, > A better solution is to remove Mach.cs completely (if it still does > what it did) because a native version of that code is now part of the > Mono runtime. Ah, that explains why there was code in SVN that didn't compile. ;) From lscoughlin at mac.com Thu Nov 29 10:48:13 2007 From: lscoughlin at mac.com (Liam Coughlin) Date: Thu, 29 Nov 2007 10:48:13 -0500 Subject: [Cocoa-sharp] [Mono-osx] Suggested Enhancement for Cocoa.String In-Reply-To: <6B5F8A10-304F-497E-B537-CA6006BE34E2@web.de> References: <000e01c831e7$901f5cc0$b05e1640$@com> <007BA8FA-1A37-406A-BAF0-E9413259CB66@web.de> <001801c83280$88e30080$9aa90180$@com> <6B5F8A10-304F-497E-B537-CA6006BE34E2@web.de> Message-ID: You know what would _REALLY_ help cocoa-sharp!? A debugger! *raspberries* XD On Nov 29, 2007, at 8:36 AM, Andreas F?rber wrote: > > Am 29.11.2007 um 13:08 schrieb marc hoffman: > >> Andreas >> >>> Well, the MonoDevelop list wasn't listed there either last time I >>> checked. >> >>> If as you say it lists such another group, you might want to try >>> posting there; >> >> Well; i've posted to said list a few times in the past, it's >> basically a big >> /dev/null. >> >>> that does still not imply that mono-osx is the most >>> suitable place. >> >> Given that even Geoff just told me he wasn't even aware of a separate >> cocoa-sharp list, i'd say that imho mono-osx comes pretty close to >> being the >> suitable place, as of now ;) > > You will find Geoff has posted there many times himself. :) > > Andreas > _______________________________________________ > Mono-osx mailing list > Mono-osx at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-osx