Hi,
Paolo Molaro wrote:
On 08/16/05 Atsushi Eno wrote:
+typedef struct {
+ const stridx_t name;
+ gint16 region_entry_index;
+} RegionInfoNameEntry;
+
+typedef struct {
+ gint16 lcid;
+ gint16 region_entry_index;
It likely makes sense to put region_entry_index inside Cu
On 08/12/05 David Srbecky wrote:
> I guess that debugger and jit support is really difficult, but I only
> want some help with the compiler support - to be more specific, I need
> to be able to 'hook' on the System.Reflection.Emit and be notified of
> additions to metadata. I will handle the format
List,
I’m writing an app that should collect data on
/dev/ttyS0 and push it out to a web service. The code for the app is included
in this message. Here is the error that I am getting:
** (Program.exe:13337): WARNING **: The class
System.IO.Ports.SerialPort could not be loaded, used
Hi Andrew,
I think xmlconf.exe should also include the actual error message
in addition to the stack trace string. Does the attached patch
look OK for you?
Atsushi Eno
Index: ChangeLog
===
--- ChangeLog (revision 48380)
+++ ChangeL
hello,
- I want to create a c# library for some optimization routines with mono. can any one explain proper staps to do ?? or if you know any web site or book which provide that information pls let me know.
- I m new to c# and mono so quite confused about how exactly c# library is created.
- a
On 08/15/05 Atsushi Eno wrote:
> I noticed that currently our RegionInfo (sys.globalization)
> support is hard-coded and pretty insufficient. So I reimplemented
> it like what we do for CultureInfo i.e. create region table from
> CLDR via locale-builder.
>
> Actually I mostly reused locale-builder
Paolo Molaro wrote:
> On 08/16/05 David Srbecky wrote:
>>Isn't it better to use managed Cecil in S.R.Emit do the reading and
>>writing of assemblies?
>
> No.
> The runtime needs to be able to read assemblies before executing them,
> so this code must be unmanaged. Having a second copy of the code
On 08/16/05 David Srbecky wrote:
> schoolwork, I will do some research, produce a battle plan and I will
> come back :-)
Ok:-)
> Do you mean that Cecil can not access the runtime similarly as
> Reflection.Emit? Ok, got it.
It can access it, but only through a very coarse mechanism: assembly
load
> Hi, Kornél.
>
> The .jvm.cs are part of the Java build that we are now doing from svn
> using make.
> The issue is not limited to the .jvm files but also to Mono sources
> (e.g. in System.Web) that are not part of the Java build. In System.Web
> we have about 30 Mono files that we don't compile
Paolo Molaro wrote:
> On 08/16/05 David Srbecky wrote:
>>Paolo Molaro wrote:
>>>What if you just recompile the assembly and develop an assembly diff
>>>tool? In a few months the Cecil library may be able to allow this.
>>
>>I been suggested this many times, but the problem is that it is way too
>>s
On 08/16/05 David Srbecky wrote:
> Paolo Molaro wrote:
> > What if you just recompile the assembly and develop an assembly diff
> > tool? In a few months the Cecil library may be able to allow this.
>
> I been suggested this many times, but the problem is that it is way too
> slow. My target for a
On 08/15/05 Shawn Singh wrote:
> I'm checking to find out if my subscription has been approved. I need
Just for the record, subscription requests are not subject to approval,
you just need to follow the procedure correctly.
lupus
--
--
On 08/16/05 Atsushi Eno wrote:
> >>+typedef struct {
> >>+ const stridx_t name;
> >>+ gint16 region_entry_index;
> >>+} RegionInfoNameEntry;
> >>+
> >>+typedef struct {
> >>+ gint16 lcid;
> >>+ gint16 region_entry_index;
> >
> >It likely makes sense to put region_entry_index inside CultureI
On Fri, 2005-08-12 at 20:41 -0400, Michael Thomsen wrote:
> I installed all of the dependencies built with VC++ in c:\monosvn and
> have VC++ 7 from VS .NET 2003 installed. Could someone tell me how to
> tell the mono configure script to use VC++ rather than the GCC suite
> supplied by cygwin? I ha
Good day.
You can try to tune keepalive TCP parameters. These parameters can be
setted via /proc file system. You can write values directly to
pseudo-files, set them with sysctl utility, or add them to
/etc/sysctl.conf. See man page for sysctl for details.
Keepalive parameters that could be us
Hi,
I think this is ok to check in.
Zoltan
On 8/14/05, Kamil Skalski <[EMAIL PROTECTED]> wrote:
> Hi!
>
> When bringing generic version of Nemerle interactive shell to live I
> encountered the problem in mono runtim
Exceptions don't appear to work correctly in the 2.0 build of
Novell.Directory.Ldap. In fact, where is this (and
System.DirectoryServices) in the Mono source tree so I can look into it?
:)
On a related note, how do you set this library to use auto-referral (the
web page says it's possible)? My
Hi Gert.
You wrote:
> I'm still working on additional fixes and tests, I should get
> things stable today (meaning tests should pass on both mono
> and MS.NET).
>
> Gert
Can you make things stable before committing, please? We are actively
working on System.Drawing these days, and it is very d
> -Original Message-
> From: Andrew Skiba [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 16 augustus 2005 13:58
> To: Gert Driesen
> Cc: mono-devel-list@lists.ximian.com
> Subject: RE: [Mono-patches] r48374 - in
> trunk/mcs/class/System.Drawing: .System.Drawing Test/System.Drawing
>
> Hi G
Hi Gert.
Can you please tell me, how do you know that dotnet uses the
CultureInfo.InvariantCulture.TextInfo.ListSeparator and not hardcoded
comma?
And BTW you did not change CT#3 testcase, so it fails now:
Failures:
1) MonoTests.System.Drawing.ColorConverterFixture.ConvertTo : CT#3
Strin
> I wrote some test cases, and searched for a culture-specific
> character that matches the results I got.
You wrote tests that demonstrate the difference in behavior of dotnet
and mono before your fixes? Can you add these tests to the testsuite, or
at least send these tests to the devlist?
Tha
> -Original Message-
> From: Andrew Skiba [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 16 augustus 2005 13:19
> To: Gert Driesen
> Cc: mono-devel-list@lists.ximian.com
> Subject: RE: [Mono-patches] r48374 - in
> trunk/mcs/class/System.Drawing: .System.Drawing Test/System.Drawing
>
> > I
Andrew,
I wrote some test cases, and searched for a culture-specific character that
matches the results I got.
I'm still working on additional fixes and tests, I should get things stable
today (meaning tests should pass on both mono and MS.NET).
Gert
> -Original Message-
> From: Andrew
Just for curiosity: can svn:eol-style of parent dir take care of all the
files?
> * Color.cs: Fixed line endings. Set eol-style to native.
> * ColorConverter.cs: Fixed line endings. Set eol-style to native.
> * Size.cs: Set eol-style to native.
> * SizeF.cs: Use current culture in ToString(), set
One more thing:
Paolo Molaro wrote:
#ifdef HAVE_ICU
Feel free to completely remove the icu stuff with another patch, too;-)
Let me keep it for a while - it's a bit convenient to check icu
performance.
Atsushi Eno
___
Mono-devel-list mailing list
Hi, Kornél.
The .jvm.cs are part of the Java build that we are now doing from svn using
make.
The issue is not limited to the .jvm files but also to Mono sources (e.g. in
System.Web) that are not part of the Java build. In System.Web we have about
30 Mono files that we don't compile in the Java b
I'm developing in Mono, but think MonoDevelop is still too buggy so
I'm using a standard text editor (vim) for coding. So I have crafted a
tiny and incomplete gui class browser that is a sort of aid for me.
Don't know if something similar or better for the same purpouse
already exists. Here it go
Zoltan Varga wrote:
Hi,
The current solution might not be elegant, but it is simple, and it
works just fine.
Yes. But because of the java profile, a large part of source files need
to be enclosed by #ifdef.
The solution Ynon proposed is sti
I think the current soltion is elegant.
Are the .jvm directories used to build the java version using Mono build
system or are they here only as a reference?
If .jvm directories are not used there are only 23 files that are enclosed
in #if NET_2_0 || TARGET_JVM. These files are for 2.0 and java.
Paolo Molaro wrote:
> What if you just recompile the assembly and develop an assembly diff
> tool? In a few months the Cecil library may be able to allow this.
I been suggested this many times, but the problem is that it is way too
slow. My target for application of EnC is < 100ms.
The Cecil: Am
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Kornél Pál
> Sent: maandag 15 augustus 2005 15:33
> To: Andrew Skiba; Gert Driesen <[EMAIL PROTECTED]>
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] RE:
> [Mono-patches]r48372-
On 08/15/05 Yaacov Akiba Slama wrote:
> > The current solution might not be elegant, but it is simple, and it
> >works just fine.
> >
> >
> Yes. But because of the java profile, a large part of source files need
> to be enclosed by #ifdef.
> The solution Ynon proposed is still quite simple as yo
On 08/14/05 Elliott Draper wrote:
> I'm using Autoconf v2.59, and Automake v1.9.2. These versions match that
> of another machine I have, which builds from source correctly. The only
[...]
> Running libtoolize...
> You should update your `aclocal.m4' by running aclocal.
> Running aclocal ...
> a
>From what I understand you are trying to ascertain whether your client
is still "alive". The way that IRC handles this is to have the server
send a "PING" message to the client every say 5 mins and the client is
obliged to send "PONG" before any further data is sent or received. If
no "PONG" is re
Thanks, that's interesting stuff.
My application is a chat server, so I really need to know sooner than 2
hours if the client is dead. On the other hand I have a web server and don't
want to introduce unnecessary traffic there. What is the right way to handle
this, right now I am just sending
35 matches
Mail list logo
