Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Hello, Slowness of MWF drawing comes from Cairo. MWF uses libgdiplus for drawing, libgdiplus uses cairo/libpixmain backends for drawing and uses version 0.3.0 of Cairo. Currently Cairo is version 0.5.2. The problem is that Cairo isn't yet stable project as API is changed even on minor version change. On mailing lists of Cairo there is talk of soon releasing of version 1 which means freezing the API. But 'soon' could be month or year by my opinion. Although Cairo is known to be a part of the problem, another part of the equation might be the event loop processing. I do not remember the details, but Gtk+ spent quite a bit of time dealing with improving their main loop and event processing to improve performance. Miguel. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Peter, I am curious as to how you tested performance/framerate. Any chance you could provide the code? (Binary should be ok, doesn't have to be source yet). I'd love to go through and see where we spend the cycles. (And I will also test with our MWF but Microsoft's GDI+ on Win32, which will give an idea of how much impact our managed approach to drawing controls has) When Jackson worked on improving performance of the X11 driver's event loop, he went through the Gtk+ code, so I'd assume he modeled it after theirs and we should have the same benefits. Also, you mention OS X. Are you testing with the X11 driver or with the OS X driver? Also, so far we have spent little time optimizing things, we've only tried to get to a code-complete state, but we're reaching the point where we're looking into performance, so you picked the perfect time to bring up the issue :-) Cheers, Peter -Original Message- From: Peter De Jager [EMAIL PROTECTED] To: 'Miguel de Icaza' [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Date: 28 July, 2005 12:08 Subject: RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET That would make sense. It almost appears as if the MWF event loop is clocked at a fixed frequency, resulting in the (almost) fixed frame rate regardless of architecture or video drivers. Of course it will be more complex than that, but it does appear that the delay is at least in part due to the event loop. What would be the best way to proceed though? In the last few days I have tried gtk-sharp on Mac without much success, having had a lot of trouble installing gtk-sharp under PowerPC (at least with Mono 1.1.8 and FC4). I saw the post by Attila Balogh who provides a modified Mono framework for OS X Tiger (90MB), which includes gtk-sharp 1.0.10, but I haven't tried it yet. I thought I'd hold out for a while and keep testing on Linux (Intel/PPC) using MWF. I've also had a look at wx.Net but it appears that gtk-sharp is more widely supported. In a perfect world I would use MWF since this requires no change from my .NET code, but failing that, I was hoping to use a single GUI toolkit for both Linux and OS X. Does gtk-sharp fit the bill? Pete. -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 19:32 To: [EMAIL PROTECTED] Cc: Peter De Jager; mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET Hello, Slowness of MWF drawing comes from Cairo. MWF uses libgdiplus for drawing, libgdiplus uses cairo/libpixmain backends for drawing and uses version 0.3.0 of Cairo. Currently Cairo is version 0.5.2. The problem is that Cairo isn't yet stable project as API is changed even on minor version change. On mailing lists of Cairo there is talk of soon releasing of version 1 which means freezing the API. But 'soon' could be month or year by my opinion. Although Cairo is known to be a part of the problem, another part of the equation might be the event loop processing. I do not remember the details, but Gtk+ spent quite a bit of time dealing with improving their main loop and event processing to improve performance. Miguel. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET
I'm attaching a small code snippet. You *should* use Invoke() instead of painting to a Form directly, but in this (very simple) example, no other thread is painting to the form so it should be safe. You can compile with .NET or mcs. Put an image file, Image.png, in the same directory as the executable before running it. The image should be smaller than approx. 800x600 otherwise it will be clipped. When the form is displayed, it shows nothing (not even a background, except on Mono where the background is incorrectly painted). When you click on the form, it repeatedly paints the bitmap to the form and displays the mean frame rate over a 10 second period. On my hardware (and using my Image.png), the figures at the end of the 10 seconds are 162 for .NET and 7.65 for Mono. With regards to Mac, I know very little about X11 (as with Linux). To be honest, I don't even understand your question ;-). When trying to get MWF and gtk-sharp running I saw on the mailing lists that X11 needs to be installed, so I did that. I also tried to run 'mono.exe' from an X11 terminal (I don't know how this differs from a normal terminal on Mac). After macpack I've managed to get a MWF app displaying for an instant before quitting, so my success has been limited so far. However, all of my non-gui code is running without problems under Mono on OS X, albeit at approximately half the speed of Mono on Linux (FC 4), on the same PowerPC hardware. Pete. -Original Message- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 20:25 To: Peter De Jager; 'Miguel de Icaza' Cc: mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET Peter, I am curious as to how you tested performance/framerate. Any chance you could provide the code? (Binary should be ok, doesn't have to be source yet). I'd love to go through and see where we spend the cycles. (And I will also test with our MWF but Microsoft's GDI+ on Win32, which will give an idea of how much impact our managed approach to drawing controls has) When Jackson worked on improving performance of the X11 driver's event loop, he went through the Gtk+ code, so I'd assume he modeled it after theirs and we should have the same benefits. Also, you mention OS X. Are you testing with the X11 driver or with the OS X driver? Also, so far we have spent little time optimizing things, we've only tried to get to a code-complete state, but we're reaching the point where we're looking into performance, so you picked the perfect time to bring up the issue :-) Cheers, Peter -Original Message- From: Peter De Jager [EMAIL PROTECTED] To: 'Miguel de Icaza' [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Date: 28 July, 2005 12:08 Subject: RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET That would make sense. It almost appears as if the MWF event loop is clocked at a fixed frequency, resulting in the (almost) fixed frame rate regardless of architecture or video drivers. Of course it will be more complex than that, but it does appear that the delay is at least in part due to the event loop. What would be the best way to proceed though? In the last few days I have tried gtk-sharp on Mac without much success, having had a lot of trouble installing gtk-sharp under PowerPC (at least with Mono 1.1.8 and FC4). I saw the post by Attila Balogh who provides a modified Mono framework for OS X Tiger (90MB), which includes gtk-sharp 1.0.10, but I haven't tried it yet. I thought I'd hold out for a while and keep testing on Linux (Intel/PPC) using MWF. I've also had a look at wx.Net but it appears that gtk-sharp is more widely supported. In a perfect world I would use MWF since this requires no change from my .NET code, but failing that, I was hoping to use a single GUI toolkit for both Linux and OS X. Does gtk-sharp fit the bill? Pete. -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 19:32 To: [EMAIL PROTECTED] Cc: Peter De Jager; mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET Hello, Slowness of MWF drawing comes from Cairo. MWF uses libgdiplus for drawing, libgdiplus uses cairo/libpixmain backends for drawing and uses version 0.3.0 of Cairo. Currently Cairo is version 0.5.2. The problem is that Cairo isn't yet stable project as API is changed even on minor version change. On mailing lists of Cairo there is talk of soon releasing of version 1 which means freezing the API. But 'soon' could be month or year by my opinion. Although Cairo is known to be a part of the problem, another part of the equation might be the event loop processing. I do not remember the details, but Gtk+ spent quite a bit
RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Thank you for explaining this. I'm (slowly) finding my way ;-). My first choice is obviously to support only one GUI framework in my code, so I'll stick to MWF and see how things pan out. Thanks again Pete. -Original Message- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 23:14 To: Peter De Jager Cc: mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET [...testcode explanation...] Thanks for the snippet, I will play and report back later. With regards to Mac, I know very little about X11 (as with Linux). To be honest, I don't even understand your question ;-). When trying to get MWF and gtk-sharp running I saw on the mailing lists that X11 needs to be installed, so I did that. I also tried to run 'mono.exe' from an X11 terminal (I don't know how this differs from a normal terminal on Mac). After macpack I've managed to get a MWF app displaying for an instant before quitting, so my success has been limited so far. However, all of my non-gui code is running without problems under Mono on OS X, albeit at approximately half the speed of Mono on Linux (FC 4), on the same PowerPC hardware. Quick and dirty intro: MWF is implemented around the concept of a 'driver'. The driver provides an abstraction layer for different windowing systems, to allow the same MWF controls to run unchanged on Win32, X11 OS X or any other desktop/window system. (Drawing is handled by System.Drawing, not the driver.) Today we have three drivers, Win32 (maintained by myself), X11 (maintained by Jackson and myself) and OS X (maintained by a non-Novell contributor, Geoff Norton). We keep Win32 and X11 en par, but due to our complete and utter lack of Mac know-how, we cannot do the same with the OS X driver, we are (until we find some time to learn Mac or it becomes a business priority) dependent on community contributions to it. The Mac driver currently does not provide keyboard handling, and has some issues with drawing and exposures. On the Mac, you can use either the X11 driver (and draw through the Mac X11 server) or the OS X driver (which draws via native Carbon). You are correct, today X11 is required on the Mac even for the native driver, due to some font handling requirements. If you run the app via macpack, you are using the OS X driver, not the X11 driver. Running from a X11 terminal should a) work and b) use the X11 driver. Remember, I'm not a mac guy, though. Cheers, Peter ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Here are my results: Image: 800x600 pixels: * Win32, MS.Net: 32fps * Win32, MWF.dll, rest MS.Net: 31.25fps * Linux (NLD), Mono: 3.54fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 3.8fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 5.73fps (local Xfree X server) * Mac OS X, Mono: 2.5fps (with the X11 driver) Image: 100x80 * Win32, MS.Net: 1612fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.55fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 354.33fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 227.28fps (Local Xfree X server) * Mac OS X, Mono: not tested Image: 100x40 * Win32, MS.Net: 2497fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.50fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 518.18fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 353.33fps (Local Xfree X server) * Mac OS X, Mono: not tested Image: 100x20 * Win32, MS.Net: 2649fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.70fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 561.95fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 486.84fps (Local Xfree X server) * Mac OS X, Mono: 56fps (with the X11 driver) My conclusions: * While we are a bit slower with our MWF dll, it's pretty obvious that the bottleneck is not MWF, but the drawing code. * The X11 message loop is not the problem, we get high speeds with our existing loop, if the image is small. * My Win32 X server is pathetic (I'm guessing that's because it doesn't support the Xrender extension) * As someone just put it, I'd say it's pretty obvious that Cairo sucks donkey ass when it comes to handling large images. This is on Cairo 0.3.0 , which was absolutely not optimized. Cairo is currently at version 0.5.0 and we have someone who's moving our libgdplus to that newer version. Once that is complete we can compare (and look into optimizations on the cairo or our libgdiplus side) One caveat here: It might be X itself that sucks donkey ass with large images, maybe I find some time to test that tonight. Cheers, Peter -Original Message- From: Peter De Jager [EMAIL PROTECTED] To: 'Peter Dennis Bartok' [EMAIL PROTECTED]; 'Miguel de Icaza' [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Date: 28 July, 2005 15:15 Subject: RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET I'm attaching a small code snippet. You *should* use Invoke() instead of painting to a Form directly, but in this (very simple) example, no other thread is painting to the form so it should be safe. You can compile with .NET or mcs. Put an image file, Image.png, in the same directory as the executable before running it. The image should be smaller than approx. 800x600 otherwise it will be clipped. When the form is displayed, it shows nothing (not even a background, except on Mono where the background is incorrectly painted). When you click on the form, it repeatedly paints the bitmap to the form and displays the mean frame rate over a 10 second period. On my hardware (and using my Image.png), the figures at the end of the 10 seconds are 162 for .NET and 7.65 for Mono. With regards to Mac, I know very little about X11 (as with Linux). To be honest, I don't even understand your question ;-). When trying to get MWF and gtk-sharp running I saw on the mailing lists that X11 needs to be installed, so I did that. I also tried to run 'mono.exe' from an X11 terminal (I don't know how this differs from a normal terminal on Mac). After macpack I've managed to get a MWF app displaying for an instant before quitting, so my success has been limited so far. However, all of my non-gui code is running without problems under Mono on OS X, albeit at approximately half the speed of Mono on Linux (FC 4), on the same PowerPC hardware. Pete. -Original Message- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 20:25 To: Peter De Jager; 'Miguel de Icaza' Cc: mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET Peter, I am curious as to how you tested performance/framerate. Any chance you could provide the code? (Binary should be ok, doesn't have to be source yet). I'd love to go through and see where we spend the cycles. (And I will also test with our MWF but Microsoft's GDI+ on Win32, which will give an idea of how much impact our managed approach to drawing controls has) When Jackson worked on improving performance of the X11 driver's event loop, he went through the Gtk+ code, so I'd assume he modeled it after theirs and we should have the same benefits. Also, you mention OS X. Are you testing with the X11 driver or with the OS X driver? Also, so far we have spent little time optimizing
Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Hello, should we expect MWF to run almost as fast as SWF when it'll use cairo 0.5.0 or will it need more work or even worst, will it never be as fast as SWF? Actually we have many layers and it makes wondering if memory won't be used too much, this may seem a stupid worry but then I would just give you this link: http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html It would also be interesting to compare the same app run with MS.NET and Mono but it's behind the scope of this MWF list. - Original Message - From: Peter Dennis Bartok [EMAIL PROTECTED] To: Peter De Jager [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Sent: Friday, July 29, 2005 12:08 AM Subject: Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET Here are my results: Image: 800x600 pixels: * Win32, MS.Net: 32fps * Win32, MWF.dll, rest MS.Net: 31.25fps * Linux (NLD), Mono: 3.54fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 3.8fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 5.73fps (local Xfree X server) * Mac OS X, Mono: 2.5fps (with the X11 driver) Image: 100x80 * Win32, MS.Net: 1612fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.55fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 354.33fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 227.28fps (Local Xfree X server) * Mac OS X, Mono: not tested Image: 100x40 * Win32, MS.Net: 2497fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.50fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 518.18fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 353.33fps (Local Xfree X server) * Mac OS X, Mono: not tested Image: 100x20 * Win32, MS.Net: 2649fps * Win32, MWF.dll, rest MS.Net: 1581fps * Linux (NLD), Mono: 3.70fps (remote Win32 X server, over the network) * Linux (NLD), Mono: 561.95fps (remote Xfree X server, over the network) * Linux (NLD), Mono: 486.84fps (Local Xfree X server) * Mac OS X, Mono: 56fps (with the X11 driver) My conclusions: * While we are a bit slower with our MWF dll, it's pretty obvious that the bottleneck is not MWF, but the drawing code. * The X11 message loop is not the problem, we get high speeds with our existing loop, if the image is small. * My Win32 X server is pathetic (I'm guessing that's because it doesn't support the Xrender extension) * As someone just put it, I'd say it's pretty obvious that Cairo sucks donkey ass when it comes to handling large images. This is on Cairo 0.3.0 , which was absolutely not optimized. Cairo is currently at version 0.5.0 and we have someone who's moving our libgdplus to that newer version. Once that is complete we can compare (and look into optimizations on the cairo or our libgdiplus side) One caveat here: It might be X itself that sucks donkey ass with large images, maybe I find some time to test that tonight. Cheers, Peter -Original Message- From: Peter De Jager [EMAIL PROTECTED] To: 'Peter Dennis Bartok' [EMAIL PROTECTED]; 'Miguel de Icaza' [EMAIL PROTECTED] Cc: mono-winforms-list@lists.ximian.com Date: 28 July, 2005 15:15 Subject: RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET I'm attaching a small code snippet. You *should* use Invoke() instead of painting to a Form directly, but in this (very simple) example, no other thread is painting to the form so it should be safe. You can compile with .NET or mcs. Put an image file, Image.png, in the same directory as the executable before running it. The image should be smaller than approx. 800x600 otherwise it will be clipped. When the form is displayed, it shows nothing (not even a background, except on Mono where the background is incorrectly painted). When you click on the form, it repeatedly paints the bitmap to the form and displays the mean frame rate over a 10 second period. On my hardware (and using my Image.png), the figures at the end of the 10 seconds are 162 for .NET and 7.65 for Mono. With regards to Mac, I know very little about X11 (as with Linux). To be honest, I don't even understand your question ;-). When trying to get MWF and gtk-sharp running I saw on the mailing lists that X11 needs to be installed, so I did that. I also tried to run 'mono.exe' from an X11 terminal (I don't know how this differs from a normal terminal on Mac). After macpack I've managed to get a MWF app displaying for an instant before quitting, so my success has been limited so far. However, all of my non-gui code is running without problems under Mono on OS X, albeit at approximately half the speed of Mono on Linux (FC 4), on the same PowerPC hardware. Pete. -Original Message- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 20:25 To: Peter De
R: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Hello list,
I wrote a sw in .NET for windows (a sort of graphical editor) and now I need
to port it to OSX.
Being Cairo so slow i decided to write an alternative libgdiplus.dylib
dedicated to OSX using only Core Graphics Calls.
It won't be complete, I will only implement those methods I used in the
original .NET sw.
I am at a good point and it works like a charm.
I will surely release it under the GPL license (because I took some code
from the original libgdiplus).
Using Cocoa i could also implement some feature that was missing in
libgdiplus ( mostly GraphicsPath.AddString() thanks to NSBezierPath ).
I am not saying that Cairo should not be used, I only had to avoid it
because I needed performances and my software must be released soon.
If you are interested I can share the code.
Ciao,
Daivde.
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per
conto di Peter De Jager
Inviato: mercoledì 27 luglio 2005 11.34
A: mono-winforms-list@lists.ximian.com
Oggetto: [Mono-winforms-list] MWF painting VERY slow compared to .NET
When painting a bitmap to a Form and measuring the frame
rate, I get vastly different figures on .NET vs. Mono. E.g.
on .NET I get 114 fps while under mono it's only 4.5 fps (on
the same hardware). What's even stranger is that I get the
same (4.5 fps) figure on a PowerPC Mac mini (1.42 GHz G4, 167MHz
bus) and an Intel box (dual 3GHz Xeon, 533MHz bus). Both
systems are running Fedora Core 4. I thought that perhaps it
relates to video drivers but I installed the latest ATI
driver on my Xeon box (Radeon 9800 Pro) and there is still no
difference.
Something else is that on WMF, the background is always
painted even though I override OnPaintBackground of my Form
with an empty implementation, e.g.:
protected override void OnPaintBackground(PaintEventArgs e) { }
On Windows, this prevents the Form from repainting the
background, thus speeding up painting and reducing flicker,
while MWF always appears to repaint the background.
I've done (very limited) testing on Gtk (Glade), and it
appears to be fast on Linux (comparable to
System.Windows.Forms on .NET), but while being fast on Linux,
Glade is MUCH slower on Windows (I don't have exact figures
but it's very noticable).
Is the MWF implementation likely to increase in speed (by 20
times!) as it matures, or should I use Gtk for Linux / OS X
and System.Windows.Forms for Windows? I was hoping that I
could use a single code base for all platforms (which has
been the case so far).
Don't take this the wrong way, I don't mean to be critical. I
think it's great that there is a managed implementation of
Windows Forms, but at 20 times slower it renders my Windows
applications unusable under Mono.
Thanks
Pete.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date:
22/07/2005
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
should we expect MWF to run almost as fast as SWF when it'll use cairo 0.5.0 or will it need more work or even worst, will it never be as fast as SWF? I will answer you once we run with cairo 0.5.0. Also, you need to understand that switching to a newer version of cairo is not a magic bullet. And there always is more work to be done, Cairo is only version 0.5, and they're just beginning to look into optimizations. We haven't looked at optimizations at all in MWF or System.Drawing. We need to finish code first. Of course speed was a consideration when writing controls, but you can't spend a month optimizing when writing the controls, or it'll never get done. Actually we have many layers and it makes wondering if memory won't be used too much, this may seem a stupid worry but then I would just give you this link: http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html It would also be interesting to compare the same app run with MS.NET and Mono but it's behind the scope of this MWF list. That's not something I'm too worried about at this point. But we will look at memory usage in the future, it is important. As for layers, depending on how you count, we only have one or two more than MS (one with cairo, and twi if you count the Xserver) Don't get your undies in a bunch just yet :-) Cheers, Peter ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MWF painting VERY slow compared to .NET
That sounds pretty exciting. Any chance you could share the code? I'd like
to investigate and see how much work it is to use your version it instead of
our cairo version when running on the Mac. I'm guessing you are still using
System.Drawing, just having it call your gdiplus lib?
Would you mind posting a URL to the code?
Cheers,
Peter
-Original Message-
From: Parser - Davide Morelli [EMAIL PROTECTED]
To: mono-winforms-list@lists.ximian.com
Date: Thursday, 28 July, 2005 18:33
Subject: R: [Mono-winforms-list] MWF painting VERY slow compared to .NET
Hello list,
I wrote a sw in .NET for windows (a sort of graphical editor) and now I need
to port it to OSX.
Being Cairo so slow i decided to write an alternative libgdiplus.dylib
dedicated to OSX using only Core Graphics Calls.
It won't be complete, I will only implement those methods I used in the
original .NET sw.
I am at a good point and it works like a charm.
I will surely release it under the GPL license (because I took some code
from the original libgdiplus).
Using Cocoa i could also implement some feature that was missing in
libgdiplus ( mostly GraphicsPath.AddString() thanks to NSBezierPath ).
I am not saying that Cairo should not be used, I only had to avoid it
because I needed performances and my software must be released soon.
If you are interested I can share the code.
Ciao,
Daivde.
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Per
conto di Peter De Jager
Inviato: mercoledì 27 luglio 2005 11.34
A: mono-winforms-list@lists.ximian.com
Oggetto: [Mono-winforms-list] MWF painting VERY slow compared to .NET
When painting a bitmap to a Form and measuring the frame
rate, I get vastly different figures on .NET vs. Mono. E.g.
on .NET I get 114 fps while under mono it's only 4.5 fps (on
the same hardware). What's even stranger is that I get the
same (4.5 fps) figure on a PowerPC Mac mini (1.42 GHz G4, 167MHz
bus) and an Intel box (dual 3GHz Xeon, 533MHz bus). Both
systems are running Fedora Core 4. I thought that perhaps it
relates to video drivers but I installed the latest ATI
driver on my Xeon box (Radeon 9800 Pro) and there is still no
difference.
Something else is that on WMF, the background is always
painted even though I override OnPaintBackground of my Form
with an empty implementation, e.g.:
protected override void OnPaintBackground(PaintEventArgs e) { }
On Windows, this prevents the Form from repainting the
background, thus speeding up painting and reducing flicker,
while MWF always appears to repaint the background.
I've done (very limited) testing on Gtk (Glade), and it
appears to be fast on Linux (comparable to
System.Windows.Forms on .NET), but while being fast on Linux,
Glade is MUCH slower on Windows (I don't have exact figures
but it's very noticable).
Is the MWF implementation likely to increase in speed (by 20
times!) as it matures, or should I use Gtk for Linux / OS X
and System.Windows.Forms for Windows? I was hoping that I
could use a single code base for all platforms (which has
been the case so far).
Don't take this the wrong way, I don't mean to be critical. I
think it's great that there is a managed implementation of
Windows Forms, but at 20 times slower it renders my Windows
applications unusable under Mono.
Thanks
Pete.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date:
22/07/2005
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, They look every bit as professional and clean as a commercial MacOS software site, but when you click the Download $COOL_APP link you get a tarball! For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. There is really nothing stopping us from building a Mono installer for applications that can be relocated, the challenges I think are: * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; The second is for fully self contained software. A prototype should not take longer than a day. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Key Exchanges (RSA vs DH)
I'm trying to evaluate key exchange algorithms for both speed, security, and verification [S, S, V]. I was thinking of using RSA mainly, but I ran accross some info about DiffieHellman being good for key exchange. I plan on using the key exchange algorithm in exchanging keys for say... Rijndael or some other configurable algorithm. I know a bit about RSA, but not much about DH. I know for RSA the key generation process is ugly (timewise), but I can't remember how the encryption/decryption process is. It seems DH is pretty fast, but I'm unsure as to how to configure it properly for my needs [ S,S,V ]. In running a few tests, I found that the static key 'generation' works pretty good, though to me, it looks pretty unsafe. Is it? With Static key generation, I didn't need to do any passing of public key information (though it would obviously be the same w/ static key)... which leads me to believe that it's relatively pointless. Also, there's 2 lengths to specify, but I don't know what really affects what. [As an aside, a patch to rename the length's names to something more meaningful would be nice... I may make a patch when I better understand how it works] Thanks for your help, sorry about the relativly messy train of thought. -- Thomas Harning Jr. signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Miguel de Icaza wrote: For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Autopackage has been in development for a long time now. It is true that a lot of this time was spent 'fixing' the design decisions of the GCC and glibc people, which I guess .NET does not suffer from, but still ... much of that time was also spent writing the bootstrap code, documentation, su/sudo wrappers, GTK+ and Qt based GUIs, integrating LZMA compression, getting professional artwork etc. * Write the code that installs software: should this be an executable program, or should it be a package format with a special extension that a minstall command can process? With autopackage it's both, but leaning more towards the former. For maxiumum ease of use, the first time you run them they'll download and install the runtime code itself. Then after that, you can just click on .package files to install them. This flexibility is why we were able to switch to a much improved compression algorithm for the 1.2 release, for instance. * Applications that use this process should probably follow the Application Guidelines, but take things a step further: be completely relocatable and break with the Unix tradition of prefixed-based configurations. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. You can see this in action here: http://autopackage.org/flash-demo-install.html This code should be in glib really, but the independent kits are useful for now. I would go as far as advocating the creation of a standard to create OSX-like bundles for Linux and encourage the various desktop efforts to include support for bundles. This has been discussed many times on autopackage-dev, and we have invented at least three different ways of implementing appfolders on Linux. Some require integration with GNOME/KDE, and other techniques are fully backwards compatible with existing desktops. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. The first addresses software that requires it to be adapted to the target system, register itself somewhere or modify some system files; Most software does, in my experience, even for trivial things like menu entries. A prototype should not take longer than a day. Heh, famous last words ;) The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
We already have a for all distros installer (that uses bitrock). But it'd be really cool to see this use autopackage. Yes, I saw. Bitrock is a good product. My main aim here is to get Mono applications themselves using graphical installers - if the Mono runtime itself is also autopackaged and so can be depsolved in then great, but if not then there's still benefit. I think the best way to start would be from the top down. It'd be nice to do a package of MonoDevelop and then see what can be made easier to do with helpers in autopackage, etc. Agreed. From what I know of Mono the following things might be an issue: * DLL mappings * the GAC * Ahead of time compilation * Detecting assembly versions (we use a variety of ugly hacks to get ELF DSO versions) But there's only one way to find out, and that's to go ahead and do it. I'd love to but right now, can't ... so hopefully somebody will decide to have a go. thanks -mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: problems with Syscall.syslog fot mono-1.1.8.3
On Thu, 2005-07-28 at 13:37 +0400, Vorobiev Maksim wrote: Today I've upgraded mono version to 1.1.8.3 and found, that it has no fixes for syslog support. Not in sources, not in binaries. That version will contain these changes? Those changes were made to svn-trunk, not the 1.1.8 branch, so they'll appear in 1.1.9. Alternatively, if a 1.1.8.4 will be released, I could backport the patches from head to 1.1.8... - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Source code file name and line form PDB
Hi, It could be very good if Mono could read PDB files because it could help debugging code on Mono compiled by MS compilers. As I know the only reason is that noone implemented it yet. Are there any known legal or other issues regarding PDB files? Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Patch for System.DirectoryServices - kerberos support for TARGET_JVM
Hello all,
Attached is a proposed patch for kerberos authentication support in
TARGET_JVM.
Most of the implementation resides in .jvm directory or under ifdef
TARGET_JVM, also I have changed Bind api a bit so it can receive
AuthenticationTypes as an additional parameter.
Boris
--
Boris Kirzner
Mono RD team, Mainsoft Corporation.
Blogging at http://boriskirzner.blogspot.com/
Index: Novell.Directory.Ldap/Connection.cs
===
--- Novell.Directory.Ldap/Connection.cs (revision 47755)
+++ Novell.Directory.Ldap/Connection.cs (working copy)
@@ -1207,6 +1207,25 @@
}
///TLS not supported in first release
+ internal Stream InputStream
+ {
+ get { return in_Renamed; }
+ }
+
+ internal Stream OutputStream
+ {
+ get { return out_Renamed; }
+ }
+
+ internal void ReplaceStreams(Stream newIn, Stream newOut)
+ {
+ // wait for reader to stop, see LdapConnection.Bind
+ waitForReader(null);
+ in_Renamed = newIn;
+ out_Renamed = newOut;
+ startReader();
+ }
+
public class ReaderThread
{
private void InitBlock(Connection enclosingInstance)
Index: Novell.Directory.Ldap/LdapConnection.cs
===
--- Novell.Directory.Ldap/LdapConnection.cs (revision 47755)
+++ Novell.Directory.Ldap/LdapConnection.cs (working copy)
@@ -36,6 +36,15 @@
using Novell.Directory.Ldap.Utilclass;
#if !TARGET_JVM
using Mono.Security.Protocol.Tls;
+#else
+using org.ietf.jgss;
+using javax.security.auth;
+using javax.security.auth.login;
+using java.security;
+
+using Novell.Directory.Ldap.Security;
+using System.Collections.Specialized;
+using System.Configuration;
#endif
using System.Security.Cryptography.X509Certificates;
@@ -471,6 +480,9 @@
private static System.Object nameLock; // protect agentNum
private static int lConnNum = 0; // Debug, LdapConnection number
private System.String name; // String name for debug
+
+ private const string LDAP_SECURITY_MECH =
System.DirectoryServices.SecurityMech;
+ private const string LDAP_SECURITY_APP_NAME =
System.DirectoryServices.SecurityAppName;
/// summary Used with search to specify that the scope of
entrys to search is to
/// search only the base obect.
@@ -1172,10 +1184,24 @@
/// /exception
public virtual void Bind(System.String dn, System.String
passwd)
{
- Bind(Ldap_V3, dn, passwd, defSearchCons);
+ Bind(dn, passwd, AuthenticationTypes.None);
return ;
}
+ public virtual void Bind(System.String dn, System.String
passwd, AuthenticationTypes authenticationTypes)
+ {
+#if TARGET_JVM
+ if (authenticationTypes != AuthenticationTypes.None
+ authenticationTypes !=
AuthenticationTypes.ServerBind
+ authenticationTypes !=
AuthenticationTypes.Anonymous)
+ BindSecure(dn, passwd, authenticationTypes);
+ else
+#endif
+ Bind(Ldap_V3, dn, passwd, defSearchCons);
+
+ return ;
+ }
+
/// summary Synchronously authenticates to the Ldap server
(that the object is
/// currently connected to) using the specified name, password,
/// and Ldap version.
@@ -1388,7 +1414,7 @@
[CLSCompliantAttribute(false)]
public virtual void Bind(int version, System.String dn,
sbyte[] passwd, LdapConstraints cons)
{
- LdapResponseQueue queue = Bind(version, dn, passwd,
null, cons);
+ LdapResponseQueue queue = Bind(version, dn, passwd,
null, cons, null);
LdapResponse res = (LdapResponse) queue.getResponse();
if (res != null)
{
@@ -1440,7 +1466,7 @@
[CLSCompliantAttribute(false)]
public virtual LdapResponseQueue Bind(int version,
System.String dn, sbyte[] passwd, LdapResponseQueue queue)
{
- return Bind(version, dn, passwd, queue, defSearchCons);
+ return Bind(version, dn, passwd, queue, defSearchCons,
null);
}
/// summary Asynchronously authenticates to the Ldap
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi, I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and 8.0.3600.0 to 8.0.0.0 where they are used to set versions of an assembly or reference an assembly. I did not add any ChangeLog entries. If we want to provide so much ChangeLog some automated tool should be used. Kornél - Original Message - From: Miguel de Icaza To: Kornél Pál Sent: Thursday, July 28, 2005 8:18 AM Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions Hello, I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646. I don't try to propose a patch file because I'm sure it would be rejected. Having a patch would be great. Miguel. AssemblyVersion20.tar.gz Description: GNU Zip compressed data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Imho it would be a good idea to fix all those attributes in System.Web first to use the Consts - Scheme before having to change all that stuff twice. mfg Andreas - Original Message - From: Kornél Pál [EMAIL PROTECTED] To: Miguel de Icaza [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Thursday, July 28, 2005 2:25 PM Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions Hi, I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and 8.0.3600.0 to 8.0.0.0 where they are used to set versions of an assembly or reference an assembly. I did not add any ChangeLog entries. If we want to provide so much ChangeLog some automated tool should be used. Kornél - Original Message - From: Miguel de Icaza To: Kornél Pál Sent: Thursday, July 28, 2005 8:18 AM Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions Hello, I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646. I don't try to propose a patch file because I'm sure it would be rejected. Having a patch would be great. Miguel. ___ 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-devel-list] mono use 100% cpu when not use root
I use SuSE Linux 9.3 (x86-64) out of the box... Is there something that I can do to solve the problem? 2005/7/28, Miguel de Icaza [EMAIL PROTECTED]: Hello, You could try stracing the process and see what its doing, or attaching with gdb and getting a stack trace of all threads (t a a bt) Miguel I attached the result. I have upgraded to 1.1.8.3 and I have also tried to compile from source but I'm not able to compile if I am not root. When copiled by root, from normal user I have thesame problem. Ah, something in your libc is making Mono hang. This seems to be very specific to your distro. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Calling Native C api - Marshalling issue.
I am getting problem while executing the c library function from C#.
Following is the equivalent code .
C Code :
---
//This is the structure in C
typedef struct MyDataType
{
u_intdata1;
u_int data2;
} MyData;
//This is the C function which is called by passing pointer to above
structure
function u_int DoSomeOperation(MyData* pData)
{
return pData-data1 +pData-data2;
}
C# Code :
Following code shows how I am executing that call.
using System;
using System.Runtime.InteropServices;
namespace Test
{
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
public UInt32 data1;
public UInt32 data2;
}
public class Test
{
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
//main function for console application
static void Main()
{
UInt32 result = 0;
CSMyData inData = new CSMyData();
inData.data1 = 0x;
inData.data2 = 0xFF;
result = OperateData(ref inData);
Console.WriteLine( Addition = result.ToString();
}
}
}
Issue:
When I am printing value in the C code side ,ie in DoSomeOperation
function , the values are corrupted.
Please let me know what part is wrong.
regards,
Yogi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] PEAPI and 1.1.8.3 build
Hi, Gary M. Smithrud wrote: I'm attempting to build 1.1.8.3 on Solaris (if anyone has any experience doing this and has suggestions, let me know) and it fails because it is attempting to build PEAPI, which is not part of the tarball. Is this needed? I'm not sure whether I should comment it out of the makefile or attempt to get it from one of the branches (main?). Thanks! PEAPI is part of the tarball. Check if your tar command works fine. (i.e. try GNU tar instead of the pre-installed one.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] PEAPI and 1.1.8.3 build
That's it! Thanks! Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 10:38 AM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-devel-list] PEAPI and 1.1.8.3 build Hi, Gary M. Smithrud wrote: I'm attempting to build 1.1.8.3 on Solaris (if anyone has any experience doing this and has suggestions, let me know) and it fails because it is attempting to build PEAPI, which is not part of the tarball. Is this needed? I'm not sure whether I should comment it out of the makefile or attempt to get it from one of the branches (main?). Thanks! PEAPI is part of the tarball. Check if your tar command works fine. (i.e. try GNU tar instead of the pre-installed one.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Calling Native C api - Marshalling issue.
Hi,
classes are by default passed by-ref to unmanaged code, i.e. a pointer to the
data is passed to the C side. If you define your managed method as 'ref', then
the unmanaged code will receive a pointer-to-a-pointer to the data. Try
removing the 'ref', or defining CSMyData as a struct, which by default
marshalled
by-value.
Zoltan
On 7/28/05, Yogendra Thakur [EMAIL PROTECTED] wrote:
I am getting problem while executing the c library function from C#.
Following is the equivalent code .
C Code :
---
//This is the structure in C
typedef struct MyDataType
{
u_intdata1;
u_int data2;
} MyData;
//This is the C function which is called by passing pointer to above
structure
function u_int DoSomeOperation(MyData* pData)
{
return pData-data1 +pData-data2;
}
C# Code :
Following code shows how I am executing that call.
using System;
using System.Runtime.InteropServices;
namespace Test
{
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
public UInt32 data1;
public UInt32 data2;
}
public class Test
{
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
//main function for console application
static void Main()
{
UInt32 result = 0;
CSMyData inData = new CSMyData();
inData.data1 = 0x;
inData.data2 = 0xFF;
result = OperateData(ref inData);
Console.WriteLine( Addition = result.ToString();
}
}
}
Issue:
When I am printing value in the C code side ,ie in DoSomeOperation
function , the values are corrupted.
Please let me know what part is wrong.
regards,
Yogi
___
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-devel-list] mono use 100% cpu when not use root
Hi, Also, could you try renaming your $HOME/.wapi directory to something else and trying again ? Zoltan On 7/28/05, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I use SuSE Linux 9.3 (x86-64) out of the box... Is there something that I can do to solve the problem? How did you install Mono, from our packages, or from your source? If you did it from source, could you post your config.h and configure log files? Miguel ___ 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] TimeStamp support on oracle...
I really need the new TimeStamp type (supported starting from oracle 9). It's
a MS.NET supported type (i've made tests)...
I've begin to do a little patch (attached) to add the timestamp type to
oracle.client...
but... I've a strange error when i try to do a Fill, it failed with:
Unhandled Exception: System.Data.OracleClient.OracleException:
in 0x0013d System.Data.OracleClient.Oci.OciStatementHandle:Fetch ()
in 0x0002c System.Data.OracleClient.OracleDataReader:Read ()
in 0x002f4 System.Data.Common.DbDataAdapter:FillTable (System.Data.DataTable
dataTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords,
System.Int32 counter)
in 0x0011f System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, System.String srcTable, IDataReader dataReader, Int32 startRecord,
Int32 maxRecords)
in 0x000d5 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable,
IDbCommand command, CommandBehavior behavior)
in 0x00044 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet)
in 0x007b8 ConsoleIntranet.Class1:TestTimestamp ()
in 0x00015 ConsoleIntranet.Class1:Main (System.String[] args)
Could someone help me how to resolve this issue?
thanks
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce
message non conforme à sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs (revision 47807)
+++ mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs (working copy)
@@ -258,7 +258,7 @@
OciDataType bindType = ociType;
IntPtr bindValue = IntPtr.Zero;
int rsize = 0;
-
+ Console.WriteLine(Parametre : +ociType.ToString());
// TODO: handle InputOutput and Return parameters
if (direction == ParameterDirection.Output) {
// TODO: need to figure out how OracleParameter
@@ -324,9 +324,11 @@
bindSize = 0;
}
else {
+ Console.WriteLine(OracleType +oracleType.ToString());
// TODO: do other data types and oracle data types
// should I be using IConvertible to convert?
if (oracleType == OracleType.DateTime) {
+ Console.WriteLine(DATE!!!);
string oraDateFormat = connection.GetSessionDateFormat ();
string sysDateFormat = OracleDateTime.ConvertOracleDateFormatToSystemDateTime (oraDateFormat);
@@ -637,8 +639,11 @@
dbType = DbType.AnsiStringFixedLength;
ociType = OciDataType.Char;
break;
+ case OracleType.Timestamp:
+ dbType = DbType.DateTime;
+ ociType = OciDataType.TimeStamp;
+ break;
case OracleType.DateTime:
- case OracleType.Timestamp:
case OracleType.TimestampLocal:
case OracleType.TimestampWithTZ:
dbType = DbType.DateTime;
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs (revision 47807)
+++ mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDataType.cs (working copy)
@@ -43,6 +43,7 @@
Blob = 0x71,
BFile = 0x72,
OciString = 0x9b,
- OciDate = 0x9c
+ OciDate = 0x9c,
+ TimeStamp = 0xbb
}
}
Index: mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParameterDescriptor.cs
===
--- mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciParameterDescriptor.cs (revision
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
Hello, For those programs that do not require native libraries, we could probably generate a Mono-based installer that can use console or Windows.Forms based installations. Well, I can see why this would be tempting for you but my advice is don't: a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. b) Autopackage is already being used by projects, it has small but rapidly growing mindshare - it'd be nice to have some standardisation across projects so users get a consistent experience Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. c) Writing installers *sounds* easy, but by the time you've made it work on N^2 distros, fixed all the bugs, added digital signatures, a nice user interface, support uninstalling/upgrading native packages if they already exist etc etc, it turns out to be a lot of work. Well, Ximian's business was largely managing software installation and all of its related angles as part of its red carpet product, so am not terrified by this. Certainly doing a general purpose tool for all kinds of software (native c, dependencies, mix of code) is needed, and I think autopackage fits nicely in this area. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Autopackages are always relocatable and we provide an easy way to install stuff to $HOME if you don't have the root password. We provide simple kits you can integrate with the program to make them relocatable, as well as complete documentation on how to do it. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. What I would like to do is break with the prefix tradition. So far we've never implemented it - it turns out that basic stuff like being able to get root on a wide variety of distributions in a fully graphical way took up all our time so far. However, it was designed from scratch to support multiple user interfaces and we already have fairly complete blueprints for not only the current wizard-style UI but also an apt-get style command line UI and a MacOS X style bundle UI. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. The advantage of this is that we could distribute cross-platform bundles that would work on OSX and Linux. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Most software does, in my experience, even for trivial things like menu entries. Yeah, this might have to live in a Mono.InstallationServices dll. The autopackage prototype only took a week, and that included uninstallation, verification and dependency checking. Turning it into a product took three years. There's no need to re-invent the wheel here. Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Looking for people to do Mono/autopackage integration
a) You'd be rewriting what already exists, for what benefit? Raise the bar in the state of art of Linux installation. That's certainly a worthy goal, but I'd like to think we already did - easy to use one click installs are something we put a lot of effort into. If you haven't watched the Flash demo, I'd recommend it: http://autopackage.org/flash-demo-install.html Am thinking of something that normal users can use, not something that copes with every possible angle of software dependencies, but going for a simple OSX-like setup. Well, it's not drag/drop, but it *is* just as simple: * Click on a link in a webpage * Click Open in the firefox file download dialog (actually you can tell firefox to always open this filetype) * It downloads ... there is a simple confirmation window: http://autopackage.org/screenshots/newshots/gtkfe-intro.png * You click Install and then enter your password (or not): http://autopackage.org/screenshots/newshots/autosu-ask.png * That's it. You get a summary screen at the end: http://autopackage.org/screenshots/newshots/gtk-yaydone.png The user doesn't have to think about dependencies, or install paths, or anything really - the only decision to make is Do I know the root password and this is easy, either you do or you don't. On MacOS X you must make some more decisions: * Do I click the app right now, while it's inside the DMG? * Or ... do I drag it to the dock? * Or ... the /Applications directory? Actually only the last one is correct, but that's something you just have to know. So I don't think the autopackage UI is complicated. What am suggesting is something Mono-specific for small applications that can take care of average applications being developed. Think about Perl, Ruby and Python's frameworks for doing software installation: they are not frameworks for doing *everything* but they can do a pretty good job for *most* of their software. Sure, but your typical Mono app does have dependencies: the Foo# library bindings if nothing else. Well, you could ship them all as part of the Mono platform and that'd work, but bleeding edge apps would still have problems. A large platform combined with automatic graphical dep resolution for very new libraries: http://autopackage.org/screenshots/newshots/gtkfe-retreive.png seems like a nice balance. Such a document would be invaluable. My feeling is that autopackage focus is in adapting existing software which is prefix-designed to be relocatable. Sure, we try and make this easy because autopackages are relocatable as a rule. But that's just an artifact of most C programs not being so, there's nothing C specific about it. Where can I find the documents/tutorials for this? We might want to change Mono's installer to use something like this, as it currently breaks for 2.x uses. Actually, this document is for an older version: http://autopackage.org/docs/binreloc/ The CVS version of binreloc is simplified considerably and can generate different styles of code (eg, raw C vs glib style). It also has less bizarre memory management semantics. Unfortunately it's not documented yet, but the basic theory is the same: provide convenience functions for finding your own path, getting the prefix from it, and then appending other paths (all in one function if you like). What I would like to do is break with the prefix tradition. Yes, me also. That's why we have it as a rule. What I care about the most with bundles is being compatible with OSX in as much as possible. Am talking about the file system structure, not really the actual dmg image, ie Chess.app. Given that bundles need to be customised anyway, for instance to have Aqua compatible artwork, I'm not sure it's worth trying to make Linux apps the same right now. It'd be better to provide an installer EXE for Windows, an autopackage for Linux and an bundle for MacOS X. The dmg problem would be handled by a mime-type handler, so am not too worried about that. Right. But MIME type handler for GNOME 2.10? or GNOME 2.8? Or KDE 3.x? Or all of them? Yeah, but like I said, autopackage is for seriously complicated apps; Am thinking it more for pure Mono apps which have much less dependencies and we can safely assume `Mono is in your path' Well, not really, right now autopackage is used for really quite simple apps packaging-wise: Gaim, Inkscape, AbiWord: none of them are too terrible. I tell you what. How about I try and package a Mono app tonight, and I will show you how trivial it really is. There's a quickstart document here: http://autopackage.org/developer-quickstart.html which shows you all the basics in one page, and it also covers basic advice like don't depend on CVS versions of unstable libraries ;) Ignore the C++ warning, this is relevant only for the stable 1.0.x series, but we have much improved C++ support in CVS that will make dealing with the ABI change fully automatic. I
RE: [Mono-devel-list] Calling Native C api - Marshalling issue.
Thanks Massi Zoltan.
It works after removing the ref. As Zoltan said, by defualt classed are
passed as reference to unmanaged code.
-YoGi
-Original Message-
From: Massimiliano Mantione
To: Yogendra Thakur
Cc: 'mono-devel-list@lists.ximian.com '
Sent: 7/28/05 11:17 AM
Subject: Re: [Mono-devel-list] Calling Native C api - Marshalling issue.
On Thu, 2005-07-28 at 10:15 -0400, Yogendra Thakur wrote:
I am getting problem while executing the c library function from C#.
//Define equivalent class to MyData structure
[StructLayout(LayoutKind.Sequential)]
public class CSMyData
{
either should be a struct, not a class...
//Import the dll and define C function.
[DllImport (mylibrary.dll, EntryPoint=DoSomeOperation)]
static extern Int32 OperateData( ref CSMyData pData);
//Other way of defining
//static extern Int32 OperateData( [In,Out] CSMyData pData);
...or you should omit the ref (or the [In,Out]).
With these modification it works.
The issue is that if CSMyData is a struct, then the ref (or the
[In,Out]) is needed to get the address of the struct.
But if CSMyData is a class, marshalling converts it correctly.
I am no marshalling expert, but I think that if you put the ref
you pass the address of the object reference :-)
Ciao,
Massi
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Npgsql breaks multi-line queries
Hi! I found that Npgsql client breaks multi-line queries by removing newline characters. This leads to improper sql being sent do postgresql. The following CommandText select a as b from C is sent as select a as bfrom C which is obviously an error because the space between b and from is missing. This is because RegExp used to filter parameters doesn't use RegexOptions.Singleline option. I'm attaching a patch against SVN trunk which fixes the problem. Would anyone care to apply it? -- Jaroslaw Kowalski http://blog.jkowalski.net/ http://nlog.sourceforge.net/ npgsql.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mod_mono / XSP compiled from scratch latest
Hello, Corlib not in sync with this runtime: expected corlib version 37, found 22. Download a newer corlib or a newer runtime at http://www.go-mono.com/daily. This is not an xsp/mod_mono issue. You updated Mono incorrectly or you have two monos installed. I’m not exactly sure what it is talking about since all my tarballs were at the latest version when I compiled them. Can anyone help me out here? Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Miguel de Icaza [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Source code file name and line form PDB
On 07/28/05 Kornél Pál wrote: As I know the only reason is that noone implemented it yet. And the real reason noone even started implementing it is that the pdb file format is not documented. The MS people responsible for it don't even let other MS programmers access the file format (for the official reason that they may want to change the implementation, but the likely reason is the same as for large part of proprietary sw: it either infringes on someone else work or it is crap:-). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Npgsql breaks multi-line queries
I've forwarded your patch to Francisco Jr. that created/maintains npgsql, as the primary repository for it is at gborg under his control, and is just synced inside Mono's. Thanks for spotting that, :) On 7/28/05, Jaroslaw Kowalski [EMAIL PROTECTED] wrote: Hi! I found that Npgsql client breaks multi-line queries by removing newline characters. This leads to improper sql being sent do postgresql. The following CommandText select a as b from C is sent as select a as bfrom C which is obviously an error because the space between b and from is missing. This is because RegExp used to filter parameters doesn't use RegexOptions.Singleline option. I'm attaching a patch against SVN trunk which fixes the problem. Would anyone care to apply it? -- Jaroslaw Kowalski http://blog.jkowalski.net/ http://nlog.sourceforge.net/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I'm trying to become a Rosh Gadol before my own eyes. See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment. It hurts! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] monodevelop-GtkSourceView-CRITICAL
Hello, i am a new mono programmer, i buy Mono-a developer's notebook of O Reilly and i am studing it. I have installed on my linux slackware notebook the latest version of mono but when i run monodevelop i have this error: (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 681 (gtk_source_buffer_new_with_language): assertion `GTK_IS_SOURCE_LANGUAGE (language)' failed (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 1470 (gtk_source_buffer_set_highlight): assertion `GTK_IS_SOURCE_BUFFER (buffer)' failed i have found on google this link http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=PROJECT;action=display;num=1116846330 and i try to delete ./config/Monodevelop but i have always this problem :-( please help me :-) thank's Stefano Somaglia -- Stefano Somaglia http://www.suma.it Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo messaggio e negli eventuali files allegati sono riservate e ad uso esclusivo del destinatario, per le finalità indicate nel messaggio stesso. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo dal Suo sistema, senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us. Thank ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Patch for generating debug info in System.Reflection.Emit
On 7/28/05, Rodrigo B. de Oliveira [EMAIL PROTECTED] wrote: ... I'm getting off-by-one errors only with raise/throw statements: The behavior is actually a little more complex but still predictable. The stack trace entry for the raise line is always the line of the next statement in the same method: src name=other.boo def foo(): raise foo return 1 def bar(): foo() bar() /src I get then: Unhandled Exception: System.ApplicationException: foo in [0xa] (at Other.boo:5) OtherModule:foo () in [0x0] (at Other.boo:8) OtherModule:bar () in [0x0] (at Other.boo:10) OtherModule:Main (System.String[] argv) Any ideas? bamboo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [off topic] mono/.net pure managed wrapperlibraries
Don't think about performance on this one, because the loss will be absolutely unmeasurable (or at least extremely small) unless you want to stream byte by byte. It is quite possible, that the mono jit will inline that code anyways... Just create an abstract base class (or interface) and then inherit and you're done. Andreas - Original Message - From: Dominik Pich [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, July 28, 2005 7:32 PM Subject: [Mono-devel-list] [off topic] mono/.net pure managed wrapperlibraries Ok, I'm aware this is offtopic but hey :) it is _RELATED_ to mono in so far that I think about using it :P So... my situation: I have managed code written using ms .NET which uses MS managed wrapper for WMP. I'd like to port that code to osx using mono and as I then dont have WMP but QuickTime, I thought I'd write a wrapper that on WINDOWS uses WMP and on OSX uses QuickTime. So far so good... ;) Instead of: on Windows I got:MyApp - managed WMP - WMP on OSX I got:MyApp - managed QuickTime - QuickTime I add the add. 'wrapper layer' so I have a common API: on Win/osx: MyApp - managed Media Player - managed WMP (win) - WMP - managed QuickTime (osx) - Quicktime Now Im thinking about the performance decrease of such an add. 'wrapper layer' and wonder if I could 'inline' it ... so I dont have the wrapper in the compiled code: I write: oMediaPlayer-play(); and it compiles to either QTplayer-play() WMPplayer-play() ... or do I worry to much? Thanks, Dominik ___ 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-devel-list] [PATCH] Profile 2.0 assembly versions
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do do
it now instead of doing it twice (and adding lots of changelog entries
twice).
Andreas
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 4:11 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
Note that I found 2:0:3600:0 in test-377-net_2_0-il.il so I canged it as
well to 2:0:0:0. I found {2,0,3600,0}and {8,0,3600,0}in domain.c I changed
them as well. I think there are no more x.0.3600.0 versions anywhere
because
this time I searched for 3600. Updated patch attached.
Could you please be more specific because I do not understand why it is
required. I was able to compile a clean checkout (mcs and mono) with the
patch applied without errors.
Are Consts.cs files automatically generated (I don't think so) or what is
the problem?
If the problem is the size of the diff file I can't help you. If you want
please feel free to separate it to as many files as you want but I don't
want do it.
Kornél
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 2:40 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Imho it would be a good idea to fix all those attributes in System.Web
first
to use the Consts - Scheme before having to change all that stuff twice.
mfg
Andreas
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@lists.ximian.com
Sent: Thursday, July 28, 2005 2:25 PM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I attached a patch file that replaces all 2.0.3600.0 to 2.0.0.0 and
8.0.3600.0 to 8.0.0.0 where they are used to set versions of an
assembly
or
reference an assembly.
I did not add any ChangeLog entries. If we want to provide so much
ChangeLog
some automated tool should be used.
Kornél
- Original Message -
From: Miguel de Icaza
To: Kornél Pál
Sent: Thursday, July 28, 2005 8:18 AM
Subject: Re: [Mono-devel-list] Profile 2.0 assembly versions
Hello,
I filed http://bugzilla.ximian.com/show_bug.cgi?id=75646.
I don't try to propose a patch file because I'm sure it would be
rejected.
Having a patch would be great.
Miguel.
___
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-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I agree with you that this a better idea but I will never try to submit such
a big patch for proposal because it would change too much code and it
figured out that it is nearly impossible to make any major change to Mono
because if there are no mistakes and errors in the patch itself an endless
list can be created about things that should be done before the patch can be
comitted altought they don't block the patch in fact.
I see a lot of things in Mono that sould be made more reliable using some
centralization but I don't want to create n+1 wariants of this patch.
I reported the problem, I proposed a patch, the patch seems to be correct
(because no notices were provided regarding the patch itself). If you want
to do hundreds of things that are not required to apply the patch before
applying the patch it's up to you but I don't want to solve all the problems
you can imagine just to commit this patch.
Anyway I think having different verion numbers than MS.NET is a more
critical issue than having a weakly centralized assembly referencing
practice.
Note that the references in System.Web.UI.WebControls are in NET_2_0 only
code blocks and these references are not in other versions. This seems to be
consistent practice in System.Web.UI.WebControls. Centralizing the assembly
reference could save some disk space but currently it is not required. It
will be required when a new (post 2.0) .NET Framework version will be
released but currently even 2.0 was not released yet so it will be in the
distant future.
Kornél
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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-devel-list] [PATCH] Profile 2.0 assembly versions
Yes - it would make a lot of sense to put them into a single file. However
it would come at a cost of up to 2kb of size added to EACH assembly that
uses Consts.
In fact I think we could do something really clever to our compiler here,
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a step
that allows the compiler to scan for dead code again AFTER constants are
resolved. This way the compiler would be able to completely eliminate the
Consts Class after compiling. This would also add lots of added value to
other applications. It's quite common to use private consts and especially
enums to structure the code and make it more readable. With the proposed
compiler function all of these things could be thrown out at compile-time,
which could help a lot of applications to get smaller.
We could add a compiler-switch for that like -EliminatePrivateConstants
Andreas
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
Bens idea is good. There should be a single file to define versions.
Then the assembly references could be in the Consts.cs files of each
assembly but there were no #if clauses to specify version because the
reference constants could use the version constants defined in the common
file.
BTW is there a way to have a common .sources file because it seems that we
are going to have more and more common files that has to be added to the
.sources file of each assembly?
Kornél
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:42 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Yes - it would make a lot of sense to put them into a single file. However
it would come at a cost of up to 2kb of size added to EACH assembly that
uses Consts.
In fact I think we could do something really clever to our compiler here,
that would also benefit for a lot of other cases.
AFAIK the compiler can already eliminate dead code. I would propose a step
that allows the compiler to scan for dead code again AFTER constants are
resolved. This way the compiler would be able to completely eliminate the
Consts Class after compiling. This would also add lots of added value to
other applications. It's quite common to use private consts and especially
enums to structure the code and make it more readable. With the proposed
compiler function all of these things could be thrown out at compile-time,
which could help a lot of applications to get smaller.
We could add a compiler-switch for that like -EliminatePrivateConstants
Andreas
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:42 +0200, Andreas Nahr wrote: Yes - it would make a lot of sense to put them into a single file. However it would come at a cost of up to 2kb of size added to EACH assembly that uses Consts. Maybe the *FILE* will be 2 kb, but the metadata added probably won't be. To add a class with a single const we'd need to add: 1) a entry in the classes table 2) an entry in the fields table 3) a constant string in the strings heap. At runtime, the only datastructure that will ever be allocated due to this class is the hashtable that goes from Namespace/Class - class field. I'm not even sure if that gets created for private classes, I'd have to dig into the code. The fields and string heap data gets loaded lazily on the first access. In fact I think we could do something really clever to our compiler here, that would also benefit for a lot of other cases. AFAIK the compiler can already eliminate dead code. I would propose a step that allows the compiler to scan for dead code again AFTER constants are resolved. This way the compiler would be able to completely eliminate the Consts Class after compiling. This would also add lots of added value to other applications. It's quite common to use private consts and especially enums to structure the code and make it more readable. With the proposed compiler function all of these things could be thrown out at compile-time, which could help a lot of applications to get smaller. A cecil based il-to-il optimizer could do that in the future. Of course, if you really want to look at how can we make teh metadata smaller we could do a simple obfuscator -- we could rename private / internal methods/classes to have small names, etc. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:57 +0200, Kornél Pál wrote: BTW is there a way to have a common .sources file because it seems that we are going to have more and more common files that has to be added to the .sources file of each assembly? I think that's a bit excessive ;-). The goal is to make sure that we don't have N versions of something that is likely to change. Since the source file is unlikely to change, that seems a bit silly. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
This patch is for System.Web.UI.WebControls.
If you find any problems regarding the patch itself feel free to comment it
but if you imagine any other non-blocking patches that should be done before
committing this one I promise that I will propose no more pathes.
Kornél
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: Ben Maurer [EMAIL PROTECTED]; Andreas Nahr
[EMAIL PROTECTED]
Cc: Miguel de Icaza [EMAIL PROTECTED];
mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:41 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
Hi,
I agree with you that this a better idea but I will never try to submit
such
a big patch for proposal because it would change too much code and it
figured out that it is nearly impossible to make any major change to Mono
because if there are no mistakes and errors in the patch itself an endless
list can be created about things that should be done before the patch can
be
comitted altought they don't block the patch in fact.
I see a lot of things in Mono that sould be made more reliable using some
centralization but I don't want to create n+1 wariants of this patch.
I reported the problem, I proposed a patch, the patch seems to be correct
(because no notices were provided regarding the patch itself). If you want
to do hundreds of things that are not required to apply the patch before
applying the patch it's up to you but I don't want to solve all the
problems
you can imagine just to commit this patch.
Anyway I think having different verion numbers than MS.NET is a more
critical issue than having a weakly centralized assembly referencing
practice.
Note that the references in System.Web.UI.WebControls are in NET_2_0 only
code blocks and these references are not in other versions. This seems to
be
consistent practice in System.Web.UI.WebControls. Centralizing the
assembly
reference could save some disk space but currently it is not required. It
will be required when a new (post 2.0) .NET Framework version will be
released but currently even 2.0 was not released yet so it will be in the
distant future.
Kornél
- Original Message -
From: Ben Maurer [EMAIL PROTECTED]
To: Andreas Nahr [EMAIL PROTECTED]
Cc: Kornél Pál [EMAIL PROTECTED]; Miguel de Icaza
[EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Sent: Friday, July 29, 2005 12:11 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
No Consts.cs aren't automatically generated.
The problem is, that several Attributes of classes in System.Web do not
use
the consts scheme, and about one third of your (BIG) patch is just for
changing these Attributes.
We will then have to change these again later, so it might make sense do
do
it now instead of doing it twice (and adding lots of changelog entries
twice).
If we really want to be clever, and avoid doing things twice, we can put
this:
internal class MonoConsts {
#if ...
public string FXVersion = ...
#elif ...
...
#endif
}
in the common build directory. This way, the next time we need to target
another FX, we don't have to do it in 100 places.
The Const.cs is probably still a good idea, since it is really ugly to
have those magic names lying around the source code.
-- Ben
___
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
System.Web.tar.gz
Description: GNU Zip compressed data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] monodevelop-GtkSourceView-CRITICAL
Hi, i am a new mono programmer, i buy Mono-a developer's notebook of O Reilly and i am studing it. It's a rather good book - my main problem with it is that it looks like a school book with those silly squares on the paper. I have installed on my linux slackware notebook the latest version of mono but when i run monodevelop Which version of mono are you running, have you compiled it yourself or installed it from the rpms? i have this error: (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 681 (gtk_source_buffer_new_with_language): assertion `GTK_IS_SOURCE_LANGUAGE (language)' failed (MonoDevelop:29539): GtkSourceView-CRITICAL **: file gtksourcebuffer.c: line 1470 (gtk_source_buffer_set_highlight): assertion `GTK_IS_SOURCE_BUFFER (buffer)' failed i have found on google this link http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=PROJECT;action=display;num=1116846330 and i try to delete ./config/Monodevelop but i have always this problem :-( That is a somewhat old reply to the problem and is probably no longer the case. If you've compiled from source, then there shouldn't be a problem with monodevelop - it certainly works at this end. TTFN Paul -- Some people will do anything for a woman in uniform - The Doctor - Unregenerate (Big Finish audio) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
On Fri, 2005-07-29 at 01:31 +0200, Kornél Pál wrote: This patch is for System.Web.UI.WebControls. If you find any problems regarding the patch itself feel free to comment it but if you imagine any other non-blocking patches that should be done before committing this one I promise that I will propose no more pathes. Gonzalo, who was smart enough to rm -rf /usr/bin on his laptop ;-), says he approves this. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] TimeStamp support on oracle...
You need to modify OciDefineHandle to deal with the TIMESTAMP.
See Define(), DefineDate(), and GetValue().
You can create a new function called DefineTimestamp() based on
DefineDate() and allocate space for it based OciDataType.TimeStamp.
What about TIMESTAMP WITH TIMEZONE and TIMESTAMP WITH LOCAL TIMEZONE?
There is also INTERVAL YEAR TO MONTH and INTERVAL DAY TO SECOND data
types. This is equivalent to System.TimeSpan and
System.Data.OracleClient types OracleMonthSpan and OracleTimeSpan.
These have not been implemented either.
Also, in OracleParameter, you need to allocate space for the Timestamp
for the output parameter, and you need to convert a .NET DateTime to an
Oracle TIMESTAMP by using OCIDateTime functions for the input parameter.
An Oracle Date uses OCIDate while TIMESTAMP uses an OCIDateTime.
You will need to DllImport into function OCIDateTimeConstruct() to
create and set the date and time in a OCIDateTime. You will also need
to DllImport into function OCIDateTimeGetTime() to get the time from the
OCIDateTime and OCIDateTimeGetDate() to get the date from the
OCIDateTime. There are other functions for the time zone, etc...
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci18map002.htm#i512069
Hubert FONGARNAND wrote:
I really need the new TimeStamp type (supported starting from oracle 9). It's
a MS.NET supported type (i've made tests)...
I've begin to do a little patch (attached) to add the timestamp type to
oracle.client...
but... I've a strange error when i try to do a Fill, it failed with:
Unhandled Exception: System.Data.OracleClient.OracleException:
in 0x0013d System.Data.OracleClient.Oci.OciStatementHandle:Fetch ()
in 0x0002c System.Data.OracleClient.OracleDataReader:Read ()
in 0x002f4 System.Data.Common.DbDataAdapter:FillTable (System.Data.DataTable
dataTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords,
System.Int32 counter)
in 0x0011f System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, System.String srcTable, IDataReader dataReader, Int32 startRecord,
Int32 maxRecords)
in 0x000d5 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet, Int32 startRecord, Int32 maxRecords, System.String srcTable,
IDbCommand command, CommandBehavior behavior)
in 0x00044 System.Data.Common.DbDataAdapter:Fill (System.Data.DataSet
dataSet)
in 0x007b8 ConsoleIntranet.Class1:TestTimestamp ()
in 0x00015 ConsoleIntranet.Class1:Main (System.String[] args)
Could someone help me how to resolve this issue?
thanks
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce
message non conforme à sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
Index:
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
===
---
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
(revision 47807)
+++
mcs/class/System.Data.OracleClient/System.Data.OracleClient/OracleParameter.cs
(working copy)
@@ -258,7 +258,7 @@
OciDataType bindType = ociType;
IntPtr bindValue = IntPtr.Zero;
int rsize = 0;
-
+ Console.WriteLine(Parametre : +ociType.ToString());
// TODO: handle InputOutput and Return parameters
if (direction == ParameterDirection.Output) {
// TODO: need to figure out how OracleParameter
@@ -324,9 +324,11 @@
bindSize = 0;
}
else {
+ Console.WriteLine(OracleType
+oracleType.ToString());
// TODO: do other data types and oracle data
types
// should I be using IConvertible to convert?
if (oracleType == OracleType.DateTime) {
+ Console.WriteLine(DATE!!!);
string oraDateFormat =
connection.GetSessionDateFormat ();
string sysDateFormat =
OracleDateTime.ConvertOracleDateFormatToSystemDateTime (oraDateFormat);
@@ -637,8 +639,11 @@
dbType = DbType.AnsiStringFixedLength;
ociType = OciDataType.Char;
Re: [Mono-devel-list] Key Exchanges (RSA vs DH)
Hello Thomas, On Thu, 2005-28-07 at 03:50 -0400, Thomas Harning Jr. wrote: I'm trying to evaluate key exchange algorithms for both speed, security, and verification [S, S, V]. I was thinking of using RSA mainly, but I ran accross some info about DiffieHellman being good for key exchange. This may, or not, be relevant to your application but DH is for key *agreement* not key exchange - so it's not exactly the same. I plan on using the key exchange algorithm in exchanging keys for say... Rijndael or some other configurable algorithm. I know a bit about RSA, but not much about DH. I know for RSA the key generation process is ugly (timewise), very true (but for some good reasons ;-) but I can't remember how the encryption/decryption process is. better. In fact *much* better when CRT can be used (i.e. when the private is used and all the extra information are available). It seems DH is pretty fast, but I'm unsure as to how to configure it properly for my needs [ S,S,V ]. In running a few tests, I found that the static key 'generation' works pretty good, you would probably get very similar times for RSA encrypt/decrypt operations when using a pre-generated key - i.e. this doesn't mean using a static key! though to me, it looks pretty unsafe. Is it? well it would be for a key exchange - but it's not for a key agreement ;-) however YMMV with how you're using the stuff With Static key generation, I didn't need to do any passing of public key information (though it would obviously be the same w/ static key)... which leads me to believe that it's relatively pointless. Also, there's 2 lengths to specify, but I don't know what really affects what. [As an aside, a patch to rename the length's names to something more meaningful would be nice... I may make a patch when I better understand how it works] Thanks for your help, sorry about the relativly messy train of thought. I've more confidence in the maths behind the crypto (both for RSA and DH) than in any software/hardware implementation of them - and MUCH more confidence in the 'wares implementations than in (most) software using them ;-) So I suggest you get a good look at some crypto book like Applied Cryptography or the more recent Practical Cryptography and/or stick as much as possible(tm) with industry standards. Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Npgsql breaks multi-line queries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rafael Teixeira wrote: I've forwarded your patch to Francisco Jr. that created/maintains npgsql, as the primary repository for it is at gborg under his control, and is just synced inside Mono's. Thanks for spotting that, Hi Rafael, Jaroslaw. Fixed in svn. Thanks for patch! - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - Science without religion is lame; religion without science is blind. ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQum21P7iFmsNzeXfAQJAlQgAj9NpoAb9iTIRvvjoqyTPYdAGirdg1NPk KfC62rttzRQlt9byaRCTs+WaHjN+l1amdRuPfXM6hBnm1OJThkOkEWvPs8E6T1ax MM8l/H/JTbtylESDj1pzQgie9S1TaRbIdDVaJV2eIPSqP/4ngcnXdUF5ST1risex 1ca7IuLivCjpTDBEGKS5FEkcGoVL+2FbqQ2v6fiVzU7hMlyklIvghO3Zogkq2cOf FPjEj61jItBvTxPnTKC5gyvNln3D+8nckxv7rKKeryNgV2FqX9yje2/jf7G63pi3 1G2Ay9bDr/NVk5+YkymcAx4TFN5jUbx3gyjKaG0gJi4eYz4F+7+5gQ== =/x8B -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] ASP.NET precompilation
Hi all, Miguel - I've just read your blog entry [1]. Very interesting. Quote: This patch is not very interesting anymore as ASP.NET 2.x allows for websites to be deployed by precompiling the whole site and copying the resulting DLL. I thought you could do this under ASP.NET 1.x? Slightly connected (but not related to Miguel's blog): I have recently been playing with the Visual Web Developer Express (VWDE) beta. It would appear that the preferred method in ASP.NET 2.x is to dynamically compile the page when requested [2]. Codebehind is now codefile, and seems to work the same way as the Src attribute. Whether this is gong to stay like this - who knows. I imported an ASP.NET 1.1 web form into VWDE, and it would not build. I hadn't included 'partial' in the class definition. I understand the partial allows one to spread a class definition over a number of source files - but my class was in a single source file! Obviously partial is now in the C# 3rd edition, but is it necessary to declare a class as partial when it exists in a single file - or is this an MS beta issue? One thing I did like was the new class derivation model. The aspx page can define controls (labels, button etc), without the need to declare the protected members within the source file. Chris [1]: http://tirania.org/blog/archive/2005/Jul-28-1.html [2]: http://msdn.microsoft.com/asp.net/whidbey/beta2update.aspx -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] ASP.NET precompilation
From: Chris Aitken Miguel - I've just read your blog entry [1]. Very interesting. Quote: This patch is not very interesting anymore as ASP.NET 2.x allows for websites to be deployed by precompiling the whole site and copying the resulting DLL. Of course all the old 1.x deploying techniques can be used in 2.z. using inline code or using Visual Studio to create a DLL, but the new ones may be better for developers because no server side compilation needed and protects your source code as well. I thought you could do this under ASP.NET 1.x? Of course 1.x can use DLLs but it creates classes in a DLL that inherit from System.Web.UI.Page and that classes are used as the base classes of the class created from the .aspx file on the server. This means that you have to include your .aspx file and it can be modified. You can modify HTML code, server side controls and you can add inline code. In 2.x the new thing is that you can compile your .aspx files into a DLL and the content of .aspx files cannot be seen on the production server nor can it be extended. There is a new tool called aspnet_compiler.exe: http://msdn2.microsoft.com/library/ms178614(en-us,vs.80).aspx (I don't wanted to be technically correct and talk about all features of ASP.NET I just tried to show the difference regarding aspnet_compiler.exe) Kornél ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] ASP.NET precompilation
Miguel - I've just read your blog entry [1]. Very interesting. Quote: This patch is not very interesting anymore as ASP.NET 2.x allows for websites to be deployed by precompiling the whole site and copying the resulting DLL. Of course all the old 1.x deploying techniques can be used in 2.z. using inline code or using Visual Studio to create a DLL, but the new ones may be better for developers because no server side compilation needed and protects your source code as well. I thought you could do this under ASP.NET 1.x? Of course 1.x can use DLLs but it creates classes in a DLL that inherit from System.Web.UI.Page and that classes are used as the base classes of the class created from the .aspx file on the server. This means that you have to include your .aspx file and it can be modified. You can modify HTML code, server side controls and you can add inline code. In 2.x the new thing is that you can compile your .aspx files into a DLL and the content of .aspx files cannot be seen on the production server nor can it be extended. Ah. I did wonder if that is what was meant. That sounds very powerful. There is a new tool called aspnet_compiler.exe: http://msdn2.microsoft.com/library/ms178614(en-us,vs.80).aspx (I don't wanted to be technically correct and talk about all features of ASP.NET I just tried to show the difference regarding aspnet_compiler.exe) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Simple Window Form can not be showed in Solaris
Hello,
I have installed mono 1.1.8.2 in Solaris and can compile the following
code with mcs -r:System.Windows.Forms Test.cs successfully. I tried
to start it mono Test.exe, but I could not get the simple Windows
Form showed. Could you help me to solve the problem? Many thanks.
--
using System;
using System.Collections;
using System.ComponentModel;
namespace client
{
public class SimpleForm
{
private System.ComponentModel.Container components = null;
[STAThread]
static void Main()
{
Application.Run(new SimpleForm());
}
public SimpleForm()
{
}
}
}
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Simple Window Form can not be showed in Solaris
Huaiyang Mao wrote:
Hello,
I have installed mono 1.1.8.2 in Solaris and can compile the following
code with mcs -r:System.Windows.Forms Test.cs successfully. I tried
to start it mono Test.exe, but I could not get the simple Windows
Form showed. Could you help me to solve the problem? Many thanks.
--
using System;
using System.Collections;
using System.ComponentModel;
namespace client
{
public class SimpleForm
{
private System.ComponentModel.Container components = null;
[STAThread]
static void Main()
{
Application.Run(new SimpleForm());
}
public SimpleForm()
{
}
}
}
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Your almost there, you just need to make your SimpleForm class inherit
from a Windows form, by adding using System.Windows.Forms; to the
using declarations at the top, and then change the line
public class SimpleForm
to read:
public class SimpleForm: Form
This now means that your simple form class is derived from a Form, and
when the app is run, it will create and display your basic blank form.
Hope that helps,
Regards,
-= El =-
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] new to mono Need help configuring
I have installed mono 1.1.8.2 on my slackware 10 standalone box. mono installed to the /opt directory. I think the path is set wrong. there is no .bashrc file so I tried creating one with various path statemnets and no result. When I go to the /opt/mono-1.1.8.2/bin directory the programs execute. When wx.NET calls mono I get a mono: not found error. How can I set the path to find mono as if it existed in a dirctory such as sbin? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Assembly.Load doubts
I have the following scenario:
-- TestBase.cs ---
public interface TestBase {
void Print();
}
--Test.cs---
public class Test : TestBase
{
public Test () {}
public void Print()
{
System.Console.WriteLine (Hola);
}
}
--- TestClass.cs
using System;
using System.Reflection;
public class TestClass
{
public static void Main (string[] args)
{
new TestClass();
}
public TestClass ()
{
AssemblyName asna = AssemblyName.GetAssemblyName (Test.dll);
Assembly asm = Assembly.LoadWithPartialName (asna.FullName);
Type t = asm.GetType(Test, true);
object obj = Activator.CreateInstance (t);
TestBase tb = (TestBase) obj; //InvalidCastException
tb.Print();
}
}
I compile like this:
mcs -target:library Test.cs TestBase.cs
mcs -debug TestClass.cs TestBase.cs
So I end up with a Test.dll and TestClass.exe. Now, executing the
TestClass.exe throws an InvalidCastException in the line with the
comment.
I think the problem is that i don't load the dll in the correct
context, but I've tried other possibilities and I couldn't make it
work. Two days ago I didn't know was an AppDomain was, so there is the
possibility that I'm doing something really stupid.
Any help pleaase?
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Assembly.Load doubts
Hi,
On 7/28/05, Mario Sopena [EMAIL PROTECTED] wrote:
I have the following scenario:
-- TestBase.cs ---
public interface TestBase {
void Print();
}
--Test.cs---
public class Test : TestBase
{
public Test () {}
public void Print()
{
System.Console.WriteLine (Hola);
}
}
--- TestClass.cs
using System;
using System.Reflection;
public class TestClass
{
public static void Main (string[] args)
{
new TestClass();
}
public TestClass ()
{
AssemblyName asna = AssemblyName.GetAssemblyName (Test.dll);
Assembly asm = Assembly.LoadWithPartialName (asna.FullName);
Type t = asm.GetType(Test, true);
object obj = Activator.CreateInstance (t);
TestBase tb = (TestBase) obj; //InvalidCastException
tb.Print();
}
}
I compile like this:
mcs -target:library Test.cs TestBase.cs
mcs -debug TestClass.cs TestBase.cs
So I end up with a Test.dll and TestClass.exe. Now, executing the
TestClass.exe throws an InvalidCastException in the line with the
comment.
I think the problem is that i don't load the dll in the correct
context, but I've tried other possibilities and I couldn't make it
work. Two days ago I didn't know was an AppDomain was, so there is the
possibility that I'm doing something really stupid.
Any help pleaase?
We just discussed this problem in monohispano:
https://listas.hispalinux.es/pipermail/mono-hispano/2005-July/003327.html
(I'm assuming that you speak spanish)
Cheers,
Rodolfo
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] GtkDotnet and Invalidate()
Hello, I'm writing a canvas applications in Gtk# using System.Drawing (via GtkDotnet). I'm doing some animations and I need to improve performance. In a Windows Forms Application, the way to do this is using the Invalidate() method to say which part of the control needs to be refreshed instead of refreshing all canvas, but I'm using Gtk# and I don't have any Windows.Forms.Control object to use Invalidate(). So, my question is: How can I do the same thing that with Invalidate() but using a Gtk.DrawingArea object? Thanks for the help. Manuel. -- · Manuel Alejandro Cerón Estrada · [EMAIL PROTECTED] · http://ceronman.blogspot.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Using Gtksourceview on Windows
Hello, I'm writing a Gtk# application and I want to port it to Windows. My application uses Gtksourceview. Is posible to use this library on Windows? Where can I get a binary version of it? Thanks, Manuel. -- · Manuel Alejandro Cerón Estrada · [EMAIL PROTECTED] · http://ceronman.blogspot.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Gtksourceview-sharp 2
I try to compil Gtksourview-sharp-2.0-0.10 [EMAIL PROTECTED] gtksourceview-sharp-2.0-0.10]# ./configure checking build system type... i686-pc-linux checking host system type... i686-pc-linux checking target system type... i686-pc-linux checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for a BSD-compatible install... /usr/bin/install -c checking for pkg-config... /usr/bin/pkg-config checking for mono = 1.0... ./configure: line 1992: 2129 Segmentation fault (core dumped) $PKG_CONFIG --exists mono = 1.0 checking for mint = 1.0... ./configure: line 2088: 2132 Segmentation fault (core dumped) $PKG_CONFIG --exists mint = 1.0 checking for csc.exe... no configure: error: You need to install either mono or .Net Thanks in advance, Cornu Nicolas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtksourceview-sharp 2
Hi, I try to compil Gtksourview-sharp-2.0-0.10 checking for pkg-config... /usr/bin/pkg-config checking for mono = 1.0... ./configure: line 1992: 2129 Segmentation fault (core dumped) $PKG_CONFIG --exists mono = 1.0 checking for mint = 1.0... ./configure: line 2088: 2132 Segmentation fault (core dumped) $PKG_CONFIG --exists mint = 1.0 checking for csc.exe... no configure: error: You need to install either mono or .Net I take it that you have got mono installed and that it is in somewhere sane (like /usr or /usr/local)? TTFN Paul -- Some people will do anything for a woman in uniform - The Doctor - Unregenerate (Big Finish audio) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] new to mono Need help configuring
Hi, I have installed mono 1.1.8.2 on my slackware 10 standalone box. mono installed to the /opt directory. I think the path is set wrong. Yep. By default, it will install to /usr/local unless you change it to /usr using --prefix= When I go to the /opt/mono-1.1.8.2/bin directory the programs execute. When wx.NET calls mono I get a mono: not found error. How can I set the path to find mono as if it existed in a dirctory such as sbin? http://www.all-the-johnsons.co.uk/mono/mono-compiling.html Grab the install script at the bottom, run and you should be fine. TTFN Paul -- Some people will do anything for a woman in uniform - The Doctor - Unregenerate (Big Finish audio) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono and Win32 fibers
has anyone gotten this to work? I'd love tips. Currently, using Mono with fibers (embedding in a Win32 app) will crash when executing managed code from the fiberproc. thx for any help! bruce ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mod_mono RedHat 9
I get this: Starting httpd: Syntax error on line 1052 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_mono.so into server: /etc/httpd/modules/mod_m ono.so: undefined symbol: apr_socket_send What's the best way to fix this? Hack mod_mono source? Is it possible to upgrade just apr? This is a VPS with Plesk provided Apache build, it's easy to mess it up. Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtksourceview-sharp 2
Paul F. Johnson a écrit :
Hi,
I try to compil Gtksourview-sharp-2.0-0.10
checking for pkg-config... /usr/bin/pkg-config
checking for mono = 1.0... ./configure: line 1992: 2129 Segmentation
fault (core dumped) $PKG_CONFIG --exists mono = 1.0
checking for mint = 1.0... ./configure: line 2088: 2132 Segmentation
fault (core dumped) $PKG_CONFIG --exists mint = 1.0
checking for csc.exe... no
configure: error: You need to install either mono or .Net
I take it that you have got mono installed and that it is in somewhere
sane (like /usr or /usr/local)?
TTFN
Paul
Yes mono is installed in /usr/local/
mono.pc in /usr/lib/pkgconfig:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Mono
Description: Mono Runtime
Version: 1.1.8.2
Requires: glib-2.0 gmodule-2.0 gthread-2.0
Libs: -L${libdir} -lmono -lpthread -lm
Cflags: -I${includedir} -D_REENTRANT
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Xcb] XCB-PROTO
Dickson Patton a écrit :
Nicolas,
You have to download build ALL the packages listed on the website:
There are multiple modules in CVS. The modules you need to checkout,
build, and install for each part of the project are, in order:
*
Xproto from xlibs http://freedesktop.org/wiki/Software_2fxlibs
*
Xau from xlibs http://freedesktop.org/wiki/Software_2fxlibs
*
xcb-proto
*
xcb
To build Xlib with support for XCB, first build XCB as above. After
that, the modules you need to checkout, build, and install for each
part of the project are, in order:
*
XExtensions from xlibs
http://freedesktop.org/wiki/Software_2fxlibs
*
xtrans from xlibs http://freedesktop.org/wiki/Software_2fxlibs
*
X11 from xlibs http://freedesktop.org/wiki/Software_2fxlibs
I just went through it for the first time myself, and had the exact
same problems.
Good Luck,
Dickson
Nicolas Cornu wrote:
I just downloaded XCB-PROTO from CVS
i get this error:
-
checking for xsltproc... /usr/bin/xsltproc
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XCBPROTO... checking for XPROTO... configure: error:
Package requirements (xproto) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively you may set the XPROTO_CFLAGS and XPROTO_LIBS
environment variables
to avoid the need to call pkg-config. See the pkg-config man page for
more details.
[EMAIL PROTECTED] xcb]# echo $PKG_CONFIG_PATH
/usr/lib/pkgconfig/
[EMAIL PROTECTED] xcb]#
---
/usr/lib/pkgconfig/xcb-proto.pc:
---
prefix=/usr/
includedir=${prefix}/include
xcbincludedir=${includedir}/X11/XCB
Name: XCBProto
Description: X protocol descriptions for XCB
Version: 0.9
---
Thanks in advance,
Cornu Nicolas
___
xcb mailing list
[EMAIL PROTECTED]
http://lists.freedesktop.org/mailman/listinfo/xcb
i have Xproto installed now moved the .pc file to /usr/lib/pkgconfig
I try to compil libgdiplus with Xcb
i get the following error
then mv -f .deps/cairo_xcb_surface.Tpo .deps/cairo_xcb_surface.Plo;
else rm -f .deps/cairo_xcb_surface.Tpo; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include
-D_XOPEN_SOURCE=500 -I/usr/local/include -I/usr/include/libpng12
-I../../libpixman/src -I/usr/include/freetype2 -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -g -O2 -MT cairo_xcb_surface.lo
-MD -MP -MF .deps/cairo_xcb_surface.Tpo -c cairo_xcb_surface.c -fPIC
-DPIC -o .libs/cairo_xcb_surface.o
cairo_xcb_surface.c:40: error: syntax error before '*' token
cairo_xcb_surface.c:43: warning: function declaration isn't a prototype
cairo_xcb_surface.c:48: error: syntax error before format_from_visual
cairo_xcb_surface.c:48: error: syntax error before '*' token
cairo_xcb_surface.c:49: warning: return type defaults to `int'
cairo_xcb_surface.c:49: warning: function declaration isn't a prototype
cairo_xcb_surface.c: In function `format_from_visual':
cairo_xcb_surface.c:50: error: syntax error before nil
cairo_xcb_surface.c: At top level:
cairo_xcb_surface.c:51: error: syntax error before '*' token
cairo_xcb_surface.c:51: warning: type defaults to `int' in declaration
of `r'
cairo_xcb_surface.c:51: warning: data definition has no type or storage
class
cairo_xcb_surface.c:52: error: syntax error before si
cairo_xcb_surface.c:52: warning: type defaults to `int' in declaration
of `si'
cairo_xcb_surface.c:52: warning: data definition has no type or storage
class
cairo_xcb_surface.c:53: error: syntax error before di
In advance thanks,
Cornu Nicolas
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] coLinux/Debian mod_mono/1.0.5 error
Hi! I'm using coLinux/Debian unstable along with Apache/2.0.54 (Debian GNU/Linux) mod_mono/1.0.5 PHP/4.3.10-15 and mono 1.1.8, when I try to connect to an app I get this error: In ModMonoWorker.Run: Abnormal string size. Parameter name: size I already tried Google... Please help! thanks! -- Fabián ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
