Nabble - Mono - OSX

MonoTouch like development experience for Mac

2009-11-28T14:06:11Z

I have been playing around with MonoTouch and I must say that I am impressed at how well done it is and how complete the development workflow is. The key aspect in my opinion is the integration with MonoDevelop. Are there plans for a similar experience for developing Mac OS X applications with Cocoa and MonoDevelop? I would imagine that people, myself included, would pay for something like that with a licensing system similar to that of MonoTouch.

Thanks,

Kevin

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Requesting tool attention for OS X

2009-11-28T13:35:57Z

Hello,

>> Another option is for someone to complete the Monodoc/Cocoa#
>> version so that
>> we can ship that by default (it has to be Cocoa# because we do ship
>> that
>> already with Mono) or it could be written against one of the other
>> bindings
>> for Cocoa, but it would have to be shipped as a separate tool.
>
> Is Cocoa# the de facto / recommended framework on Mac? There are a few
> out there and I've lost track as to which is "the one to use".

Well, we do ship Cocoa# but it has not been maintained for a long
time. I am merely saying that if we want this to be part of the core
Mono, it has to be done using Cocoa# as we do not currently plan on
bundling any of the other libraries until one of them emerges as the
clear superior framework.

That being said, I did look at the other frameworks a few months ago,
and they had various degrees of completeness, design goals and
licenses. I would not say that there is any framework (including
Cocoa#) that I really like.

For us to bundle a new Mac framework it would have to satisfy a couple
of requirements:

* MIT X11, Apache 2 or MS-PL licensed class libraries.

* Commitment to API backwards compatibility.

* It should probably be closer to what we did with MonoTouch's API
design than to Objective-C's native APIs.

Mono has accumulated third party libraries over the years that did not
meet some of these criteria and we ended up with the burden of
maintenance, so I would not like to repeat that. In particular we
have ended up in a situation where we either deprecate libraries, try
to merge two APIs and expose them both and do multiple builds or ship
two versions of the same library. I would not like to repeat this
process, not for the Mac, and not for anything else.

In the short term, Cocoa# is what we have, and although not perfect,
it is bundled and would be fine to build a tool like native MonoDoc.

Miguel.
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Requesting tool attention for OS X

2009-11-28T13:29:29Z

Hello,

Re: Requesting tool attention for OS X

2009-11-28T11:02:30Z

On Sat, Nov 28, 2009 at 10:45 AM, Miguel de Icaza <miguel@...> wrote:
> Hello,

Thanks. In addition to helping me understand, it shows that there is
awareness on all these issues on the Mono team.

> ...
> Another option is for someone to complete the Monodoc/Cocoa# version so that
> we can ship that by default (it has to be Cocoa# because we do ship that
> already with Mono) or it could be written against one of the other bindings
> for Cocoa, but it would have to be shipped as a separate tool.

Is Cocoa# the de facto / recommended framework on Mac? There are a few
out there and I've lost track as to which is "the one to use".

-Chuck
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Re questing tool attention for OS X

2009-11-28T10:46:31Z

>
> I think this is the conflict between Mono pkg-config and MacPorts
> pkg-config.

RIght, so you need to fix that in your local setup.
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Requesting tool attention for OS X

2009-11-28T10:45:21Z

Hello,

> Poking around the web, I found "monodoc"
> (http://www.mono-project.com/Monodoc), but it doesn't appear to be
> available for Mac.

Correct; The problem is that Monodoc needs an HTML rendering
control, and none of the HTML engines available for Gtk+ have been
made part of the Gtk+ distribution due to the complexity of building
them. Until that can be solved, the standard Monodoc will not be
available.

Another option is for someone to complete the Monodoc/Cocoa# version
so that we can ship that by default (it has to be Cocoa# because we do
ship that already with Mono) or it could be written against one of the
other bindings for Cocoa, but it would have to be shipped as a
separate tool.

> I saw someone reference "mdb" in IRC, but that's missing too.

We do not ship MDB yet, mostly because we have dropped the ball there.

For mdb to work on new OSX versions, we have to sign the executable,
and although it is on the TODO list for the packaging team, the team
has been busy with other things, so mdb does not yet work in a usable
state, despite the fact that it does work.

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Re questing tool attention for OS X

2009-11-28T10:42:16Z

Hello,

> I do have multiple Mono's installed with the current one pointing to
> 2.6. Seems like MonoDevelop should say "2.4 only" or "cannot have
> multiple Monos" instead of "you don't have 2.4 or later".

Right, the last MonoDevelop 2.2 beta was botched in this regard, this
was fixed on SVN, but we have not issued a new preview of MonoDevelop
since.

You can fix this for now by editing the monodevelop script and
removing that check.

Miguel
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Re questing tool attention for OS X

2009-11-28T10:33:02Z

Thanks for the tip. I tried it and get:

$ export AS="as -arch i386"
$ mkbundle -o hello hello.exe --deps
OS is: Darwin
Sources: 1 Auto-dependencies: True
embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
embedding: /Library/Frameworks/Mono.framework/Versions/2.6/lib/mono/2.0/mscorlib.dll
Compiling:
as -arch i386 -o temp.o temp.s
cc -g -o hello -Wall temp.c `pkg-config --cflags --libs mono` temp.o
Package mono was not found in the pkg-config search path.
Perhaps you should add the directory containing `mono.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mono' found
temp.c:2:36: error: mono/metadata/assembly.h: No such file or directory
temp.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘assembly_bundle_hello_exe’
temp.c:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘assembly_bundle_mscorlib_dll’
temp.c:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
temp.c:21: error: ‘NULL’ undeclared here (not in a function)
temp.c: In function ‘mono_mkbundle_init’:
temp.c:25: warning: implicit declaration of function
‘mono_register_bundled_assemblies’
temp.c:25: error: ‘bundled’ undeclared (first use in this function)
temp.c:25: error: (Each undeclared identifier is reported only once
temp.c:25: error: for each function it appears in.)
temp.c: In function ‘main’:
temp.c:117: warning: implicit declaration of function ‘mono_set_dirs’
[Fail]

I think this is the conflict between Mono pkg-config and MacPorts pkg-config.

-Chuck

On Sat, Nov 28, 2009 at 10:17 AM, Duane Wandless <duane@...> wrote:

> Regarding the mkbundle error, try:
> export AS="as -arch i386"
> mkbundle....
>
>
>
> On Sat, Nov 28, 2009 at 12:56 PM, Stifu <stifu@...> wrote:
>>
>> Hello,
>>
>> About MonoDevelop not working, telling you you don't have Mono 2.4 or
>> later,
>> this can happen if you have multiple versions of Mono installed. You could
>> double check it's not the case.
>>
>>
>> Chuck Esterbrook wrote:
>> >
>> > Hi,
>> >
>> > Poking around the web, I found "monodoc"
>> > (http://www.mono-project.com/Monodoc), but it doesn't appear to be
>> > available for Mac.
>> >
>> > I saw someone reference "mdb" in IRC, but that's missing too.
>> >
>> > There is also "mkbundle", which is present, but not working:
>> >
>> > $ mkbundle -o hello hello.exe --deps
>> > OS is: Darwin
>> > Sources: 1 Auto-dependencies: True
>> > embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
>> > embedding:
>> >
>> > /Library/Frameworks/Mono.framework/Versions/2.4.2.3/lib/mono/2.0/mscorlib.dll
>> > Compiling:
>> > as -o temp.o temp.s
>> > temp.s:2:unknown section type: symbol_stubs
>> > temp.s:2:Rest of line ignored. 1st junk character valued 112 (p).
>> > temp.s:3082:unknown section type: symbol_stubs
>> > temp.s:3082:Rest of line ignored. 1st junk character valued 112 (p).
>> > [Fail]
>> >
>> > That's all on Mono 2.4.2.3 on OS X 10.6.1.
>> >
>> > I just installed Mono 2.6 preview 1 with no improvement.
>> >
>> > Then I tried MonoDevelop for the first time. It won't launch because
>> > it claims that I don't have Mono 2.4 or later (obviously I do). There
>> > is a MonoDevelop preview download listed with the Mono 2.6 preview,
>> > but it's MonoDevelop 2.0 instead of 2.2.
>> >
>> > Mono works great for me on Mac in terms of compilers and non-GUI
>> > libraries. But the other tools seem non-existant or broken.
>> >
>> >
>> > Are there any insights from Mono project folks such as "get monodoc
>> > here" or "change mkbundle options to this"?
>> >
>> > If I need to fill out bug reports, let me know.
>> >
>> >
>> > -Chuck
>> > _______________________________________________
>> > Mono-osx mailing list
>> > Mono-osx@...
>> > http://lists.ximian.com/mailman/listinfo/mono-osx
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Requesting-tool-attention-for-OS-X-tp26555333p26555390.html
>> Sent from the Mono - OSX mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Mono-osx mailing list
>> Mono-osx@...
>> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Re questing tool attention for OS X

2009-11-28T10:23:40Z

Thanks for the comment.

I do have multiple Mono's installed with the current one pointing to
2.6. Seems like MonoDevelop should say "2.4 only" or "cannot have
multiple Monos" instead of "you don't have 2.4 or later".

Sorry if that sounds picky, but user experience is important too.

In /Library/Frameworks/Mono.framework/Versions, I have 2.4, 2.4.2.3
and 2.6. I "sudo rm -rf"ed 2.4 and still get the message. Then I
killed 2.4.2.3, with only 1 mono remaining, but still get the same
message. MonoDevelop 2.2 beta 2 says it wants 2.4.2.3_6 or later but
what it really wants is >= 2.4.2.3_6 and < 2.6.

Okay, so next I remove MonoDevelop 2.2 beta 2 and install the 2.0
version presented with Mono 2.6 preview 1. It launches, and creating a
Console application goes well. Next I create a Gnome# solution, but it
fails to compile because:

The type or namespace name `Gtk' could not be found. Are you missing a
using directive or an assembly reference?

However, I already tested that I can build and run a GTK# application
from the command line, so I'm not expecting such an error.

This experience is all kinds of FAIL.

(Btw I know the next step is to check for the GTK# reference in the solution.)

-Chuck

On Sat, Nov 28, 2009 at 9:56 AM, Stifu <stifu@...> wrote:

>
> Hello,
>
> About MonoDevelop not working, telling you you don't have Mono 2.4 or later,
> this can happen if you have multiple versions of Mono installed. You could
> double check it's not the case.
>
>
> Chuck Esterbrook wrote:
>>
>> Hi,
>>
>> Poking around the web, I found "monodoc"
>> (http://www.mono-project.com/Monodoc), but it doesn't appear to be
>> available for Mac.
>>
>> I saw someone reference "mdb" in IRC, but that's missing too.
>>
>> There is also "mkbundle", which is present, but not working:
>>
>> $ mkbundle -o hello hello.exe --deps
>> OS is: Darwin
>> Sources: 1 Auto-dependencies: True
>> embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
>> embedding:
>> /Library/Frameworks/Mono.framework/Versions/2.4.2.3/lib/mono/2.0/mscorlib.dll
>> Compiling:
>> as -o temp.o temp.s
>> temp.s:2:unknown section type: symbol_stubs
>> temp.s:2:Rest of line ignored. 1st junk character valued 112 (p).
>> temp.s:3082:unknown section type: symbol_stubs
>> temp.s:3082:Rest of line ignored. 1st junk character valued 112 (p).
>> [Fail]
>>
>> That's all on Mono 2.4.2.3 on OS X 10.6.1.
>>
>> I just installed Mono 2.6 preview 1 with no improvement.
>>
>> Then I tried MonoDevelop for the first time. It won't launch because
>> it claims that I don't have Mono 2.4 or later (obviously I do). There
>> is a MonoDevelop preview download listed with the Mono 2.6 preview,
>> but it's MonoDevelop 2.0 instead of 2.2.
>>
>> Mono works great for me on Mac in terms of compilers and non-GUI
>> libraries. But the other tools seem non-existant or broken.
>>
>>
>> Are there any insights from Mono project folks such as "get monodoc
>> here" or "change mkbundle options to this"?
>>
>> If I need to fill out bug reports, let me know.
>>
>>
>> -Chuck
>> _______________________________________________
>> Mono-osx mailing list
>> Mono-osx@...
>> http://lists.ximian.com/mailman/listinfo/mono-osx
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Requesting-tool-attention-for-OS-X-tp26555333p26555390.html
> Sent from the Mono - OSX mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Re questing tool attention for OS X

2009-11-28T10:17:56Z

Regarding the mkbundle error, try:
export AS="as -arch i386"
mkbundle....

On Sat, Nov 28, 2009 at 12:56 PM, Stifu <stifu@...> wrote:

Hello,

About MonoDevelop not working, telling you you don't have Mono 2.4 or later,
this can happen if you have multiple versions of Mono installed. You could
double check it's not the case.

Chuck Esterbrook wrote:
>
> Hi,
>
> Poking around the web, I found "monodoc"
> (http://www.mono-project.com/Monodoc), but it doesn't appear to be
> available for Mac.
>
> I saw someone reference "mdb" in IRC, but that's missing too.
>
> There is also "mkbundle", which is present, but not working:
>
> $ mkbundle -o hello hello.exe --deps
> OS is: Darwin
> Sources: 1 Auto-dependencies: True
> embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
> embedding:
> /Library/Frameworks/Mono.framework/Versions/2.4.2.3/lib/mono/2.0/mscorlib.dll
> Compiling:
> as -o temp.o temp.s
> temp.s:2:unknown section type: symbol_stubs
> temp.s:2:Rest of line ignored. 1st junk character valued 112 (p).
> temp.s:3082:unknown section type: symbol_stubs
> temp.s:3082:Rest of line ignored. 1st junk character valued 112 (p).
> [Fail]
>
> That's all on Mono 2.4.2.3 on OS X 10.6.1.
>
> I just installed Mono 2.6 preview 1 with no improvement.
>
> Then I tried MonoDevelop for the first time. It won't launch because
> it claims that I don't have Mono 2.4 or later (obviously I do). There
> is a MonoDevelop preview download listed with the Mono 2.6 preview,
> but it's MonoDevelop 2.0 instead of 2.2.
>
> Mono works great for me on Mac in terms of compilers and non-GUI
> libraries. But the other tools seem non-existant or broken.
>
>
> Are there any insights from Mono project folks such as "get monodoc
> here" or "change mkbundle options to this"?
>
> If I need to fill out bug reports, let me know.
>
>
> -Chuck
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>

--
View this message in context: http://old.nabble.com/Requesting-tool-attention-for-OS-X-tp26555333p26555390.html
Sent from the Mono - OSX mailing list archive at Nabble.com.

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Requesting tool attention for OS X

2009-11-28T09:56:04Z

Hello,

About MonoDevelop not working, telling you you don't have Mono 2.4 or later, this can happen if you have multiple versions of Mono installed. You could double check it's not the case.

Chuck Esterbrook wrote:

Hi,

Poking around the web, I found "monodoc"
(http://www.mono-project.com/Monodoc), but it doesn't appear to be
available for Mac.

I saw someone reference "mdb" in IRC, but that's missing too.

There is also "mkbundle", which is present, but not working:

$ mkbundle -o hello hello.exe --deps
OS is: Darwin
Sources: 1 Auto-dependencies: True
embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
embedding: /Library/Frameworks/Mono.framework/Versions/2.4.2.3/lib/mono/2.0/mscorlib.dll
Compiling:
as -o temp.o temp.s
temp.s:2:unknown section type: symbol_stubs
temp.s:2:Rest of line ignored. 1st junk character valued 112 (p).
temp.s:3082:unknown section type: symbol_stubs
temp.s:3082:Rest of line ignored. 1st junk character valued 112 (p).
[Fail]

That's all on Mono 2.4.2.3 on OS X 10.6.1.

I just installed Mono 2.6 preview 1 with no improvement.

Then I tried MonoDevelop for the first time. It won't launch because
it claims that I don't have Mono 2.4 or later (obviously I do). There
is a MonoDevelop preview download listed with the Mono 2.6 preview,
but it's MonoDevelop 2.0 instead of 2.2.

Mono works great for me on Mac in terms of compilers and non-GUI
libraries. But the other tools seem non-existant or broken.

Are there any insights from Mono project folks such as "get monodoc
here" or "change mkbundle options to this"?

If I need to fill out bug reports, let me know.

-Chuck
_______________________________________________
Mono-osx mailing list
Mono-osx@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-osx

Requesting tool attention for OS X

2009-11-28T09:50:38Z

Hi,

Poking around the web, I found "monodoc"
(http://www.mono-project.com/Monodoc), but it doesn't appear to be
available for Mac.

I saw someone reference "mdb" in IRC, but that's missing too.

There is also "mkbundle", which is present, but not working:

$ mkbundle -o hello hello.exe --deps
OS is: Darwin
Sources: 1 Auto-dependencies: True
embedding: /Users/chuck/Scrap/dev/sharp/hello.exe
embedding: /Library/Frameworks/Mono.framework/Versions/2.4.2.3/lib/mono/2.0/mscorlib.dll
Compiling:
as -o temp.o temp.s
temp.s:2:unknown section type: symbol_stubs
temp.s:2:Rest of line ignored. 1st junk character valued 112 (p).
temp.s:3082:unknown section type: symbol_stubs
temp.s:3082:Rest of line ignored. 1st junk character valued 112 (p).
[Fail]

That's all on Mono 2.4.2.3 on OS X 10.6.1.

I just installed Mono 2.6 preview 1 with no improvement.

Then I tried MonoDevelop for the first time. It won't launch because
it claims that I don't have Mono 2.4 or later (obviously I do). There
is a MonoDevelop preview download listed with the Mono 2.6 preview,
but it's MonoDevelop 2.0 instead of 2.2.

Mono works great for me on Mac in terms of compilers and non-GUI
libraries. But the other tools seem non-existant or broken.

Are there any insights from Mono project folks such as "get monodoc
here" or "change mkbundle options to this"?

If I need to fill out bug reports, let me know.

-Chuck
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: MonoTouch vs Unity for iPhone

2009-11-26T11:28:34Z

Thanks for the details.

Talking about the trials, from what I see, the MonoTouch one isn't limited in time unlike Unity for iPhone (30 days). That's cool.

Miguel de Icaza-2 wrote:

Hello,

I forgot one important bit here:

> Am I overlooking anything? Has anyone tried either and can share their
> experience?

You can try both MonoTouch and Unity for free and see what is
better suited for your development needs without having to pay.

You can even build/prototype your entire app, until the time that
you are ready to start testing on the real hardware.

Miguel
_______________________________________________
Mono-osx mailing list
Mono-osx@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: MonoTouch vs Unity for iPhone

2009-11-26T11:23:27Z

Hello,

I forgot one important bit here:

> Am I overlooking anything? Has anyone tried either and can share their
> experience?

You can try both MonoTouch and Unity for free and see what is
better suited for your development needs without having to pay.

You can even build/prototype your entire app, until the time that
you are ready to start testing on the real hardware.

Miguel
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: MonoTouch vs Unity for iPhone

2009-11-26T04:20:10Z

On Wed, Nov 25, 2009 at 11:22 PM, Stifu <stifu@...> wrote:

> ...
> ---
>
> Unity
> Pros:
> - Specialized in game making, so good for me
>
> Cons:
> - .NET 1.1 (no generics)
> - Startup "Made with Unity" splash screen (unless you get the $1500 version
> rather than the $400 one)
>

I've heard it will be possible to choose which profile you want to
deploy your game with (.NET 1.1 with no generics OR .NET 2.x including
generics)... No promises though :)
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: MonoTouch vs Unity for iPhone

2009-11-25T21:19:51Z

Hello,

Unity in general is better suited for building games, in
particular 3D games and there is a large community of game developers
for it. The developer experience is mostly focused on the game side
of the code and you will do a lot of your tune-ups in Unity itself.

MonoTouch will work if you are planning on building your own
engine (like the SharpGames guys did with XnaTouch), and the
development experience is mostly focused on the code.

I think that MonoTouch is better suited for more business-y
application setups than games, for apps that need to use the native
CocoaTouch APIs day-in and day-out.

> MonoTouch
> Pros:
> - .NET 2.0 and 3.5 features (which, I take it, includes generics)
>
> Cons:
> - No more MonoTouch updates after one year
>
> ---
>
> Unity
> Pros:
> - Specialized in game making, so good for me
>
> Cons:
> - .NET 1.1 (no generics)
> - Startup "Made with Unity" splash screen (unless you get the $1500
> version
> rather than the $400 one)
>
>
> Am I overlooking anything? Has anyone tried either and can share their
> experience?
> Is MonoTouch actually a good choice to make a game (something rather
> simple,
> 2D)? I take it it can do everything plain Objective C can do? No
> idea what
> the graphics API is like, for example, but I assume it's iPhone
> specific...
> --
> View this message in context: http://old.nabble.com/MonoTouch-vs-Unity-for-iPhone-tp26521303p26521303.html
> Sent from the Mono - OSX mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: A very basic question-- running Win .net exe on Mac OS X w/ Mono

2009-11-25T15:30:35Z

I have the same question. This is the message I get:

** (program.exe:58983): WARNING **: Could not load file or assembly 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The entry point method could not be loaded
macbook-pro:program TH$ mcs program.exe
error CS2015: Source file `program.exe' is a binary file and not a text file
Compilation failed: 1 error(s), 0 warnings
macbook-pro:program TH$ mono program.exe

** (program.exe:59005): WARNING **: The following assembly referenced from /Users/TH/Desktop/folder/program.exe could not be loaded:
Assembly: PresentationFramework (assemblyref_index=8)
Version: 3.0.0.0
Public Key: 31bf3856ad364e35
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/Users/TH/Desktop/Folder/).

** (program.exe:59005): WARNING **: Could not load file or assembly 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The entry point method could not be loaded

MonoTouch vs Unity for iPhone

2009-11-25T14:22:51Z

I'm thinking of making an iPhone game (maybe), and was considering MonoTouch and Unity.
Both are expensive (same price: $400), but I guess Apple users enjoy paying. :\

After having looked around, this is what I concluded:

MonoTouch
Pros:
- .NET 2.0 and 3.5 features (which, I take it, includes generics)

Cons:
- No more MonoTouch updates after one year

---

Unity
Pros:
- Specialized in game making, so good for me

Cons:
- .NET 1.1 (no generics)
- Startup "Made with Unity" splash screen (unless you get the $1500 version rather than the $400 one)

Am I overlooking anything? Has anyone tried either and can share their experience?
Is MonoTouch actually a good choice to make a game (something rather simple, 2D)? I take it it can do everything plain Objective C can do? No idea what the graphics API is like, for example, but I assume it's iPhone specific...

Re: Mono 2.6 and Windows.Forms on MacOSX

2009-11-24T13:04:56Z

Chuck Esterbrook wrote:

I wonder if the fact that MonoDevelop is done in GTK# will mean that
GTK# will generally run better on Mac OS X than WinForms because it
has to for the MonoDevelop team.

Has anyone used both WinForms and GTK# on Mac OS X such that you can
share which was better behaved and more productive?

well...
GTK# and Cocoa# are better than windows.forms on Linux and OSX but i would like to see an update to windows.forms on OSX.
windows.forms is much better on Linux than OSX.
it would be great to have the same performances on OSX and Linux (i'm talking about windows.forms)

Re: Mono 2.6 and Windows.Forms on MacOSX

2009-11-24T12:57:55Z

On Tue, Nov 24, 2009 at 12:05 PM, AleStanga <alessandro.stanga@...> wrote:

> Kevin Heeney wrote:
>>
>> I was looking for any information on the Mac Windows.Forms update planned
>> for Mono 2.6. The Roadmap just says Windows.Forms update for Mac OS X,
>> but
>> I could not find any details.
>>
>
> no more Mac Windows.Forms update in the roadmap.
> why?

I wonder if the fact that MonoDevelop is done in GTK# will mean that
GTK# will generally run better on Mac OS X than WinForms because it
has to for the MonoDevelop team.

Has anyone used both WinForms and GTK# on Mac OS X such that you can
share which was better behaved and more productive?

-Chuck
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Mono 2.6 and Windows.Forms on MacOSX

2009-11-24T12:05:53Z

Kevin Heeney wrote:

I was looking for any information on the Mac Windows.Forms update planned
for Mono 2.6. The Roadmap just says Windows.Forms update for Mac OS X, but
I could not find any details.

no more Mac Windows.Forms update in the roadmap.
why?

MonoVS and OS X

2009-11-12T07:50:54Z

hey all

Can this tool be made to work on OS X ?

http://www.go-mono.com/monovs/

What are people using to debug mono on OS X these days ?

Thanks
Raj

Re: Winforms app under Mac OS X: change menu name

2009-11-10T05:18:18Z

Lee V. Andrus wrote:

> The MonoDevelop for Mac Preview seems to have done the trick and more:
> http://go-mono.com/forums/#nabble-to23418439%7Ca23418568
> http://go-mono.com/forums/#nabble-to23418439%7Ca23418568
> I am not sure how. There is a mention that the Mac-friendly features
> involve a lot of PInvokes of Carbon functions.
>
> When I tried to do something similar with Cocoa via MCocoa & MObjc there
> seemed to be no connection between the menu displayed and the mainMenu
> property of the NSApplication object. It was nil initially. When I tried
> to create a menu and set this property to it, there was no change in the
> displayed menu.

The application name in main menu is set automatically by the system,
when you launch a Mac OS X application, i.e. open a MyProgram.app
special folder in Finder. I don't know if there's any other method to
set this name.

To handle Quit item correctly you'll need some magic with Carbon
P/Invokes, though.

--
Regards,
Alex

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: Winforms app under Mac OS X: change menu name

2009-11-09T13:57:44Z

The MonoDevelop for Mac Preview seems to have done the trick and more:
http://go-mono.com/forums/#nabble-to23418439%7Ca23418568
I am not sure how. There is a mention that the Mac-friendly features involve a lot of PInvokes of Carbon functions.

When I tried to do something similar with Cocoa via MCocoa & MObjc there seemed to be no connection between the menu displayed and the mainMenu property of the NSApplication object. It was nil initially. When I tried to create a menu and set this property to it, there was no change in the displayed menu.

Andrew Brehm wrote:

Is it possible for a Winforms app to rename the top screen menu in Mac
OS X to something other than Mono?

The menu doesn't have to work, it should just show the correct app
name. It would be great if the "Quit" menu item could be made to work
for the app though.

Re: external reference to a class

2009-11-06T14:49:51Z

That is much better... thank you for suggesting this.
Duane

On Fri, Nov 6, 2009 at 2:53 AM, Laurent Etiemble <laurent.etiemble@...> wrote:

Hello,

Why don't you use the "NSClassFromString" function
(http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSClassFromString)
? The return type is a Class instance, and is not as low-level as a
call to objc_getClass().

[NSClassFromString(@"MyMonoClass") testTouch];

Note 1: See http://www.cocoadev.com/index.pl?NSClassFromString for more comments
Note 2: you can even define a macro to avoid the cluttering of your code.

Regards, Laurent Etiemble.

2009/10/22 Duane Wandless <duane@...>:

> 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
>

> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: libsqlite3.0.dylib - SQLITE_ENABLE_COLUMN_METADATA required

2009-11-06T00:01:51Z

abryson wrote:

Hi all,

I've got a application which usess NHibernate to access SQLite. This works well on Windows, and I'm trying to get the application unit tests (Nunit) to run on Mac OS X 10.5.

The unit tests have been failing because the native library (libsqlite3.0.dylib) was not compiled with the SQLITE_ENABLE_COLUMN_METADATA directive. My nunit tests started working again once I:

- recompiled from source (http://www.sqlite.org/sqlite-amalgamation-3.6.19.tar.gz) passing SQLITE_ENABLE_COLUMN_METADATA through CFLAGS to configure.
- overwriting the existing mono version of libsqlite3.0.dylib (/Library/Frameworks/Mono.framework/Versions/Current/lib/libsqlite3.0.dylib) with the resulting library.

I'm also using the ADO.NET provider for SQLite from http://sourceforge.net/projects/sqlite-dotnet2/files/SQLite%20for%20ADO.NET%202.0/1.0.65.0/SQLite-1.0.65.0-managedonly-binaries.zip/download (http://sqlite.phxsoftware.com/). This requires the native SQlite library to be in place though.

I've run my unit tests on the Mono 2.4 VMWare image which I downloaded from the Mono website, and the tests work as expected.

Questions:

1. Does mono ship a version of libsqlite3.0.dylib, and if so, can it be updated to support SQLITE_ENABLE_COLUMN_METADATA please?
2. What else could I do to resolve this problem? I don't want to provide a copy of the native library alongside my application, but would this be possible to do?

Thanks,

Andrew Bryson

Bump... can anybody help?

Thanks,
andy

Re: external reference to a class

2009-11-05T23:53:54Z

Hello,

Why don't you use the "NSClassFromString" function
(http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSClassFromString)
? The return type is a Class instance, and is not as low-level as a
call to objc_getClass().

[NSClassFromString(@"MyMonoClass") testTouch];

Note 1: See http://www.cocoadev.com/index.pl?NSClassFromString for more comments
Note 2: you can even define a macro to avoid the cluttering of your code.

Regards, Laurent Etiemble.

2009/10/22 Duane Wandless <duane@...>:

> 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
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx@...
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
>

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Winforms app under Mac OS X: change menu name

2009-11-03T06:33:42Z

This has probably been asked before but I couldn't find it.

Is it possible for a Winforms app to rename the top screen menu in Mac
OS X to something other than Mono?

The menu doesn't have to work, it should just show the correct app
name. It would be great if the "Quit" menu item could be made to work
for the app though.

Any ideas?
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Winforms app under Mac OS X: change menu name

2009-11-03T06:32:50Z

This has probably been asked before but I couldn't find it.

Is it possible for a Winforms app to rename the top screen menu in Mac OS X to something other than Mono?

The menu doesn't have to work, it should just show the correct app name. It would be great if the "Quit" menu item could be made to work for the app though.

Any ideas?

Winforms app under Mac OS X: change menu name

2009-11-03T06:29:34Z

This has probably been asked before but I couldn't find it.

Is it possible for a Winforms app to rename the top screen menu in Mac OS X to something other than Mono?

The menu doesn't have to work, it should just show the correct app name. It would be great if the "Quit" menu item could be made to work for the app though.

Any ideas?

Re: [Mono-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

2009-10-29T07:59:26Z

Sebastien Pouliot wrote:
>
> Please open a bug report on bugzilla.novell.com and attach your test
> case.

https://bugzilla.novell.com/show_bug.cgi?id=551009

>> On my Linux box it crashes all the time. I get a wide variety of errors
>> from gdb stacktraces with SIGSEGV or SIGABRT in the end, to SIGILL with
>> .Net stack trace.
>>
>> Uncommenting these lock {} lines in the ThreadProc helps, but not an
>> option for my real app, as there's simply no single place a lock could
>> be added.
>>
>> I've also tried writing some code in plain C which links to libgdiplus
>> directly: see `threads-gdiplus.c'. It happily crashes just like the C#
>> version.
>
> Most of System.Drawing is only a small wrapper abound libgdiplus (or GDI
> + under Windows). Any bug will likely be inside libgdiplus so it's
> "normal" (i.e. expected) that you get the same behavior.

Yes, it's what I expected. Just thought it might be helpful in
debugging the problem. Attached this to the bug too.

>> My tests show that even using unsynchronized GdipGetImageGraphicsContext
>> / GdipDeleteGraphics (no fonts stuff touched) can easily lead to crashes.
>>
>> From what I've seen, cairo seems to be thread-safe: see attached[1]
>> `cairo-multi-thread-text.c'.
>
> It's thread-safe as long as everything is created and executed in the
> same thread. Otherwise it would not be safe-thread (just like .net and
> most libraries are).

This is actually what I meant by thread-safe here. :)

I'd expect any library not to crash under similar circumstances as long
as it doesn't use global variables or, if so, does ensure proper locking
around them.

--
Regards,
Alex

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: [Mono-dev] Is System.Drawing (libgdiplus) thread-safe?

2009-10-28T14:09:12Z

Hello,

It is thread safe for instances of objects, but you can not mix
objects that need to interact with the windowing system with calls
made in separate threads.

The simple solution is to make sure that anything that interacts
with the GUI uses Control.Invoke.

On Oct 28, 2009, at 1:37 PM, Alex Shulgin wrote:

> Hi all,
>
> Is System.Drawing by any means thread-safe?
>
> Can I create some threads, create a Graphics object in each of them
> and then work with it from within that thread? Is this supposed to
> work or am I doing something really stupid here?
>
> I ask because I've noticed random crashes in a WinForms app on OS X
> (but it happens on Linux too). Most of the time it crashes in
> System.Drawing.Graphics' DrawString or MeasureString methods and
> seems to occur then a background worker thread is working in
> parallel with UI thread.
>
> I've tried to do a stress-test of System.Drawing in a sample multi-
> threaded program. See attached `test-multi-threaded-drawing.cs'.
>
> On my Linux box it crashes all the time. I get a wide variety of
> errors from gdb stacktraces with SIGSEGV or SIGABRT in the end, to
> SIGILL with .Net stack trace.
>
> Uncommenting these lock {} lines in the ThreadProc helps, but not an
> option for my real app, as there's simply no single place a lock
> could be added.
>
> I've also tried writing some code in plain C which links to
> libgdiplus directly: see `threads-gdiplus.c'. It happily crashes
> just like the C# version.
>
> My tests show that even using unsynchronized
> GdipGetImageGraphicsContext / GdipDeleteGraphics (no fonts stuff
> touched) can easily lead to crashes.
>
> From what I've seen, cairo seems to be thread-safe: see attached[1]
> `cairo-multi-thread-text.c'.
>
> Also, there's a few locking used around thread-unsafe fontconfig
> calls in libgdiplus itself. I didn't examined the whole code, so
> there's possibly other places in it missing locking primitives.
>
> I would appreciate any help on this subject!
>
> --
> Regards,
> Alex
> [1] originally found in the cairo bugzilla for a few-years-old bug;
> my sligthly enhanced version
> /* gmcs test-multi-threaded-drawing.cs -
> r:System.Drawing,System.Windows.Forms */
> using System;
> using System.Text;
> using System.Drawing;
> using System.Windows.Forms;
> using System.Threading;
>
> namespace test {
> public class MainForm : Form {
> private static int threadCount = 0;
>
> private object consoleLock = new Object();
> private object hwndLock = new Object();
>
> public static void Main(string[] args) {
> threadCount = args.Length == 0 ? 6 : int.Parse(args[0]);
>
> Application.Run(new MainForm());
> }
>
> protected override void OnLoad(EventArgs e) {
> base.OnLoad(e);
>
> for (int i = 0; i < threadCount; ++i) {
> Thread t = new Thread(ThreadProc);
> t.Start(i);
> }
> }
>
> void ThreadProc(object data) {
> int threadnum = (int) data;
>
> Random rnd = new Random((int) DateTime.Now.Ticks);
> int count = rnd.Next(250, 1000);
> lock (consoleLock) {
> Console.WriteLine("thread{0} start: {1}", threadnum, count);
> }
>
> for (int i = 0; i < count; ++i) {
> string str = CreateRandomString(rnd);
>
> using (Graphics g = GetGraphicsForMeasurement()) {
> using (Font font = CreateRandomFont(rnd)) {
> //lock (hwndLock) {
> SizeF sz = g.MeasureString(str, font);
>
> using (Bitmap bmp = new Bitmap((int) sz.Width, (int)
> sz.Height)) {
> using (Graphics gfx = Graphics.FromImage(bmp)) {
> using (Brush b = Brushes.Red) {
> gfx.DrawString(str, font, b, new PointF(0f, 0f));
> }
> }
> }
> //}
> }
> }
> }
>
> lock (consoleLock) {
> Console.WriteLine("thread{0} done", threadnum);
> }
> }
>
> string CreateRandomString(Random rnd) {
> int len = 1 + rnd.Next(60);
> StringBuilder sb = new StringBuilder(len);
> for (int j = 0; j < len; ++j) {
> int ch = (rnd.Next() & 1) == 1 ? 0x41 : 0x61; // 'A' or 'a'
> sb.Append(Char.ConvertFromUtf32(ch + rnd.Next(26)));
> }
> return sb.ToString();
> }
>
> Graphics GetGraphicsForMeasurement() {
> #if NO_GRAPHICS_FROM_HWND
> Bitmap tmp = new Bitmap(1, 1);
> return Graphics.FromImage(tmp);
> #else
> Graphics g;
> lock (hwndLock) {
> g = Graphics.FromHwnd(this.Handle);
> }
> return g;
> #endif
> }
>
> Font CreateRandomFont(Random rnd) {
> return new Font("Sans", (int) (8 + rnd.NextDouble()*10));
> }
> }
> }
> /* gcc `pkg-config --cflags --libs cairo` -lpthread multi-thread-
> text.c -o multi-thread-text */
>
> /*
> * Copyright © 2005 Red Hat, Inc.
> *
> * Permission to use, copy, modify, distribute, and sell this software
> * and its documentation for any purpose is hereby granted without
> * fee, provided that the above copyright notice appear in all copies
> * and that both that copyright notice and this permission notice
> * appear in supporting documentation, and that the name of
> * Red Hat, Inc. not be used in advertising or publicity pertaining to
> * distribution of the software without specific, written prior
> * permission. Red Hat, Inc. makes no representations about the
> * suitability of this software for any purpose. It is provided "as
> * is" without express or implied warranty.
> *
> * RED HAT, INC. DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
> * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> * FITNESS, IN NO EVENT SHALL RED HAT, INC. BE LIABLE FOR ANY SPECIAL,
> * INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
> * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
> * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR
> * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> *
> * Author: Carl D. Worth <cworth@...>
> */
>
> #include <assert.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <cairo.h>
> #include <pthread.h>
>
> static void *
> start (void *closure)
> {
> int i;
>
> for (i = 0; i < 1000; ++i) {
> cairo_surface_t *surface;
> cairo_t *cr;
>
> surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 100,
> 100);
> cr = cairo_create (surface);
>
> cairo_move_to (cr, 10, 10);
>
> cairo_set_font_size (cr, 10);
> cairo_show_text (cr, "Hello world.\n");
>
> cairo_set_font_size (cr, 9);
> cairo_show_text (cr, "Hello world.\n");
>
> cairo_set_font_size (cr, 8);
> cairo_show_text (cr, "Hello world.\n");
>
> cairo_destroy (cr);
> cairo_surface_destroy (surface);
> }
>
> return NULL;
> }
>
> int
> main (int argc, char *argv[0])
> {
> int i, num_threads;
> pthread_t *pthread;
>
> if (argc > 1) {
> num_threads = atoi (argv[1]);
> } else {
> num_threads = 6;
> printf ("Running with default value of %d threads.\n"
> "To change, call: %s <number_of_threads>\n",
> num_threads, argv[0]);
> }
>
> pthread = malloc (num_threads * sizeof (pthread_t));
> assert (pthread != NULL);
>
> for (i = 0; i < num_threads; i++)
> pthread_create (&pthread[i], NULL, start, NULL);
>
> for (i = 0; i < num_threads; i++) {
> pthread_join (pthread[i], NULL);
> printf("joined thread%d\n", i);
> }
>
> return 0;
> }
> /* gcc threads-gdiplus.c `pkg-config --cflags glib-2.0` -Wall -
> lgdiplus -lpthread */
>
> #include <assert.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <wchar.h>
>
> #include <gdiplus/GdiPlusFlat.h>
> #include <pthread.h>
>
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
>
> void
> fatal(char const* func, GpStatus err)
> {
> fprintf(stderr, "%s: %d\n", func, err);
> exit(1);
> }
>
> static void*
> start(void* closure)
> {
> GpStatus err;
>
> GpBitmap* img;
> int width = 128;
> int height = 32;
> int stride = width*4;
>
> GpGraphics* gfx;
>
> GpFontFamily* family;
> GpFont* font;
>
> WCHAR const str[] = {'H','e','l','l','o',',','
> ','W','o','r','l','d','!'};
> size_t len = sizeof(str)/sizeof(WCHAR);
> RectF rect;
> RectF bounds;
>
> int i;
>
> for (i = 0; i < 1000; ++i) {
>
> err = GdipCreateBitmapFromScan0(width, height, stride,
> PixelFormat32bppARGB, /* scan0 = */ NULL, &img);
> if (err != Ok)
> fatal("GdipCreateBitmapFromScan0", err);
>
> //assert(pthread_mutex_lock(&mutex) == 0);
>
> err = GdipGetImageGraphicsContext(img, &gfx);
> if (err != Ok)
> fatal("GdipGetImageGraphicsContext", err);
>
> //assert(pthread_mutex_unlock(&mutex) == 0);
>
>
> err = GdipGetGenericFontFamilySansSerif(&family);
> if (err != Ok)
> fatal("GdipGetGenericFontFamilySansSerif", err);
>
> err = GdipCreateFont(family, 12.0, FontStyleRegular, UnitPoint,
> &font);
> if (err != Ok)
> fatal("GdipCreateFont", err);
>
>
>
> rect.X = 0;
> rect.Y = 0;
> rect.Width = width;
> rect.Height = height;
>
> //assert(pthread_mutex_lock(&mutex) == 0);
>
> err = GdipMeasureString(gfx, str, len, font, &rect, /* format =
> */ NULL, &bounds,
> /* codepoints = */ NULL, /* lines = */
> NULL);
> if (err != Ok)
> fatal("GdipMeasureString", err);
>
> //assert(pthread_mutex_unlock(&mutex) == 0);
>
>
> err = GdipDeleteFont(font);
> if (err != Ok)
> fatal("GdipDeleteFont", err);
>
>
>
> err = GdipDeleteGraphics(gfx);
> if (err != Ok)
> fatal("GdipDeleteGraphics", err);
>
>
> err = GdipDisposeImage(img);
> if (err != Ok)
> fatal("GdipDisposeImage", err);
>
> }
>
> return NULL;
> }
>
> int
> main(int argc, char *argv[0])
> {
> int i, num_threads;
> pthread_t* pthread;
>
> GpStatus err;
> ULONG_PTR gdiptok;
> GdiplusStartupInput gdipinput;
> GdiplusStartupOutput gdipoutput;
>
> err = GdiplusStartup(&gdiptok, &gdipinput, &gdipoutput);
> if (err != Ok)
> fatal("GdiplusStartup", err);
>
>
> if (argc > 1) {
> num_threads = atoi(argv[1]);
> } else {
> num_threads = 6;
> printf("Running with default value of %d threads.\n"
> "To change, call: %s <number_of_threads>\n",
> num_threads, argv[0]);
> }
>
> pthread = malloc(num_threads * sizeof(pthread_t));
> assert(pthread != NULL);
>
> for (i = 0; i < num_threads; i++)
> pthread_create(&pthread[i], NULL, start, NULL);
>
> for (i = 0; i < num_threads; i++) {
> pthread_join(pthread[i], NULL);
> printf("joined thread%d\n", i);
> }
>
> pthread_mutex_destroy(&mutex);
>
> return 0;
> }
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@...
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: [Mono-dev] [Mono-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

2009-10-28T11:16:37Z

On Wed, 2009-10-28 at 19:47 +0200, Alex Shulgin wrote:

> Alex Shulgin wrote:
> > Hi all,
> >
> > Is System.Drawing by any means thread-safe?
> >
> > Can I create some threads, create a Graphics object in each of them and
> > then work with it from within that thread? Is this supposed to work or
> > am I doing something really stupid here?
>
> Oh, forgot to mention that I've tested this on both 2.4 and latest
> available 2.6. The results are the same.

There has not been many changes between 2.4 and 2.6 wrt
System.Drawing.dll and libgdiplus (i.e. minor maintenance).

Most graphic stuff (and time) now happens in Moonlight...

Sebastien

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: [Mono-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

2009-10-28T11:13:52Z

On Wed, 2009-10-28 at 19:37 +0200, Alex Shulgin wrote:
> Hi all,
>
> Is System.Drawing by any means thread-safe?

No, like most of the .net framework, i.e.

<quote>Any public static (Shared in Visual Basic) members of
this type are thread safe. Any instance members are not
guaranteed to be thread safe.</quote>

>
> Can I create some threads, create a Graphics object in each of them and
> then work with it from within that thread?

Yes, you can (or it's a bug). However you also need to make sure you're
not using the Graphic instance (and other created objects) only from a
single (and original) thread.

> Is this supposed to work or
> am I doing something really stupid here?
>
> I ask because I've noticed random crashes in a WinForms app on OS X (but
> it happens on Linux too). Most of the time it crashes in
> System.Drawing.Graphics' DrawString or MeasureString methods and seems
> to occur then a background worker thread is working in parallel with UI
> thread.
>
> I've tried to do a stress-test of System.Drawing in a sample
> multi-threaded program. See attached `test-multi-threaded-drawing.cs'.

Please open a bug report on bugzilla.novell.com and attach your test
case.

> On my Linux box it crashes all the time. I get a wide variety of errors
> from gdb stacktraces with SIGSEGV or SIGABRT in the end, to SIGILL with
> .Net stack trace.
>
> Uncommenting these lock {} lines in the ThreadProc helps, but not an
> option for my real app, as there's simply no single place a lock could
> be added.
>
> I've also tried writing some code in plain C which links to libgdiplus
> directly: see `threads-gdiplus.c'. It happily crashes just like the C#
> version.

Most of System.Drawing is only a small wrapper abound libgdiplus (or GDI
+ under Windows). Any bug will likely be inside libgdiplus so it's
"normal" (i.e. expected) that you get the same behavior.

> My tests show that even using unsynchronized GdipGetImageGraphicsContext
> / GdipDeleteGraphics (no fonts stuff touched) can easily lead to crashes.
>
> From what I've seen, cairo seems to be thread-safe: see attached[1]
> `cairo-multi-thread-text.c'.

It's thread-safe as long as everything is created and executed in the
same thread. Otherwise it would not be safe-thread (just like .net and
most libraries are).

> Also, there's a few locking used around thread-unsafe fontconfig calls
> in libgdiplus itself. I didn't examined the whole code, so there's
> possibly other places in it missing locking primitives.

Yep. Font-related code (and older, pre-1.4, versions of Cairo) had quite
a few problems (solved with the locking code). Other than that SWF and
ASP.NET were the big clients for SD/libgdiplus and, for SWF,
multithreading was not an issue at all.

> I would appreciate any help on this subject!
>
> --
> Regards,
> Alex
> [1] originally found in the cairo bugzilla for a few-years-old bug; my
> sligthly enhanced version
> _______________________________________________
> Mono-winforms-list maillist - Mono-winforms-list@...
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

Re: [Mono-winforms-list] Is System.Drawing (libgdiplus) thread-safe?

2009-10-28T10:45:03Z

Alex Shulgin wrote:
> Hi all,
>
> Is System.Drawing by any means thread-safe?
>
> Can I create some threads, create a Graphics object in each of them and
> then work with it from within that thread? Is this supposed to work or
> am I doing something really stupid here?

Oh, forgot to mention that I've tested this on both 2.4 and latest
available 2.6. The results are the same.

--
Alex

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx