fix to issue 5 has been pulled together with issue 3.
besides the fix to the Encoding.GetEncoding itself, the change also contains
several fixes to avoid race-condition in multithreading environment, and some
performance improvements of I18N.
https://github.com/mono/mono/pull/1272/files
it will
i saw the bug you have opened, the behavior is pretty interesting, which is out
of my expectation. thank you for the information.
.Hzj_jie
Subject: Re: [Mono-dev] a set of tests to find out the difference between
.Net and Mono implementation
From: jonpr...@vt.edu
Date: Tue, 16 Sep
hi, all,i am trying to move my code mainly vb.net from .net to mono, there
are ~300 test cases, which can help to find out the difference between .Net and
Mono implementation.if you are interesting, you can enlist the code from
codeplex,
Hi,
i tried it myself, and find out several issues, which are mainly against
Mono 3.10 from development tree.
Thanks for the analysis more comments inline.
1. GC
thought GC.Collect() does not guarantee all the inaccessible objects are
finalized and reclaimed, .Net implementation
On 16/09/14 12:31, Marek Safar wrote:
Linux, it's not. i do not think this is a Mono issue, but will it be better
to help set the execute permission if Process.Start calls a non-executable
file? or at least provide a more friendly exception, current the error
message is 'Cannot find the
If you really mean to execute an arbitrary file
(Process.Start(foo.xlsx) will open foo.xlsx in Excel, on Windows, for
example) then call /usr/bin/xdg-open thing - this is probably the most
useful use-case, and is also valid when thing is a URL, opening in the
default browser.
AFAIK, xdg-open is
Yes, in the scenario to start a URL or an xls file, the behavior is correct.
But think about a different scenario, the logic extract a set of files from a
gzip package to the hard disk, start the executable file in the package, the
Process.Start will fail. And except for some tricks, dev cannot
Thank you Marek,
1. GC
It's do tricky, briefly WeakReference an object, and call GC.Collect() and
GC.WaitForPendingFinalizers() for several times 3 in my case , in .Net, the
WeakReference will be invalid. in Mono, I did not see the same behavior. I
agree your point, there should be no
On Sep 16, 2014, at 6:10 AM, 何子杰Hzj_jie hzj_...@hotmail.com wrote:
1. GC
thought GC.Collect() does not guarantee all the inaccessible objects are
finalized and reclaimed, .Net implementation usually be able to delete all
the inaccessible objects.
impacts, delegate_pinning_test, it make sure
