Marek Safar wrote:
Hi,
When will be C# 3.0 will be complete and included in main package?
Some features like
* extension methods,
* automatically generated properties,
* implicitly typed arrays,
* implicitly typed local variables,
* lambda expressions
will be included in the upcoming
On Thu, 2007-08-02 at 23:44 +0200, pablosantosluac wrote:
Hi again,
Will changing
formatter ref=binary typeFilterLevel=Full /
To low increase performance???
hmmm, I didn't try that but I don't think it will increase performance
as it's only a security setting (as in allow X but not Y).
Found few regressions in SWF comparing to 1.2.4
You can see them this http://bugzilla.ximian.com/show_bug.cgi?id=82164 bug
report (look at last comment)
--
View this message in context:
http://www.nabble.com/Mono-1.2.5-Preview-tf4161435.html#a11860906
Sent from the Mono - Dev mailing list
http://www.mono-project.com/MoonlightShots
On Mon, 2007-07-30 at 22:10 +0200, pablosantosluac wrote:
Hi,
Where can I find screenshots of Mono/Linux/Silverlight?
pablo
- Original Message -
From: Chris Toshok [EMAIL PROTECTED]
To: Miguel de Icaza [EMAIL PROTECTED]
Cc: Mono Olive
There are a lot of rpms but debian packet
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
nowadays the user can use single-dash with either short and long
options, what you lose with (still you can configure for the old
behaviour) is option consolidation (many single-letter options
together in a single-dash), like you see in tar for example:
tar -zxf filename
Mono.GetOptions still
On Fri, 2007-08-03 at 13:32 +0200, pablosantosluac wrote:
One question: is it recommended to compile with Mono to get better
perfomance? I guess the answer but I just want to be sure.
That shouldn't make a performance difference, the big optimizations are
either in the C# implementation itself
And I was assuming (probably it is wrong) that the parameter X was always
the itemId (which is a long). It used to work, but now I realize it can be
wrong
This does look very wrong. All the values in the binary search must be
of the same type and you are casting it to two different
Yes, because I'm looking for an specific element into an array, I'm looking
by index. Instead of creating an object of this type I just send the ID...
ok, ok, ok... I'll change it... :-(
- Original Message -
From: Miguel de Icaza [EMAIL PROTECTED]
To: pablosantosluac [EMAIL PROTECTED]
Well, I'm not sure now this is a problem, maybe I'm doing something wrong,
but it works in 1.2.4 and in .NET:
I have this code
int position = ArrayList.Adapter(list).BinarySearch(itemId, this);
And I was assuming (probably it is wrong) that the parameter X was always
the itemId (which is a
I meant Mono.DataConverter
I think I need a C# compiler for my email to check the
errors. :-)
--- Daniel Morgan [EMAIL PROTECTED] wrote:
Date: Fri, 3 Aug 2007 08:58:19 -0700 (PDT)
From: Daniel Morgan [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev]
Rafael,
So, you basically mean changing the API from
MyType[] GetData()
to something like
byte[] GetData()
and perform the marshalling yourself?
Or maybe something like
MyArrayType GetData()
and then MyArrayType gets a customized serializer?
Thanks!
pablo
- Original Message -
On Thu, 2007-08-02 at 22:54 +0200, pablosantosluac wrote:
Thanks Mirco,
Well, all my objects are already marked as [Serializable] instead of
extending the MarshalByRefObject.
Ok, then you are passing the objects by value already.
So, you mean if I extend the class it will go worse?
Yes
Hi,
I've just run Plastic with preview 1.2.5 and:
- I got a Comparer threw an exception in a ArrayList BinarySearch which
was working with 1.2.4. It looks like the list is sending a wrong parameter
to the Compare(object x, object y) method. The x is expected to be a long
but an objects
Hi Pablo,
pablosantosluac wrote:
Because the people who actually implemented both serialization and remoting
are in this list :-) I'd like to ask them to share with us some tips to
improve performance in serialization/remoting: I don't know, maybe always
reduce the number of objects
Hi again,
I've just run some tests comparing mono to .net. It is exaclty the same code
compiled with .NET but run with .NET and mono. The test case is a server
(actually the plastic server) with the data cached and a client. So only
serialization/deserialization play the game, no other
Title: RE: [Mono-dev] IKVM.NET and JDBC and Banshee on Windows and MD on Win
The code of mainsoft's JDBC provider is hosted and constantly maintained inside the mono svn (HEAD: http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System.Data/ or 2.0 stable:
Daniel Morgan wrote:
IKVM.NET and JDBC.
Has anyone tried connecting to a database using JDBC on top of IKVM.NET
yet? I'm interested in using Oracle's JDBC Thin driver to connect to
an Oracle database using IKVM.NET on top of Mono? Is this possible?
It would be neat if someone wrote a
Thanks Robert.
So, you mean it is better to pass an array of objects than actually a list??
Ok, I was already using arrays but I'll take it into account...
pablo
- Original Message -
From: Robert Jordan [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com
Sent: Friday, August 03,
Pablo,
I should add that probably custom serialization should happen at the
Array level, not each element, or you may end experiencing a similar
problem with System.Runtime.Serialization.ObjectIDGenerator.
If you know that all the array elements are different instances (no
repeated references),
I haven't but I'll take a look. Do you use the double-dash
convention as well? I wonder if that's something windows
users can get accustomed to?
It seems that the majority of the flags on Windows take the form /word
but they tend to accept -word.
In Unix historically options after a single
-Original Message-
From: [EMAIL PROTECTED] [mailto:mono-devel-list-
[EMAIL PROTECTED] On Behalf Of pablosantosluac
Sent: viernes, 03 de agosto de 2007 15:02
To: Wade Berrier; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 1.2.5 Preview 2
Hi,
I've just run
Thanks goes to Mono project.
The Mono.DataConvert class (replacement for
BitConverter) works very well.
I just replaced BitConverter with Mono.DataConvert and
conversions from little endian to big endian and vice
versa happens as expected.
Thanks again,
Daniel
Hello,
The attached trivial patch, part of the ppc64 port, adds support for
building standard 32-bit Mono on a 64-bit PowerPC Debian Linux host,
where it's powerpc64-* instead of powerpc-*.
Please tell me if this is okay to commit.
Andreas
ppc64-Linux32build.diff
Description: Binary data
24 matches
Mail list logo
