Re: [Mono-winforms-list] Could not load file or assembly
My problem was solved after I posted here: http://ubuntuforums.org/showthread.php?t=1034940 But essentially the solution was to install this: http://directhex.mfgames.com/pool/ma...1~dhx1_all.deb -- View this message in context: http://www.nabble.com/Could-not-load-file-or-assembly-tp21335169p22946550.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] DrawImage alpha blend broken in libgdiplus
Alex Shulgin wrote:
Hi,
I believe that alpha blending is broken in libgdiplus.
I've located the problem. It is due to the inconsistent handling of
PixelFormat32bppPArgb (premultiplied alpha) in libgdiplus.
In the attached patch I've added the check on PArgb to DrawImageRect in
analogy with texturebrush.c and fixed pngcodec.c to set pixel format to
PArgb if premultiplication was done.
This fixes my demo program and there's no visible regressions in a
fairly complex application which originally revealed the problem.
If the feeling is such that this is appropriate patch, I'd add the same
handling for places like this (there's few).
--
Regards,
Alex
Index: src/image.c
===
--- src/image.c (revision 130138)
+++ src/image.c (working copy)
@@ -380,6 +380,8 @@
BOOL need_scaling = FALSE;
double scaled_width, scaled_height;
cairo_matrix_t orig_matrix;
+ BYTE *premul = NULL;
+ cairo_surface_t *surface = NULL;
if (!graphics || !image)
return InvalidParameter;
@@ -430,13 +432,24 @@
/* Create a surface for this bitmap if one doesn't exist */
gdip_bitmap_ensure_surface (image);
+ surface = image-surface;
+
+ if (gdip_bitmap_format_needs_premultiplication (image)) {
+premul = gdip_bitmap_get_premultiplied_scan0 (image);
+if (premul) {
+BitmapData *data = image-active_bitmap;
+surface = cairo_image_surface_create_for_data (premul, CAIRO_FORMAT_ARGB32,
+data-width, data-height, data-stride);
+}
+}
+
if (width != image-active_bitmap-width || height != image-active_bitmap-height) {
scaled_width = (double) width / image-active_bitmap-width;
scaled_height = (double) height / image-active_bitmap-height;
need_scaling = TRUE;
}
- pattern = cairo_pattern_create_for_surface (image-surface);
+ pattern = cairo_pattern_create_for_surface (surface);
cairo_pattern_set_filter (pattern, gdip_get_cairo_filter (graphics-interpolation));
@@ -458,6 +471,12 @@
cairo_pattern_destroy (org_pattern);
cairo_pattern_destroy (pattern);
+ if (premul)
+ {
+ cairo_surface_destroy (surface);
+ GdipFree (premul);
+ }
+
return Ok;
}
Index: src/pngcodec.c
===
--- src/pngcodec.c (revision 130138)
+++ src/pngcodec.c (working copy)
@@ -527,7 +527,6 @@
result-cairo_format = CAIRO_FORMAT_ARGB32;
result-active_bitmap-stride = stride;
- result-active_bitmap-pixel_format = PixelFormat32bppARGB;
result-active_bitmap-width = width;
result-active_bitmap-height = height;
result-active_bitmap-scan0 = rawdata;
@@ -543,7 +542,7 @@
result-active_bitmap-pixel_format = PixelFormat24bppRGB;
result-active_bitmap-image_flags = ImageFlagsColorSpaceRGB;
} else if (channels == 4) {
- result-active_bitmap-pixel_format = PixelFormat32bppARGB;
+ result-active_bitmap-pixel_format = PixelFormat32bppPARGB;
result-active_bitmap-image_flags = ImageFlagsColorSpaceRGB;
} else if ((channels == 1) (color_type == PNG_COLOR_TYPE_GRAY)) {
// doesn't apply to 2bpp images
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] DrawImage alpha blend broken in libgdiplus
Hello Alex, The patch looks good. However this kind of fix has been known to cause regression in the past. Could you supply unit tests that ensure that the image can be saved and reloaded correctly ? (modifying your previous sample code should be easy). With this (and if all existing tests pass successfully) I'll be able to commit your patch. Thanks! Sebastien On Wed, 2009-04-08 at 18:59 +0300, Alex Shulgin wrote: Alex Shulgin wrote: Hi, I believe that alpha blending is broken in libgdiplus. I've located the problem. It is due to the inconsistent handling of PixelFormat32bppPArgb (premultiplied alpha) in libgdiplus. In the attached patch I've added the check on PArgb to DrawImageRect in analogy with texturebrush.c and fixed pngcodec.c to set pixel format to PArgb if premultiplication was done. This fixes my demo program and there's no visible regressions in a fairly complex application which originally revealed the problem. If the feeling is such that this is appropriate patch, I'd add the same handling for places like this (there's few). -- Regards, Alex ___ 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-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Hi, Can you give us a breakdown of the size of the many files produced by mono? Like sizes of the runtime, assemblies after linking/stripping and AOT'd binaries. I can't get exact numbers for profile 2.0 because it doesn't work with mono-2-0 AOT, so best what I can do is to extrapolate numbers from profile 1.0 data. There are some numbers for profile 1.0 when mono linker is NOT used: Total size for sample iPhone application made with Unity (it includes Unity engine + .NET interface to its functions, physX, libcurl, mono runtime and AOTed mscorlib.dll): 15,999,648 bytes breakdown of this number a) Mono runtime compiled for ARM with --enable- minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes. b) mscorlib.dll (.dll size 2,081,280 bytes) AOTed code size: 6,703,136 c) UnityEngine.dll (.dll size 376,320 bytes) AOTed code size: 2,313,696 Numbers when mono linker IS used: Total size for sample iPhone application made with Unity (it includes Unity engine + .NET interface to its functions, physX, libcurl, mono runtime and AOTed mscorlib.dll): 11,791,088 bytes breakdown of this number a) Mono runtime compiled for ARM with --enable- minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes. b) mscorlib.dll (.dll size 1,418,240 bytes, we use less strict than default monolinker blacklist for mscorlib) AOTed code size: 4,259,216 bytes c) UnityEngine.dll (.dll size 112,128 bytes) AOTed code size: 543,024 bytes In general mono linker does great job (when supplied with optimized blacklists). Numbers written above are just for empty application and if you add something useful like Sockets to you C# scripts then suddenly main binary size explodes, reaches 28 MB and more, iPhone SDK linker fails to link it, so use of .NET Sockets without mono linker step is impossible. Numbers for application that uses Sockets and goes through mono linker: Total size: 14,0334,40 bytes. breakdown of this number a) Mono runtime compiled for ARM with --enable- minimal=jit,reflection_emit,profiler,com option takes 1,790,384 bytes. b) mscorlib.dll (.dll size 1,430,016 bytes) AOTed code size: 4,298,672 c) System.Xml.dll (.dll size 557,056 bytes after mono linker) AOTed code size: 1,725,872 bytes d) System.dll (.dll size 130048 bytes after mono linker) AOTed code size: 462,416 bytes e) UnityEngine.dll (.dll size 112,128 bytes) AOTed code size: 543,024 So adding of reference to .NET Socket API adds two new dependencies System.dll and System.Xml.dll and ends up with 2.1 MB of additional ARM code. I checked what dependencies would be in the case of 2.0 profile when application is using sockets: Mono.Security.dll - official size 285,696 bytes, after monolinker - N/A* System.Configuration.dll - official size 117,760 bytes, after monolinker - N/A* System.Security.dll - official size 132,608 bytes, after monolinker - N/A* System.Xml.dll - official size 1,250,304 bytes, after monolinker - N/A* System.dll - official size 1,467,392 bytes, after monolinker - N/A* mscorlib.dll - official size 2,508,288 bytes, after monolinker - 1,640,960. after monolinker - N/A* means that currently my version of monolinker strips these dll too much (no exported types are left), so I can't get these numbers without fixing mono linker. I would estimate that in total it would increase our footprint for sample Sockets application at least by 1 MB (bigger mscorlib + 3 additional dependencies) Would us help Silverlight profile? I doubt it, because we are using shorter mono linker blacklist for mscorlib and we are achieving smaller working size of this lib already. I think these big binary size (and also big memory footprint) is common for other embedded devices, not just iPhone. I see mscorlib (and other libraries) profile 1.0 as best fit for embedded devices. Miguel, I saw your comment that people who are using profile 1.0 should stick with mono-2-4 then I would like to ask what about AOT on other platforms support? Let's say mono adds PPC AOT support to mono-2-6 will it be backported to mono-2-4? If not then I see the problem how mono based applications could be developed for small devices that currently are not supported by mono-2-4, but maybe will be supported in the next versions. There are a lot of optimizations that can be done to reduce footprint like embedding assemblies content in the AOT'd image in a compact form and improving the ARM code generator. Embedding something into AOT'd image (mean linked into main app binary) makes everything worse in respect to binary size and maybe memory footprint. Maybe I'm missing something in your idea? Mantas Puida ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
On Wed, Apr 8, 2009 at 11:50 AM, Mantas Puida man...@unity3d.com wrote: Hi, Embedding something into AOT'd image (mean linked into main app binary) makes everything worse in respect to binary size and maybe memory footprint. Maybe I'm missing something in your idea? Yes, the idea is to embed more data from the assembly into the AOT image and strip/eliminate the assembly. Besides that, a lot of the code generated due to full AOT could be implemented in a general, but slower fashion in the runtime, resulting in some space savings. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
Embedding something into AOT'd image (mean linked into main app binary) makes everything worse in respect to binary size and maybe memory footprint. Maybe I'm missing something in your idea? Yes, the idea is to embed more data from the assembly into the AOT image and strip/eliminate the assembly. I think if it's data (i.e. not a CPU instruction stream), it should not be linked into AOT image. This is mostly specific to the iPhone. Applications can be compressed, but Apple first encrypts all the code. So anything that is in the executable is effectively not compressible. To save space, everything that is not machine code should ideally be outside of the executable. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.0 and 2.0 profiles
Hello, Sorry, I forgot to CC m-d-l in the last post. Hello Mantas, Thanks for your feedback: So adding of reference to .NET Socket API adds two new dependencies System.dll and System.Xml.dll and ends up with 2.1 MB of additional ARM code. Would you mind checking why Sockets is pulling System.Xml for you? Another thing that would be useful is to find out why System ends up so large even with the linker being used if you are only using sockets. For example, let us consider the Silverlight profile: it requires us to ifdef some steps during the build time that to assist the linker. The linker works, but it can not do magic without some help here and there. That is why I am wondering if we can do something along the lines of adding a build profile that would work for embedded case scenarios, but still based on a generics-based profile instead of the non- generics build. I am interested in getting to the bottom of why the generics-based profile can not be used in embedded systems and address that issue, because that is where most of the pain comes from (other pieces are just low-tech variations of what the Mono linker can do). If we can figure out a way to have you guys up and running with a generics-based mscorlib that consumes as much memory/space as the 1.0 profile I think we will all win. Question: what are the problems that you guys are facing with AOT and generics? Miguel, I saw your comment that people who are using profile 1.0 should stick with mono-2-4 then I would like to ask what about AOT on other platforms support? Let's say mono adds PPC AOT support to mono-2-6 will it be backported to mono-2-4? If not then I see the problem how mono based applications could be developed for small devices that currently are not supported by mono-2-4, but maybe will be supported in the next versions. Possibly, but I have a hard time coming up with a PowerPC device that can be considered a small device. The only case I am aware of where the AOT code for PPC makes sense are gaming consoles, and those are capable systems. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Implement support for compiled regular expressions in profile 1.x
2009/4/8 Aras Pranckevicius a...@unity3d.com Embedding something into AOT'd image (mean linked into main app binary) makes everything worse in respect to binary size and maybe memory footprint. Maybe I'm missing something in your idea? Yes, the idea is to embed more data from the assembly into the AOT image and strip/eliminate the assembly. I think if it's data (i.e. not a CPU instruction stream), it should not be linked into AOT image. This is mostly specific to the iPhone. Applications can be compressed, but Apple first encrypts all the code. So anything that is in the executable is effectively not compressible. To save space, everything that is not machine code should ideally be outside of the executable. Oh, I see, well. There are a couple of things you guys should try: Use linker/cecil to merge all assemblies before AOT'ng them. This should save some bytes. Improve the linker and your linker scripts to be more aggressive and make more assumptions. Improve the arm codegen to emit more compact code. Move some code emitted by the full AOT mode to be fixed functionality of the runtime. Fix the runtime so it can be compiled with thumb. Port the JIT to emit thumb. Strip more functionality of the runtime. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.0 and 2.0 profiles
AFAIR, AOTed code still need the original assemblies can then be compressed separately as data, or those numbers doesn't include that part. It would be even better if the runtime could use those zipped versions directly instead of having them unzipped on install. It would be similar to how java jars work. Just my two cents, On Wed, Apr 8, 2009 at 3:13 PM, Miguel de Icaza mig...@novell.com wrote: Hello, Sorry, I forgot to CC m-d-l in the last post. Hello Mantas, Thanks for your feedback: So adding of reference to .NET Socket API adds two new dependencies System.dll and System.Xml.dll and ends up with 2.1 MB of additional ARM code. Would you mind checking why Sockets is pulling System.Xml for you? Another thing that would be useful is to find out why System ends up so large even with the linker being used if you are only using sockets. For example, let us consider the Silverlight profile: it requires us to ifdef some steps during the build time that to assist the linker. The linker works, but it can not do magic without some help here and there. That is why I am wondering if we can do something along the lines of adding a build profile that would work for embedded case scenarios, but still based on a generics-based profile instead of the non- generics build. I am interested in getting to the bottom of why the generics-based profile can not be used in embedded systems and address that issue, because that is where most of the pain comes from (other pieces are just low-tech variations of what the Mono linker can do). If we can figure out a way to have you guys up and running with a generics-based mscorlib that consumes as much memory/space as the 1.0 profile I think we will all win. Question: what are the problems that you guys are facing with AOT and generics? Miguel, I saw your comment that people who are using profile 1.0 should stick with mono-2-4 then I would like to ask what about AOT on other platforms support? Let's say mono adds PPC AOT support to mono-2-6 will it be backported to mono-2-4? If not then I see the problem how mono based applications could be developed for small devices that currently are not supported by mono-2-4, but maybe will be supported in the next versions. Possibly, but I have a hard time coming up with a PowerPC device that can be considered a small device. The only case I am aware of where the AOT code for PPC makes sense are gaming consoles, and those are capable systems. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using mdoc for internal documentation
On Apr 7, 2009, at 7:08 PM, Jonathan Pryor wrote: On Tue, 2009-04-07 at 17:54 -0700, Casey Marshall wrote: `foo.dll' is an assembly I've built (forgive the obfuscation). It's typically a very core assembly, i.e., one very high up in the dependency tree, and most certainly is in the same directory as the assembly depending on it, and is being specified on the command line. In fact, I was really surprised that it was complaining about not finding that assembly, since it is such a central one. WRT this, it seems like somehow mdoc is trying to look up the qualified (or whatever) name, which includes the Version=1.0.0.0, PublicKeyToken=XXX, et al. Cecil seems to just try name + .dll and name + .exe, which obviously won't work. It should work...within reason, as the qualified assembly name will (by necessity) include the file's base name, e.g. 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' must be located within an assembly having 'mscorlib' as the basename. Now, that (obviously) can't be the only check -- after finding an assembly with a matching basename it'll need to check that the version, culture, and PublicKeyToken of the found assembly are correct (and if not correct continue looking for the next one), but as a start it should be fine. Which leads to the next question: where is 'foo.dll' located? In a path on the command line, e.g. 'mdoc update path/to/foo.dll'? foo.dll is in the directory bin/Debug, and so is the assembly I'm documenting (call it bar.dll), which depends on foo.dll. Or is foo.dll in the GAC? Or is foo.dll in MONO_PATH, e.g. 'MONO_PATH=/tmp mdoc update ...'? For the first two cases (command line and GAC), Cecil *should* be finding the assembly (otherwise we couldn't resolve IEnumerableT and other mscorlib types, and I know I fixed a bug related to the first case that the Gendarme build process was encountering). MONO_PATH, as mentioned before, isn't currently supported (as it hadn't even occurred to me to support it). If 'foo.dll' is in MONO_PATH, could you try using the patch I applied to the previous email and see if that fixes the issue? I don't think that will fix it — I dug around with mdb and it looks like the assembly resolver being used (a DefaultAssemblyResolver) only has the default directories in the search path, . and bin. The directory `foo.dll' (along with everything else) is in, bin/Debug, doesn't get added to that resolver. It's a different object than the one that AddSearchDirectory is called on in monodocer.cs. Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using mdoc for internal documentation
On Wed, 2009-04-08 at 13:37 -0700, Casey Marshall wrote:
I don't think that will fix it — I dug around with mdb and it looks
like the assembly resolver being used (a DefaultAssemblyResolver) only
has the default directories in the search path, . and bin.
This is exactly what I needed to know. I didn't realize that each
assembly would have a different Resolver... :-(
In any event, I was (eventually) able to reproduce the problem, and have
cooked up the attached patch which appears to fix it for me.
Hopefully this will fix things for you.
- Jon
Index: tools/mdoc/Mono.Documentation/monodocer.cs
===
--- tools/mdoc/Mono.Documentation/monodocer.cs (revision 128117)
+++ tools/mdoc/Mono.Documentation/monodocer.cs (working copy)
@@ -47,6 +47,7 @@
static string srcPath;
static ListAssemblyDefinition assemblies;
+ static DefaultAssemblyResolver assemblyResolver = new DefaultAssemblyResolver();
static bool nooverrides = true, delete = false, ignoremembers = false;
static bool pretty = false;
@@ -231,9 +232,9 @@
if (assembly == null)
throw new InvalidOperationException(Assembly + name + not found.);
- var r = assembly.Resolver as BaseAssemblyResolver;
- if (r != null name.Contains (Path.DirectorySeparatorChar)) {
- r.AddSearchDirectory (Path.GetDirectoryName (name));
+ assembly.Resolver = assemblyResolver;
+ if (name.Contains (Path.DirectorySeparatorChar)) {
+ assemblyResolver.AddSearchDirectory (Path.GetDirectoryName (name));
}
return assembly;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Question on Code Generation
I'd like to hear about, you can email me directly if you don't mind. I'm working on Microsoft Oslo stuff for my own shop and asked via the Mono wiki if Mono work in-progress to support it. Due to Oslo currently being on a preview pre-release (CTP), Mono will wait. Understandable. But, I'd be interested in seeing to it Mono can support .Net 4.0 modeling the very day.Net 4.0 releases. - Original Message - From: anton123 niniendowarr...@gmail.com To: mono-list@lists.ximian.com Sent: Tuesday, April 07, 2009 6:08 PM Subject: Re: [Mono-list] Question on Code Generation I took a peek at T4 and it looks interesting. I'm still going through the tutorials on Mono development though so I'll take a deeper look on it once I get a better handle on Mono. I'll try everything I can to make Mono work for my project. I'm hell bent on it. That much can be said. :-) jhill wrote: CodeSmith 2.6 is almost 5 years old. Sadly, it probably isn't that far off from working with Mono, but it has some p/invokes, and after this long, it doesn't seem like they have any incentive to do any maintenance on the freeware tool. If you want to generate code from CodeSmith tempates on Mono, then it may be worth seeing if they have plans to support Mono with a newer version of their tool. On the other hand, I would love to see the T4 community grow. It seems like a lot more projects are starting to use it (particularly MS projects)... --Joseph Hi Michael! Thanks for the information. As a short exercise, I tried to run the freeware version of CodeSmith (2.6) on Mono and it didn't work. At least I tried. I was also thinking that CodeSmith should generate code that Mono can use as well. I'm writing on Linux mostly and I'm trying to really make this work since I don't want to own a Windows box for this. I'm scouring for everything that I can about this. Thank you for the link on T4. I'll be sure to read up on it. Michael Hutchinson wrote: On Mon, Apr 6, 2009 at 7:00 PM, anton123 niniendowarr...@gmail.com wrote: I'm wondering if there's a Mono substitute/counterpart to CodeSmith (or if Mono does support CodeSmith). I'm hoping it might since I'm anticipating a lot of code-generation heavy work. Can anyone shed some light? I don't know whether CodeSmith runs on Mono, though it must be able to generate code that will run on Mono, so if you're writing code on Windows, then it might be a good choice. If you're in Linux/Mac, or you need more flexibility to customise and ship the generator, then check out Mono's implementation of Visual Studio's T4 (Text Template Transformation Toolkit) system: http://tirania.org/blog/archive/2009/Mar-10.html -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://www.nabble.com/Question-on-Code-Generation-tp22919191p22940139.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Fwd: System.IO.SerialPort.BytesToRead closes program
Compiled using gmcs on Ubuntu, getting an exception, no crash.
Mono C# compiler version 2.0.1.0
Mono JIT compiler version 2.0.1 (tarball)
Same results on:
Mono C# compiler version 2.4.0.0
Mono JIT compiler version 2.4 (/branches/mono-2-4/mono r130414 za mrt 28
17:21:49 CET 2009)
LANG=C mono --debug ./WindowsCrash.exe:
Unhandled Exception: System.IO.IOException: No such file or directory
at System.IO.Ports.SerialPortStream.ThrowIOException () [0x00012] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:299
at System.IO.Ports.SerialPortStream..ctor (System.String portName, Int32
baudRate, Int32 dataBits, Parity parity, StopBits stopBits, Boolean
dtrEnable, Boolean rtsEnable, Handshake handshake, Int32 readTimeout, Int32
writeTimeout, Int32 readBufferSize, Int32 writeBufferSize) [0x0001e] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:36
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPortStream:.ctor
(string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
at System.IO.Ports.SerialPort.Open () [0x00078] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPort.cs:563
at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort:Open ()
at WindowsCrash.Program.Main (System.String[] args) [0x0]
On Tue, Apr 7, 2009 at 1:39 PM, trampster tramps...@gmail.com wrote:
it appears that calling System.IO.SerialPort.BytesToRead closes my
application when runing on windows using mono 2.4. The following code
reproduces the problem. No error message or exception seems to be generated
it just closes.
using System.IO.Ports;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SerialPort serialPort = new SerialPort(Com4, 19200);
serialPort.Open();
Console.WriteLine(before);
int bytesToRead = serialPort.BytesToRead;
Console.WriteLine(after);
}
}
}
My questions are as follows.
1. I'm I doing something wrong, (the code works when run on dot net)
2. Does this work on the linux build?
I raised a bug https://bugzilla.novell.com/show_bug.cgi?id=490910
but it is not getting any activity.
I am very interested in getting my coding running on mono, and was under
the
impression that all this .net 2.0 stuff was implemented and stable. Was I
wrong?
--
View this message in context:
http://www.nabble.com/System.IO.SerialPort.BytesToRead-closes-program-tp22927258p22927258.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
Mark
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Question on Code Generation
I certainly have no problems touching base with you over how this one goes. :-) Trober wrote: I'd like to hear about, you can email me directly if you don't mind. I'm working on Microsoft Oslo stuff for my own shop and asked via the Mono wiki if Mono work in-progress to support it. Due to Oslo currently being on a preview pre-release (CTP), Mono will wait. Understandable. But, I'd be interested in seeing to it Mono can support .Net 4.0 modeling the very day.Net 4.0 releases. - Original Message - From: anton123 niniendowarr...@gmail.com To: mono-list@lists.ximian.com Sent: Tuesday, April 07, 2009 6:08 PM Subject: Re: [Mono-list] Question on Code Generation I took a peek at T4 and it looks interesting. I'm still going through the tutorials on Mono development though so I'll take a deeper look on it once I get a better handle on Mono. I'll try everything I can to make Mono work for my project. I'm hell bent on it. That much can be said. :-) jhill wrote: CodeSmith 2.6 is almost 5 years old. Sadly, it probably isn't that far off from working with Mono, but it has some p/invokes, and after this long, it doesn't seem like they have any incentive to do any maintenance on the freeware tool. If you want to generate code from CodeSmith tempates on Mono, then it may be worth seeing if they have plans to support Mono with a newer version of their tool. On the other hand, I would love to see the T4 community grow. It seems like a lot more projects are starting to use it (particularly MS projects)... --Joseph Hi Michael! Thanks for the information. As a short exercise, I tried to run the freeware version of CodeSmith (2.6) on Mono and it didn't work. At least I tried. I was also thinking that CodeSmith should generate code that Mono can use as well. I'm writing on Linux mostly and I'm trying to really make this work since I don't want to own a Windows box for this. I'm scouring for everything that I can about this. Thank you for the link on T4. I'll be sure to read up on it. Michael Hutchinson wrote: On Mon, Apr 6, 2009 at 7:00 PM, anton123 niniendowarr...@gmail.com wrote: I'm wondering if there's a Mono substitute/counterpart to CodeSmith (or if Mono does support CodeSmith). I'm hoping it might since I'm anticipating a lot of code-generation heavy work. Can anyone shed some light? I don't know whether CodeSmith runs on Mono, though it must be able to generate code that will run on Mono, so if you're writing code on Windows, then it might be a good choice. If you're in Linux/Mac, or you need more flexibility to customise and ship the generator, then check out Mono's implementation of Visual Studio's T4 (Text Template Transformation Toolkit) system: http://tirania.org/blog/archive/2009/Mar-10.html -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://www.nabble.com/Question-on-Code-Generation-tp22919191p22940139.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://www.nabble.com/Question-on-Code-Generation-tp22919191p22945451.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead closes program
Would be good if you supply a example which does work anywhere, it's hard to
test for me, because I don't have the knowledge to get Open() to work.
On Wed, Apr 8, 2009 at 10:44 AM, Daniel tramps...@gmail.com wrote:
-- Forwarded message --
From: Daniel tramps...@gmail.com
To: Mark de Bruijn kram...@gmail.com
Date: Wed, 08 Apr 2009 20:41:18 +1200
Subject: Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead closes
program
Thanks for trying but your code threw the exception on Open() not on
accessing BytesToRead. Most likely because you don't have a Com4.
I do have a Com4 and Open works it's calling BytesToRead that causes my
program to close.
Any more ideas?
Cheers,
Daniel
Mark de Bruijn wrote:
Compiled using gmcs on Ubuntu, getting an exception, no crash.
Mono C# compiler version 2.0.1.0
Mono JIT compiler version 2.0.1 (tarball)
Same results on:
Mono C# compiler version 2.4.0.0
Mono JIT compiler version 2.4 (/branches/mono-2-4/mono r130414 za mrt 28
17:21:49 CET 2009)
LANG=C mono --debug ./WindowsCrash.exe:
Unhandled Exception: System.IO.IOException: No such file or directory
at System.IO.Ports.SerialPortStream.ThrowIOException () [0x00012] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:299
at System.IO.Ports.SerialPortStream..ctor (System.String portName, Int32
baudRate, Int32 dataBits, Parity parity, StopBits stopBits, Boolean
dtrEnable, Boolean rtsEnable, Handshake handshake, Int32 readTimeout, Int32
writeTimeout, Int32 readBufferSize, Int32 writeBufferSize) [0x0001e] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:36
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPortStream:.ctor
(string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
at System.IO.Ports.SerialPort.Open () [0x00078] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPort.cs:563
at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort:Open
()
at WindowsCrash.Program.Main (System.String[] args) [0x0]
On Tue, Apr 7, 2009 at 1:39 PM, trampster tramps...@gmail.com mailto:
tramps...@gmail.com wrote:
it appears that calling System.IO.SerialPort.BytesToRead closes my
application when runing on windows using mono 2.4. The following code
reproduces the problem. No error message or exception seems to be
generated
it just closes.
using System.IO.Ports;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SerialPort serialPort = new SerialPort(Com4, 19200);
serialPort.Open();
Console.WriteLine(before);
int bytesToRead = serialPort.BytesToRead;
Console.WriteLine(after);
}
}
}
My questions are as follows.
1. I'm I doing something wrong, (the code works when run on dot net)
2. Does this work on the linux build?
I raised a bug https://bugzilla.novell.com/show_bug.cgi?id=490910
but it is not getting any activity.
I am very interested in getting my coding running on mono, and was
under the
impression that all this .net 2.0 stuff was implemented and
stable. Was I
wrong?
--
View this message in context:
http://www.nabble.com/System.IO.SerialPort.BytesToRead-closes-program-tp22927258p22927258.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
Mark
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
Mark
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Fwd: Fwd: System.IO.SerialPort.BytesToRead closes program
It runs fine now, no error. So yeah, windows side bug.
On Wed, Apr 8, 2009 at 10:53 AM, Daniel tramps...@gmail.com wrote:
You can use.
System.IO.Ports.SerialPort.GetPortNames()
to find what ports are available on your PC, just pick one
Cheers,
Daniel
Mark de Bruijn wrote:
Would be good if you supply a example which does work anywhere, it's hard
to test for me, because I don't have the knowledge to get Open() to work.
On Wed, Apr 8, 2009 at 10:44 AM, Daniel tramps...@gmail.com mailto:
tramps...@gmail.com wrote:
-- Forwarded message --
From: Daniel tramps...@gmail.com mailto:tramps...@gmail.com
To: Mark de Bruijn kram...@gmail.com mailto:kram...@gmail.com
Date: Wed, 08 Apr 2009 20:41:18 +1200
Subject: Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead
closes program
Thanks for trying but your code threw the exception on Open() not
on accessing BytesToRead. Most likely because you don't have a Com4.
I do have a Com4 and Open works it's calling BytesToRead that
causes my program to close.
Any more ideas?
Cheers,
Daniel
Mark de Bruijn wrote:
Compiled using gmcs on Ubuntu, getting an exception, no crash.
Mono C# compiler version 2.0.1.0
Mono JIT compiler version 2.0.1 (tarball)
Same results on:
Mono C# compiler version 2.4.0.0
Mono JIT compiler version 2.4 (/branches/mono-2-4/mono r130414
za mrt 28 17:21:49 CET 2009)
LANG=C mono --debug ./WindowsCrash.exe:
Unhandled Exception: System.IO.IOException: No such file or
directory
at System.IO.Ports.SerialPortStream.ThrowIOException ()
[0x00012] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:299
at System.IO.Ports.SerialPortStream..ctor (System.String
portName, Int32 baudRate, Int32 dataBits, Parity parity,
StopBits stopBits, Boolean dtrEnable, Boolean rtsEnable,
Handshake handshake, Int32 readTimeout, Int32 writeTimeout,
Int32 readBufferSize, Int32 writeBufferSize) [0x0001e] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:36
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPortStream:.ctor
(string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
at System.IO.Ports.SerialPort.Open () [0x00078] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPort.cs:563
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPort:Open ()
at WindowsCrash.Program.Main (System.String[] args) [0x0]
On Tue, Apr 7, 2009 at 1:39 PM, trampster tramps...@gmail.com
mailto:tramps...@gmail.com mailto:tramps...@gmail.com
mailto:tramps...@gmail.com wrote:
it appears that calling System.IO.SerialPort.BytesToRead
closes my
application when runing on windows using mono 2.4. The
following code
reproduces the problem. No error message or exception seems
to be
generated
it just closes.
using System.IO.Ports;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SerialPort serialPort = new SerialPort(Com4, 19200);
serialPort.Open();
Console.WriteLine(before);
int bytesToRead = serialPort.BytesToRead;
Console.WriteLine(after);
}
}
}
My questions are as follows.
1. I'm I doing something wrong, (the code works when run on
dot net)
2. Does this work on the linux build?
I raised a bug
https://bugzilla.novell.com/show_bug.cgi?id=490910
but it is not getting any activity.
I am very interested in getting my coding running on mono,
and was
under the
impression that all this .net 2.0 stuff was implemented and
stable. Was I
wrong?
--
View this message in context:
http://www.nabble.com/System.IO.SerialPort.BytesToRead-closes-program-tp22927258p22927258.html
Sent from the Mono - General mailing list archive at
Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--Mark
___
Re: [Mono-list] LockBits() on Mono 2.2?
Hey, I finally got around to nail the bug down. Here's the report: https://bugzilla.novell.com/show_bug.cgi?id=493047 Alan McGovern-2 wrote: Hey, Well, if there's a bug then please try to reduce the testcase as much as possible before submitting it. If you can't it's still worth filing a bug and giving as much detail as you can. If its working on .NET but not Mono that's not a good sign. I was afraid of something like this. If there is an issue with a specific method, there are generally other ways of accomplishing exactly the same task. Sometimes all you need to do is use a different overload of the same method. For example here are two alternate methods of copying a bitmap, both of which are probably higher performance and both are definitely less bug prone: http://msdn.microsoft.com/en-us/library/aa457087.aspx So if you do encounter any issues, please file bug reports so they can be dealt with for the next release. Alan. Stifu wrote: I found a certain GDI+ bug recently, and I *think* it's related to LockBits(). I'm not sure, and didn't report the bug as I couldn't make a reduced test case yet. However, if you're interested, I can send you my not-so-reduced test case so you can have a look. But to sum things up: I have a Bitmap, try to clone it, and the cloned Bitmap is all black... while this works fine with .NET. LKeene wrote: Hello all, I have a general question regarding the use of LockBits() (in GDI+) for reading/writing to a bitmap. I'm using Mono 2.2 and am targeting Windows, OSX and Linux. Any current issues concerning the use of LockBits()/UnlockBits() I should be aware of? Any nasty buggies I should be on the lookout for? I found a few posts pertaining to this but they're not very current. Thanks eveyone. -L -- View this message in context: http://www.nabble.com/LockBits%28%29-on-Mono-2.2--tp22611389p22611603.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://www.nabble.com/LockBits%28%29-on-Mono-2.2--tp22611389p22946015.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead closes program
---BeginMessage---
Thanks for trying but your code threw the exception on Open() not on
accessing BytesToRead. Most likely because you don't have a Com4.
I do have a Com4 and Open works it's calling BytesToRead that causes
my program to close.
Any more ideas?
Cheers,
Daniel
Mark de Bruijn wrote:
Compiled using gmcs on Ubuntu, getting an exception, no crash.
Mono C# compiler version 2.0.1.0
Mono JIT compiler version 2.0.1 (tarball)
Same results on:
Mono C# compiler version 2.4.0.0
Mono JIT compiler version 2.4 (/branches/mono-2-4/mono r130414 za mrt
28 17:21:49 CET 2009)
LANG=C mono --debug ./WindowsCrash.exe:
Unhandled Exception: System.IO.IOException: No such file or directory
at System.IO.Ports.SerialPortStream.ThrowIOException () [0x00012] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:299
at System.IO.Ports.SerialPortStream..ctor (System.String portName,
Int32 baudRate, Int32 dataBits, Parity parity, StopBits stopBits,
Boolean dtrEnable, Boolean rtsEnable, Handshake handshake, Int32
readTimeout, Int32 writeTimeout, Int32 readBufferSize, Int32
writeBufferSize) [0x0001e] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:36
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPortStream:.ctor
(string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
at System.IO.Ports.SerialPort.Open () [0x00078] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPort.cs:563
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPort:Open ()
at WindowsCrash.Program.Main (System.String[] args) [0x0]
On Tue, Apr 7, 2009 at 1:39 PM, trampster tramps...@gmail.com
mailto:tramps...@gmail.com wrote:
it appears that calling System.IO.SerialPort.BytesToRead closes my
application when runing on windows using mono 2.4. The following code
reproduces the problem. No error message or exception seems to be
generated
it just closes.
using System.IO.Ports;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SerialPort serialPort = new SerialPort(Com4, 19200);
serialPort.Open();
Console.WriteLine(before);
int bytesToRead = serialPort.BytesToRead;
Console.WriteLine(after);
}
}
}
My questions are as follows.
1. I'm I doing something wrong, (the code works when run on dot net)
2. Does this work on the linux build?
I raised a bug https://bugzilla.novell.com/show_bug.cgi?id=490910
but it is not getting any activity.
I am very interested in getting my coding running on mono, and was
under the
impression that all this .net 2.0 stuff was implemented and
stable. Was I
wrong?
--
View this message in context:
http://www.nabble.com/System.IO.SerialPort.BytesToRead-closes-program-tp22927258p22927258.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
Mark
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
---End Message---
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead closes program
You can use.
System.IO.Ports.SerialPort.GetPortNames()
to find what ports are available on your PC, just pick one
Cheers,
Daniel
Mark de Bruijn wrote:
Would be good if you supply a example which does work anywhere, it's
hard to test for me, because I don't have the knowledge to get Open()
to work.
On Wed, Apr 8, 2009 at 10:44 AM, Daniel tramps...@gmail.com
mailto:tramps...@gmail.com wrote:
-- Forwarded message --
From: Daniel tramps...@gmail.com mailto:tramps...@gmail.com
To: Mark de Bruijn kram...@gmail.com mailto:kram...@gmail.com
Date: Wed, 08 Apr 2009 20:41:18 +1200
Subject: Re: [Mono-list] Fwd: System.IO.SerialPort.BytesToRead
closes program
Thanks for trying but your code threw the exception on Open() not
on accessing BytesToRead. Most likely because you don't have a Com4.
I do have a Com4 and Open works it's calling BytesToRead that
causes my program to close.
Any more ideas?
Cheers,
Daniel
Mark de Bruijn wrote:
Compiled using gmcs on Ubuntu, getting an exception, no crash.
Mono C# compiler version 2.0.1.0
Mono JIT compiler version 2.0.1 (tarball)
Same results on:
Mono C# compiler version 2.4.0.0
Mono JIT compiler version 2.4 (/branches/mono-2-4/mono r130414
za mrt 28 17:21:49 CET 2009)
LANG=C mono --debug ./WindowsCrash.exe:
Unhandled Exception: System.IO.IOException: No such file or
directory
at System.IO.Ports.SerialPortStream.ThrowIOException ()
[0x00012] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:299
at System.IO.Ports.SerialPortStream..ctor (System.String
portName, Int32 baudRate, Int32 dataBits, Parity parity,
StopBits stopBits, Boolean dtrEnable, Boolean rtsEnable,
Handshake handshake, Int32 readTimeout, Int32 writeTimeout,
Int32 readBufferSize, Int32 writeBufferSize) [0x0001e] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPortStream.cs:36
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPortStream:.ctor
(string,int,int,System.IO.Ports.Parity,System.IO.Ports.StopBits,bool,bool,System.IO.Ports.Handshake,int,int,int,int)
at System.IO.Ports.SerialPort.Open () [0x00078] in
/build/buildd/mono-2.0.1/mcs/class/System/System.IO.Ports/SerialPort.cs:563
at (wrapper remoting-invoke-with-check)
System.IO.Ports.SerialPort:Open ()
at WindowsCrash.Program.Main (System.String[] args) [0x0]
On Tue, Apr 7, 2009 at 1:39 PM, trampster tramps...@gmail.com
mailto:tramps...@gmail.com mailto:tramps...@gmail.com
mailto:tramps...@gmail.com wrote:
it appears that calling System.IO.SerialPort.BytesToRead
closes my
application when runing on windows using mono 2.4. The
following code
reproduces the problem. No error message or exception seems
to be
generated
it just closes.
using System.IO.Ports;
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SerialPort serialPort = new SerialPort(Com4, 19200);
serialPort.Open();
Console.WriteLine(before);
int bytesToRead = serialPort.BytesToRead;
Console.WriteLine(after);
}
}
}
My questions are as follows.
1. I'm I doing something wrong, (the code works when run on
dot net)
2. Does this work on the linux build?
I raised a bug
https://bugzilla.novell.com/show_bug.cgi?id=490910
but it is not getting any activity.
I am very interested in getting my coding running on mono,
and was
under the
impression that all this .net 2.0 stuff was implemented and
stable. Was I
wrong?
--
View this message in context:
http://www.nabble.com/System.IO.SerialPort.BytesToRead-closes-program-tp22927258p22927258.html
Sent from the Mono - General mailing list archive at
Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
--
Mark
Re: [Mono-list] Cairo
Same problem here. Files should not be necessary. With System.Drawing (gdi+) I used the Image object, but I want to get rid of gdi+. Is it possible to use the Data property and convert the data to png? -- View this message in context: http://www.nabble.com/Cairo-tp22135584p22952296.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
