[EMAIL PROTECTED] ObjC app calling Mono library

[Duane Wandless]

Hello all... this project looks very promising.  I am trying to write a C#
library that will be called from an existing ObjC application.  I had found
this web page:http://www.mono-project.com/ObjCSharp

Which this seems to be going down the path I want, however it has not been
updated in 2 years.

I have some common code that needs to run between Mac and Windows.  But the
UI can be in true native.  All of the examples for monoobjc seem to be the
C# app runs and has the ability to handle the NIB.  What I want is an ObjC
app that runs and can invoke my C# library.

Can anyone point me in the right direction?

Thanks.

[EMAIL PROTECTED] embedding mono libraries issue

[Duane Wandless]

First I am very pleased with the integration monobjc provides.  Excellent
work.

I have an issue where I am trying to build a no-mono version of my
application.  Everything seems to work, all the correct libraries are
embedded and copied in.  I have this very simple test case below.  Note the
NNN in the URL.  I use build.sh -build.  I then move Mono.framework out of
the way.  Then when I run my application this error is printed:
http://www.yahoo.com/nnn

Yes lowercase nnn... and that is the complete error.  No innerexception, no
other text.  Now if I move Mono.framework back the application runs as
expected.

Any help will be greatly appreciated.  We very much want to utilize the
embedded application so we can avoid a full install of Mono.

Thanks,
Duane

