Re: [Mono-dev] Add constants for directory and file max length name? (on windows)

[Jérôme De Cuyper]

If I understand correctly, I should not be checking for this on the
framework level but instead on the layer below it?
Somehow I should catch the syscall errors and then throw a .NET exception,
is that correct?


On Mon, Dec 13, 2010 at 10:17 PM, Rodrigo Kumpera  wrote:

> Can't we check for syscall errors instead?
>
>
> On Mon, Dec 13, 2010 at 10:43 PM, Jérôme De Cuyper <
> jerome.decuy...@gmail.com> wrote:
>
>> I'm working on the following bug:
>> https://bugzilla.novell.com/show_bug.cgi?id=
>> 383909 
>>
>> On a windows box, the
>> size of the name of file may not be longer than 260 and the size of the name
>> of a directory must be smaller than 248 chars. I was thinking about adding a
>> constant to the Path.cs file and then using it to apply restrictions
>> when necessary (inside DirectoryInfo's constructor for instance). But I'm
>> not sure that adding those constants is the best cross-platform way to
>> handle this. Maybe it's is enough to use hard-coded values inside a
>> "IsRunningOnWindows" conditional. Any thoughts?
>>
>> Jerome.
>>
>>
>>
>>
>> On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
>> charles.c.stra...@gmail.com> wrote:
>>
>>> Jon,
>>>
>>> If I understand correctly, we'd have two options for using DLLImport:
>>>
>>>  1.) Emit classes at runtime, containing the necessary native
>>> function adorned with the DLLImport attribute.
>>>  2.) Use DLLImport/PInvoke to provide access to
>>> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
>>> load DLLs and invoke their functions.
>>>
>>> Is this correct? Option #1 seems relatively feasible, although we
>>> would give up the ability to use our RubyFFI implementation where
>>> Reflection.Emit is not available; Option #2 seems rather daunting.
>>>
>>>
>>> Thanks,
>>>
>>> -Charles
>>>
>>> >On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
>>> >> Has anyone created or investigated Mono support for libffi?
>>> >
>>> >Once upon a time, Mono used libffi directly.  It was removed in r724
>>> >(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
>>> >(and earlier).  Unfortunately, the commit message is useless, but iirc
>>> >the reason for removing it was because it was significantly slower than
>>> >what Mono could do itself.
>>> >
>>> >> I'd like to contribute this to help support Ruby-FFI for IronRuby.
>>> >
>>> >I imagine IronRuby doesn't require it's own FFI, it would just use the
>>> >usual .NET FFI of DllImport, no?
>>> >
>>> >As for supporting Ruby-FFI, perhaps you can extend the existing Mono FFI
>>> >support to support Ruby?  I don't know what would be involved...
>>> >
>>> > - Jon
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Miguel de Icaza]

Hello,

I figured contributing to an area I work with would be easier. I was
> looking at WF or System.Messaging and was interested in finding out
> the status of those 'areas' to see what love they need. Failing that,
> I'm open to other suggestions that need more immediate love.
>

Most brilliant!

We got a System.Messaging implementation on top of RabbitMQ, although not
being a messaging-kind of guy myself, I can not really say much about it.

The consensus is that WF 4 is the way to go for WF, and that WF3.5 should be
ignored.   WF4 is also supposedly smaller, cleaner and easier to understand.
  The 3.5 effort is outdated, and has not been touched in probably 3-4
years.

We should just pick up starting with the WF4 code and stubs that Atsushi
contributed recently.

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

Re: [Mono-dev] Add constants for directory and file max length name? (on windows)

[Rodrigo Kumpera]

Can't we check for syscall errors instead?


On Mon, Dec 13, 2010 at 10:43 PM, Jérôme De Cuyper <
jerome.decuy...@gmail.com> wrote:

> I'm working on the following bug:
> https://bugzilla.novell.com/show_bug.cgi?id=
> 383909 
>
> On a windows box, the
> size of the name of file may not be longer than 260 and the size of the name
> of a directory must be smaller than 248 chars. I was thinking about adding a
> constant to the Path.cs file and then using it to apply restrictions
> when necessary (inside DirectoryInfo's constructor for instance). But I'm
> not sure that adding those constants is the best cross-platform way to
> handle this. Maybe it's is enough to use hard-coded values inside a
> "IsRunningOnWindows" conditional. Any thoughts?
>
> Jerome.
>
>
>
>
> On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
> charles.c.stra...@gmail.com> wrote:
>
>> Jon,
>>
>> If I understand correctly, we'd have two options for using DLLImport:
>>
>>  1.) Emit classes at runtime, containing the necessary native
>> function adorned with the DLLImport attribute.
>>  2.) Use DLLImport/PInvoke to provide access to
>> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
>> load DLLs and invoke their functions.
>>
>> Is this correct? Option #1 seems relatively feasible, although we
>> would give up the ability to use our RubyFFI implementation where
>> Reflection.Emit is not available; Option #2 seems rather daunting.
>>
>>
>> Thanks,
>>
>> -Charles
>>
>> >On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
>> >> Has anyone created or investigated Mono support for libffi?
>> >
>> >Once upon a time, Mono used libffi directly.  It was removed in r724
>> >(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
>> >(and earlier).  Unfortunately, the commit message is useless, but iirc
>> >the reason for removing it was because it was significantly slower than
>> >what Mono could do itself.
>> >
>> >> I'd like to contribute this to help support Ruby-FFI for IronRuby.
>> >
>> >I imagine IronRuby doesn't require it's own FFI, it would just use the
>> >usual .NET FFI of DllImport, no?
>> >
>> >As for supporting Ruby-FFI, perhaps you can extend the existing Mono FFI
>> >support to support Ruby?  I don't know what would be involved...
>> >
>> > - Jon
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] libffi

[Rodrigo Kumpera]

One thing, it's possible to use a binding to libffi with mono, it's just
that mono's p/invoke is not built using it anymore.



On Tue, Dec 14, 2010 at 1:48 AM, Jonathan Pryor  wrote:

> On Dec 13, 2010, at 7:08 PM, Charles Strahan wrote:
> > If I understand correctly, we'd have two options for using DLLImport:
>
> I am missing some important context, so I don't understand what you want to
> accomplish, what the problems are, and thus what the "best" way to do it is.
>  As per my original response, libffi was removed from mono for performance
> reasons, and it is thus unlikely to return.
>
> I do not know or understand the semantics of RubyFFI, how it's similar to
> libffi & P/Invoke, and how it differs from P/Invoke, much less how to map
> RubyFFI use to P/Invoke use (if that's even desirable; again, I have no
> idea).
>
> >  1.) Emit classes at runtime, containing the necessary native
> > function adorned with the DLLImport attribute.
>
> I can't say if this would work for _you_, but I can say that this can work
> in general; see:
>
>
> https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/CdeclFunction.cs
>
> >  2.) Use DLLImport/PInvoke to provide access to
> > dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
> > load DLLs and invoke their functions.
>
> This seems silly, given that [DllImport] & P/Invoke are built upon
> dlopen+dlsym/LoadLibrary+GetProcAddress; I do not see the point.
>
>  - Jon
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] libffi

[Jonathan Pryor]

On Dec 13, 2010, at 7:08 PM, Charles Strahan wrote:
> If I understand correctly, we'd have two options for using DLLImport:

I am missing some important context, so I don't understand what you want to 
accomplish, what the problems are, and thus what the "best" way to do it is.  
As per my original response, libffi was removed from mono for performance 
reasons, and it is thus unlikely to return.

I do not know or understand the semantics of RubyFFI, how it's similar to 
libffi & P/Invoke, and how it differs from P/Invoke, much less how to map 
RubyFFI use to P/Invoke use (if that's even desirable; again, I have no idea).

>  1.) Emit classes at runtime, containing the necessary native
> function adorned with the DLLImport attribute.

I can't say if this would work for _you_, but I can say that this can work in 
general; see:


https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/CdeclFunction.cs

>  2.) Use DLLImport/PInvoke to provide access to
> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
> load DLLs and invoke their functions.

