Doesn't it make more sense to add something like a macro system (see Boo,
Nemerle, Scheme, ...) ? That way you would only change the compiler once
(for the macro resolution) and then you can extend the language at your wish
in external libraries (as with Mono.Rocks).
The three main advantages I
Sounds to me like you should suggest that on the wiki ;)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
On 02/09/09 Rodrigo Kumpera wrote:
The attached patch adds a new hook to allow threads to shutdown after the
GC finalizer has finished.
The motivation for it is to improve profiler's reliability at shutdown
time.
The new callback notifies the thread when regular shutdown starts and
All,
Not sure the best way to submit this, please correct me if there is a
better way to do this (via bugzilla?)
I encountered a problem when casting a long to an IntPtr, which is
something we have ended up doing a lot (we want to keep binary assembly
compatibility between x86 and x64,
All,
I have encountered a problem with the Oracle Data Client when porting an
application over from Windows, basically we are using NHibernate as a
frontend to the database and we have recently moved the backend from
MySQL (for development) to Oracle (for deployment) and we encountered a
russell@realtimeworlds.com wrote:
I encountered a problem when casting a long to an IntPtr, which is
something we have ended up doing a lot (we want to keep binary assembly
compatibility between x86 and x64, only changing the native code on the
different architectures). We encountered a
2009/2/11 russell@realtimeworlds.com:
All,
I have encountered a problem with the Oracle Data Client when porting an
application over from Windows, basically we are using NHibernate as a
frontend to the database and we have recently moved the backend from MySQL
(for development) to
We get addresses on Linux that are 2Gb from malloc in the native code,
if we go through the conversion from int (i.e.)IntPtr.ToInt64() is not
giving a sign extended value back when this happens and then a cast to
IntPtr will fail. The cast from a pointer i.e. void* or byte* will also
not sign
Replying to myself here
Using the output from this small program
using System;
namespace ConsoleApplication4
{
enum Ptr : long
{
}
class Program
{
static unsafe void Main(string[] args)
{
IntPtr test = new IntPtr(0x);
Ptr
using today's svn version, .proj file generated with set
MSBuildEmitSolution=1 trick:
[mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj
XBuild Engine Version 0.1
Mono, Version 2.5.0.0
Copyright (C) Marek Sieradzki 2005. All rights reserved.
MSBUILD: error MSBUILD:
Hello,
I am guessing xbuild is only supporting 2.0 for now. I am not sure how much
effort is needed to support 3.5/2008 projects.
Thanks,
Jonathan
On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski skol...@gmail.comwrote:
using today's svn version, .proj file generated with set
When I forced msbuild 2.0 and regenerated the project, xbuild bails
out on ResolveAssemblyReferences. Log attached.
On Wed, Feb 11, 2009 at 5:35 PM, Jonathan Chambers jonc...@gmail.com wrote:
Hello,
I am guessing xbuild is only supporting 2.0 for now. I am not sure how much
effort is needed to
Russel,
I think the issue is that you're using long to represent pointers when you
should be using IntPtr only.
2009/2/11 russell@realtimeworlds.com
All,
Not sure the best way to submit this, please correct me if there is a
better way to do this (via bugzilla?)
I encountered a
I have seen this repeatedly and have not been able to figure out why (unless
it's just old things lying around). If you look in your GAC, somewhere you
will have 2 versions of some assembly that both are 2.0.0.xxx. The current
resolve logic chokes on this trying to add a duplicate key to a
Rodrigo,
IntPtr objects are very awkward to use and optimise badly, we unwrap an
IntPtr to an internal type called Ptr, that is an enum based on a long,
as this generates much better code within loops and generally inlines
better (on both Mono and MS.Net) we also keep this as a long so that we
Hello,
this patch adds hooks to profile monitor activity.
I already have a profiler that uses it, and it works (I must finish the
post processing part but the event writing and decoding works well).
I only posted the runtime portion to keep the review easier...
I know the
Something along this patch? :-)
And the problematic assemblies follow:
Target ResolveAssemblyReferences:
Replacing reference to assembly:
/opt/mono/lib/mono/gac/System.Runtime.Serialization/2.0.5.0__7cec85d7bea7798e/System.Runtime.Serialization.dll
with
IntPtr code should optimize as well as int on 32bits machines and long on 64
bits machine. If it's not the case, report it.
Working with ints using long will be a lot slower on 32bits machines for
sure.
Regarding doing pointer math, the usual way to do it with C# is to use a
block of unsafe code
Russell,
The CLI has first class support for IntPtr but C# unfortunately needs to
call IntPtr methods instead of using opcodes directly. But I believe
that these methods should be inlined by the runtime. (If not this should
be tracked in bugzilla.)
And as Rodrigo said you should use unsafe
On Wed, Feb 11, 2009 at 12:55 PM, Paolo Molaro lu...@ximian.com wrote:
On 02/09/09 Rodrigo Kumpera wrote:
The attached patch adds a new hook to allow threads to shutdown after
the
GC finalizer has finished.
The motivation for it is to improve profiler's reliability at shutdown
time.
Hi,
I'd like to ask you guys the plans for the Mono Debugger in the
short/mid term.
Are you planning to support debugger on MacOS?
How hard would be to port it to other x86 OSs like Solaris?
Thanks,
pablo
___
Mono-devel-list mailing list
Hi Arno,
I think Qyoto is a really great initiative and a really strong point to
make Mono shine.
But I wonder if you have plans (and resources) to:
- Relaunch a website with information/tutorials/downloads. It doesn't
matter how good Qyoto is if no one can easily find it.
- Publish builds on
mono-devel-list-boun...@lists.ximian.com wrote on 01/31/2009 07:43:09 AM:
What do you guys think about performance penalization installing the
Linux OS in a specially formatted partition inside the AS?
What sort of performance penalty are you worried about? One on the overall
system on one on
Hi,
I'm cross compiling mono 2.2 for the ARM. I'm getting linker errors:
../utils/.libs/libmonoutils.a(mono-mmap.o): In function
`mono_shared_area_remove':/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:486:
undefined reference to
Hi,
The attached patch fixes some problems we are seeing with marshaling
bools and IDspatch types in Native code.
I can split the patch separating the bool changes form the dispatch
changes if needed. I would like to apply this to the 2.4 branch as
well.
-bill
2009-02-12 Bill Holmes
Hi,
This looks ok, I'm just concerned that the new code will be run even
in non-com situations,
and it might cause problems, like it uses CEE_LDIND_I4 to load a bool value.
Zoltan
2009/2/12 Bill Holmes billholme...@gmail.com:
Hi,
The attached patch fixes some problems we
IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
by Bartolomeo Nicolotti :: Rate this Message:
Reply | Reply to Author | View Threaded | Show Only this Message
Hello,
I've installed mono, and xsp (not yet mod_mono) on ubuntu following the
instruction here:
27 matches
Mail list logo