using Monobjc;
using Monobjc.Cocoa;
using System;
using System.Net;
public static void Main()
{
   string xmlAddress = "http://www.yahoo.com/NNN";;
   try
   {
  HttpWebRequest httpReq = WebRequest.Create(xmlAddress)
as HttpWebRequest;
   }
   catch (Exception err)
   {
  Console.WriteLine(err.Message);
   }

   // Load the Frameworks
   ObjectiveCRuntime.LoadFramework("Cocoa");
.

[EMAIL PROTECTED] calling native Cocoa code

[Duane Wandless]

Hello again... I have a new issue.  Is it possible to include native Cocoa
code in the bundle?  I would like to have a Cocoa objective-C class that is
hooked up to the same XIB that my C# class is hooked up to.  Different
elements but within the same XIB.  ideally I'd have the NSTabViewItem
handled by an objective-C class and an NSArrayController that is handled by
a C# class.

Is that possible?

Thanks,
Duane

[EMAIL PROTECTED] error running PDFKitViewer example

[Duane Wandless]

The document "PDFKitViewer.exe" could not be opened.  PDFKitViewer cannot
open file in the "EXE File" format.



I receive this popup message when I run the PDFKitViewer from the samples
directory.  I get the same error from my own executable.The Info.plist
is essentially the problem but I do not see how to make the message go
away.  Below is the Info.plist from PDFKitViewer.

thanks,
Duane




http://www.apple.com/DTDs/PropertyList-1.0.dtd";>

  
CFBundleDevelopmentRegion
English
CFBundleDocumentTypes

  
CFBundleTypeExtensions

  pdf
  PDF

CFBundleTypeMIMETypes

  application/pdf

CFBundleTypeName
DocumentType
CFBundleTypeOSTypes

  PDF 

CFBundleTypeRole
Viewer
NSDocumentClass
MyPDFDocument
  

CFBundleExecutable
PDFKitViewer
CFBundleIconFile
Monobjc
CFBundleIdentifier
net.monobjc.samples.PDFKitViewer
CFBundleInfoDictionaryVersion
6.0
CFBundleName
PDFKitViewer
CFBundlePackageType
APPL
CFBundleSignature

CFBundleVersion
1.0
NSMainNibFile
MainMenu
NSPrincipalClass
NSApplication
  

Re: [EMAIL PROTECTED] error running PDFKitViewer example

[Duane Wandless]

Thanks for the update.  I did not need to use the NSDocument nib in the
info.plist.  I reverted back to the simpler setup and everything works great
that way.

Duane

On Wed, Sep 17, 2008 at 9:55 AM, Laurent Etiemble <
[EMAIL PROTECTED]> wrote:

> Hello,
>
> This is a known bug related to the way Mono parse the command line.
>
> I posted a workaround some times ago :
> http://www.mail-archive.com/users@lists.monobjc.net/msg00046.html . Let me
> know if it works for you.
>
> Regards, Laurent Etiemble.
>
> 2008/9/17 Monobjc Support <[EMAIL PROTECTED]>
>
>> Hello,
>>
>> This is a known bug related to the way Mono parse the command line.
>>
>> I posted a workaround some times ago :
>> http://www.mail-archive.com/users@lists.monobjc.net/msg00046.html . Let
>> me know if it works for you.
>>
>> Regards, Laurent Etiemble.
>>
>> 2008/9/17 Duane Wandless <[EMAIL PROTECTED]>
>>
>> The document "PDFKitViewer.exe" could not be opened.  PDFKitViewer cannot
>>> open file in the "EXE File" format.
>>>
>>>
>>>
>>> I receive this popup message when I run the PDFKitViewer from the samples
>>> directory.  I get the same error from my own executable.The Info.plist
>>> is essentially the problem but I do not see how to make the message go
>>> away.  Below is the Info.plist from PDFKitViewer.
>>>
>>> thanks,
>>> Duane
>>>
>>>
>>>
>>> 
>>> >> http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
>>> 
>>>   
>>> CFBundleDevelopmentRegion
>>> English
>>> CFBundleDocumentTypes
>>> 
>>>   
>>> CFBundleTypeExtensions
>>> 
>>>   pdf
>>>   PDF
>>> 
>>> CFBundleTypeMIMETypes
>>> 
>>>   application/pdf
>>> 
>>> CFBundleTypeName
>>> DocumentType
>>> CFBundleTypeOSTypes
>>> 
>>>   PDF 
>>> 
>>> CFBundleTypeRole
>>> Viewer
>>> NSDocumentClass
>>> MyPDFDocument
>>>   
>>> 
>>> CFBundleExecutable
>>> PDFKitViewer
>>> CFBundleIconFile
>>> Monobjc
>>> CFBundleIdentifier
>>> net.monobjc.samples.PDFKitViewer
>>> CFBundleInfoDictionaryVersion
>>> 6.0
>>> CFBundleName
>>> PDFKitViewer
>>> CFBundlePackageType
>>> APPL
>>> CFBundleSignature
>>> 
>>> CFBundleVersion
>>> 1.0
>>> NSMainNibFile
>>> MainMenu
>>> NSPrincipalClass
>>> NSApplication
>>>   
>>> 
>>>
>>>
>>
>

Re: [EMAIL PROTECTED] How to listen for notifications (NSDistributedNotificationCenter) ?

[Duane Wandless]

Hopefully this will help you.  Sorry for the bad formatting... trying out
Opera.

  [ObjectiveCMessage("init")]
  public override Id Init()
  {

  ObjectiveCRuntime.SendMessageSuper(this, ControllerClass,
"init");

NSNotificationCenter.DefaultCenter.AddObserverSelectorNameObject(this,
ObjectiveCRuntime.Selector("doAuth:"), "doAuth", null);

  return this;

  }


  [ObjectiveCMessage("doAuth:")]
  public void SelectionChanged(NSNotification notification)
  {
  NSArray loginParms = notification.UserInfo.ObjectForKey(new
NSString("params")).CastTo();
  Session.DoAuthenticate(loginParms[0].CastTo(),
loginParms[1].CastTo());
  }

In the .m:

  NSString *username = [usernameTextField stringValue];
  NSString *password = [passwordTextField stringValue];

  NSArray *loginParams = [NSArray arrayWithObjects:username, password, nil];
  NSDictionary* dict = [NSDictionary dictionaryWithObject:loginParams
forKey:@"params"];
  NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
  [nc postNotificationName:@"doAuth" object:nil userInfo:dict];


Duane

On Thu, Oct 9, 2008 at 9:22 AM, Miguel De Buf <[EMAIL PROTECTED]>wrote:

>  Hi,
>
> I am trying to use NSDistributedNotificationCenter to send a notification
> to a listener application.  I am stuck since I do not know what to pass to
> the AddObserverSelectorNameObject() function. I could not find an example or
> more info on how to use this function.  Here is my code (which fails to
> compile) :
>
> using System;
> using System.Collections.Generic;
> using System.Text;
>
> using Monobjc;
> using Monobjc.Cocoa;
>
> namespace ipc_listener
> {
> class Program : NSObject
> {
> private static Listener l = null;
>
> static void Main(string[] args)
> {
> ObjectiveCRuntime.LoadFramework("Cocoa");
> ObjectiveCRuntime.Initialize();
> NSApplication.Initialize();
>
> l = new Listener();
> l.run();
>
> NSApplication.RunApplication();
> }
> }
>
> class Listener : NSObject
> {
> private NSNotificationCenter nc = null;
> private delegate void NotificationHandler(NSNotification n);
>
> public void run()
> {
> nc = NSDistributedNotificationCenter.DefaultCenter;
> NotificationHandler h = handler;
>
> nc.AddObserverSelectorNameObject((Id)this, h, (NSString)null,
> (Id)null);
> }
>
> void handler(NSNotification n)
> {
> Console.WriteLine("name=" + n.Name);
> }
> }
> }
>
>
> What fails is the nc.AddObserverSelectorNameObject() call, since the
> delegate h cannot be converted to an IntPtr.  I have no idea what that
> IntPtr actially represents.  I am sorry if this is a simple question, but I
> am very new to MacOSX programming and Cocoa, and do not know ObjC at all.
>
> Many thanks,
> Miguel
>
> --
>
>
>  *Miguel De Buf*
> Chief Technology Officer
> Aventiv NV, creators of NomaDesk(R) 
> Tel. +32 9 233 68 86 (*Belgium*)
> Fax +32 9 240 10 39 (*Belgium*)
> [EMAIL PROTECTED]
>
> Confidentiality Notice:
> *This message, together with any attachments, is intended only for the use
> of the individual or entity to which it is addressed. It may contain
> information that is confidential and prohibited from disclosure. If you are
> not the intended recipient, you are hereby notified that any dissemination
> or copying of this message or any attachment is strictly prohibited. If you
> have received this item in error, please notify the original sender and
> destroy this item, along with any attachments.*
>
>
>

Re: [EMAIL PROTECTED] Data binding

[Duane Wandless]

Not knowing what you have accomplished already I will briefly describe what
I have done.  When I find time I'll post something with pictures.  My main
application is a Cocoa ObjC app that controls the GUI.  When the app starts
the very first thing I do is load my C# EXE, note not a DLL.  A bug/issue
exists that loading a DLL does not completely init the mono environment.

Using Monobjc I export my C# classes to the Cocoa world.  This is why the
mono executable must be properly initialized first, so that when the NIB
files are loaded by Cocoa it will find my registered mono classes.

In the NIB file I add an NSObject and set the class to be the name of my C#
class, say MonoObject.  Add some class outlets to the MonoObject in the NIB
file that point to array/tree controllers within that NIB file.  The tree
controller's mode should be class and the class name most likely will be
NSMutableDictionary, though it can be a class defined in mono as well.  You
can add keys to these controllers to make binding easier on the table
views.  Speaking of the table views, you simply point them to the tree
controller and bind as usual.

Back in your C# class you will have a NSTreeController variable that is
hooked up by monobjc to the tree controller in the NIB file.  Whenver
appropriate you can, from within C#, clear the tree controller data, add
data, remove data etc.  I call something like
treeController.addObject() where myobject is an instance of a C#
class.  That class then must register the methods to expose the keys you
have setup in the tree controller.

You most likely will need to send a reload data notification to the views
that use these tree controllers.  So you should also set class outlets that
point to these views so that you can send them reload data messages.
PostNotification is a nice way to send messages to your mono class so that
it can load the data as needed.

Another solution is to set your table view's/outline view's datasource to be
MonoObject.  Just provide the datasource methods in your C# class.  I have
not implemented this way but I think I'm leaning toward switching.

Not a lot of detail here but hopefully it helps.
Duane

On Fri, Nov 21, 2008 at 9:44 AM, Mario De Clippeleir <[EMAIL PROTECTED]>wrote:

>  Hi,
>
>
>
> I am trying monobjc to port an existing .NET application to the Mac. I
> would like to use a DLL in which an object model resides. When loading a
> file, the object model is being filled. This logic is all in the library.
>
> Now, my question is : if I want to use binding for the Mac gui, do I need
> the "wrap" the object classes from the library into Managed object classes ?
> What would be the best way to handle this ?
>
>
>
> On another note : In the latest monobjc distribution, I can't seem to get
> the TwoManyControllers project working. "The document TwoManyControllers.exe
> could not be opened. TwoManyControllers cannot open files in the EXE File
> format."
>
> I mean, it loads up, but you can't do anything…
>
> Does anyone else has this problem ?
>
>
>
> Thanks,
>
>
>
> Mario
>

Re: [EMAIL PROTECTED] Data binding

[Duane Wandless]

No problem.  The DLL vs EXE is mostly just a compiling change.  Rather than
compile as a DLL compile it as an executable for use on the Mac.  I have a
small static void Main() in my EXE that inits the monobjc framework.  Yes a
console app would work, though it will not run from the console, only from
within the cocoa app.

Yes you can use Core Data, though I have been advised not to use Core Data.
In fact the advice was to use the datasource solution.  So yes the table
view will ask the mono layer for every row and every column.  I have not
tested this for performance.  And yes you can populate the core data
entities from within mono and it should show up in the UI... haven't tried
it myself.

NSNotificationCenter has a few methods to post notifications, you can
observe for notifications within mono as well as send.

It does seem odd to revert back to using the datasouce method essentially
not using the advances of bindings and core data.  But the theory is this
will greatly reduce the amount of code.  I have not verified performance of
the datasouce method.  As is right now I populate the tree controllers
manually from within C#, which works.  Though now I'm trying to use mutiple
NIBs and my current approach is causing problems in splitting the NIBs.

Duane

On Fri, Nov 21, 2008 at 11:34 AM, Mario De Clippeleir <[EMAIL PROTECTED]>wrote:

>  Thanks a lot Duane !
>
>
>
> Couple of questions though :
>
> -  The reason I want to work with the DLL is because I include
> this in another Windows Forms project, which has the Windows Gui. Should I
> compile it then to a Console application ?
>
> -  The way you explained it, is that you have to populate
> everything yourself.. is it possible to use the Core Data Framework ?
>
> -  (perhaps silly question : what do you mean by
> "PostNotification" ?)
>
> -  If you embed the datasource methods in the c# class, isn't that
> like polluting the model with View methods ?
>
>
>
> Thanks for helping me out !
>
>
>
> Mario
>
>
>
> *From:* Duane Wandless [mailto:[EMAIL PROTECTED]
> *Sent:* vrijdag 21 november 2008 16:51
> *To:* users@lists.monobjc.net
> *Subject:* Re: [EMAIL PROTECTED] Data binding
>
>
>
> Not knowing what you have accomplished already I will briefly describe what
> I have done.  When I find time I'll post something with pictures.  My main
> application is a Cocoa ObjC app that controls the GUI.  When the app starts
> the very first thing I do is load my C# EXE, note not a DLL.  A bug/issue
> exists that loading a DLL does not completely init the mono environment.
>
> Using Monobjc I export my C# classes to the Cocoa world.  This is why the
> mono executable must be properly initialized first, so that when the NIB
> files are loaded by Cocoa it will find my registered mono classes.
>
> In the NIB file I add an NSObject and set the class to be the name of my C#
> class, say MonoObject.  Add some class outlets to the MonoObject in the NIB
> file that point to array/tree controllers within that NIB file.  The tree
> controller's mode should be class and the class name most likely will be
> NSMutableDictionary, though it can be a class defined in mono as well.  You
> can add keys to these controllers to make binding easier on the table
> views.  Speaking of the table views, you simply point them to the tree
> controller and bind as usual.
>
> Back in your C# class you will have a NSTreeController variable that is
> hooked up by monobjc to the tree controller in the NIB file.  Whenver
> appropriate you can, from within C#, clear the tree controller data, add
> data, remove data etc.  I call something like
> treeController.addObject() where myobject is an instance of a C#
> class.  That class then must register the methods to expose the keys you
> have setup in the tree controller.
>
> You most likely will need to send a reload data notification to the views
> that use these tree controllers.  So you should also set class outlets that
> point to these views so that you can send them reload data messages.
> PostNotification is a nice way to send messages to your mono class so that
> it can load the data as needed.
>
> Another solution is to set your table view's/outline view's datasource to
> be MonoObject.  Just provide the datasource methods in your C# class.  I
> have not implemented this way but I think I'm leaning toward switching.
>
> Not a lot of detail here but hopefully it helps.
> Duane
>
> On Fri, Nov 21, 2008 at 9:44 AM, Mario De Clippeleir <[EMAIL PROTECTED]>
> wrote:
>
> Hi,
>
>
>
> I am trying monobjc to port an existing .NET application to the Mac. I
> would like to use a DLL in which an object model resi

Re: [us...@lists.monobjc.net] Issues with NSObject.dealloc and NSProxy.dealloc (perhaps dealloc wrappers in general)

[Duane Wandless]

Hard to say without seeing the code.  Are you using the Cocoa garbage
collector?  This will have odd issues unless you ensure the ref count is set
correctly.  I use a GC enabled Cocoa app to embed my mono library... I had
lots of random crashes (impossible to trace as the crash report was
misleading) until I added my mono created objects to a Cocoa container so
the GC would not come along and destroy them.
Best of luck.

On Tue, Dec 23, 2008 at 11:43 AM, yoni shalom  wrote:

> I have an application that uses monobjc, embedded under a Cocoa app.
> I have witnessed various timing/threading issues (.net exceptions, SIGSEGV
> | EXC_BAD_ACCESS signals etc) with variouse stacks, for example :
>
> [NSRunloop run]//beginning
> ... //some framework code
> ...
> [NSDistantObject dealloc]
> ??
> ??   //.net JIT compiled function addresses - the .net
> wrappers for NSObject dealloc, or NSProxy dealloc
> ??
> [NSProxy isKindOfClass]
> ...   //some native forwarding...
> ...
> [SIGSEGV handler / native exception handler]
>
> I'm attaching a real example at the end of this post.
> some facts :
>
> 1. The object for which the wrapper-dealloc is called on is NOT A .Net
> monobjc NSObject !  Are all objective-c native objects becoming "wrapped"
> just because we are using Monobjc ?
> 2. If the answer to the previous question is Yes (as it seems from my
> debugging session), I personally see it as a major flaw - bugs in monobjc
> shouldn't affect objects which the developer never intended to instanciate
> .Net managed wrappers for.
>
> 3. The code in the dealloc wrapper causes induces the use of Monitor.Enter,
> which in some occasions causes deadlocks (couldn't figure out why, didn't
> bother on debugging)
> 4. The code in the dealloc wrapper may run AFTER the native ptr is no
> longer valid for some reason, causing the native call to [self dealloc] to
> crash and burn with all kinds of nasty signals and shit.
>
> Removing the function "dealloc" in NSObject and NSProxy wrappers problems
> I've been trying to solve for two days.
> This, again, despite the fact that the objects causing the problem in the
> stack are not .net instances related to my managed embedded stack!, they are
> just regular, native, objective-c objects!
>
>
> A real example (crash report), in which u see WebKit (WebView embedded in
> my app) trying to release an object (note the command on line 10):
>
> Thread 0 Crashed:
> 0   libSystem.B.dylib  0x96f45b9e __kill + 10
> 1   libSystem.B.dylib  0x96fbcec2 raise + 26
> 2   libSystem.B.dylib  0x96fcc47f abort + 73
> 3   libmono.0.0.0.dylib0x0078e999 mono_handle_native_sigsegv +
> 215 (mini-exceptions.c:1366)
> 4   libmono.0.0.0.dylib0x00730ece sigsegv_signal_handler + 226
> (mini.c:13441)
> 5   libSystem.B.dylib  0x96f4409b _sigtramp + 43
> 6   ???0x 0 + 4294967295
> 7   com.apple.CoreFoundation   0x921156bd ___forwarding___ + 237
> 8   com.apple.CoreFoundation   0x92115a12 _CF_forwarding_prep_0 + 50
> 9   com.apple.Foundation   0x937485a0 -[NSProxy isKindOfClass:] +
> 160
> 10  ???0x0304d567 0 + 50648423// >
> somewhere along the ?? functions is Monobjc, trying to execute the managed
> wrapper function NSProxy.Dealloc()!
> 11  ???0x16d00436 0 + 382731318
> 12  ???0x16d0021e 0 + 382730782
> 13  ???0x16d001ac 0 + 382730668
> 14  ???0x02ad0bfa 0 + 44895226
> 15  com.apple.Foundation   0x93708695 -[NSDistantObject dealloc] +
> 117
> 16  com.apple.CoreFoundation   0x9202c823 CFBagApplyFunction + 131
> 17  com.apple.Foundation   0x93748094 invalidateConnection + 596
> 18  com.apple.Foundation   0x93747815 -[NSConnection invalidate] +
> 613
> 19  com.apple.Foundation   0x93740238 +[NSConnection
> _portInvalidated:] + 712
> 20  com.apple.Foundation   0x936c91da _nsnote_callback + 106
> 21  com.apple.CoreFoundation   0x92077aba __CFXNotificationPost + 362
> 22  com.apple.CoreFoundation   0x92077d93
> _CFXNotificationPostNotification + 179
> 23  com.apple.Foundation   0x936c6440 -[NSNotificationCenter
> postNotificationName:object:userInfo:] + 128
> 24  com.apple.Foundation   0x93711c7a _NSPortDeathNotify + 106
> 25  com.apple.CoreFoundation   0x920723eb CFMachPortInvalidate + 219
> 26  com.apple.CoreFoundation   0x92072de6 __CFNotifyDeadMachPort + 294
> 27  com.apple.CoreFoundation   0x92072635 __CFMachPortPerform + 117
> 28  com.apple.CoreFoundation   0x92096908 CFRunLoopRunSpecific + 3896
> 29  com.apple.CoreFoundation   0x92096cf8 CFRunLoopRunInMode + 88
> 30  com.apple.Foundation   0x93750ef0 -[NSConcreteTask
> waitUntilExit] + 128
> 31  com.myapp.plugin  0x17207c79 -[plu

Re: [us...@lists.monobjc.net] How to use Monobjc in Visual Studio or Monodevelop

[Duane Wandless]

It has been a few months since I used MonoObjc... but back then I developed
in VM using Visual Studio... just compile use intellisense, etc..  Then
would run a NANT script in OSX to actually run the app.

I have not tried monovs but sounds interesting.

Duane

On Fri, Sep 18, 2009 at 2:02 PM, Matthias Fuchs wrote:

> Is there a possibility to create some kind of "post compile script" to
> create the bundle?
>
> I though about coding in SharpDevelop (in a VM) and use the NANT plugin to
> create the bundle. Though there would still be no debugging support, at
> least coding would be much more comfortable.
>
> Btw, did you guys hear of monovs (Mono Tools for Visual Studio,
> http://go-mono.com/monovs/)? With this plugin it's possible to use Visual
> Studio for building Mono apps. There is even a remote debugger included,
> that allows to start and debug mono apps, that run inside a VM with linux. I
> already tried it and it works quite well.
> Maybe someday in the future this will also be possible to use with Mac OS
> X.
>
> br, matthias
>
> Am 18.09.09 18:14, schrieb Russell Joyce:
>
>  I personally use MonoDevelop to write code and the terminal (using nant)
>> to compile and run, this way you get the advantages of code completion and
>> basic syntax checking from MonoDevelop (as long as the Monobjc libraries are
>> added as references in the project) and can still compile to a bundle.
>> However, you don't get the debugging support of MonoDevelop which would be
>> very useful (trying to debug in MonoDevelop just produces a "Cannot find
>> nib" error).
>>
>
>

[us...@lists.monobjc.net] external reference to a class

[Duane Wandless]

Hopefully someone can help with this.

I am currently doing this.

id myobj = objc_getClass("MyMonoClass");
[myobj testTouch];

which works.  MyMonoClass is not defined so I cannot do this:
[MyMonoClass testTouch];

Because the compiler tries to resolve the class reference, of course.

Is there a better way to do this than what I have?  Which I got the idea of
how to do this from Monobjc!

The context is that I have a Cocoa application that loads the mono runtime
which loads my Monobjc enabled library.  Which that is where MyMonoClass is
defined.  Then I need to invoke a method on the mono class from Cocoa.

Thanks,
Duane

Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard

[Duane Wandless]

I can confirm as well that Laurent's patch fixes the issue seen in my
application.   And thank you very much for making the 2.6_M patch.

To get mkbundle to work I edited
/Library/Frameworks/Mono.framework/Versions/2.6_M/etc/mono/config to have
this line:


adding the full path allowed mkbundle to work.

Duane

On Sat, Oct 24, 2009 at 2:02 AM, Anthony Bowker  wrote:

>  I second that.  Thank you Laurent and Sledge for your hard work thus far.
>
>
>
> I've been following the e-mail exchange and the direction of your solution
> seems sound.  I haven't built Mono myself at present, but I've tested the
> 2.6_M patch and my app then works well on SL - had it running today for over
> 4 hours without a problem.
>
>
>
> Likewise, if there are updated binaries to test I'd be happy to help.
>
>
>
> Many Thanks!
>
> Anthony
>
>
>
> *From:* Franky De Meyer [mailto:f...@eazign.be]
> *Sent:* Tuesday, October 20, 2009 1:08 PM
>
> *To:* users@lists.monobjc.net
> *Subject:* RE: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net]
> Feeback Wanted on Snow Leopard
>
>
>
> A big thanks to Laurent and Sledge for all the hard work in debugging this
> pesky problem! It is really greatly appreciated...
>
>
>
> Laurent, I have installed your patched Mono on my Snow Leopard system, and
> can confirm that my software appears to work smoothly now! Great job!
>
> I know the patch will not be the final fix, but in any case it shows that
> you guys have a good grip on what exactly goes wrong.
>
>
>
> If you want any more or different tests, let me know.
>
>
>
> Thanks once more!
>
> Franky
>
>
>
>
>
>
>
> *From:* laurent.etiem...@gmail.com [mailto:laurent.etiem...@gmail.com] *On
> Behalf Of *Laurent Etiemble
> *Sent:* maandag 19 oktober 2009 11:41
> *To:* users@lists.monobjc.net
> *Subject:* Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net]
> Feeback Wanted on Snow Leopard
>
>
>
> Hello,
>
>
>
> I have built a variant of the Mono framework on Snow Leopard with an
> improved patch for bug 
> #537764.
> For those who are interested, you can:
>
> - install an official version of Mono to get all the soft links in place
>
> - download the archive:
> http://build.monobjc.net/binaries/Mono.framework.2.6_M.tar.bz2
>
> - unarchive it under /Library/Frameworks/Mono.framework/Versions
>
> - relink the current version to the new one (sudo rm Current && sudo ln -s
> 2.6_M Current)
>
>
>
> Beware that:
>
> - The archive only contains a small subset of the Mono framework (Mono +
> NAnt)
>
> - You should be able to package and run Monobjc's applications
>
> - It does not contains all the third-party assemblies or the GTK parts.
>
> - It will probably only work on Snow Leopard
>
>
>
> My goal is to know if the patch is robust enough to be pushed to Mono team.
>
>
>
> Regards, Laurent Etiemble.
>
>
>
> 2009/10/12 Franky De Meyer 
>
> Thanks for the extra tips Kenny, but I must admit I've now given up on
> trying to build Mono on Snow Leopard myself.
> This seems like a rather specialized matter, and requires more insight in
> the Mono build process (+ related Linux tools) than I can handle.
>
> I noticed the new installer for OSX today (on mono-project), version
> 2.4.2.3_6, so I was anxious to try it out on the SimpleCocoaApp on Snow
> Leopard, but unfortunately it still crashes, so it looks like the proposed
> patch is not in it yet...
>
> This is all quite depressing. Just as I was finally getting ready to
> release
> my app for OSX, it turns out that many of the potential users have already
> upgraded to Snow Leopard, so it's back to zero now. Sometimes I wonder
> whether I shouldn't have just taken the plunge and should have ported the
> entire app to XCode. Of course that would mean that none of my code would
> have been shared between Windows and Mac, while with the mono/monobjc
> solution I can have 70% common code.
>
> In any case, thanks again to Laurent for the great work and trying to help
> us out with this Mono problem. And thanks to you Kenny, for your efforts
> and
> guidance.
> Let's hope we can soon join the Snow Leopard gang ...
>
> Franky
>
>
>
>
> -Original Message-
> From: Kenny Clement [mailto:psyki...@gmail.com]
>
> Sent: vrijdag 2 oktober 2009 15:23
> To: users@lists.monobjc.net
> Subject: Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net]
> Feeback
> Wanted on Snow Leopard
>
> Franky,
>
> For glib, I'm using the following:
>
> CC="cc -L/Users/fdm/Mono/lib" CFLAGS="-I/Users/fdm/Mono/include -m32"
> PATH=/Users/fdm/Mono/bin:$PATH ./configure --prefix=/Users/fdm/Mono
>
> sorry, I forgot that CC and extra CFLAGS in my previous mail.
> When I got your gettext error, it was because my mono prefix was not in
> the path, however, you say it is.
>
> I also did an upgrade from leopard to Snow.
>
> My application is now working without crashes, however, on a certain
> window in my app, CPU spikes to 100% whenever something on the form is
> changed.
> 

[us...@lists.monobjc.net] NSManagedObject

[Duane Wandless]

Has anyone used NSMangedObjects and NSManagedObjectModel with monobjc.

My limited understanding of NSMangedObjects is that when I subclass from
NSManagedObjects and create an entity the object model should correctly call
the accessors on the subclass.  But this does not happen for me.

Any guidance would be very helpful!
Thanks,
Duane

[us...@lists.monobjc.net] Re: [de...@lists.monobjc.net] Snow Leopard support: call for testing

[Duane Wandless]

Initial testing of the new Monobjc DLLs on Snow Leopard did NOT work for me.

I moved the /Library/Frameworks/Mono.Framework/Versions/2.6_M directory out
of the way so it could not be referenced.  I ran my app first and received
this error:
Monobjc.ObjectiveCException: The 'libmonobjc.2.dylib' library was not found.

I then placed the dylib in the correct location.  This verified to me that I
was using the correct version of the Monobjc DLLs.  Then running my app I
still received a thread_get_state failure after a few minutes of running.

crash report
http://pastebin.com/m65fa182f

Switching back to using the 2.6_M mono install the thread issue did not
occur.

Thanks for your continued efforts.
Duane



On Wed, Nov 11, 2009 at 1:33 PM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> I have finally come to a solution regarding the Snow Leopard support:
> I have introduced a native library into the bridge to avoid the
> reported crash on Mac OS X 10.6 [1]. After reviewing all the
> feebacks[2][3], I came to the conclusion that a native library was the
> only solution to:
> - avoid the native/managed cross-calls when a thread exists and
> dealloc its exit notification
> - avoid the Mono runtime hacking (the Mono team is not really for it)
>
> The preview of the new release of the bridge is available for
> download: http://downloads.monobjc.net/Monobjc-2.0.436.0.tar.gz
>
> Here are some noticeable points:
> - the bridge now requires two shared libraries: libmonobjc.1.dylib and
> libmonobjc.2.dylib (They are used for each version of the Objective-C
> runtime). You have to put them in the MacOS folder of the application
> bundle. Refer to the samples applications to see how you can simply do
> that.
> - the dealloc method is no more overriden. When using this version,
> you will see a bunch of errors related to that. A search and replace
> should do the trick.
> - I saw some crashes on PowerPC G4 machines with Mono 2.6. Please use
> Mono 2.4 as it is known to work ok.
> - I think there are still some hidden issues (performance, optimization,
> etc).
>
> Can you please provide feedback on:
> - the platform you are testing on (OS and Processor)
> - the Mono version you are testing with
> - the kind of application you are testing
> - the result (work or crash)
>
> Thank you to everybody who has helped, and happy testing.
>
> Regards, Laurent Etiemble.
>
> [1] https://bugzilla.novell.com/show_bug.cgi?id=537764
> [2] http://www.mail-archive.com/users@lists.monobjc.net/msg00251.html
> [3] http://www.mail-archive.com/users@lists.monobjc.net/msg00286.html
>

[us...@lists.monobjc.net] NSURLConnection

[Duane Wandless]

I'm trying to use NSURLConnection, mainly to take advantage of Apple's built
in proxy detection.  However I cannot get the delegate to work.

Any help in getting NSURLConnection to work would be greatly appreciated.

NSURLConnection.Class.cs defines:
public virtual Id Delegate
{
get { return ObjectiveCRuntime.SendMessage(this,
"delegate"); }
set { ObjectiveCRuntime.SendMessage(this, "setDelegate:",
value); }
}

However there is no "delegate" selector defined on NSURLConnection so
SetDelegate fails with:
2009-11-14 10:50:12.468 SimplePrototype[1356:5e03] -[NSURLConnection
delegate]: unrecognized selector sent to instance 0x6d3b20

Also if I try:
NSURLConnection.NSURLConnectionEventDispatcher d =  new
NSURLConnection.NSURLConnectionEventDispatcher();
d.ConnectionDidFailWithError += new
NSURLConnection.ConnectionDidFailWithErrorEventHandler(d_ConnectionDidFailWithError);
d.ConnectionDidFinishLoading += new
NSURLConnection.ConnectionDidFinishLoadingEventHandler(d_ConnectionDidFinishLoading);
d.ConnectionDidReceiveData += new
NSURLConnection.ConnectionDidReceiveDataEventHandler(d_ConnectionDidReceiveData);
d.ConnectionDidReceiveResponse += new
NSURLConnection.ConnectionDidReceiveResponseEventHandler(d_ConnectionDidReceiveResponse);
NSURLConnection conn = new NSURLConnection(req, d);

none of the callbacks are invoked.  I also tried creating a class that
defined:
[ObjectiveCMessage("connection:didReceiveResponse:")]
public void didReceiveResponse(NSURLConnection conn, NSURLResponse
resp)

but that failed to receive a response either.  I also tried creating the
connection with start immediately false and then calling start, again
without success.

Thanks,
Duane

[us...@lists.monobjc.net] Re: NSURLConnection

[Duane Wandless]

Some more info.  I am on Snow Leopard but get the same results on Leopard.
I took the code from NSURLConnection.SetDelegate() and moved it into my code
like this:

Action
assignment =
(d =>
{
d.ConnectionDidCancelAuthenticationChallenge += new
NSURLConnection.ConnectionDidCancelAuthenticationChallengeEventHandler(d_ConnectionDidCancelAuthenticationChallenge);
d.ConnectionDidFailWithError += new
NSURLConnection.ConnectionDidFailWithErrorEventHandler(d_ConnectionDidFailWithError);
d.ConnectionDidFinishLoading += new
NSURLConnection.ConnectionDidFinishLoadingEventHandler(d_ConnectionDidFinishLoading);
d.ConnectionDidReceiveAuthenticationChallenge += new
NSURLConnection.ConnectionDidReceiveAuthenticationChallengeEventHandler(d_ConnectionDidReceiveAuthenticationChallenge);
d.ConnectionDidReceiveData += new
NSURLConnection.ConnectionDidReceiveDataEventHandler(d_ConnectionDidReceiveData);
d.ConnectionDidReceiveResponse += new
NSURLConnection.ConnectionDidReceiveResponseEventHandler(d_ConnectionDidReceiveResponse);
d.ConnectionWillCacheResponse += new
NSURLConnection.ConnectionWillCacheResponseEventHandler(d_ConnectionWillCacheResponse);
d.ConnectionWillSendRequestRedirectResponse += new
NSURLConnection.ConnectionWillSendRequestRedirectResponseEventHandler(d_ConnectionWillSendRequestRedirectResponse);
d.ConnectionDidSendBodyData += new
NSURLConnection.ConnectionDidSendBodyDataTotalBytesWrittenTotalBytesExpectedToWriteEventHandler(d_ConnectionDidSendBodyData);
});
NSURLConnection.NSURLConnectionEventDispatcher @delegate =
new NSURLConnection.NSURLConnectionEventDispatcher();
assignment(@delegate);
NSURLConnection conn = new NSURLConnection(req, @delegate);

Also added some logging to
NSURLConnectionEventDispatcher.RespondsToSelector() and I do see in the log
some requests to see if my delegate responds to:
selector
connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:
selector connection:canAuthenticateAgainstProtectionSpace:
selector connection:needNewBodyStream:

But only these 3.  I added the ConnectionDidSendBodyData event, which is
also not called.  I did do the same code in obj-c and the same 3 selectors
are checked plus a few extra.  And the didSendBodyData selectors is called
in obj-c.

Because of the logging I know that the @delegate is being inspected by
NSURLConnection.  But after those 3 no selectors are called on
NSURLConnectionEventDispatcher.  I even tried just returning true to
respondsToSelector hoping to raise an error, but that did not.

Any help would be greatly appreciated.

Duane

On Sat, Nov 14, 2009 at 11:09 AM, Duane Wandless  wrote:

> I'm trying to use NSURLConnection, mainly to take advantage of Apple's
> built in proxy detection.  However I cannot get the delegate to work.
>
> Any help in getting NSURLConnection to work would be greatly appreciated.
>
> NSURLConnection.Class.cs defines:
> public virtual Id Delegate
> {
> get { return ObjectiveCRuntime.SendMessage(this,
> "delegate"); }
> set { ObjectiveCRuntime.SendMessage(this, "setDelegate:",
> value); }
> }
>
> However there is no "delegate" selector defined on NSURLConnection so
> SetDelegate fails with:
> 2009-11-14 10:50:12.468 SimplePrototype[1356:5e03] -[NSURLConnection
> delegate]: unrecognized selector sent to instance 0x6d3b20
>
> Also if I try:
> NSURLConnection.NSURLConnectionEventDispatcher d =  new
> NSURLConnection.NSURLConnectionEventDispatcher();
> d.ConnectionDidFailWithError += new
> NSURLConnection.ConnectionDidFailWithErrorEventHandler(d_ConnectionDidFailWithError);
> d.ConnectionDidFinishLoading += new
> NSURLConnection.ConnectionDidFinishLoadingEventHandler(d_ConnectionDidFinishLoading);
> d.ConnectionDidReceiveData += new
> NSURLConnection.ConnectionDidReceiveDataEventHandler(d_ConnectionDidReceiveData);
> d.ConnectionDidReceiveResponse += new
> NSURLConnection.ConnectionDidReceiveResponseEventHandler(d_ConnectionDidReceiveResponse);
> NSURLConnection conn = new NSURLConnection(req, d);
>
> none of the callbacks are invoked.  I also tried creating a class that
> defined:
> [ObjectiveCMessage("connection:didReceiveResponse:")]
> public void didReceiveResponse(NSURLConnection conn, NSURLResponse
> resp)
>
> but that failed to receive a response either.  I also tried creating the
> connection with start immediately false and then calling start, again
> without success.
>
> Thanks,
> Duane
>
>

Re: [us...@lists.monobjc.net] Re: NSURLConnection

[Duane Wandless]

Thanks for logging the bug about the delegate property.

I think the issue of the callbacks not occurring was being caused by my
delegate object running on a background thread and then the thread ending
before the callback could occur.  It works now so that I can do:

NSURLConnection conn = new NSURLConnection(req, this);
and this registers the objective-c selectors to be the NSURLConnection
delegate.

Duane


On Tue, Nov 17, 2009 at 5:01 AM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> I will log a bug about the delegate property, as obviously it was
> mis-generated. For the rest, can you provide a small test-case ?
>
> Regards, Laurent Etiemble.
>
> 2009/11/15 Duane Wandless :
> > Some more info.  I am on Snow Leopard but get the same results on
> Leopard.
> > I took the code from NSURLConnection.SetDelegate() and moved it into my
> code
> > like this:
> >
> > Action
> > assignment =
> > (d =>
> > {
> > d.ConnectionDidCancelAuthenticationChallenge +=
> new
> >
> NSURLConnection.ConnectionDidCancelAuthenticationChallengeEventHandler(d_ConnectionDidCancelAuthenticationChallenge);
> > d.ConnectionDidFailWithError += new
> >
> NSURLConnection.ConnectionDidFailWithErrorEventHandler(d_ConnectionDidFailWithError);
> > d.ConnectionDidFinishLoading += new
> >
> NSURLConnection.ConnectionDidFinishLoadingEventHandler(d_ConnectionDidFinishLoading);
> > d.ConnectionDidReceiveAuthenticationChallenge +=
> new
> >
> NSURLConnection.ConnectionDidReceiveAuthenticationChallengeEventHandler(d_ConnectionDidReceiveAuthenticationChallenge);
> > d.ConnectionDidReceiveData += new
> >
> NSURLConnection.ConnectionDidReceiveDataEventHandler(d_ConnectionDidReceiveData);
> > d.ConnectionDidReceiveResponse += new
> >
> NSURLConnection.ConnectionDidReceiveResponseEventHandler(d_ConnectionDidReceiveResponse);
> > d.ConnectionWillCacheResponse += new
> >
> NSURLConnection.ConnectionWillCacheResponseEventHandler(d_ConnectionWillCacheResponse);
> > d.ConnectionWillSendRequestRedirectResponse +=
> new
> >
> NSURLConnection.ConnectionWillSendRequestRedirectResponseEventHandler(d_ConnectionWillSendRequestRedirectResponse);
> > d.ConnectionDidSendBodyData += new
> >
> NSURLConnection.ConnectionDidSendBodyDataTotalBytesWrittenTotalBytesExpectedToWriteEventHandler(d_ConnectionDidSendBodyData);
> > });
> > NSURLConnection.NSURLConnectionEventDispatcher @delegate
> =
> > new NSURLConnection.NSURLConnectionEventDispatcher();
> > assignment(@delegate);
> > NSURLConnection conn = new NSURLConnection(req,
> @delegate);
> >
> > Also added some logging to
> > NSURLConnectionEventDispatcher.RespondsToSelector() and I do see in the
> log
> > some requests to see if my delegate responds to:
> > selector
> > connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:
> > selector connection:canAuthenticateAgainstProtectionSpace:
> > selector connection:needNewBodyStream:
> >
> > But only these 3.  I added the ConnectionDidSendBodyData event, which is
> > also not called.  I did do the same code in obj-c and the same 3
> selectors
> > are checked plus a few extra.  And the didSendBodyData selectors is
> called
> > in obj-c.
> >
> > Because of the logging I know that the @delegate is being inspected by
> > NSURLConnection.  But after those 3 no selectors are called on
> > NSURLConnectionEventDispatcher.  I even tried just returning true to
> > respondsToSelector hoping to raise an error, but that did not.
> >
> > Any help would be greatly appreciated.
> >
> > Duane
> >
> > On Sat, Nov 14, 2009 at 11:09 AM, Duane Wandless 
> wrote:
> >>
> >> I'm trying to use NSURLConnection, mainly to take advantage of Apple's
> >> built in proxy detection.  However I cannot get the delegate to work.
> >>
> >> Any help in getting NSURLConnection to work would be greatly
> appreciated.
> >>
> >> NSURLConnection.Class.cs defines:
> >> public virtual Id Delegate
> >> {
> >> get { return ObjectiveCRuntime.SendMessage(this,
> >> "delegate"); }
> >> set { ObjectiveCRuntime.SendMessage(this, "setDelegate:",
> >

[us...@lists.monobjc.net] NSProxy exception

[Duane Wandless]

I am getting the full call stack below when running, on SL and Leopard.
Using 2.4.2.3 and Monobjc 2.0.413.0.  Now I'm pretty confident this is a
terrible solution I found.  Any suggestions on how I can address this
correctly would be greatly appreciated.

I traced the workaround to NSProxy.Dealloc().  I added:
if (this == null)
  return;
And adding the check (see below) on cls.Name == "Proxy" to
ObjectiveCRuntime.GetInstance(IntPtr, bool).

Then the crash no longer occurs.  But this does not resolve why 'this' is
null when Dealloc is being called nor why an object of NSProxy is being
referenced in GetInstance.

I added logging to ObjectiveCRuntime.GetInstance(IntPtr, bool) as well as
the return null if class name is "NSProxy".

// If no match, try to see if there is an
inheritance relationship
if (result == default(TClass))
{
Class cls = Class.GetClassFromType(typeof
(TClass));
Console.WriteLine("Monobjc class name: {0}
ip {1:X} {2}", cls.Name, value, canFail);
   * if (cls.Name == "NSProxy")
return null;
*
I also added logging to Dealloc to print out what object is being
deallocated.  I see lots of this:
Console.WriteLine("nativeptr {0:X} {1}", this.NativePointer,
this.Class.Name);

nativeptr 398951232 _IKIRLMainProxy
nativeptr 402144384 _IKIRLMainProxy
nativeptr 402144400 _IKIRLMainProxy
nativeptr 402167744 _IKIRLMainProxy
nativeptr 398909232 _IKIRLMainProxy
nativeptr 398940800 _IKIRLMainProxy

Whenever I alt-tab away from my window and come back this output streams for
hundreds of lines with every once in a while a reference to Dealloc having a
this pointer that is null.

So some questions.  Should an NSProxy class ever be checked in GetInstance?
Is the constant Dealloc-ing of _IKIRLMainProxy expected?  Any ideas on how
this becomes null and then dealloc is called?

thanks!
Duane

Here is the call stack from C#.

(gdb) p (char *)mono_pmip (0x058db27e)
$6 = 0x18128d90 " (wrapper managed-to-native)
Monobjc.ObjectiveCRuntime:isKindOfClass (intptr,intptr,intptr) + 0x2e
(0x58db250 0x58db2a4) [0x20bde58 - MacMonoClient.exe]"
(gdb) p (char *)mono_pmip (0x03f0ef22)
$7 = 0x17196eb0 " Monobjc.ObjectiveCRuntime:GetInstance
(intptr,bool) + 0x152 (0x3f0edd0 0x3f0f431) [0x20bde58 - MacMonoClient.exe]"
(gdb) p (char *)mono_pmip (0x03f0edbf)
$8 = 0x1717f690 " Monobjc.ObjectiveCRuntime:GetInstance (intptr) +
0x27 (0x3f0ed98 0x3f0edc4) [0x20bde58 - MacMonoClient.exe]"
(gdb) p (char *)mono_pmip (0x180c4eee)
$9 = 0x1812ccd0 " Monobjc.Dynamic.Proxies.Monobjc.Cocoa.NSProxy:Dealloc
(intptr,intptr) + 0x16 (0x180c4ed8 0x180c4eff) [0x20bde58 -
MacMonoClient.exe]"
(gdb) p (char *)mono_pmip (0x03f017e6)
$10 = 0x1812c770 " (wrapper native-to-managed)
Monobjc.Dynamic.Proxies.Monobjc.Cocoa.NSProxy:Dealloc (intptr,intptr) + 0x2e
(0x3f017b8 0x3f017f2) [0x20bde58 - MacMonoClient.exe]"

*Monobjc class name: NSProxy ip 401881888 False*
2009-11-17 18:35:45.576 PIXFiles[11651:980b] An uncaught exception was
raised
2009-11-17 18:35:45.577 PIXFiles[11651:980b] *** -[NSProxy
doesNotRecognizeSelector:isKindOfClass:] called!
2009-11-17 18:35:45.579 PIXFiles[11651:980b] *** Terminating app due to
uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSProxy
doesNotRecognizeSelector:isKindOfClass:] called!'
*** Call stack at first throw:
(gdb) where
#0  0x9264fb07 in ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ ()
#1  0x94e1cf49 in objc_exception_throw ()
#2  0x926052b8 in +[NSException raise:format:arguments:] ()
#3  0x9260522a in +[NSException raise:format:] ()
#4  0x96a42b51 in -[NSProxy doesNotRecognizeSelector:] ()
#5  0x925ad026 in ___forwarding___ ()
#6  0x925acbf2 in __forwarding_prep_0___ ()
#7  0x96a43040 in -[NSProxy isKindOfClass:] ()
#8  0x058db27e in ?? ()
#9  0x03f0ef22 in ?? ()
#10 0x03f0edbf in ?? ()
#11 0x180c4eee in ?? ()
#12 0x03f017e6 in ?? ()
#13 0x90014f2e in -[_IKIRLMainProxy dealloc] ()
#14 0x9253f9d8 in CFRelease ()
#15 0x9256c5bd in _CFAutoreleasePoolPop ()
#16 0x9690be62 in NSPopAutoreleasePool ()
#17 0x9690bd8a in -[NSAutoreleasePool drain] ()
#18 0x900cbdea in -[IKTaskManager taskLoop] ()
#19 0x9691e964 in -[NSThread main] ()
#20 0x9691e914 in __NSThread__main__ ()
#21 0x90468f39 in _pthread_start ()
#22 0x90468dbe in thread_start ()

Re: [us...@lists.monobjc.net] Snow Leopard support: call for testing

[Duane Wandless]

I ran into this issue as well.  In my opinion this is a limitation of Mono.
Mono should look in the path of the running EXE or DLL.  To truly embed mono
in an application this would be ideal.

http://www.mono-project.com/Interop_with_Native_Libraries

Basically you have setup an env variable or place the dylib in a default
directory.

Duane

On Sun, Nov 22, 2009 at 9:18 AM, marc hoffman  wrote:

> Laurent,
>
> im getting the following error, although the dylib(s) *are* deployed in the
> MacOS folder of the .app bundle. Snow Leopard 10.6.2, using the current
> stable 2.4.2.3_6 version of Mono.
>
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474] Unhandled
> Exception: Monobjc.ObjectiveCException: The 'libmonobjc.2.dylib' library was
> not found. Please check that you have correctly installed it. --->
> System.DllNotFoundException: libmonobjc.2
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at (wrapper
> managed-to-native)
> Monobjc.Runtime.ObjectiveC20.NativeMethods:setLifecycleCallback
> (Monobjc.Runtime.RuntimeBridge/LifecycleCallback)
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at
> Monobjc.Runtime.ObjectiveC20.ObjectiveC20Bridge.SetLifecycleCallback
> (Monobjc.Runtime.LifecycleCallback callback) [0x0]
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   --- End of inner
> exception stack trace ---
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at
> Monobjc.Runtime.ObjectiveC20.ObjectiveC20Bridge.SetLifecycleCallback
> (Monobjc.Runtime.LifecycleCallback callback) [0x0]
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at
> Monobjc.Runtime.RuntimeBridge.get_Current () [0x0]
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at (wrapper
> synchronized) Monobjc.Runtime.RuntimeBridge:get_Current ()
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at
> Monobjc.ObjectiveCRuntime.DefineClass (System.Type type) [0x0]
> 11/22/09 3:14:57 PM [0x0-0x5df5df].DAServer6[29474]   at
> Monobjc.ObjectiveCRuntime.ScanAssembly (System.Reflection.Assembly assembly)
> [0x0]
>
> same app that ran fine with the previous Monobjc (which did not need the
> unmanaged dylib).
>
> any suggestions?
> marc
>
> On Nov 11, 2009, at 7:33 PM, Laurent Etiemble wrote:
>
> > Hello,
> >
> > I have finally come to a solution regarding the Snow Leopard support:
> > I have introduced a native library into the bridge to avoid the
> > reported crash on Mac OS X 10.6 [1]. After reviewing all the
> > feebacks[2][3], I came to the conclusion that a native library was the
> > only solution to:
> > - avoid the native/managed cross-calls when a thread exists and
> > dealloc its exit notification
> > - avoid the Mono runtime hacking (the Mono team is not really for it)
> >
> > The preview of the new release of the bridge is available for
> > download: http://downloads.monobjc.net/Monobjc-2.0.436.0.tar.gz
> >
> > Here are some noticeable points:
> > - the bridge now requires two shared libraries: libmonobjc.1.dylib and
> > libmonobjc.2.dylib (They are used for each version of the Objective-C
> > runtime). You have to put them in the MacOS folder of the application
> > bundle. Refer to the samples applications to see how you can simply do
> > that.
> > - the dealloc method is no more overriden. When using this version,
> > you will see a bunch of errors related to that. A search and replace
> > should do the trick.
> > - I saw some crashes on PowerPC G4 machines with Mono 2.6. Please use
> > Mono 2.4 as it is known to work ok.
> > - I think there are still some hidden issues (performance, optimization,
> etc).
> >
> > Can you please provide feedback on:
> > - the platform you are testing on (OS and Processor)
> > - the Mono version you are testing with
> > - the kind of application you are testing
> > - the result (work or crash)
> >
> > Thank you to everybody who has helped, and happy testing.
> >
> > Regards, Laurent Etiemble.
> >
> > [1] https://bugzilla.novell.com/show_bug.cgi?id=537764
> > [2] http://www.mail-archive.com/users@lists.monobjc.net/msg00251.html
> > [3] http://www.mail-archive.com/users@lists.monobjc.net/msg00286.html
>
>

[us...@lists.monobjc.net] Re: [de...@lists.monobjc.net] Snow Leopard support: call for testing

[Duane Wandless]

Laurent, any update on this issue?

Thanks,
Duane

On Thu, Nov 12, 2009 at 6:27 AM, Duane Wandless  wrote:

> Initial testing of the new Monobjc DLLs on Snow Leopard did NOT work for
> me.
>
> I moved the /Library/Frameworks/Mono.Framework/Versions/2.6_M directory out
> of the way so it could not be referenced.  I ran my app first and received
> this error:
> Monobjc.ObjectiveCException: The 'libmonobjc.2.dylib' library was not
> found.
>
> I then placed the dylib in the correct location.  This verified to me that
> I was using the correct version of the Monobjc DLLs.  Then running my app I
> still received a thread_get_state failure after a few minutes of running.
>
> crash report
> http://pastebin.com/m65fa182f
>
> Switching back to using the 2.6_M mono install the thread issue did not
> occur.
>
> Thanks for your continued efforts.
> Duane
>
>
>
>
> On Wed, Nov 11, 2009 at 1:33 PM, Laurent Etiemble <
> laurent.etiem...@monobjc.net> wrote:
>
>> Hello,
>>
>> I have finally come to a solution regarding the Snow Leopard support:
>> I have introduced a native library into the bridge to avoid the
>> reported crash on Mac OS X 10.6 [1]. After reviewing all the
>> feebacks[2][3], I came to the conclusion that a native library was the
>> only solution to:
>> - avoid the native/managed cross-calls when a thread exists and
>> dealloc its exit notification
>> - avoid the Mono runtime hacking (the Mono team is not really for it)
>>
>> The preview of the new release of the bridge is available for
>> download: http://downloads.monobjc.net/Monobjc-2.0.436.0.tar.gz
>>
>> Here are some noticeable points:
>> - the bridge now requires two shared libraries: libmonobjc.1.dylib and
>> libmonobjc.2.dylib (They are used for each version of the Objective-C
>> runtime). You have to put them in the MacOS folder of the application
>> bundle. Refer to the samples applications to see how you can simply do
>> that.
>> - the dealloc method is no more overriden. When using this version,
>> you will see a bunch of errors related to that. A search and replace
>> should do the trick.
>> - I saw some crashes on PowerPC G4 machines with Mono 2.6. Please use
>> Mono 2.4 as it is known to work ok.
>> - I think there are still some hidden issues (performance, optimization,
>> etc).
>>
>> Can you please provide feedback on:
>> - the platform you are testing on (OS and Processor)
>> - the Mono version you are testing with
>> - the kind of application you are testing
>> - the result (work or crash)
>>
>> Thank you to everybody who has helped, and happy testing.
>>
>> Regards, Laurent Etiemble.
>>
>> [1] https://bugzilla.novell.com/show_bug.cgi?id=537764
>> [2] http://www.mail-archive.com/users@lists.monobjc.net/msg00251.html
>> [3] http://www.mail-archive.com/users@lists.monobjc.net/msg00286.html
>>
>
>

Re: [us...@lists.monobjc.net] Snow Leopard support: call for testing (Take 2)

[Duane Wandless]

A quick update.  I've only tested Snow Leopard with *success*.  I have not
seen the thread crashing issue.  Using 2.4.2.3_M and 2.0.413.0.  SL 10.6.2.
I'm hoping to test Leopard later today or tomorrow.

The UI is native Cocoa calling into an embedded mono runtime.  The C# code
is multithreaded handling requests from the UI to a backend server.  On
average there probably are 5 active C# threads during usage.

Thanks,
Duane

On Tue, Dec 1, 2009 at 6:15 PM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> Sorry for the late update, but I had some busy nights trying to find
> another work-around for the Snow Leopard crash. The 4.0.436 release of
> the Monobjc bridge has brought mixed results regarding the Snow
> Leopard crash: some users have reported success while others have
> reported nasty crashes.
>
> So, I have resumed my work on the Mono runtime patching to find an
> acceptable way to do it (not too hacky so Novell would accept it).
> During my tests, I have discover that the conditions of the bug are
> already present under Leopard. Why it does not crash seems linked to
> the way TSD (Thread Specfic Data) are destroyed. So I have changed my
> approach and I have come to a workaround that seems to prevent the
> crash.
>
> The archive of the patched Mono runtime is available at:
>
> http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2
>
> In order to use the archive:
> - you need to have a working installation of Mono.
> - uncompress the archive in /Library/Frameworks/Mono.framework/Versions
> - relink the Current symlink to the archive (sudo rm Current && sudo
> ln -s 2.4.2.3_M Current)
>
> Some points about this runtime:
> - The runtime is universal. I have made some tests under some
> OS/Processor combinations, but I cannot cover all hardware.
> - The runtime contains Mono, Visual Basic and NAnt. It does not
> contains libgdiplus or any of the third-party packages.
> - The runtime contains all what is needed to run mkbundle or the
> packaging tasks.
> - The runtime also contains other patches: embedded "machine.config"
> and "app.config" are now usable.
>
> If you decide to test this runtime, please provide the following:
> - hardware/system full version
> - kind of application/complexity
> - anything that can help in case of crash
>
> Regards, Laurent Etiemble.
>

[us...@lists.monobjc.net] thread safe SendMessage

[Duane Wandless]

Laurent, I'm guessing this is a threading issue.  I ran into this call
stack:

Unhandled Exception: System.ArgumentException: Duplicate type name within an
assembly.
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr, System.Type parent, System.Type[] interfaces,
PackingSize packingSize, Int32 typesize) [0x0]
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr, System.Type parent, System.Type[] interfaces)
[0x0]
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr) [0x0]
  at
Monobjc.Bridge.Generators.DynamicMessagingGenerator.DefineMessagingDelegate[UInt32]
(System.String message, System.String typeName, System.Type[]
parameterTypes) [0x0]
  at Monobjc.Bridge.Generators.DynamicMessagingGenerator.SendMessage[UInt32]
(System.String message, IntPtr receiver, IntPtr selector) [0x0]
  at Monobjc.ObjectiveCRuntime.SendMessage[UInt32] (IManagedWrapper
receiver, System.String selector) [0x0]
  at Monobjc.Cocoa.NSData.get_Length () [0x0]
  at MyAPI.XmlRpc.DownloadData (System.String url) [0x0]
  at MyAPI.Loader.DownloadThumbnail (System.String fileUrl, System.String
localName, Boolean bAsync, Boolean bEncrypt) [0x0]
  at MyAPI.Loader.ThreadRun () [0x0]


I am firing off 3 threads that execute this same code.  Looking
at DynamicMessagingGenerator.SendMessage() it appears it would not be thread
safe.  SendMessage checks in messagingMethodsArgs to see if the key already
exists... if not it creates a new one.

In my console output from this crash I actually saw this same stack twice...
which implies all 3 got past the if check, the first thread created the
invoker and the next 2 threads failed because it already existed.

And of course this is not easy to reproduce as it would be a timing issue.
 I'd appreciate your thoughts on this.  I could see adding a lock
around messagingMethodsArgs.

Thanks,
Duane

Re: [us...@lists.monobjc.net] thread safe SendMessage

[Duane Wandless]

This is the only stack trace I've seen:
Unhandled Exception: System.ArgumentException: Duplicate type name within an
assembly.
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr, System.Type parent, System.Type[] interfaces,
PackingSize packingSize, Int32 typesize) [0x0]
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr, System.Type parent, System.Type[] interfaces)
[0x0]
  at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
TypeAttributes attr) [0x0]
  at
Monobjc.Bridge.Generators.DynamicMessagingGenerator.DefineMessagingDelegate[UInt32]
(System.String message, System.String typeName, System.Type[]
parameterTypes) [0x0]
  at Monobjc.Bridge.Generators.DynamicMessagingGenerator.SendMessage[UInt32]
(System.String message, IntPtr receiver, IntPtr selector) [0x0]
  at Monobjc.ObjectiveCRuntime.SendMessage[UInt32] (IManagedWrapper
receiver, System.String selector) [0x0]
  at Monobjc.Cocoa.NSData.get_Length () [0x0]
  at MyAPI.XmlRpc.DownloadData (System.String url) [0x0]
  at MyAPI.Loader.DownloadThumbnail (System.String fileUrl, System.String
localName, Boolean bAsync, Boolean bEncrypt) [0x0]
  at MyAPI.Loader.ThreadRun () [0x0]

And I've not seen it again.  So I'm very glad that I did my analysis right
then.  Do let me know if you need anything further with this issue.
Thanks,
Duane

On Wed, Dec 9, 2009 at 1:35 PM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> You are right, this part is not guarded to be thread-safe. I will add
> a critical section around the generation code.
>
> Can you still send the stack-trace for curiosity ?
>
> Regards, Laurent Etiemble.
>
> 2009/12/9 Duane Wandless :
> > Laurent, I'm guessing this is a threading issue.  I ran into this call
> > stack:
> > Unhandled Exception: System.ArgumentException: Duplicate type name within
> an
> > assembly.
> >   at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
> > TypeAttributes attr, System.Type parent, System.Type[] interfaces,
> > PackingSize packingSize, Int32 typesize) [0x0]
> >   at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
> > TypeAttributes attr, System.Type parent, System.Type[] interfaces)
> > [0x0]
> >   at System.Reflection.Emit.ModuleBuilder.DefineType (System.String name,
> > TypeAttributes attr) [0x0]
> >   at
> >
> Monobjc.Bridge.Generators.DynamicMessagingGenerator.DefineMessagingDelegate[UInt32]
> > (System.String message, System.String typeName, System.Type[]
> > parameterTypes) [0x0]
> >   at
> Monobjc.Bridge.Generators.DynamicMessagingGenerator.SendMessage[UInt32]
> > (System.String message, IntPtr receiver, IntPtr selector) [0x0]
> >   at Monobjc.ObjectiveCRuntime.SendMessage[UInt32] (IManagedWrapper
> > receiver, System.String selector) [0x0]
> >   at Monobjc.Cocoa.NSData.get_Length () [0x0]
> >   at MyAPI.XmlRpc.DownloadData (System.String url) [0x0]
> >   at MyAPI.Loader.DownloadThumbnail (System.String fileUrl, System.String
> > localName, Boolean bAsync, Boolean bEncrypt) [0x0]
> >   at MyAPI.Loader.ThreadRun () [0x0]
> >
> > I am firing off 3 threads that execute this same code.  Looking
> > at DynamicMessagingGenerator.SendMessage() it appears it would not be
> thread
> > safe.  SendMessage checks in messagingMethodsArgs to see if the key
> already
> > exists... if not it creates a new one.
> > In my console output from this crash I actually saw this same stack
> twice...
> > which implies all 3 got past the if check, the first thread created the
> > invoker and the next 2 threads failed because it already existed.
> > And of course this is not easy to reproduce as it would be a timing
> issue.
> >  I'd appreciate your thoughts on this.  I could see adding a lock
> > around messagingMethodsArgs.
> > Thanks,
> > Duane
> >
>