This seems silly, given that [DllImport] & P/Invoke are built upon 
dlopen+dlsym/LoadLibrary+GetProcAddress; I do not see the point.

 - Jon

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Atsushi Eno]

Oh, ok. It is indeed outdated (it has been unchanged for 3 years).
We indeed have stubs for WF4 in olive module since it is smaller than 
WF3 and easier, but right now the mono team has no plan to work on it. 
So it is left as "contribution welcome" area.
https://github.com/mono/olive/tree/master/class/System.Activities

IMO I don't think we should dare explicitly state that the wiki page is 
outdated on that page itself (since there are indeed some code that used 
to work and some people might want to continue hacking these old stuff). 
It could be done after someone actually started WF4 hacking as an 
alternative effort.

Atsushi Eno

(2010/12/14 12:07), Travis Smith wrote:
> http://mono-project.com/Workflow could use to be updated on the
> location of the mailing list then.
>
> What's the status of these sections? Are there portions that need love
> that I could look at digging into?
>
> Thanks,
>
> -Travis
>
> On Mon, Dec 13, 2010 at 10:00 PM, Atsushi Eno
>   wrote:
>> The mono-olive mailing list was shut down to migrate to here (I posted about
>> that as the last message there), so you are welcome here in the right place
>> now to discuss WF or Messaging :)
>>
>> Atsushi Eno
>>
>> (2010/12/14 11:52), Travis Smith wrote:
>>> Miguel-
>>>
>>> I figured contributing to an area I work with would be easier. I was
>>> looking at WF or System.Messaging and was interested in finding out
>>> the status of those 'areas' to see what love they need. Failing that,
>>> I'm open to other suggestions that need more immediate love.
>>>
>>> -Travis
>>>
>>> On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icaza
>>>   wrote:
 Hello Travis,
  Most of the libraries "graduate" into regular Mono, and with it, most
 of
 the discussions.   This is the new home of the discussion.
  Is there a particular area that you are interested in contributing
 to?

 On Mon, Dec 13, 2010 at 7:25 PM, Travis Smith
   wrote:
> I was looking at possible ways to provide value for mono, saw Olive on
> the site (http://mono-project.com/Olive). I went over to the mailing
> list but it's just filled with spam. Anyone know what the status of
> that is? Is the page just out of date?
>
> Thanks,
>
> -Travis
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>>
>>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Travis Smith]

http://mono-project.com/Workflow could use to be updated on the
location of the mailing list then.

What's the status of these sections? Are there portions that need love
that I could look at digging into?

Thanks,

-Travis

On Mon, Dec 13, 2010 at 10:00 PM, Atsushi Eno
 wrote:
> The mono-olive mailing list was shut down to migrate to here (I posted about
> that as the last message there), so you are welcome here in the right place
> now to discuss WF or Messaging :)
>
> Atsushi Eno
>
> (2010/12/14 11:52), Travis Smith wrote:
>>
>> Miguel-
>>
>> I figured contributing to an area I work with would be easier. I was
>> looking at WF or System.Messaging and was interested in finding out
>> the status of those 'areas' to see what love they need. Failing that,
>> I'm open to other suggestions that need more immediate love.
>>
>> -Travis
>>
>> On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icaza
>>  wrote:
>>>
>>> Hello Travis,
>>>     Most of the libraries "graduate" into regular Mono, and with it, most
>>> of
>>> the discussions.   This is the new home of the discussion.
>>>     Is there a particular area that you are interested in contributing
>>> to?
>>>
>>> On Mon, Dec 13, 2010 at 7:25 PM, Travis Smith
>>>  wrote:

 I was looking at possible ways to provide value for mono, saw Olive on
 the site (http://mono-project.com/Olive). I went over to the mailing
 list but it's just filled with spam. Anyone know what the status of
 that is? Is the page just out of date?

 Thanks,

 -Travis
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Atsushi Eno]

The mono-olive mailing list was shut down to migrate to here (I posted 
about that as the last message there), so you are welcome here in the 
right place now to discuss WF or Messaging :)

Atsushi Eno

