Hi, Atsushi.
O.K. Let's use the TARGET_JVM then. Shouldn't we ad some kind of FIXME or
MonoTODO in this case? I'd like to still keep track of this issue and get rid
of the '#if TARGET_JVM' when Mono and Grasshopper behave the same.
Eyal.
On Wed, 8 Jun 2005, Atsushi Eno wrote:
Date: Wed, 08
If you want please feel free to do so.
Atsushi Eno
Eyal Alaluf wrote:
Hi, Atsushi.
O.K. Let's use the TARGET_JVM then. Shouldn't we ad some kind of FIXME or
MonoTODO in this case? I'd like to still keep track of this issue and get rid
of the '#if TARGET_JVM' when Mono and Grasshopper behave
Hi Eno.
I see that upgrading to v4 of the testsuite is not smooth, so I will not
waste my time on this anymore. Please try the applied patch, and if it's
OK, then I'm done with this testsuite.
Andrew.
Index: ChangeLog
===
---
Hi Andrew,
+-test-case category=XSLT-Result-Tree id=string_string09
+-input-file role=principal-datastring09.xml/input-file
+-input-file role=principal-stylesheetstring09.xsl/input-file
+-output-file role=principal compare=XMLstring09.out/output-file
Was there anything wrong with string09
Atsushi Eno wrote:
Andrew: I think there was a similar problem in XmlConvert.cs.
Eno, I see once the fix was in XmlConvert, but now the flow for this
testcase does not pass there. Do you think I have to fix both places anyway?
Thanks,
Andrew.
___
I agree, good shot Ben!
Attached updated patch.
Thank you,
Ilya.
Ben Maurer wrote:
On Wed, 2005-06-08 at 13:17 +0300, Ilya Kharmatsky wrote:
InProc = 1,
StateServer = 2,
SQLServer = 3
+#if TARGET_J2EE
+ ,J2ee = 4
+#endif
It's probably a
Sorry I've sent the old diff - here is a new one - the value changed to
'1024'.
Ilya Kharmatsky wrote:
I agree, good shot Ben!
Attached updated patch.
Thank you,
Ilya.
Ben Maurer wrote:
On Wed, 2005-06-08 at 13:17 +0300, Ilya Kharmatsky wrote:
InProc =
It doesn't look like the embedding runtime is looking
for AOT files. When I run mono from the command line I
get Mono-INFO: AOT loaded/failed to load AOT module
messages, but I don't get these when I run the
application embedding mono, just messages talking
about loading the normal bytecode
Hello All,
I woke this morning to find my code that runs itself in a loop and processes
commands as its given them. I found it offline, which normally
wouldnt bother me, until I tried to restart it. It goes through
its normal sequence before coming to its looped state of wait, and a
Hi,
This is due to a problem in out embedding interface. It is now tracked as:
http://bugzilla.ximian.com/show_bug.cgi?id=75194
Zoltan
On 6/9/05, Jim Purbrick [EMAIL PROTECTED] wrote:
It doesn't look like the embedding runtime is looking
for
Hello All,
I woke this morning to find my code that runs itself in a
loop and processes commands as it's given them. I found it offline,
which normally wouldn't bother me, until I tried to restart it. It
goes through its normal sequence before coming to its looped state of
wait,
Hi,
I've made a sublayer that embed several Mono in several pthread to
run C# SPMD program over NUMA. I 've not made yet the communication lib
(I just use pipe now to communicate between different Mono).
To illustrate my work I need a scientific
Pierre,
I (and others) have made the same request on the mono windows
forms mailing list. No answers so far. I started to look into it, but
haven't had time lately. If I figure anything out, I'll post it.
- Jonathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Dnia roda, 8 czerwca 2005 22:40, Martin Baulig napisa:
Hello,
I'll commit it tomorrow morning.
Don't worry, we're waiting with the release to get a few more of my
fixes in, so this'll definitely go in :-)
Sorry you had problems merging this patch. It was created against 45614.
Seems like
Hello,
During making Nemerle work with Mono generics, I've stumbled across
something that seems to be a bug in Mono runtime.
Inside:
mono_reflection_bind_generic_parameters (MonoReflectionType *type,
int type_argc, MonoType **types)
there is a call:
Hi Ilya,
It's worth to wrap the
java.net.InetAddress address = java.net.InetAddress.getLocalHost();
with an appropriate try/catch/throw, otherwise a Java exception would be
thrown to the user.
Regards,
Konstantin Triger
Ilya Kharmatsky wrote:
Please review the patch.
Thanks,
Ilya.
Hey,
Currently, when loading a reflection only assembly, and then a normal
assembly is also loaded, they share their images, which of course is not
correct.
With the attached patch separated images are loaded.
Carlos.
Index: appdomain.c
In this case there is no "appropriate" throw. May
be I'm wrong, but
in .Net code there is no exception in this method.
Konstantin Triger wrote:
Hi Ilya,
It's worth to wrap the
"java.net.InetAddress address = java.net.InetAddress.getLocalHost();"
with an appropriate
On Wed, 2005-06-08 at 13:11 +0300, Ilya Kharmatsky wrote:
Hi, All!
Please review updated version of patch.
The patch is fine.
As long as the new code is inside TARGET_JVM, feel free to commit all
the patches you want.
-Gonzalo
___
On Fri, 2005-06-10 at 00:31 +0300, Ilya Kharmatsky wrote:
In this case there is no appropriate throw. May be I'm wrong, but
in .Net code there is no exception in this method.
Commit, commit. I'm fine with all these patches that are for
synchronizing mainsoft and mono libraries, as the new code
(This message was originally sent to Miguel de Icaza)
As you may remember, the LRDE (http://www.lrde.epita.fr) planed to
use monoburg for its Tiger Compiler (http://tiger.lrde.epita.fr).
As we have some specific needs, we modified it a little bit. Clément
Vasseur and Benoit Perrot
21 matches
Mail list logo
