[Mono-dev] How to use cross compiler arm-linux-gcc to build mono for ARM?

2006-04-18 Thread ZhangZQ

Hi,

I've build my own board using Samsung S3C2410 ARM9 CPU, and it can run Linux 
2.6.14 now. I have only the cross-compiler arm-linux-gcc that running in 
i386, and I found there is someone has ported mono to Nokia 770, I want to 
know How to use cross compiler arm-linux-gcc to build mono for ARM?


Thank you!
ZhangZQ 


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


[Mono-dev] gtkSharpNotification and PKG_CONFIG_PATH help

2006-04-18 Thread Dave Ludwigsen
This is my first posting to the list, so hello, and hope I'm not out of line with anything.
 
I'm in the midst of putting together an OSX/Win application and am new to Mono/Gtk/Cocoa development (although not new to c/++/# or windows development). I'm receiving the following error when trying to run mono TrayTest.exe
 from the following source (after downloading both and compiling). http://www.mono-project.com/GtkSharpNotificationIcon
 

unhandled exception : system.dllnotfoundexception:gdk-x11-2.0 in  Egg.TrayIcon:gdk_x11_display_get_display

 
1) I have mono version 1.1.14 installed.
2) I'm using cygwin, have all -devel packages installed and can see gdk-x11-2.0.pc in /lib/pkgconfig.
3) PKG_CONFIG_PATH is set and looks like this : /usr/X11R6/lib/pkgconfig:/lib/pkgconfig:/bin/Mono-1.1.14/lib/pkgconfig (mono is installed in c:/cygwin/bin)
4) If I run pkg-config --libs gdk-x11-2.0, I get "Package gdk-x11-2.0 was not found in the pkg-config search path."
5) I turned on PKG_CONFIG_DEBUG_SPEW, and I get the following as a dump : "Cannot open directory '/usr/X11R6/lib/pkgconfig:/lib/pkgconfig:/bin/Mono-1.1.14/lib/pkgconfig' in package search path: No such file or directory.

 
I've scoured the web and read through the blogs of the authors and the only thing I've found is to have the correct libraries installed. I found a few things in gnome to install both the gtk+ devel and glib -devel libraries, but I have (I believe), all the .pc files installed (from the error messages it just looks like pkg-config isn't looking in the right spot).

 
Or if anyone has another idea as to how to get a notification area up and running on win/osX, I'd be much obliged.
 
Any help or advice would be greatly appreciated. Thanks! ...Dave
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Cairo.ImageSurface

2006-04-18 Thread John Luke
On 4/15/06, Philipp Baer <[EMAIL PROTECTED]> wrote:
John Luke wrote:[...]>> I must admit that I don't exactly know how the content of a string>> is passed to the non-managed context. Because of the fact that a>> string is composed of chars (which represent 2-byte unicode characters),
>> the raw string buffer presumably is a char array. IMO a byte array>> would be much better suited (it simply is more generic).>>> Yes. If you can resend it as a patch, something like that could probably
> be committed.Ok, here it is.This is ok to commit in my opinion, however I don't have a mono setup right now to do it.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] remoting after ip change

2006-04-18 Thread Carlos Solorzano
I have problem that when I change the IP of the system doing remoting to 
itself some parts of remoting fail.


The error I get is at the bottom. What is really strange is that part of 
the remoting works, as far as I can tell I can retrieve the remoting 
object using Activator.GetObject and I can make a method call which 
returns an array of Marshalbyref objects. The error doesn't happen until 
I start looping those Objects and printing out values from them. If I 
kill the code and run it again then it works just fine, this only 
happens when the IP changes while the code is running. Any ideas?



System.Net.WebException: Error: ConnectFailure
in <0x000e1> System.Net.HttpWebRequest:EndGetRequestStream (IAsyncResult 
asyncResult)

in <0x00077> System.Net.HttpWebRequest:GetRequestStream ()
in <0x002ab> 
System.Runtime.Remoting.Channels.Http.HttpClientTransportSink:CreateWebRequest 
(System.String url, ITransportHeaders requestHeaders, System.IO.Stream 
requestStream)
in <0x000d0> 
System.Runtime.Remoting.Channels.Http.HttpClientTransportSink:ProcessMessage 
(IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream 
requestStream, ITransportHeaders responseHeaders, System.IO.Stream 
responseStream)
in <0x00068> 
System.Runtime.Remoting.Channels.SoapClientFormatterSink:SyncProcessMessage 
(IMessage msg)
in <0x002e8> System.Runtime.Remoting.Proxies.RemotingProxy:Invoke 
(IMessage request)
in <0x002e5> System.Runtime.Remoting.Proxies.RealProxy:PrivateInvoke 
(System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, 
System.Exception exc, System.Object[] out_args)


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


Re: [Mono-dev] Feedback for Windows Forms in 1.1.15

2006-04-18 Thread Peter Dennis Bartok
Andreas,

Thanks for the testing. I'd be great if you could log bugs for these, that 
way we don't loose track of them. Also, if you could provide links where to 
get the sample apps you used, that would help in reproducing the problems.

What were the problems with the real-world apps?

Cheers,
 Peter

-Original Message-
From: "Andreas Nahr" <[EMAIL PROTECTED]>
To: 
Date: 18 April, 2006 13:04
Subject: [Mono-dev] Feedback for Windows Forms in 1.1.15


>I tested some of my Winforms Apps on Mono 1.1.15 running on WinXP x64.
>Most of the real-world apps didn't start, but some small sample ones did.
>Here are some notes about Problems with the ones that did:
>
>Toolwindow:
>Wrong clipping region/ Window size calculation? See screenshot
>
>Propertygrid:
>* Dividing line at wrong position -> should be at 50% of width of control.
>* Readonly Elements not grayed out -> Gray out
>* Readonly Elements show designers (if designers are used -> crash) -> 
>Don't
>display designers for readonly elements
>* Category Names not determined correctly if inherited -> Use inherited
>CategoryName Attributes
>* Description default is currently: "TitleThe long important
>Description" -> should be ""
>* Default: All Entries expanded -> Should be: All entries NOT expanded
>* Setting values does not work
>* ToolbarVisible/HelpVisible ignored sometimes -> See screenshot
>
>DirectorySearcher:
>Crashes with any selection
>
>Happy hacking!
>Andreas
> 

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


Re: [Mono-dev] "safe" way about Marshal.UnsafeAddrOfPinnedArrayElement

2006-04-18 Thread Sebastien Pouliot
Hello,

On Tue, 2006-04-18 at 12:27 +0800, GaoXianchao wrote:
> hi all,
> I'm wrapping epoll api on linux.
> To pass address of managed struct array to unmanaged code, I use
> Marshal.UnsafeAddrOfPinnedArrayElement . But the method is "unsafe".
> Is there a "safe" way to do what the Marshal.UnsafeAddrOfPinnedArrayElement 
> do?

Safe and unsafe are used for different meanings between languages (e.g.
C#) and the framework base class library.

In this case, like many times it's used in the FX BCL, the Unsafe prefix
means that special security requirements for this method makes it
dangerous to use with non fully-trusted code (see MSDN documentation for
more details).

So unless you are using "mono --security" to activate the (partial and
unsupported) security manager this *doesn't* affect you at all (as all
your code is *always* executed under FullTrust).

-- 
Sebastien Pouliot  <[EMAIL PROTECTED]>
Blog: http://pages.infinit.net/ctech/

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


Re: [Mono-dev] "safe" way about Marshal.UnsafeAddrOfPinnedArrayElement

2006-04-18 Thread Kornél Pál

Hi,

Unsafe code usually means code that uses pointers. But that unsafe code has 
to use the fixed statement when accessing objects that can be moved. fixed 
statement pins the object so that GC will not move it within the block of 
fixed statement. (As far as I know Mono still uses non-moving GC but that 
will change in the future and MS.NET uses moving GC.)


Marshal.UnsafeAddrOfPinnedArrayElement is unsafe in addition to pointer 
operations because it assumes that the array is already pinned so it won't 
(an in fact can't as it has no scope) pin the object so the GC can move it 
that can result in invalidation of the returned pointer so has to be used 
carefully. (When the array is moved by the GC you can overwrite some other 
object that can have unpredictable results.)


Marshal.UnsafeAddrOfPinnedArrayElement is intended to be used with a pinned 
GCHandle. (Or alternatively on an array that is already pinned using fixed 
statement but in that case you have a pointer to an array element so you 
probably don't need this method.)


If you have a non-pinned array you should use fixed statement instead as 
Jonathan explained it.


So Marshal.UnsafeAddrOfPinnedArrayElement is even more unsafe than unsafe 
code when used on a non-pinned array.


Kornél

- Original Message - 
From: "Jonathan Pryor" <[EMAIL PROTECTED]>

To: "GaoXianchao" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, April 18, 2006 1:48 PM
Subject: Re: [Mono-dev] "safe" way about 
Marshal.UnsafeAddrOfPinnedArrayElement




On Tue, 2006-04-18 at 12:27 +0800, GaoXianchao wrote:

hi all,
I'm wrapping epoll api on linux.
To pass address of managed struct array to unmanaged code, I use
Marshal.UnsafeAddrOfPinnedArrayElement . But the method is "unsafe".
Is there a "safe" way to do what the 
Marshal.UnsafeAddrOfPinnedArrayElement do?


It's "unsafe" because you need to be careful. :-)

An alternative is to use *real* unsafe code, e.g.

FooStruct[] array = ...;
unsafe {
fixed (FooStruct* pArray = array) {
FooStruct* element = &pArray [index];
}
}

I'm not entirely sure what your problem is though.  "Unsafe" code (like
the above `unsafe' block) just means that you're possibly executing
without a net, which could result in memory corruption and abortion of
the process. :-)

Marshal.UnsafeAddrOfPinnedArrayElement isn't even in an unsafe C#
context, it just has "Unsafe" in the name.

Here's a hint of truth: ANY time you do a P/Invoke, you're potentially
doing something unsafe. :-)

(Especially considering that you're invoking external code which could
really do anything, such as overwrite the entire GC heap, which would
cause the process an ugly death in the future...)

However, I'm not sure why you need
Marshal.UnsafeAddrOfPinnedArrayElement in the first place.
epoll_wait(2) takes a `struct epoll_event' array parameter, so unless
you wanted to only send a subset of your array, the default marshaling
rules which convert a managed array to an array pointer should be fine.

- 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] "safe" way about Marshal.UnsafeAddrOfPinnedArrayElement

2006-04-18 Thread Jonathan Pryor
On Tue, 2006-04-18 at 12:27 +0800, GaoXianchao wrote:
> hi all,
> I'm wrapping epoll api on linux.
> To pass address of managed struct array to unmanaged code, I use
> Marshal.UnsafeAddrOfPinnedArrayElement . But the method is "unsafe".
> Is there a "safe" way to do what the Marshal.UnsafeAddrOfPinnedArrayElement 
> do?

It's "unsafe" because you need to be careful. :-)

An alternative is to use *real* unsafe code, e.g.

FooStruct[] array = ...;
unsafe {
fixed (FooStruct* pArray = array) {
FooStruct* element = &pArray [index];
}
}

I'm not entirely sure what your problem is though.  "Unsafe" code (like
the above `unsafe' block) just means that you're possibly executing
without a net, which could result in memory corruption and abortion of
the process. :-)

Marshal.UnsafeAddrOfPinnedArrayElement isn't even in an unsafe C#
context, it just has "Unsafe" in the name.

Here's a hint of truth: ANY time you do a P/Invoke, you're potentially
doing something unsafe. :-)

(Especially considering that you're invoking external code which could
really do anything, such as overwrite the entire GC heap, which would
cause the process an ugly death in the future...)

However, I'm not sure why you need
Marshal.UnsafeAddrOfPinnedArrayElement in the first place.
epoll_wait(2) takes a `struct epoll_event' array parameter, so unless
you wanted to only send a subset of your array, the default marshaling
rules which convert a managed array to an array pointer should be fine.

 - Jon


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


Re: [Mono-dev] Re: mono frustration

2006-04-18 Thread PFJ
Hi,

> > I will wait a few more months I suppose till fedora core 5 binaries are
> > released or the yum dependencies are fixed ...
> 
> Maintaining package dependencies and stability of the bleeding-edge 
> versions of programs is a very hard work for the distributions' 
> employees and/or contributors. It's normal to have problems like these 
> ones when using the latest versions of packages, because unstability 
> increases.

Well, that's not quite true. What usually happens is that when a rebuild
is requested, not all of the other packages which depend on the rebuilt
one are rebuilt. The reasons can be many fold. Normal users (those using
core) don't see this very often, but it's something those using the
developer branch (rawhide) have to put up with a lot. But hey, it's part
of the fun!

> And when I have problems, I try to report them as detailed as possible, 
> and to the correct sources (probably these concrete reports are also 
> welcome on Fedora mailing-lists, for example, although I don't know if 
> you have already sent them there). But I understand that this could be 
> very annoying/frustrating.

I've not seen any reports (except for mine) on any of the FC mailing
lists (extras/test/developers/core).

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who

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


Re: [Mono-dev] mono frustration

2006-04-18 Thread PFJ
Hi,

On Tue, 2006-04-18 at 12:24 +0300, Anton Andreev wrote:
>   Did anyone installed mono on fedora core 5

Yes. It's quite nice. Okay, it needs updating to 1.1.15, but this isn't
the right list for discussion on that.

> There is a problem with gtkhtml3 and gtk-sharp, pango ...

Is there?

>  Mono frustrated me again,cause I wanted to try the new Fedora with new
> Monodevelop with the new Glade designer. 

Monodevelop is not in FC-extras yet. It is currently awaiting approval.

> I even reinstalled my fedora, replaced
> the 64 bit edition with 32 bit edition, but guess what - I had the same
> problem.

And that doesn't surprise me. 

> I will wait a few more months I suppose till fedora core 5 binaries are
> released or the yum dependencies are fixed ...

Okay, quick fix (won't work on 64bit fedora core currently). Open a
terminal window

su
yum -y install fedora-rpmdevtools
exit
fedora-buildrpmtree
wget http://www.smmp.salford.ac.uk/packages/boo-0.7.5.2013-2.src.rpm
wget
http://www.smmp.salford.ac.uk/packages/gtksourceview-sharp-2.0-3.src.rpm
wget http://www.smmp.salford.ac.uk/packages/ikvm-0.22-4.src.rpm
wget http://www.smmp.salford.ac.uk/packages/mod_mono-1.1.14-1.src.rpm
wget http://www.smmp.salford.ac.uk/packages/mono-debugger-0.12-1.src.rpm
wget http://www.smmp.salford.ac.uk/packages/monodevelop-0.10-4.src.rpm
wget http://www.smmp.salford.ac.uk/packages/monodoc-1.1.13-3.src.rpm
wget http://www.smmp.salford.ac.uk/packages/xsp-1.1.13-1.src.rpm
rpm -ihv *.src.rpm
rpmbuild -ba rpmbuild/SPECS/boo.spec
rpmbuild -ba rpmbuild/SPECS/gtksourceview-sharp.spec
su
rpm -ihv rpmbuild/noarch/*
rpm -ihv rpmbuild/i386/*
exit
rpmbuild -ba rpmbuild/SPECS/ikvm.spec
su
rpm -ihv rpmbuild/i386/ikvm*
exit

(you'll need to do this after each package being built - change ikvm for
the name of the package)

rpmbuild -ba rpmbuild/SPECS/monodoc.spec
rpmbuild -ba rpmbuild/SPECS/mono-debugger.spec
rpmbuild -ba rpmbuild/SPECS/monodevelop.spec

If you want to server ASP.NET files via Apache

rpmbuild -ba rpmbuild/SPECS/xsp.spec
rpmbuild -ba rpmbuild/SPECS/mod_mono.spec

If the build process stops and says you need a particular package,

yum -y install 

That lot may look a bit hairy, but if you follow my instructions, it
will be quite painless.

I've not put the rpms up on the Salford server as they're not required
for Fedora Extras approval.

You now have just about all of the rpms available installed on your
machine. Any problems, please email me directly (or report them here). I
am pushing quite hard for these to be included into Fedora Extras, but
things are a tad slow with the chaps currently.

It may be worth joining the fedora-extras list as well and poking there.

TTFN

Paul

-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who

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


[Mono-dev] Re: mono frustration

2006-04-18 Thread Andrés G. Aragoneses

Anton Andreev escribió:

  Did anyone installed mono on fedora core 5

There is a problem with gtkhtml3 and gtk-sharp, pango ...

 Mono frustrated me again,cause I wanted to try the new Fedora with new
Monodevelop with the new Glade designer. I could not install the
monodevelop. It never ever installed with "yum install monodevelop". Have
in mind that I am an ordinary Linux user, .NET developer and I ve been
intrested in Mono for a long time. I even reinstalled my fedora, replaced
the 64 bit edition with 32 bit edition, but guess what - I had the same
problem.

I will wait a few more months I suppose till fedora core 5 binaries are
released or the yum dependencies are fixed ...


Maintaining package dependencies and stability of the bleeding-edge 
versions of programs is a very hard work for the distributions' 
employees and/or contributors. It's normal to have problems like these 
ones when using the latest versions of packages, because unstability 
increases.


In my humble and personal opinion, if you are very interested in the 
Mono platform and like to try the latest releases of the Mono tools, try 
the SUSE distribution because it's the closest to this software. Since I 
use SUSE I don't have any problems with package dependencies or 
stability of the latest versions of the Mono packages.


And when I have problems, I try to report them as detailed as possible, 
and to the correct sources (probably these concrete reports are also 
welcome on Fedora mailing-lists, for example, although I don't know if 
you have already sent them there). But I understand that this could be 
very annoying/frustrating.


Regards,

Andrés  [ knocte ]

--

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


RE: [Mono-dev] System.Web.UI.WebControls/Menu

2006-04-18 Thread Konstantin Triger
Yes, possibly.

All I wanted is to let the default ("") work. So if someone creates , it does not throw for him.

I'll store it in the ViewState.

Regards,
Konstantin Triger


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lluis Sanchez
Sent: Tuesday, April 18, 2006 11:07 AM
To: Konstantin Triger
Cc: mono-devel
Subject: Re: [Mono-dev] System.Web.UI.WebControls/Menu

Shouldn't SkipLinkText be stored in the view state?

El lun, 17-04-2006 a las 07:41 -0700, Konstantin Triger escribió:
> Hello,
> 
>  
> 
> The attached patch handles the following:
> 
>  1. Enables DataBinding by not throwing NotImplementedException in
> OnDataBound event.
>  2. Provides basic CreateChildControls implementation by ensuring
> the control is bound.
>  3. Ensures the child controls are created when the postback event
> is raised.
>  4. Provides default implementation for SkipLinkText to let the
> default functionality to work.
> 
>  
> 
> Please review. If no one objects I'll commit.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> ___
> 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-dev] mono frustration

2006-04-18 Thread Anton Andreev

  Did anyone installed mono on fedora core 5

There is a problem with gtkhtml3 and gtk-sharp, pango ...

 Mono frustrated me again,cause I wanted to try the new Fedora with new
Monodevelop with the new Glade designer. I could not install the
monodevelop. It never ever installed with "yum install monodevelop". Have
in mind that I am an ordinary Linux user, .NET developer and I ve been
intrested in Mono for a long time. I even reinstalled my fedora, replaced
the 64 bit edition with 32 bit edition, but guess what - I had the same
problem.

I will wait a few more months I suppose till fedora core 5 binaries are
released or the yum dependencies are fixed ...





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


Re: [Mono-dev] System.Web.UI.WebControls/Menu

2006-04-18 Thread Lluis Sanchez
Shouldn't SkipLinkText be stored in the view state?

El lun, 17-04-2006 a las 07:41 -0700, Konstantin Triger escribió:
> Hello,
> 
>  
> 
> The attached patch handles the following:
> 
>  1. Enables DataBinding by not throwing NotImplementedException in
> OnDataBound event.
>  2. Provides basic CreateChildControls implementation by ensuring
> the control is bound.
>  3. Ensures the child controls are created when the postback event
> is raised.
>  4. Provides default implementation for SkipLinkText to let the
> default functionality to work.
> 
>  
> 
> Please review. If no one objects I’ll commit.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> ___
> 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] System.Web.UI.WebControls/FormView

2006-04-18 Thread Konstantin Triger








Hello,

 

Attached a reworked patch, which keeps the
old logic if FormView.AllowPaging is true.

In addition, EnsureDataBound() and CreateControlsStyle()
fallback to base.

 

If no one objects I’ll commit.

 



Regards,

Konstantin Triger



 









From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Konstantin Triger
Sent: Sunday, April 16, 2006 4:04
PM
To: mono-devel
Subject: [Mono-dev]
System.Web.UI.WebControls/FormView



 

Hello,

 

The attached patch ensures rebinding when FormView.PageIndex
is called. A relevant test is inside.

 

If no one objects I’ll commit.

 

Regards,

Konstantin Triger

 








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