(2010/12/14 11:52), Travis Smith wrote:
> Miguel-
>
> I figured contributing to an area I work with would be easier. I was
> looking at WF or System.Messaging and was interested in finding out
> the status of those 'areas' to see what love they need. Failing that,
> I'm open to other suggestions that need more immediate love.
>
> -Travis
>
> On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icaza  wrote:
>> Hello Travis,
>>  Most of the libraries "graduate" into regular Mono, and with it, most of
>> the discussions.   This is the new home of the discussion.
>>  Is there a particular area that you are interested in contributing to?
>>
>> On Mon, Dec 13, 2010 at 7:25 PM, Travis Smith  wrote:
>>> I was looking at possible ways to provide value for mono, saw Olive on
>>> the site (http://mono-project.com/Olive). I went over to the mailing
>>> list but it's just filled with spam. Anyone know what the status of
>>> that is? Is the page just out of date?
>>>
>>> Thanks,
>>>
>>> -Travis
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Travis Smith]

Miguel-

I figured contributing to an area I work with would be easier. I was
looking at WF or System.Messaging and was interested in finding out
the status of those 'areas' to see what love they need. Failing that,
I'm open to other suggestions that need more immediate love.

-Travis

On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icaza  wrote:
> Hello Travis,
>     Most of the libraries "graduate" into regular Mono, and with it, most of
> the discussions.   This is the new home of the discussion.
>     Is there a particular area that you are interested in contributing to?
>
> On Mon, Dec 13, 2010 at 7:25 PM, Travis Smith  wrote:
>>
>> I was looking at possible ways to provide value for mono, saw Olive on
>> the site (http://mono-project.com/Olive). I went over to the mailing
>> list but it's just filled with spam. Anyone know what the status of
>> that is? Is the page just out of date?
>>
>> Thanks,
>>
>> -Travis
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Olive Status

[Miguel de Icaza]

Hello Travis,

Most of the libraries "graduate" into regular Mono, and with it, most of
the discussions.   This is the new home of the discussion.

Is there a particular area that you are interested in contributing to?

On Mon, Dec 13, 2010 at 7:25 PM, Travis Smith  wrote:

> I was looking at possible ways to provide value for mono, saw Olive on
> the site (http://mono-project.com/Olive). I went over to the mailing
> list but it's just filled with spam. Anyone know what the status of
> that is? Is the page just out of date?
>
> Thanks,
>
> -Travis
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Add constants for directory and file max length name? (on windows)

[Jérôme De Cuyper]

I'm working on the following bug:
https://bugzilla.novell.com/show_bug.cgi?id=
383909 

On a windows box, the
size of the name of file may not be longer than 260 and the size of the name
of a directory must be smaller than 248 chars. I was thinking about adding a
constant to the Path.cs file and then using it to apply restrictions
when necessary (inside DirectoryInfo's constructor for instance). But I'm
not sure that adding those constants is the best cross-platform way to
handle this. Maybe it's is enough to use hard-coded values inside a
"IsRunningOnWindows" conditional. Any thoughts?

Jerome.




On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
charles.c.stra...@gmail.com> wrote:

> Jon,
>
> If I understand correctly, we'd have two options for using DLLImport:
>
>  1.) Emit classes at runtime, containing the necessary native
> function adorned with the DLLImport attribute.
>  2.) Use DLLImport/PInvoke to provide access to
> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
> load DLLs and invoke their functions.
>
> Is this correct? Option #1 seems relatively feasible, although we
> would give up the ability to use our RubyFFI implementation where
> Reflection.Emit is not available; Option #2 seems rather daunting.
>
>
> Thanks,
>
> -Charles
>
> >On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
> >> Has anyone created or investigated Mono support for libffi?
> >
> >Once upon a time, Mono used libffi directly.  It was removed in r724
> >(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
> >(and earlier).  Unfortunately, the commit message is useless, but iirc
> >the reason for removing it was because it was significantly slower than
> >what Mono could do itself.
> >
> >> I'd like to contribute this to help support Ruby-FFI for IronRuby.
> >
> >I imagine IronRuby doesn't require it's own FFI, it would just use the
> >usual .NET FFI of DllImport, no?
> >
> >As for supporting Ruby-FFI, perhaps you can extend the existing Mono FFI
> >support to support Ruby?  I don't know what would be involved...
> >
> > - Jon
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Olive Status

[Travis Smith]

I was looking at possible ways to provide value for mono, saw Olive on
the site (http://mono-project.com/Olive). I went over to the mailing
list but it's just filled with spam. Anyone know what the status of
that is? Is the page just out of date?

Thanks,

-Travis
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] libffi

[Charles Strahan]

Jon,

If I understand correctly, we'd have two options for using DLLImport:

  1.) Emit classes at runtime, containing the necessary native
function adorned with the DLLImport attribute.
  2.) Use DLLImport/PInvoke to provide access to
dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
load DLLs and invoke their functions.

Is this correct? Option #1 seems relatively feasible, although we
would give up the ability to use our RubyFFI implementation where
Reflection.Emit is not available; Option #2 seems rather daunting.


Thanks,

-Charles

>On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
>> Has anyone created or investigated Mono support for libffi?
>
>Once upon a time, Mono used libffi directly.  It was removed in r724
>(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
>(and earlier).  Unfortunately, the commit message is useless, but iirc
>the reason for removing it was because it was significantly slower than
>what Mono could do itself.
>
>> I'd like to contribute this to help support Ruby-FFI for IronRuby.
>
>I imagine IronRuby doesn't require it's own FFI, it would just use the
>usual .NET FFI of DllImport, no?
>
>As for supporting Ruby-FFI, perhaps you can extend the existing Mono FFI
>support to support Ruby?  I don't know what would be involved...
>
> - Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Problem when running winforms app on arm processor

[jaekim]

I'm getting this same assertion with an arm processor.  The following code
triggers this exception.

PositionReport.Position position =
Serializer.Deserialize(streamParse);

Jae


mj1856 wrote:
> 
> I have cross compiled mono 2.8 with libgdiplus for the s3c2410 processor I
> am running. It is an arm920t (armv4t architecture).  I use scratchbox with
> a recent codesourcery toolchain.
> 
> I have two test applications that I wrote in visual studio targeting .net
> 2.0.  The first is a console app with a basic "Hello world".  It works
> perfectly.  The second is a winforms app with a single form that has a
> simple label that gets updated with a timer control to show the current
> date and time. (basically a digital clock).  Running it, I get the
> following error:
> 
> * Assertion: should not be reached at tramp-arm.c:48
> 
> Checking /mono/mini/tramp-arm.c, the function in question is
> mono_arch_patch_callsite, which has two blocks of code, where one of them
> is supposed to run.  I'm not sure exactly what it's checking here, but
> neither block gets executed, so it hits the assertion.  Can anyone shed
> some light on what might be the problem?
> 
> One note that may or may not be of interest, but because the codesourcery
> toolchain is multilib, I have to specify -march=armv4t on the CFLAGS
> passed to configure mono.  This appears to be working, as my console app
> works fine.
> 
> I do have a running X server, which I've tested with other native apps, so
> I know at least that part is functional.
> 
> Thanks,
> Matt
> 

-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/Problem-when-running-winforms-app-on-arm-processor-tp3064820p3085957.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] profiler in master

[Duane Wandless]

The final answer was to modify the Makefile.am in mono/profiler.

if PLATFORM_DARWIN
libmono_profiler_log_la_LDFLAGS = -Wl,-undefined -Wl,suppress
-Wl,-flat_namespace
endif

Thanks Lupus for the help!
Duane

On Fri, Dec 10, 2010 at 9:23 AM, Paolo Molaro  wrote:

> On 12/10/10 Duane Wandless wrote:
> > That has the same result as before.
>
> Could you post the output of the following commands in mono/profiler?
> make clean
> make V=1
> make install
> mono-sgen --version
> mono-sgen --profile=log:heapshot,report app.exe
>
> Thanks
> lupus
>
> --
> -
> lu...@debian.org debian/rules
> lu...@ximian.com Monkeys do it better
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list