>> Building mono-3.0.2 is getting time consuming and frustrating. I am really tempted to go back to 2.8.11 that was working pretty much out of the box for me.
Meant mono 2.11.4 (not 2.8.11.) From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, January 17, 2013 2:26 AM To: 'mono-devel-list' Subject: Re: [Mono-dev] Question on SerialPort - Serial.c I am running into an issue building latest libgdiplus-2.10.9 - I found no solution for this online. The output of 'configure' is clean with everything required met, (only after installing a bunch of last versions libraries). When I do 'make' the libgdiplus I get this. Any ideas? . /usr/bin/ld: testgdi.o: undefined reference to symbol 'g_free' /usr/bin/ld: note: 'g_free' is defined in DSO /usr/local/lib/libglib-2.0.so.0 so try adding it to the linker command line /usr/local/lib/libglib-2.0.so.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [testgdi] Error 1 make[2]: Leaving directory `/home/arocholl/libgdiplus-2.10.9/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/arocholl/libgdiplus-2.10.9' make: *** [all] Error 2 Building mono-3.0.2 is getting time consuming and frustrating. I am really tempted to go back to 2.8.11 that was working pretty much out of the box for me. My system: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Linux 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:45:18 UTC 2012 i686 i686 i386 GNU/Linux Thanks in advance From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, January 14, 2013 2:41 AM To: 'mono-devel-list' Subject: Re: [Mono-dev] Question on SerialPort - Serial.c Bugzilla - Bug 9525 filed in. I think I will branch off 3.0.3 based on your report on how fast Mono 3.x is being released. That sounds really encouraging. Thanks From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Lo Nigro Sent: Monday, January 14, 2013 1:01 AM To: [email protected] Cc: mono-devel-list Subject: Re: [Mono-dev] Question on SerialPort - Serial.c So except anyone disagree, baudrate values should not be checked for anything different than that. I agree - Mono should do whatever Microsoft .NET does. In general terms, how often a new Mono version is released with all the accumulated fixes? Releases of Mono 3.0 are coming out more frequently than previous releases did. Mono 3.0 came out in October 2012 and there have already been releases of 3.0.1, 3.0.2 and 3.0.3 to fix (mostly) minor bugs. I made a bug fix back in December and it's already in Mono 3.0.3. I think the Mono team are aiming for frequent small releases rather than infrequent massive releases. I am a Mercurial guy so have to get used to GIT in the first place. Git is very similar to Mercurial, it shouldn't take you too long to get used to Git :) On Mon, Jan 14, 2013 at 9:56 AM, <[email protected]> wrote: >>Does Microsoft's implementation accept *any* baud rate, or are there only some that it accepts that Mono doesn't? If Microsoft's accepts any then maybe the baud rate validation should be moved from Mono. Apparently, yes, MS accepts any baudrate but zero or lower than zero. I tested several custom baudrate values and, as far as I can see, all them are accepted by .NET SerialPort. Perhaps the Microsoft approach is to ask the underlying driver to validate baudrates, if at all. In the case of the Windows CP2102 driver, it will accept any baudrate including ones that are not physically supported. For instance I tested 1,500,000bps which is not really going to work on the physical CP2102 hardware (max available speed is 920,000bps on the CP2102 device) and still the SerialPort accepts the 1,500,000 bps, connects to it and if you read the baudrate property, it returns 1,500,000. So probably the Mono approach is too limited, because it really depends on a switch/case with a set of hardcoded, predefined values. See a fraction of Serial.c below switch (baud_rate) { .. case 115200: baud_rate = B115200; break; case 57600: baud_rate = B57600; break; .. case 50: case 0: default: baud_rate = -1; break; } Anything that is unknown goes to <default> which in the end returns an unsupported baudrate exception to the caller. However, that doesn't seem the way the Windows .NET SerialPort class works and, in today's world of interconnected USB COM custom devices, it really puts a hard limit on baudrates you can use. Interestingly, the documentation of SerialPort::Open doesn't explicitly document any baudrate value being invalid, except if it is equal or lower than zero. From MSDN: ArgumentOutOfRangeException <http://msdn.microsoft.com/en-us/library/system.argumentoutofrangeexception% 28v=vs.100%29.aspx> One or more of the properties for this instance are invalid. For example, the <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.parity%2 8v=vs.100%29.aspx> Parity, <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.databits %28v=vs.100%29.aspx> DataBits, or <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.handshak e%28v=vs.100%29.aspx> Handshake properties are not valid values; the <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.baudrate %28v=vs.100%29.aspx> BaudRate is less than or equal to zero; the <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readtime out%28v=vs.100%29.aspx> ReadTimeout or <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.writetim eout%28v=vs.100%29.aspx> WriteTimeout property is less than zero and is not <http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.infinite timeout%28v=vs.100%29.aspx> InfiniteTimeout. So except anyone disagree, baudrate values should not be checked for anything different than that. I will then fill in a bugzilla entry and pull a request in a few days. I am a Mercurial guy so have to get used to GIT in the first place. In general terms, how often a new Mono version is released with all the accumulated fixes? I saw releases are probably a few months apart in the official download site, is that driven by a scheduled event of any kind? >> You should be able to run "make" and "make install" in the directory of the file you're modifying, and that should compile and install just that component. Thanks for the tip, this is much better. It works nicely. _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
