Re: [Mono-dev] Mono 1.1.17 has been released.
On 8/29/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one.i would recommend not split GTK# into multiple packages , it not suitable for end user. It is better to split into sub-projects. It become a bit irksome to build every single package manually and there are already so many packages. -- Sharique uddin Ahmed Farooqui(C++/C# Developer. IT Consultant, Open Source Expert)http://www.sharique.managefolio.com/Read my Blogs at http://safknw.blogspot.comA revolution is about to begin.A world is about to change.And you and me are the initiator. ___ 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.1.17 has been released.
Sharique uddin Ahmed Farooqui escribió: Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. i would recommend not split GTK# into multiple packages , it not suitable for end user. It is better to split into sub-projects. It become a bit irksome to build every single package manually and there are already so many packages. But, if you are talking only about the end-user perspective, I'm sure there won't be any compilation requisite (all would be managed by precompiled packages and dependencies between them). Regards, Andrés [ knocte ] -- ___ 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.1.17 ASP.NET Problem
Have you tried building your ASP.NET projects without the help of Visual Studio.net? Another words, build and run everything from the commmand-line? You can try it. It will help you learn a lot of what's going on behind-the-scenes. Auto compilation of code in the App_Code directory has absolutely nothing to do with Visual Studio, it is a feature of the ASP.NET 2.0 parser and related libraries. As I now appreciate, it has yet to be implemented in Mono, hence my posts. Visual Studio does a lot of things for you, but this isn't one. As far as completeness of support for ASP.NET 2.0 in Mono, I'd say it's shaping up pretty well, from first hand experience of running my 2.0 code. Notable exceptions being Configuration and a few controls. Auto compiliation seems to be the biggest bit of missing functionality (to me, anyway). So, I'll see what I can do to help out with that. Nick H ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] File System-like storage
Hi, Is there any library that can be used to store a file system like structure inside only one file? Ok, don't tell me a ZIP file... I already tried and performance is quite bad (tried with different libraries even)... pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
pablosantosluac wrote: Hi, Is there any library that can be used to store a file system like structure inside only one file? Ok, don't tell me a ZIP file... I already tried and performance is quite bad (tried with different libraries even)... Already tried with compression turned off? We're using ICSharpCode.SharpZipLib with huge (600MB) uncompressed ZIPs containing a lot of small files. The performance is better than using a true file system. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
In the OLE world, this is/was called structured storage. You might try searching on that. pablosantosluac wrote: Hi, Is there any library that can be used to store a file system like structure inside only one file? Ok, don't tell me a ZIP file... I already tried and performance is quite bad (tried with different libraries even)... pablo ___ 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-dev] Patches
Hi,
Currently, I have patches for...
boo
ikvm
monodebugger
monodevelop
monodoc
xsp
I've attached them all to this email - they're not huge in themselves,
but they do change where packages go - and go correctly!
TTFN
Paul
--
Bist Du meine Mutter? - das leere kind
--- default.build 2006-04-24 16:15:20.0 +0100
+++ boo-0.7.6.2237/default.build 2006-06-07 10:19:35.0 +0100
@@ -23,8 +23,8 @@
property name=build.dir value=build dynamic=True/
property name=distrobuild.dir value=distrobuild/
- property name=install.prefix value=/usr/local /
- property name=install.destdir value=/ /
+ property name=install.prefix value=/var/tmp/boo-0.7.6.2237-1-root-paul/usr /
+ property name=install.destdir value=/var/tmp/boo-0.7.6.2237-1-root-paul/ /
property name=install.share value=${path::combine(install.prefix,'share')} /
property name=install.bindir value=${path::combine(install.prefix,'bin')} /
diff -ru ikvm-0.22.orig/scripts/ikvmc.in ikvm-0.22/scripts/ikvmc.in
--- ikvm-0.22.orig/scripts/ikvmc.in 2005-12-15 22:29:34.0 -0500
+++ ikvm-0.22/scripts/ikvmc.in 2006-03-06 16:54:14.0 -0500
@@ -1,2 +1,2 @@
#!/bin/sh
-exec @RUNTIME@ @prefix@/lib/ikvm/ikvmc.exe $@
+exec @RUNTIME@ @libdir@/ikvm/ikvmc.exe $@
diff -ru ikvm-0.22.orig/scripts/ikvm.in ikvm-0.22/scripts/ikvm.in
--- ikvm-0.22.orig/scripts/ikvm.in 2005-12-15 22:29:34.0 -0500
+++ ikvm-0.22/scripts/ikvm.in 2006-03-06 16:54:22.0 -0500
@@ -1,2 +1,2 @@
#!/bin/sh
-exec @RUNTIME@ @prefix@/lib/ikvm/ikvm.exe $@
+exec @RUNTIME@ @libdir@/ikvm/ikvm.exe $@
diff -ru ikvm-0.22.orig/scripts/ikvmstub.in ikvm-0.22/scripts/ikvmstub.in
--- ikvm-0.22.orig/scripts/ikvmstub.in 2005-12-15 22:29:34.0 -0500
+++ ikvm-0.22/scripts/ikvmstub.in 2006-03-06 16:54:32.0 -0500
@@ -1,2 +1,2 @@
#!/bin/sh
-exec @RUNTIME@ @prefix@/lib/ikvm/ikvmstub.exe $@
+exec @RUNTIME@ @libdir@/ikvm/ikvmstub.exe $@
--- mono-debugger-0.30/configure.in 2006-07-18 17:59:13.0 +0100
+++ mono-debugger-0.30/configure.in 2006-08-27 10:33:30.0 +0100
@@ -153,7 +153,7 @@
AC_SUBST(WRAPPER_CFLAGS)
AC_SUBST(WRAPPER_LIBS)
- GACUTIL_FLAGS='/package $(PACKAGE) /gacdir $(prefix)/lib /root $(DESTDIR)$(prefix)/lib'
+ GACUTIL_FLAGS='/package $(PACKAGE) /gacdir $(libdir) /root $(DESTDIR)$(libdir)'
AC_PATH_PROG(GACUTIL, gacutil, no)
if test x$GACUTIL = xno ; then
AC_MSG_ERROR([No gacutil tool found])
--- mono-debugger-0.30/mono-debugger.pc.in 2006-07-18 17:59:13.0 +0100
+++ mono-debugger-0.30/mono-debugger.pc.in 2006-08-27 10:35:11.0 +0100
@@ -1,9 +1,9 @@
[EMAIL PROTECTED]@
exec_prefix=${prefix}
-libdir=${exec_prefix}/lib
+libdir=${exec_prefix}/$(lib)
Name: Mono.Debugger
Description: Debugging API for Mono
Version: @VERSION@
-Libs: -r:${prefix}/lib/mono/mono-debugger/Mono.Debugger.dll
+Libs: -r:@libdir@/mono/mono-debugger/Mono.Debugger.dll
--- mono-debugger-0.30/build/Makefile.am 2006-07-18 17:59:12.0 +0100
+++ mono-debugger-0.30/build/Makefile.am 2006-08-27 10:58:34.0 +0100
@@ -1,4 +1,4 @@
-onedir = $(prefix)/lib/mono/1.0
+onedir = $(libdir)/mono/1.0
bin_SCRIPTS = mdb
--- monodevelop-0.11/configure.in 2006-05-06 00:26:55.0 +0100
+++ monodevelop-0.11/configure.in 2006-08-27 20:58:14.0 +0100
@@ -205,7 +205,7 @@
AC_SUBST(CSC_FLAGS)
-MD_DIR='$(prefix)/lib/monodevelop'
+MD_DIR='$(libdir)/monodevelop'
MD_ASSEMBLY_DIR=$MD_DIR/bin
MD_ADDIN_DIR=$MD_DIR/AddIns
--- monodevelop-0.11/Makefile.am 2006-05-06 00:26:55.0 +0100
+++ monodevelop-0.11/Makefile.am 2006-08-27 20:59:07.0 +0100
@@ -15,7 +15,7 @@
pkgconfig_in_files = monodevelop.pc.in
-pkgconfigdir= $(prefix)/lib/pkgconfig
+pkgconfigdir= $(libdir)/pkgconfig
pkgconfig_DATA = $(pkgconfig_in_files:.pc.in=.pc)
if ENABLE_UPDATE_MIMEDB
--- monodevelop-0.11/monodevelop.pc.in 2006-05-06 00:26:55.0 +0100
+++ monodevelop-0.11/monodevelop.pc.in 2006-08-27 20:59:46.0 +0100
@@ -1,6 +1,6 @@
[EMAIL PROTECTED]@
exec_prefix=${prefix}
-libdir=${exec_prefix}/lib
[EMAIL PROTECTED]@
Name: MonoDevelop
Description: Free .NET Development Environment
--- xsp-1.1.17/configure.in 2006-08-25 20:55:56.0 +0100
+++ xsp-1.1.17/configure.in 2006-08-31 00:29:53.0 +0100
@@ -56,7 +56,7 @@
echo $CS compiler: $MCS
test x$GMCS = xno || echo $CS 2.0 compiler: $GMCS
-GACUTIL_FLAGS='-root $(DESTDIR)$(prefix)/lib'
+GACUTIL_FLAGS='-root $(DESTDIR)$(libdir)'
AC_SUBST(MCS)
AC_SUBST(GMCS)
--- xsp-1.1.17/scripts/Makefile.am 2006-08-25 20:55:56.0 +0100
+++ xsp-1.1.17/scripts/Makefile.am 2006-08-31 00:32:55.0 +0100
@@ -12,10 +12,10 @@
CLEANFILES = $(bin1_scripts) $(bin2_scripts_real) $(tool_scripts) $(tool2_scripts)
-plat_bindir = $(prefix)/lib/mono/1.0
-plat_bindir2 = $(prefix)/lib/mono/2.0
-plat_tooldir = $(prefix)/lib/xsp/1.0
-plat_tooldir2 = $(prefix)/lib/xsp/2.0
+plat_bindir =
[Mono-dev] BindingList?
Hi all I have been tasked with getting some windows C# code to compile/run using mono under Linux. I have run into the problem, that BindingList is not implemented in mono. (Which is also evident from the status page). I was wondering if there are anyone working on it? And, perhaps, if there is a timeframe for mono supporting it? (Still on target to q4 2006?) And, to avoid the DIY reponse - I am linux/unix guy, not a c# guy, and have no actual idea what BindingList does or should do - so, suggestions on implementing it myself will not be appreciated/workable ;-) Any other suggestions to work around a dependency on BindingList - including using other similar mono classes - will be great though. Regards and thanks in advance. Mads P.S. Is there something similar to make's -k option to gmcs to force it to report as many errors as possible? -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] BindingList?
Mads Bondo Dydensborg wrote: Hi all I have been tasked with getting some windows C# code to compile/run using mono under Linux. I have run into the problem, that BindingList is not implemented in mono. (Which is also evident from the status page). I was wondering if there are anyone working on it? And, perhaps, if there is a timeframe for mono supporting it? (Still on target to q4 2006?) And, to avoid the DIY reponse - I am linux/unix guy, not a c# guy, and have no Hey, thanks to Mono, those guys are playing now in the same sandbox. So grab a shovel and jump in :-) actual idea what BindingList does or should do - so, suggestions on implementing it myself will not be appreciated/workable ;-) Any other suggestions to work around a dependency on BindingList - including using other similar mono classes - will be great though. I guess your app is using System.Windows.Forms 2.0, right? BindingList is mainly used inside System.Windows.Forms 2.0, which is not yet on Mono's radar. The upcoming 1.2 release will include SWF 1.1. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] BindingList?
Mads, Any other suggestions to work around a dependency on BindingList - including using other similar mono classes - will be great though. We ran into the same thing recently, so we rolled a partial replacement, InMemoryBindingListT. This isn't everything that BindingList does, but it does implement IBindingList. You can see/get the code here: http://code.wesay.org/WeSay/trunk/src/WeSay.Data/InMemoryBindingList.cs . Unit tests are at http://code.wesay.org/WeSay/trunk/src/WeSay.Data.Tests/ Feel free to use it however you want. John Hatton WeSay.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hello Zoltan, Hi, The best approach, as I said previously, is to make sure all the tests (except perhaps the pinvoke/marshalling tests) run under mono/tests. Since these tests are much simpler than mcs, it is much easier to track down the possible problems. I am trying to understand why invoke.cs test fails. The Test1 method is called but ss parameter contains wrong data (ss.a = ss.b = true). If the Test1 method if called directly (not by invoke) the parameter has right values. What should I look at? Is there some kind casting exists from array of objects to SimpleStruct? Some box/unbox methods for parameters? Thank you, -- Sergey Tikhonov Solvo Ltd. Saint-Petersburg, Russia [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch to avoid some race conditions on the mono runtime
Hi, The first two modifications look ok, and are now in SVN. I'm not sure why the third is needed tough. Zoltan On 8/29/06, briaeros007 [EMAIL PROTECTED] wrote: Hello, I'm sorry to double post this message, but I just find out that my first post doesn't have a subject ! I'm really sorry if you have already seen the first message. In my work, i have to use mono with a specific thread library which permits us to see some race conditions when we use mono as a library in a threaded environnement . Mono with the use of this library show some race conditions that i've tried to fixed. In the patch we can see four modifications of the file mini.c. The first two are modifications which avoid to put two times the same fonction in a table. The last modification (which corresponds to the two last modifications on the patch) was done since we have plenty of bugs which aren't reproductibles, but all theses bugs have this fonction as a common point. In this way we have just extend the critical section. this modifications permits to run our tests program without any scratch. yours sincerely Ps : theses errors are also in the new release of mono 1.1.17. The patch work on this version too, even if there are a fuzz without any consequences. --- Subete ga wakatta toki…watashi ga anta wo korosu. ___ 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-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Thu, 2006-08-31 at 07:27 +0200, pablosantosluac wrote: So, let's say I want to develop a filesystem to be integrated with our software: should I use SULF or should I wait for Mono.Fuse? SULF is dead (if I'm interpreting Valient Gough's comments correctly). It's been replaced by fusewrapper: http://arg0.net/darcs/fusewrapper fusewrapper's C# interface is a virtual copy of FUSE's low-level interface. To see what this means, compare the FUSE low-level hello_ll.c program with the high level hello.c program: http://fuse.cvs.sourceforge.net/fuse/fuse/example/hello_ll.c?revision=1.11view=markup http://fuse.cvs.sourceforge.net/fuse/fuse/example/hello.c?revision=1.18view=markup I personally find the low-level interface to be as appealing as manually handling WM_* messages in a System.Windows.Forms app... fusewrapper does have a higher-level interface which is very similar to the previous SULF library, however it's written in Nemerle (see the fusewrapper/nemerle/Sulf directory within a fusewrapper darcs checkout). So you basically have four choices: 1. Use Sulf, even though it's been abandoned (it's darcs repo is inaccessible, so you'd have to go with the previous 0.3 tarball). (Furthermore, I've had no luck building installing the 0.3 tarball, but your mileage may vary.) 2. Use fusewrapper's low-level C# interface. 3. Use Nemerle and fusewrapper's high-level Sulf interface. 4. Wait for Mono.Fuse. (Actually, you'd be waiting for the Mono.Fuse dependencies within Mono.Posix to be committed, then either use svn-HEAD or wait for 1.1.18 to use a separate Mono.Fuse tarball. Furthermore, I have no idea when the Mono.Posix dependencies will get committed; it depends on when I get approval, which may require changes...) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patches
On Thu, 2006-08-31 at 10:09 +0100, Paul wrote: Currently, I have patches for... boo ikvm monodebugger monodevelop monodoc xsp I've attached them all to this email - they're not huge in themselves, but they do change where packages go - and go correctly! Why the use of $libdir instead of $prefix/lib? These are all managed programs, with no use of native libraries, so why do they need to be in $prefix/lib64 on 64-bit architectures? What's wrong with sticking with $prefix/lib? (Alternatively, why are they in $libdir or $prefix/lib at all? Surely $prefix/share would make more sense, given that they don't use native code...) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Thu, 2006-08-31 at 06:43 -0400, Jonathan Pryor wrote: On Thu, 2006-08-31 at 07:27 +0200, pablosantosluac wrote: So, let's say I want to develop a filesystem to be integrated with our software: should I use SULF or should I wait for Mono.Fuse? ... So you basically have four choices: 1. Use Sulf, even though it's been abandoned (it's darcs repo is inaccessible, so you'd have to go with the previous 0.3 tarball). (Furthermore, I've had no luck building installing the 0.3 tarball, but your mileage may vary.) 2. Use fusewrapper's low-level C# interface. 3. Use Nemerle and fusewrapper's high-level Sulf interface. 4. Wait for Mono.Fuse. (Actually, you'd be waiting for the Mono.Fuse dependencies within Mono.Posix to be committed, then either use svn-HEAD or wait for 1.1.18 to use a separate Mono.Fuse tarball. Furthermore, I have no idea when the Mono.Posix dependencies will get committed; it depends on when I get approval, which may require changes...) And a 5th option: If you need a solution *now*, you can fork Mono.Fuse and MonoPosixHelper. Copy the required MonoPosixHelper type declarations and conversion functions into MonoFuseHelper (e.g. Mono_Posix_ToStat, Mono_Posix_FromStat, Mono_Posix_ToFilePermissions, etc.), and build your own copy of MonoFuseHelper. This would work, and can be done now, it's just not terribly elegant (nor long-term safe, if e.g. a Mono.Unix.Native structure needs to change your copied functions will be out-of-sync). - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: FireFox plugin/ClickOnce was: Mono 1.1.17 has been released.
Personally, I think it'd be better if CAS was done before something like that was officially supported: that is, after all, the killer feature of .NET on the web. However, it could take awhile to get all the fixings right for such a plugin, so it could be better to start it soon and have it ready (or close to it) for when CAS is fully functional. On a side note, won't it be strange when malware targets .NET ClickOnce instead of native ActiveX? I wonder what .NET malware written for Windows would do on a Linux box (heh, probably not much). I think the reason that Mono hasn't gone in this direction is (along with, of course, the CAS prerequisite) is because the public use of client-side .NET web applications is actually pretty small (not including company-internal stuff)... so it's less of a need and more of a want. If these oodles of contributors who are waiting for a plugin really exist, I think they should help out with CAS, because that's what's holding back a secure implementation. On 8/30/06, Carlos J. Muentes [EMAIL PROTECTED] wrote: We use ClickOnce internally and wouldn't roll without it; it rocks to say the least. On Wed, 2006-08-30 at 11:31 -0500, Michael Schurter wrote: Sebastien Pouliot wrote: Hello Ted, On Wed, 2006-08-30 at 00:44 -0400, ted leslie wrote: ... write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Yes, this feature would be a nice one and, as Jon said in another email, ClickOnce [1] would too be a nice feature. And I can quickly think, even without caffeine, about a few more ;-) I'm sorry if you've already been over this before: but does anyone actually use ClickOnce? The only time I've even seen it mentioned (outside of this mailing list) was on Microsoft's site. I was forced to use it to download some application, and I remember having so much trouble trying to get ClickOnce to work (even with IE on Windows) that I eventually gave up. I understand how in-browser apps (like Flash ActiveX) are appealing, but what is the use case for ClickOnce over the standard Click Twice it takes to run a normal application? (First click download, second click to run.) ___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-dev] File System-like storage
but, can you add files?? I tried with a commercial tool, and setting compression off... was horrible for performance inserting data... - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, August 31, 2006 10:41 AM Subject: Re: [Mono-dev] File System-like storage pablosantosluac wrote: Hi, Is there any library that can be used to store a file system like structure inside only one file? Ok, don't tell me a ZIP file... I already tried and performance is quite bad (tried with different libraries even)... Already tried with compression turned off? We're using ICSharpCode.SharpZipLib with huge (600MB) uncompressed ZIPs containing a lot of small files. The performance is better than using a true file system. Robert ___ 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-dev] File System-like storage
Packed file systems (or any other data representation for that matter) are good for read-only purposes. Any read-write use will need to re-pack things and will suffer badly, that is why normal file systems leave holes (by allocating fixed-size blocks) and scatter file contents as a consequence of allocating new space on demand. You can try to optimize space by using the exact number of bytes a file-write needs, but you can't avoid scattering the contents. Even those optimizations aren't good enough to deal with changes in the middle of the contents of file, specially if the contents will change in size also. It will degrade in to erasing/freeing the previous tail of the file and allocating/writing the new tail what needs the contents of the old tail so unless you can buffer it all on memory means you can't just overwrite to avoid a freed hole. Well that is basically the description of a journalling file-system, and you get back where you started. :| On 8/31/06, pablosantosluac [EMAIL PROTECTED] wrote: but, can you add files?? I tried with a commercial tool, and setting compression off... was horrible for performance inserting data... - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Thursday, August 31, 2006 10:41 AM Subject: Re: [Mono-dev] File System-like storage pablosantosluac wrote: Hi, Is there any library that can be used to store a file system like structure inside only one file? Ok, don't tell me a ZIP file... I already tried and performance is quite bad (tried with different libraries even)... Already tried with compression turned off? We're using ICSharpCode.SharpZipLib with huge (600MB) uncompressed ZIPs containing a lot of small files. The performance is better than using a true file system. Robert ___ 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 -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Componentized memory manager
Hey guys,I was about to send this suggestion to Maoni (of the .NET GC - http://blogs.msdn.com/maoni/) and wanted to send it here first, if nothing else, to make the idea less patentable by MS. I would like for the whole memory manager system to be componentized and replaceable. This would allow the user to choose what is the right approach for their application. Then, if done well, third-parties could develop alternate memory managers that were geared for specific purposes. Here's my rationale:1) In some scenarios, I want a memory manager with explicit finalization. That is a priority in scenario A. I will take the performance hit to have full reference counting and immediate finalization. The benefit to me is better control of memory and RAM utilization. 2) I may want a Workstation version that is memory footprint priority. Running on a Citrix server with 4GB RAM but needing to limit the app to 60MB per client (by customer request) is nearly impossible. Either the customer's request cannot be met or .NET Framework / Mono cannot be the platform. 3) I don't assume that MS will implement the best memory manager for me. Make allowances for others to improve on it.Potential issues against it:1) If a memory manager could be replaced, I could re-implement one (or modify an OpenSource one) to circumvent DRM. I can see that being why MS won't do it. 2) Complexity of the integration.3) Not a large enough perceived benefit/need.What are your thoughts?-Mark E. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
pablosantosluac wrote: but, can you add files?? Yes, but off-line. We're using a differential file system, which writes the changes into a parallel directory hierarchy: data.zip(the zip file) data.zip.diff\ (the differential file system) No way to use a ZIP file on-line. I thought you need it read-only. Robert ___ 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.1.17 has been released.
Miguel de Icaza wrote: Bugs fixed The following bugs were fixed on this release: 7, 76449, 76453, 76757, 77340, 77551, 77820, 78190, 78220, 78271, 78288, 78291, 78328, 78399, 78483, 78513, 78525, 78592, 78607, 78646, 78661, 78696, 78730, 78731, 78732, 78737, 78746, 78753, 78759, 78761, 78773, 78775, 78800, 78804, 78806, 78810, 78813, 78816, 78821, 78822, 78825, 78826, 78827, 78837, 78854, 78855, 78856, 78859, 78864, 78865, 78866, 78868, 78869, 78871, 78877, 78886, 78889, 78907, 78912, 78914, 78927, 78929, 78931, 78939, 78945, 78949, 78969, 78970, 78971, 78972, 78977, 79000, 79001, 79002, 79007, 79016, 79020, 79023, 79030, 79037, 79052, 79053, 79076, 79080, 79085, 79087, 79091, 79095, 79096, 79150, 30235, 45730, 70506, 77403, 77489, 77539, 78253, 78468, 78703, 78724, 78767, 78770, 78784, 78799, 78842, 78860, 7, 78899, 78901, 78943, 78968, 79010, 79033, 79056, 79067, 79084, 79090, 79112, 79117, 79118, 79125, 77396, 78323, 78384, 78986, 78990, 79012, 79019, 79026, 79064, 77963, 78985, 79027 and 79028. Allow me to say a big thanks to everyone who works so hard to make Mono a better product. I'm looking forward to using Mono more and more in my future projects. You guys do an awesome job. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
pablosantosluac wrote: but, can you add files?? I tried with a commercial tool, and setting compression off... was horrible for performance inserting data... Is it out-of-the-question to use a Linux loop device to create a filesystem inside a file? Granted, that requires admin privileges... --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
pablosantosluac wrote:
would be great! but I wonder if it will work on windows... ;-)
Not in the least! :P But lightweight read-write filesystems that can be used
inside another program are in short supply. You might as well just use the
actual filesystem.
Besides, I just checked, and only root can do this. But it's one of the neatest
things I've learned about Linux so far, so I'll share it anyhow.
Create an empty file where your partition will reside:
# dd if=/dev/zero of=my.fs bs=1M count={count}
...where {count} is the number of MB in the filesystem.
Then create the filesystem. mke2fs will do it straight on the file; if others
refuse, research losetup.
# mke2fs my.fs
mke2fs 1.38 (30-Jun-2005)
my.fs is not a block special device.
Proceed anyway? (y,n) y
...
Mount your filesystem using a loop device.
# mkdir my.fs.dir
# mount -o loop my.fs my.fs.dir
When you're done, unmount it.
# umount my.fs.dir
Feel free to compress the resulting file. It will give worse results than just
doing tar/gz, though.
--Brian
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File System-like storage
I guess we will continue using our current storage. Not as fast as the
filesystem but faster than these alternatives... ;-)
- Original Message -
From: Brian Crowell [EMAIL PROTECTED]
To: pablosantosluac [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Sent: Thursday, August 31, 2006 7:25 PM
Subject: Re: [Mono-dev] File System-like storage
pablosantosluac wrote:
would be great! but I wonder if it will work on windows... ;-)
Not in the least! :P But lightweight read-write filesystems that can be
used inside another program are in short supply. You might as well just
use the actual filesystem.
Besides, I just checked, and only root can do this. But it's one of the
neatest things I've learned about Linux so far, so I'll share it anyhow.
Create an empty file where your partition will reside:
# dd if=/dev/zero of=my.fs bs=1M count={count}
...where {count} is the number of MB in the filesystem.
Then create the filesystem. mke2fs will do it straight on the file; if
others refuse, research losetup.
# mke2fs my.fs
mke2fs 1.38 (30-Jun-2005)
my.fs is not a block special device.
Proceed anyway? (y,n) y
...
Mount your filesystem using a loop device.
# mkdir my.fs.dir
# mount -o loop my.fs my.fs.dir
When you're done, unmount it.
# umount my.fs.dir
Feel free to compress the resulting file. It will give worse results than
just doing tar/gz, though.
--Brian
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DynamicMethod skipVisibility
Hi,
This is now fixed in SVN.
Zoltan
On 8/18/06, tcmichals [EMAIL PROTECTED] wrote:
Version 1.1.16.1, when creating a dynamic function with the skipVisibility
set to true and creating a Delegate to the new function. The dynamic
function is calling another function which is not public, this gives me an
exception, but I thought the skipVisibility flag allows this? Also, tested
on .NET and it worked fine.
class foo()
{
void fooFunc() {}
}
. delegate del = DynamiclyCreateFunc(methodInfo fooFunc);
del (thisFoo, null); - get execption, if the fooFunc is public it is
invoked...
___
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-dev] [PATCH] Rename mono-1.dll to mono.dll (win32, remove version)
Hey, This is ok to check in. Zoltan On 8/25/06, Kornél Pál [EMAIL PROTECTED] wrote: Hi, I'm not going to commit this patch without approval. And I sent the patch to the list for review so you don't have to be worried about breaking changes in 1.1.17. Kornél - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Friday, August 25, 2006 3:53 PM Subject: Re: [Mono-dev] [PATCH] Rename mono-1.dll to mono.dll (win32,remove version) Hi, Kornél Pál wrote: The name mono-1.dll is unusual on Windows. And I see no reason to version the dll. This dll is private to Mono or the application that bundles it. As only one Mono version can be installed to a single directory there is no reason to version the dll name. The name mono.dll would follow Windows dll naming conventions. Please review and approve the patch. This will break already deployed apps, which embed the Mono runtime and rely on the official Mono Windows Installer. I'm urged to make an unnecessary update, if this change will be applied. Please let it be or, at least, postpone the change after 1.1.17. Thanks! Robert ___ 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-dev] Componentized memory manager
Hello, 1) If a memory manager could be replaced, I could re-implement one (or modify an OpenSource one) to circumvent DRM. I can see that being why MS won't do it. 2) Complexity of the integration. 3) Not a large enough perceived benefit/need. What are your thoughts? This is possible to some extent today with Mono, we have a number of GC backends already made pluggable. A full pluggable architecture (something to plug at runtime instead of compile time) would probably be more work and we would miss some optimizations; It is also targeted today only to replace the GC, you might possibly want to look into something broader. The short answer is that this is not too difficult, and it might be a worthwhile research project for someone to take on. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
Hello Jon, 4. Wait for Mono.Fuse. (Actually, you'd be waiting for the Mono.Fuse dependencies within Mono.Posix to be committed, then either use svn-HEAD or wait for 1.1.18 to use a separate Mono.Fuse tarball. Furthermore, I have no idea when the Mono.Posix dependencies will get committed; it depends on when I get approval, which may require changes...) Am wondering how much of the stuff in Mono.Posix is actually needed. Am wondering if we would not be just a whole lot better by having a private libMonoFuseHelper.so that only contains the code that needs to be OS-specific, and not try to force Mono.Posix into larger uses. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in System.Configuration
this patch looks good (especially the NameValueConfigurationElement change. I thought I'd caught all the configuration properties :) - can you add a unit test that shows the failure/fix as well? Chris On Thu, 2006-08-31 at 09:41 -0700, Vladimir Krasnov wrote: System.Configuration has a bug in processing remove tag, while deserializaing this element it creates configuration element of the same type as add and fails because remove doesnt have required properties. Please look at attached patch that fixes this bug. Vladimir. ___ 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-dev] Componentized memory manager
Miguel,On 8/31/06, Miguel de Icaza [EMAIL PROTECTED] wrote: This is possible to some extent today with Mono, we have a number ofGC backends already made pluggable.Cool. I wasn't aware of that. A full pluggable architecture (something to plug at runtime instead ofcompile time) would probably be more work [...]I image it could be done at the time when a specific runtime is targeted. The short answer is that this is not too difficult, and it might be aworthwhile research project for someone to take on. Thanks for the information and response. I'm glad to hear that it wouldn't be such an impossible thing to do.-Mark E. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
On Thu, 2006-08-31 at 17:36 -0400, Miguel de Icaza wrote: 4. Wait for Mono.Fuse. (Actually, you'd be waiting for the Mono.Fuse dependencies within Mono.Posix to be committed, then either use svn-HEAD or wait for 1.1.18 to use a separate Mono.Fuse tarball. Furthermore, I have no idea when the Mono.Posix dependencies will get committed; it depends on when I get approval, which may require changes...) Am wondering how much of the stuff in Mono.Posix is actually needed. Am wondering if we would not be just a whole lot better by having a private libMonoFuseHelper.so that only contains the code that needs to be OS-specific, and not try to force Mono.Posix into larger uses. I'm big on Single Points Of Truth. :-) MonoPosixHelper *already* contains code to convert `struct stat' and `struct statvfs' into a Mono.Unix.Native.Stat Mono.Unix.Native.Statvfs (and code for several other structures). `struct statvfs' in particular has lots of code to deal with Linux Mac OS X/*BSD (which use a `struct statfs' for the same purpose -- so much for portability!). So removing a dependency on the Mono.Posix changes would require copying this existing code, introducing *two* points of truth, which I dislike (the bad taste in my mouth design opinion). In short, I'd prefer to avoid copy pasting code unless it can't be avoided, and this most certainly *can* be avoided. (Plus, as lupus mentioned earlier, if the conversion functions are not added to Mono.Posix then it is useless for all but the trivial cases, and I'm trying to *improve* its usefulness, not keep it useless for all but the currently support cases.) (Recall why I started this: I wondered why Sulf didn't use Mono.Posix, and came to the conclusion that it *couldn't* use Mono.Posix because Mono.Posix didn't offer the required functionality.) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.1.17.1, small update.
Hello folks, We have released Mono 1.1.17.1, it contains three small updates: Fix HttpListener, it was failing with a few post operations [Gonzalo Paniagua] mono-service is now installed into the GAC, the recent changes broke applications that created new AppDomains [Robert Jordan] Fix a race condition on array new [briaeros007]. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to make new locales for CultureInfo?
In our application, which is solely for the world's minority languages, we would like to be able to make new CultureInfo's from ldlm files (Locale Data Markup Language). On the Windows side, we can use the .Net Framework 2.0's CultureAndRegionInfoBuilder class. Any ideas on how we could do something on the Linux side? Is ICU still used underneath? (It still has a property called IcuName). If so, is that the level that our app needs to introduce new locale info, and then mono's CultureInfo will be able to pick it up there? Thanks John Hatton wesay.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to make new locales for CultureInfo?
Hello, Sadly we don't have sysglobl.dll which implements CultureAndRegionInfoBuilder. It is a bit messy that it requires additional consideration on how culture resources should be retrieved and stored (I have to admit that I dislike it since this framework works only on the machine that installed the corresponding culture). Our culture information is created from LDML information (which is actually from ICU) and stored in the mono runtime itself. If you want to add other cultures that we miss, you might be able to pull them from newer ICU and add it in the catalog (mono/tools/locale-builder/lcids.xml). Which culture do you need specifically ? Atsushi Eno John Hatton wrote: In our application, which is solely for the world's minority languages, we would like to be able to make new CultureInfo's from ldlm files (Locale Data Markup Language). On the Windows side, we can use the .Net Framework 2.0's CultureAndRegionInfoBuilder class. Any ideas on how we could do something on the Linux side? Is ICU still used underneath? (It still has a property called IcuName). If so, is that the level that our app needs to introduce new locale info, and then mono's CultureInfo will be able to pick it up there? Thanks John Hatton wesay.org ___ 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
