[Mono-dev] mkbundle assembler generation
Hi,
(I am not subscribed to mono-devel so please cc:) . Recently I have played with
mkbundle and monolinker and they are rather neat! So thanks.
I am wondering why mkbundle generates assembler, instead of say, C? according
to the git log, it has been this way since day 1. What the generated assembler
(but with 3 different headers for linux/windows/mac os platforms) basically
amounts is something like this in C:
const unsigned char assembly_data_dllname[] = {hexdump};
I know doing it in assembler is faster (given that it is just a temporary
file); but in terms of post-generation customization, it might be easier?
I suppose there are the possibility of padding and alignment issues if a C
compiler is in the middle.
Hin-Tak Leung
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono 2.6+ : Garbage added to BinaryWriter/GZipStream output?
--- On Sun, 31/1/10, Gonzalo Paniagua Javier gonzalo.m...@gmail.com wrote: On Sun, 2010-01-31 at 13:29 -0500, Miguel de Icaza wrote: Hello Hin-Tak, There was a bug in Mono 2.6 that got fixed in a service release (2.6.1). Could you confirm which Mono version you are running? Use: mono --version on the command line. I should say a big thank-you to everybody for the good work for making .NET stuff runnable on linux. mono-devel-list is just a little slow because my posts needs moderation. (non-subscriber). I found the cause and filed the bug and patch at: https://bugzilla.novell.com/show_bug.cgi?id=574597 Gonszalo has already committed the fix as r150349 . FWIW, here it is: mono --version Mono JIT compiler version 2.6.1 (tarball Wed Jan 6 18:55:00 GMT 2010) Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC:Included Boehm (with typed GC and Parallel Mark) SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none I applied the patch that Hin-Tak sent in another email to the list a few days ago. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono 2.6+ : Garbage added to BinaryWriter/GZipStream output?
(I am not on the list - please CC) I have a small application which writes gzip'ed data like this: sw = new BinaryWriter(new GZipStream(new FileStream(filename, FileMode.Create, FileAccess.Write, FileShare.None), CompressionMode.Compress, true ); sw.Write(...); sw.Write(...); sw.Flush(); sw.Close(); It use to work fine with mono 2.4, and still does in a way with mono 2.6 . What happens is that now it seems to append a lot of extra garbage to the end of the output. The uncompressed data is 1234127 bytes, and still recoverable in a indentical manner from the output with gzip -dc; but the output file is now 8126815 bytes with mono 2.6.x instead of 282363 bytes under mono 2.4.x , so almost 8MB of garbage is added somehow. I tried truncating the file, but it seems to truncate the gz stream as well. So does anybody else observe similiar problems and/or know of any reasons why mono 2.6 behaves differently in this regard compared to mono 2.4? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] poor compression with mono 2.6 (Re: mono 2.6+ : Garbage added to BinaryWriter/GZipStream output?)
Hi, I found the source of my problem with the poor GZipStream compression with mono 2.6 - it is r138254, which rewrites the gzipstream implementation: -- Author: gonzalo gonz...@e3ebcda4-bce8-0310-ba0a-eca2169e7518 Date: Tue Jul 21 02:25:00 2009 + 2009-07-20 Gonzalo Paniagua Javier gonz...@novell.com * Makefile.am: replaced zlib_macros.c with zlib-helper.c * zlib_macros.c: Removed file. * zlib-helper.c: new interface for DeflateStream. Flush() actually does something. -- The problem is that this change makes the zlib code compress per each write (before the change, it buffers by the zlib default, which is trying to compress per 32k input). Most of my little program culculates and write 1 byte out, so it is mostly 5-byte zlib header overhead + 1 byte! and the file size is increased about 6 times. I have tried and tested this patch, which restore the zlib default to the compression code to buffer data before compression. With this patch, I can just replace libMonoPosixHelper.so and get compression behavior similiar to mono 2.4. So the mono-2.4 behavior and with this patch, 1.2MB data is written out as 280k ; without this patch, mono 2.6 writes 8.1MB out (about x6). Curiously, Microsoft .Net's runtime's Gzipstream implementation seems to do something between - it generates a filesize of 2MB, which possibly means it buffers and compresses by 4-byte chunks, not 1 byte and not 32k. (5-byte overhead + 2-3 bytes after compression). So a question for Gonzalo Paniagua Javier: do I need to file a bug report properly to get the attached patch committed? It should be obvious why it does what it does. Cheers, Hin-Tak --- On Wed, 27/1/10, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: (I am not on the list - please CC) I have a small application which writes gzip'ed data like this: sw = new BinaryWriter(new GZipStream(new FileStream(filename, FileMode.Create, FileAccess.Write, FileShare.None), CompressionMode.Compress, true ); sw.Write(...); sw.Write(...); sw.Flush(); sw.Close(); It use to work fine with mono 2.4, and still does in a way with mono 2.6 . What happens is that now it seems to append a lot of extra garbage to the end of the output. The uncompressed data is 1234127 bytes, and still recoverable in a indentical manner from the output with gzip -dc; but the output file is now 8126815 bytes with mono 2.6.x instead of 282363 bytes under mono 2.4.x , so almost 8MB of garbage is added somehow. I tried truncating the file, but it seems to truncate the gz stream as well. So does anybody else observe similiar problems and/or know of any reasons why mono 2.6 behaves differently in this regard compared to mono 2.4? gzipstream-patch 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-dev] poor compression with mono 2.6 (Re: mono 2.6+ : Garbage added to BinaryWriter/GZipStream output?)
sorry, attached the wrong patch in the previous e-mail. (ReadStream probably should use NO_FLUSH For performance as well?). File the issue as Bug 574597 , since mono 2.4 behaves much better (and better than MS .Net), mono 2.6's behavior is probably considered a regression. diff --git a/support/zlib-helper.c b/support/zlib-helper.c index 1d61c3d..f8f1587 100644 --- a/support/zlib-helper.c +++ b/support/zlib-helper.c @@ -207,7 +207,7 @@ WriteZStream (ZStream *stream, guchar *buffer, gint length) zs-next_out = stream-buffer; zs-avail_out = BUFFER_SIZE; } - status = deflate (stream-stream, Z_SYNC_FLUSH); + status = deflate (stream-stream, Z_NO_FLUSH); if (status != Z_OK status != Z_STREAM_END) return status; ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] poor compression with mono 2.6 (Re: mono 2.6+ : Garbage added to BinaryWriter/GZipStream output?)
--- On Thu, 28/1/10, Gonzalo Paniagua Javier gonz...@novell.com wrote: On Thu, 2010-01-28 at 03:19 +, Hin-Tak Leung wrote: sorry, attached the wrong patch in the previous e-mail. (ReadStream probably should use NO_FLUSH For performance as well?). File the issue as Bug 574597 , since mono 2.4 behaves much better (and better than MS .Net), mono 2.6's behavior is probably considered a regression. Hi there. Your patch looks good. I'm going to check it in right now into all the branches where the change is needed. Could you provide a small test case to be added to our test suite? Thanks. I'll see about creating a simple test program and attach to the bug report. (the program I have is currently a bit complicated). Is there any plan for a mono 2.6.2 any time soon? Cheers, Hin-Tak ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] windows installer regression - Re: [Mono-announce-list] Mono 2.0 RC3 is out!!
Not a regression on mono itself, but the rc3 windows installer never exit under wine - it seems to stay with a zero-size window towards the end (and installation seems to have fully completed). winow. 1.9.1 rc1 both installs and exits cleanly. Anyboy observed this behavior under real window, or interested in running mono under wine? --- On Mon, 29/9/08, Thomas Wiest [EMAIL PROTECTED] wrote: From: Thomas Wiest [EMAIL PROTECTED] Subject: [Mono-announce-list] Mono 2.0 RC3 is out!! To: Mono List [EMAIL PROTECTED], mono-devel mono-devel-list@lists.ximian.com, [EMAIL PROTECTED], Ximian List [EMAIL PROTECTED] Date: Monday, 29 September, 2008, 10:43 PM Hey Everyone, We've just released Mono 2.0 RC3 today! Please help us out by giving it a try with your applications. Unfortunately this version doesn't include an update for the OS X installer. We're looking to update it with the next release candidate. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.0 here: https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstrbug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2Forder=bugs.bug_status%20 The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.0 the best ever. Thanks again! Mono QA ___ Mono-announce-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-announce-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