Re: [us...@lists.monobjc.net] NSProxy exception

[Duane Wandless]

Making a test case is not easy.  And this may actually be a SnowLeopard only
issue.  But I think I found the cause.  I have a bunch of these:
public NSString Name
{
[ObjectiveCMessage("name")]
get
{
return new NSString("name");
}

And I had a few of these:
public NSString Field
{
[ObjectiveCMessage("field")]
get
{
return "field";
}

I'm guessing the issue is autorelease/retain.  The implicit operator for
string to NSString does an autorelease.  Where new NSString(string) does
not.  So I changed the 2nd to also call new NSString() and the frequency of
the issue is reduced.  I am going through the code to make sure I do not
have other instances.  But the source object of the dealloc is very hard to
track down.

I still have the modified ObjectiveCRuntime.GetInstance, otherwise the app
will crash.

Now does this theory make sense?  And any suggestions on how to track down
the object that is being dealloced?

Thanks,
Duane


On Thu, Nov 26, 2009 at 2:51 AM, Laurent Etiemble <
laurent.etiem...@monobjc.net> wrote:

> Hello,
>
> Can you post a small test-case so we can investigate the issue ?
>
> Regards, Laurent Etiemble.
>
> 2009/11/18 Duane Wandless :
> > I am getting the full call stack below when running, on SL and Leopard.
> > Using 2.4.2.3 and Monobjc 2.0.413.0.  Now I'm pretty confident this is a
> > terrible solution I found.  Any suggestions on how I can address this
> > correctly would be greatly appreciated.
> >
> > I traced the workaround to NSProxy.Dealloc().  I added:
> > if (this == null)
> >   return;
> > And adding the check (see below) on cls.Name == "Proxy" to
> > ObjectiveCRuntime.GetInstance(IntPtr, bool).
> >
> > Then the crash no longer occurs.  But this does not resolve why 'this' is
> > null when Dealloc is being called nor why an object of NSProxy is being
> > referenced in GetInstance.
> >
> > I added logging to ObjectiveCRuntime.GetInstance(IntPtr, bool) as well as
> > the return null if class name is "NSProxy".
> >
> > // If no match, try to see if there is an
> > inheritance relationship
> > if (result == default(TClass))
> > {
> > Class cls = Class.GetClassFromType(typeof
> > (TClass));
> > Console.WriteLine("Monobjc class name:
> {0}
> > ip {1:X} {2}", cls.Name, value, canFail);
> > if (cls.Name == "NSProxy")
> > return null;
> >
> > I also added logging to Dealloc to print out what object is being
> > deallocated.  I see lots of this:
> > Console.WriteLine("nativeptr {0:X} {1}", this.NativePointer,
> > this.Class.Name);
> >
> > nativeptr 398951232 _IKIRLMainProxy
> > nativeptr 402144384 _IKIRLMainProxy
> > nativeptr 402144400 _IKIRLMainProxy
> > nativeptr 402167744 _IKIRLMainProxy
> > nativeptr 398909232 _IKIRLMainProxy
> > nativeptr 398940800 _IKIRLMainProxy
> >
> > Whenever I alt-tab away from my window and come back this output streams
> for
> > hundreds of lines with every once in a while a reference to Dealloc
> having a
> > this pointer that is null.
> >
> > So some questions.  Should an NSProxy class ever be checked in
> GetInstance?
> > Is the constant Dealloc-ing of _IKIRLMainProxy expected?  Any ideas on
> how
> > this becomes null and then dealloc is called?
> >
> > thanks!
> > Duane
> >
> > Here is the call stack from C#.
> >
> > (gdb) p (char *)mono_pmip (0x058db27e)
> > $6 = 0x18128d90 " (wrapper managed-to-native)
> > Monobjc.ObjectiveCRuntime:isKindOfClass (intptr,intptr,intptr) + 0x2e
> > (0x58db250 0x58db2a4) [0x20bde58 - MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x03f0ef22)
> > $7 = 0x17196eb0 " Monobjc.ObjectiveCRuntime:GetInstance
> > (intptr,bool) + 0x152 (0x3f0edd0 0x3f0f431) [0x20bde58 -
> MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x03f0edbf)
> > $8 = 0x1717f690 " Monobjc.ObjectiveCRuntime:GetInstance (intptr)
> +
> > 0x27 (0x3f0ed98 0x3f0edc4) [0x20bde58 - MacMonoClient.exe]"
> > (gdb) p (char *)mono_pmip (0x180c4eee)
> > $9 = 0x1812ccd0 " Monobjc.Dynamic.Proxies.Monobjc.Cocoa.NSProxy:Dealloc
> > (intptr,intptr) + 0x16 (0x180c4ed8 0x180c4eff) [0x20bde58 -
> > 

Re: [us...@lists.monobjc.net] Snow Leopard support: call for testing (Take 2)

[Duane Wandless]

An update on the Mono 2.6 RC.  As expected the thread_get_state crash still
exists with Monobjc 2.0.413.0.  I have not tried with 2.0.436.0.

I do have the MD soft debugger working with my embedded monobjc app.  It is
not perfect as sometimes the app freezes but this could be a cause of the
thread issue.

I will try later today (but more likely tomorrow) to provide the MD addins
that enable debugging embedded applications.  Being able to run a test case
for the thread issue in the debugger might prove useful to resolving it.

Duane

On Fri, Dec 11, 2009 at 6:45 AM, marc hoffman  wrote:

> Laurent,
>
> > I understand your point and also think that providing a custom runtime
> > can be awkward. I am still working hard to have a clean an acceptable
> > solution to the problem.
> >
> > The Monobjc 4.0.436 (dylib inside) has solved some crash problems but
> > not all. That makes me say that there are other cases when the bridge
> > is crossed outside the thread management scope of Mono:
> > - the first solution is to identify all theses possible paths (that
> > lead to crash) and forbid them.
> > - the second solution is to provide a patched Mono runtime that do a
> > proper thread management.
> >
> > I need to provide both a short-term and a long-term solution to
> > Monobjc's users. So I am open to any suggestions on how to do it well.
>
> me, im perfectly happy with the dylib solution, if that can fix all the
> issues. if later on official Mono distros will get fixes that make the dylib
> obsolete - great. but until then. i'd prefer needing the dylib to  needing a
> custom Mono runtime, a thousand-fold.
>
> the dylib is pretty much a non-issue. Apps get .app-bundled anyways, so
> copying two more files is a no-brainer (especially if MacPac does it for
> you). needing a custom runtime to test and debug Monobjc aps is a real
> showstopper for us telling our customers to use Monobjc (and mkbundle - all
> comments for or against it, aside - only helps with final deployment. the
> developer (our customer ;) still needs the custom runtime, which will get
> confusing and problematic, once newer Mono's come out (as the one that just
> did, which is a critically important update that users wot wanna skip).
>
> so my vote is on keeping the dylib, until such time that we can make do
> entirely without it, on a new vanilla Mono.
>
> hth,
> marc
>
> > 2009/12/6 marc hoffman :
> >> Am i the only one who thinks this custom runtime thing is not really
> acceptable for anyone who wants to - oh, say - *deploy* applications to
> regular users who can't/won't just patch their Mono install? what's the
> short-term plan for enabling people to actually ship apps based on Monobjc,
> and why can't we stick to the unmanaged dylib that can easily be deployed
> alongside the app, at least until an official Mono is out that contains
> these patches (if that will ever happen)?
> >>
> >> just thinking out loud, here.
> >>
> >> On Dec 2, 2009, at 12:15 AM, Laurent Etiemble wrote:
> >>
> >>> Hello,
> >>>
> >>> Sorry for the late update, but I had some busy nights trying to find
> >>> another work-around for the Snow Leopard crash. The 4.0.436 release of
> >>> the Monobjc bridge has brought mixed results regarding the Snow
> >>> Leopard crash: some users have reported success while others have
> >>> reported nasty crashes.
> >>>
> >>> So, I have resumed my work on the Mono runtime patching to find an
> >>> acceptable way to do it (not too hacky so Novell would accept it).
> >>> During my tests, I have discover that the conditions of the bug are
> >>> already present under Leopard. Why it does not crash seems linked to
> >>> the way TSD (Thread Specfic Data) are destroyed. So I have changed my
> >>> approach and I have come to a workaround that seems to prevent the
> >>> crash.
> >>>
> >>> The archive of the patched Mono runtime is available at:
> >>>
> http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2
> >>>
> >>> In order to use the archive:
> >>> - you need to have a working installation of Mono.
> >>> - uncompress the archive in /Library/Frameworks/Mono.framework/Versions
> >>> - relink the Current symlink to the archive (sudo rm Current && sudo
> >>> ln -s 2.4.2.3_M Current)
> >>>
> >>> Some points about this runtime:
> >>> - The runtime is universal. I have made some tests under some
> >>> OS/Processor combinations, but I cannot cover all hardware.
> >>> - The runtime contains Mono, Visual Basic and NAnt. It does not
> >>> contains libgdiplus or any of the third-party packages.
> >>> - The runtime contains all what is needed to run mkbundle or the
> >>> packaging tasks.
> >>> - The runtime also contains other patches: embedded "machine.config"
> >>> and "app.config" are now usable.
> >>>
> >>> If you decide to test this runtime, please provide the following:
> >>> - hardware/system full version
> >>> - kind of application/complexity
> >>> - anything that can help in case of crash
> >>>
> >>> Regards, L

[us...@lists.monobjc.net] Re: [MonoDevelop] [Mono-osx] Debug embedded OSX app

[Duane Wandless]

The box.net file is my project to create the 2 addins required to enable
debugging an embedded application using MD 2.2RC and Mono 2.6RC.

IMPORTANT:  For some reason only right clicking in the Solution explorer and
selecting Debug Item works.  I did not even attempt to investigate this.  In
other words the menu items Run | Debug and Run | Run do not work.  And right
clicking in the solution explorer and selecting Run Item does not work
either.

http://www.box.net/shared/lskor4zxgc

You must edit EmbeddedSoftDebuggerSession.cs and change this line:
var psi = new ProcessStartInfo ("open", ".app")

Then build both projects.  Then from the command line go into the repos
directory and type:
./clean
./docopy

This will create a MD addin repository in the directory three.

Then go to MD and click Tools | Addin Manager.  Click Repositories.  Click
Add.  Check Register a local repository.  Select the directory three.  Click
Install Addins.  At this point you should have two options.  Debugging and
Embedded.  Install both.  Restart MD.

Create a new project and select EmbeddedProject.  You can change this to be
a DLL or EXE based on how you are embedding.

You can modify an existing project (at least this worked for me) to be an
EmbeddedProject by editing the csproj file directly.  Add this line after
the  entry:

 
{84408980-E7F5-11DE-B313-B87456D89593};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}

Best of luck!
Duane

On Mon, Dec 14, 2009 at 8:55 AM, ptr  wrote:

>
>
> On Sat, Dec 12, 2009 at 11:55 AM, Duane Wandless wrote:
>
>> Here is my create process code.  Is this the code in question?
>>
>> Process browser;
>> var psi = new ProcessStartInfo ("open",
>> "/Users/me/Src/sandbox/nov05/svn/working/PFiles/build/Debug/PFiles.app") {
>>  UseShellExecute = false,
>> RedirectStandardOutput = false,
>> RedirectStandardError = true,
>>  };
>> psi.EnvironmentVariables.Add ("MOON_SOFT_DEBUG",
>> string.Format ("transport=dt_socket,address={0}:{1}", dsi.Address,
>> dsi.DebugPort));
>>  browser = Process.Start (psi);
>> ConnectOutput (browser.StandardOutput, false);
>>  ConnectOutput (browser.StandardError, true);
>>
>> I did modify the Waiting for debugger to connect message to print out both
>> DebugPort and OutputPort.  OutputPort is zero.
>>
>> protected override string GetListenMessage (RemoteDebuggerStartInfo dsi)
>> {
>>  return string.Format("Waiting for debugger to connect at
>> {0}:dbg{1}:con{2}", dsi.Address, dsi.DebugPort, dsi.OutputPort);
>> }
>>
>> Thanks,
>> Duane
>>
>> On Sat, Dec 12, 2009 at 11:12 AM, Geoff Norton wrote:
>>
>>> Duane,
>>>
>>>   How are you initializing the remove debug agent?  It sounds like you're
>>> listening for a console connection as well, but not connecting to that port.
>>>
>>> -g
>>>
>>> On 2009-12-12, at 10:49 AM, Duane Wandless wrote:
>>>
>>> I'm finally very close to enabling the soft debugger for embedded OSX
>>> applications.  Any help would be greatly appreciated.  I am blocked on the
>>> MD debugger not responding to the remote app.  Is this issue related to the
>>> debugger needing to be signed or something similar?
>>>
>>> I now can invoke the debugger and have it launch my cocoa app.  I see the
>>> Waiting for debugger to connect message.  And in the console I see these 2
>>> lines and no other errors:
>>>
>>> 12/12/09 9:44:04 AM Firewall[72] mono is listening from 
>>> 127.0.0.1:10001proto=6
>>> 12/12/09 9:44:04 AM Firewall[72] mono is listening from 
>>> 127.0.0.1:52690proto=6
>>>
>>> But the invoked app hangs with this call stack:
>>> #0  0x97c056ca in recvfrom$NOCANCEL$UNIX2003 ()
>>> #1  0x97c6fe99 in recv ()
>>> #2  0x00a9e906 in transport_connect (host=0x150c440 "127.0.0.1",
>>> port=10001) at debugger-agent.c:1003
>>> #3  0x00a9e12d in finish_agent_init (on_startup=1) at
>>> debugger-agent.c:809
>>> #4  0x00a9df90 in mono_debugger_agent_init () at debugger-agent.c:763
>>> #5  0x009d6b20 in mini_init (filename=0x150c100
>>> "/Users/me/Src/sandbox/dec10/svn/my_files/PFiles/build/Debug/PFiles.app/Contents/Libraries/MacMonoClient.exe",
>>> runtime_version=0x0) at mini.c:5109
>>> #6  0x00a5e59a in mono_jit_init (file=0x150c100
>>> "/Users/me/Src/sandbox/dec10/svn/my_files/PFiles/build/Debug/PFiles.app/Contents/Libraries/MacMonoClient.exe")
>>> at driver.c:1892
>>> #7  0x0004fbf7 in InitMono (argc=1, argv=0xb644)

[us...@lists.monobjc.net] Re: [MonoDevelop] [Mono-osx] Debug embedded OSX app

[Duane Wandless]

I did just follow the Moonlight addin example.  I'm just glad that it
basically works.  Some breakpoints are not being hit but that is a topic for
another day.

Great work on the debugger.
Duane

On Thu, Dec 17, 2009 at 3:55 PM, Michael Hutchinson <
m.j.hutchin...@gmail.com> wrote:

> On Thu, Dec 17, 2009 at 6:52 AM, Lluis Sanchez Gual
>  wrote:
> > Hi Duane,
> >
> > Thanks for sharing this project. It is a great example about extending
> > MD's project and debugging service. A few comments:
> >
> >  * You don't need to create two separate add-ins. You can create a
> >single add-in with all extensions you require.
> >  * The DoExecute method is supposed to be synchronous, that is, it
> >should not exit until execution has completed. It should wait
> >for the execution of ExecutionHandler.Execute to complete.
>
> Assuming this is based on the Moonlight addin, that's my fault (I only
> fixed it about a week ago, just in time for 2.2). The IConsole needs
> to be disposed too.
>
> --
> Michael Hutchinson
> http://mjhutchinson.com
>

[us...@lists.monobjc.net] Re: [MonoDevelop] [Mono-osx] Debug embedded OSX app

[Duane Wandless]

I have not had time to use this on Mono 2.6 GA.  When I tried, the addin was
not working for me.  Has anyone updated the addin to work with the GA
release?

Thanks,
Duane

On Mon, Dec 14, 2009 at 10:09 AM, Duane Wandless  wrote:

> The box.net file is my project to create the 2 addins required to enable
> debugging an embedded application using MD 2.2RC and Mono 2.6RC.
>
> IMPORTANT:  For some reason only right clicking in the Solution explorer
> and selecting Debug Item works.  I did not even attempt to investigate this.
>  In other words the menu items Run | Debug and Run | Run do not work.  And
> right clicking in the solution explorer and selecting Run Item does not work
> either.
>
> http://www.box.net/shared/lskor4zxgc
>
> You must edit EmbeddedSoftDebuggerSession.cs and change this line:
> var psi = new ProcessStartInfo ("open", ".app")
>
> Then build both projects.  Then from the command line go into the repos
> directory and type:
> ./clean
> ./docopy
>
> This will create a MD addin repository in the directory three.
>
> Then go to MD and click Tools | Addin Manager.  Click Repositories.  Click
> Add.  Check Register a local repository.  Select the directory three.  Click
> Install Addins.  At this point you should have two options.  Debugging and
> Embedded.  Install both.  Restart MD.
>
> Create a new project and select EmbeddedProject.  You can change this to be
> a DLL or EXE based on how you are embedding.
>
> You can modify an existing project (at least this worked for me) to be an
> EmbeddedProject by editing the csproj file directly.  Add this line after
> the  entry:
>
>  
> {84408980-E7F5-11DE-B313-B87456D89593};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
>
> Best of luck!
> Duane
>
> On Mon, Dec 14, 2009 at 8:55 AM, ptr  wrote:
>
>>
>>
>> On Sat, Dec 12, 2009 at 11:55 AM, Duane Wandless wrote:
>>
>>> Here is my create process code.  Is this the code in question?
>>>
>>> Process browser;
>>> var psi = new ProcessStartInfo ("open",
>>> "/Users/me/Src/sandbox/nov05/svn/working/PFiles/build/Debug/PFiles.app") {
>>>  UseShellExecute = false,
>>> RedirectStandardOutput = false,
>>> RedirectStandardError = true,
>>>  };
>>> psi.EnvironmentVariables.Add ("MOON_SOFT_DEBUG",
>>> string.Format ("transport=dt_socket,address={0}:{1}", dsi.Address,
>>> dsi.DebugPort));
>>>  browser = Process.Start (psi);
>>> ConnectOutput (browser.StandardOutput, false);
>>>  ConnectOutput (browser.StandardError, true);
>>>
>>> I did modify the Waiting for debugger to connect message to print out
>>> both DebugPort and OutputPort.  OutputPort is zero.
>>>
>>> protected override string GetListenMessage (RemoteDebuggerStartInfo dsi)
>>> {
>>>  return string.Format("Waiting for debugger to connect at
>>> {0}:dbg{1}:con{2}", dsi.Address, dsi.DebugPort, dsi.OutputPort);
>>> }
>>>
>>> Thanks,
>>> Duane
>>>
>>> On Sat, Dec 12, 2009 at 11:12 AM, Geoff Norton wrote:
>>>
>>>> Duane,
>>>>
>>>>   How are you initializing the remove debug agent?  It sounds like
>>>> you're listening for a console connection as well, but not connecting to
>>>> that port.
>>>>
>>>> -g
>>>>
>>>> On 2009-12-12, at 10:49 AM, Duane Wandless wrote:
>>>>
>>>> I'm finally very close to enabling the soft debugger for embedded OSX
>>>> applications.  Any help would be greatly appreciated.  I am blocked on the
>>>> MD debugger not responding to the remote app.  Is this issue related to the
>>>> debugger needing to be signed or something similar?
>>>>
>>>> I now can invoke the debugger and have it launch my cocoa app.  I see
>>>> the Waiting for debugger to connect message.  And in the console I see 
>>>> these
>>>> 2 lines and no other errors:
>>>>
>>>> 12/12/09 9:44:04 AM Firewall[72] mono is listening from 
>>>> 127.0.0.1:10001proto=6
>>>> 12/12/09 9:44:04 AM Firewall[72] mono is listening from 
>>>> 127.0.0.1:52690proto=6
>>>>
>>>> But the invoked app hangs with this call stack:
>>>> #0  0x97c056ca in recvfrom$NOCANCEL$UNIX2003 ()
>>>> #1  0x97c6fe99 in recv ()
>>>> #2  0x00a9e906 in transport_connect (host=0x150c440 "127.0.0.1",
>>>> port=10001) at debugger-agent.c:1003
>>&g

Re: [us...@lists.monobjc.net] dll.config paths in redistributable apps

[Duane Wandless]

I embed my app so your solution will most likely be different.  I call:

mono_config_parse ([configFile UTF8String]);

Where configFile contains the full path to my target libfoo.dylib.

You can also do this:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono MyProgram.exe

Which will give lots of debug output and help identify why it cannot find
the dll.

Hope this points you in the right direction.
Duane

On Tue, Feb 16, 2010 at 3:49 PM, anthony taranto
wrote:

> Hello,
>
> I'm building an application using monobjc. This application has a dll
> that relies on a compiled c library (dylib). When running my
> application using the mono installation, I have a dll.config file with
> the following contents:
>
> 
>  
> 
>
> This config file is placed in the same directory as my .exe and .dll
> files and i can run the application.
>
> When building a standalone application, I can't run it because it
> can't find libfoo.dylib. This seems to have something to do with
> relative paths. I notice that the mkappl nant task outputs that it is
> including and "relocating" the config file.
>
> My question is, what path can I supply to the target attribute to get
> my standalone application to load libfoo.dylib appropriately?
> Alternatively, how should I approach this problem?
>
> Thanks,
>
> --Anthony
>