[Mono-devel-list] Re: [Mono-patches] r46767 - trunk/mcs/class/System.Web.Services/System.Web.Services.Protocols
This requires a little bit more clean design which ensures the server is
always IDisposable. As far I understand it's always correct, but if this
changes, there will be a hard to find bug. So I decided to use a plain
try/finally block.
Thanks for notification!
Regards,
Konstantin Triger
Ben Maurer wrote:
On Thu, 2005-06-30 at 09:29 -0400, Konstantin Triger wrote:
Modified:
trunk/mcs/class/System.Web.Services/System.Web.Services.Protocols/HttpSimpleWebServiceHandler.cs
===
---
trunk/mcs/class/System.Web.Services/System.Web.Services.Protocols/HttpSimpleWebServiceHandler.cs
2005-06-30 13:05:37 UTC (rev 46766)
+++
trunk/mcs/class/System.Web.Services/System.Web.Services.Protocols/HttpSimpleWebServiceHandler.cs
2005-06-30 13:29:37 UTC (rev 46767)
@@ -115,9 +115,16 @@
try
{
object server = CreateServerInstance ();
- object[] res = method.Invoke (server,
parameters);
- if (!method.IsVoid) return res[0];
- else return null;
+ try {
+ object[] res = method.Invoke (server,
parameters);
+ if (!method.IsVoid) return res[0];
+ else return null;
+ }
+ finally {
+ IDisposable disp = server as
IDisposable;
+ if (disp != null)
+ disp.Dispose();
+ }
}
The cleanest way to do this is with the using statement. That
automatically does the try...finally for you.
Not only does it make the C# code clearer, it also enables a cool
optimization to make the bytecode shorter :-).
-- Ben
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Mono SVN / gmcs.exe compile error
Hello, I've been compiling Mono from SVN regularly now but a couple of days ago I started getting the following: ** (../../gmcs/gmcs.exe:7176): WARNING **: The class System.Collections.IKeyComparer could not be loaded, used in /cruft/cvs/mono/mcs/class/lib/net_2_0/System.Xml.dll (token 0x01a8) The full output can be seen here: http://pastebin.com/306755 Any help would be greatly appreciated. Regards, Hisham -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono SVN / gmcs.exe compile error
On 7/3/05, Hisham Mardam Bey [EMAIL PROTECTED] wrote: Hello, I've been compiling Mono from SVN regularly now but a couple of days ago I started getting the following: ** (../../gmcs/gmcs.exe:7176): WARNING **: The class System.Collections.IKeyComparer could not be loaded, used in /cruft/cvs/mono/mcs/class/lib/net_2_0/System.Xml.dll (token 0x01a8) The full output can be seen here: http://pastebin.com/306755 Did you try make clean first? -- Michal Moskal, http://nemerle.org/~malekith/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Mono SVN / gmcs.exe compile error
Hisham, I've been compiling Mono from SVN regularly now but a couple of days ago I started getting the following: ** (../../gmcs/gmcs.exe:7176): WARNING **: The class System.Collections.IKeyComparer could not be loaded, used in /cruft/cvs/mono/mcs/class/lib/net_2_0/System.Xml.dll (token 0x01a8) The full output can be seen here: http://pastebin.com/306755 Any help would be greatly appreciated. $ make distclean $ ./autogen.sh Rob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Mono SVN / gmcs.exe compile error
Michal, Robert, Thank you for your suggestion, but I already tried that. I just rm -rf'ed mono and mcs and I'm trying a fresh new checkout from SVN (developer repository). Lets hope this helps. I'll let everyone know what happens. Regards, Hisham. On 7/3/05, Robert Jordan [EMAIL PROTECTED] wrote: Hisham, I've been compiling Mono from SVN regularly now but a couple of days ago I started getting the following: ** (../../gmcs/gmcs.exe:7176): WARNING **: The class System.Collections.IKeyComparer could not be loaded, used in /cruft/cvs/mono/mcs/class/lib/net_2_0/System.Xml.dll (token 0x01a8) The full output can be seen here: http://pastebin.com/306755 Any help would be greatly appreciated. $ make distclean $ ./autogen.sh Rob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] [PATCH] Race condition when restarting threads
Hey,
In a Mono bug report, we noticed a very rare race in the GC when
restarting the world. GC_restart_handler states:
/* Let the GC_suspend_handler() know that we got a SIG_THR_RESTART. */
/* The lookup here is safe, since I'm doing this on behalf */
/* of a thread which holds the allocation lock in order */
/* to stop the world. Thus concurrent modification of the */
/* data structure is impossible.*/
However, this comment is not always true. When starting the world, the
thread that does the restarting does *not* wait for all threads to get
past the point where they need the structures used by the lookup for it
to release the GC_lock.
So the sequence of events looked something like:
* T1 signals T2 to restart the world
* T1 releases the GC_lock
* T3 is a newborn thread and adds itself to the table
* T2 gets the signal and sees a corrupt table because T3 is
concurrently modifying it.
What would end up happening when we experienced the race was either a
deadlock or a SIGSEGV.
The race was extremely rare. It took 1-2 hours to reproduce on an SMP
machine. With the attached patch, it has not segfaulted or hung for 21
hrs.
-- Ben
Index: pthread_stop_world.c
===
--- pthread_stop_world.c (revision 46881)
+++ pthread_stop_world.c (working copy)
@@ -163,6 +163,12 @@
/* to accidentally leave a RESTART signal pending, thus causing us to */
/* continue prematurely in a future round.*/
+/* Tell the thread that wants to start the world that this */
+/* thread has been started. Note that sem_post() is */
+/* the only async-signal-safe primitive in LinuxThreads.*/
+sem_post(GC_suspend_ack_sem);
+
+
#if DEBUG_THREADS
GC_printf1(Continuing 0x%lx\n, my_thread);
#endif
@@ -421,6 +427,7 @@
register GC_thread p;
register int n_live_threads = 0;
register int result;
+int code;
# if DEBUG_THREADS
GC_printf0(World starting\n);
@@ -450,7 +457,21 @@
}
}
}
+
#if DEBUG_THREADS
+GC_printf0 (All threads signaled);
+#endif
+
+for (i = 0; i n_live_threads; i++) {
+ while (0 != (code = sem_wait(GC_suspend_ack_sem))) {
+ if (errno != EINTR) {
+ GC_err_printf1(Sem_wait returned %ld\n, (unsigned long)code);
+ ABORT(sem_wait for handler failed);
+ }
+ }
+}
+
+#if DEBUG_THREADS
GC_printf0(World started\n);
#endif
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Diagnostics.Process redirection
On Sunday 03 July 2005 06:10, Colin JN Breame wrote:
Hello,
Below is a program that on my system replicates an unexpected exit by the
mono runtime.
The lines of interest are:
stdout.WriteLine(1);
p.StandardInput.WriteLine(hello world!);
stdout.WriteLine(2);
As the program runs, it prints '1' but exit before '2' is printed
1. Have you tried adding a catch so you can see any errors that might be
thrown? You have that code nested in a try -- but no cache.
2. Have you stepped it through monodevelop?
3. I know from Windows .NET that the methods for monitoring the state, and
completion of a Process is somewhat ill-defined. Yes, there are several
sample code examples but some say different things. For a project I did
that send an lpr command, I ended up doing two things.
Set a new Process equal to the actual process and monitor that as a kind of
handle. Two, put in a Thread.Sleep to give process a chance to clean
up. There seems to be some long disconnect between when the process
'stops' and when it 'really stops'.
At least that has been my experience w/Windows.NET
.
Any ideas what might be going on here? Could this be SIGPIPE related?
-- Colin
ps. mono 1.1.8.1
using System;
using System.IO;
using System.Diagnostics;
public class main_t {
public static void Main() {
while (true) {
run();
}
}
public static void run() {
Process p = null;
try {
p = new Process();
string pipe = echo hello;
int i = pipe.IndexOf(' ');
if (i == -1) {
p.StartInfo.FileName = pipe;
} else {
p.StartInfo.FileName = pipe.Substring(0,
i); p.StartInfo.Arguments = pipe.Substring(i+1, pipe.Length-i-1);
}
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardInput = true;
try {
p.Start();
} catch (Exception e) {
Console.Error.WriteLine(could not execute:
{0}, pipe);
goto init_error;
}
TextWriter stdout = Console.Out;
Console.SetOut(p.StandardInput);
stdout.WriteLine(1);
p.StandardInput.WriteLine(hello world!);
stdout.WriteLine(2);
Console.SetOut(stdout);
p.StandardInput.Close();
if (p != null) {
p.WaitForExit();
}
} finally {
if (p != null) p.Close();
}
init_error:;
}
}
___
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-devel-list] Warning with Gnome.About
On Fri, 2005-07-01 at 09:15 -0700, Harry Chesley wrote: I use Gnome.About to display my about box. If I just open and close the about box, I get four of the following warnings (with sequential increasing ids): (Argeebee:5931): GLib-GObject-WARNING **: gsignal.c:1781: instance `0x9f08310' has no handler with id `183' If I open and close the credits sub-window before closing the about box, I don't get any warnings. Is there a way to avoid these warnings? (I can easily write my own about box, but it seems a shame not to use the standard one.) Thanks! This has to do with you calling Destroy with attached signal handlers, You should either let the gc handle it for you, or detach the signal handlers before you call Destroy. All I do in my program is this (with appropriate declarations of progname, progversion, prismIcon, authors, and documenters): new Gnome.About(progname, progversion, (C) 2005 Harry Chesley, Optics game, authors, documenters, null, prismIcon).Run(); So I suspect the offending behavior is inside the Gnome.About class. Short of fixing it there (which I'd rather not get into as a first Mono project :-), is there any way to work around it? Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] make test error
Hello I have the following error. I suspect it was caused by /debug:full but I m not so sure. Please give me some directions, thank you in advance. vbc.exe /lib:../../../class/lib/default -d:NET_1_1 -d:ONLY_1_1 /debug+ /debugfull /target:library /out:rerrors_btest_default.dll /r:../../../class/lib/defaut/rerrors.dll -r:../../../class/lib/default/nunit.framework.dll -r:../../../clas/lib/default/nunit.core.dll -r:../../../class/lib/default/nunit.util.dll @.././../build/deps/rerrors_btest_default.dll.responseOption debug can be used at most 1 times. Ignoring extras...MonoBASIC Compiler 0.96.2.0 - (c)2002, 2003, 2004, 2005 Rafael TeixeiraTHIS IS AN ALPHA SOFTWARE.error BC2001: Source file 'full' could not be found!!!Compilation failed: 1 Error(s), 0 warningsmake[2]: *** [rerrors_btest_default.dll] Error 1make[2]: Target `test-local' not remade because of errors.make[2]: Leaving directory `/monosrc/mcs/mbas/Test/rerrors'make[1]: *** [do-test] Error 2make[1]: Target `test' not remade because of errors.make[1]: Leavi ng directory `/monosrc/mcs/mbas/Test/rerrors'make: *** [test-recursive] Error 1make: Target `test' not remade because of errors. __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
On Sun, 2005-07-03 at 12:16 -0400, Brandon Hale wrote: I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
On Sun, 2005-07-03 at 12:09 -0500, Mike Kestner wrote: On Sun, 2005-07-03 at 12:16 -0400, Brandon Hale wrote: I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? The entire mono stack, including MD and gtk-sharp2 will be included in Ubuntu in a tested working state. I can guarantee that packages that I ship are working, same as bundling things into one big stew. The problem comes some months down the road when developers (and bleeding edge users) try to build new upstream releases / cvs using a different API. They will be in the same boat as the last Ubuntu release, where they were on their own to update a bunch of the platform. If at all possible, I'd like to give these people a stable platform to build on this time around. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
On Sun, 2005-07-03 at 12:09 -0500, Mike Kestner wrote: On Sun, 2005-07-03 at 12:16 -0400, Brandon Hale wrote: I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? I assume you are trying to say ignore the fact that gtk# 2.x is unstable, just include it with md. If so, MD could just copy the .dll files as private assemblies. Much easier (and smaller!) than bundling. However, we are planning to ship gtk# 2.x with Mono 1.2 as a package (like 1.0 and 1.0 were), right? It'd be a shame not to see us ship one half of the package. All that tseng really needs is to know that by Aug. Xth, Gtk# 2.x will be reasonably API frozen. I think its pretty clear that 1.2 will be way before the Ubuntu final release. We just need to make sure that we are frozen early enough so that they feel comfortable using our code. Imagine what kind of mess it would be if Ubuntu shipped Gtk+ 2.7.5. That's the kind of mess we'll be facing if we make it hard for them to ship Gtk# 2. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
Hello, I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? It could be possible to ship the gtk# 2.x libraries in a way similar to what I describe here: http://www.mono-project.com/Template:LibrariesWithUnstableAPIs Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Mono SVN / gmcs.exe compile error
Apparently after wiping out mono and mcs and checking them out from SVN everything worked properly. Thanks for your help folks. Regards, Hisham. -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] System.Diagnostics.Process redirection
On Sunday 03 Jul 2005 16:45, John Bailo wrote:
1. Have you tried adding a catch so you can see any errors that might be
thrown? You have that code nested in a try -- but no cache.
Yes I have - I've tried both a catch and a finally block around the suspect
line. It really is exiting at that point.
2. Have you stepped it through monodevelop?
I don't have monodevelop installed. I would be grateful if someone else could
try the program to see if they get the same result.
3. I know from Windows .NET that the methods for monitoring the state, and
completion of a Process is somewhat ill-defined. Yes, there are several
sample code examples but some say different things. For a project I did
that send an lpr command, I ended up doing two things.
Set a new Process equal to the actual process and monitor that as a kind of
handle. Two, put in a Thread.Sleep to give process a chance to clean
up. There seems to be some long disconnect between when the process
'stops' and when it 'really stops'.
At least that has been my experience w/Windows.NET
.
Any ideas what might be going on here? Could this be SIGPIPE related?
-- Colin
ps. mono 1.1.8.1
using System;
using System.IO;
using System.Diagnostics;
public class main_t {
public static void Main() {
while (true) {
run();
}
}
public static void run() {
Process p = null;
try {
p = new Process();
string pipe = echo hello;
int i = pipe.IndexOf(' ');
if (i == -1) {
p.StartInfo.FileName = pipe;
} else {
p.StartInfo.FileName = pipe.Substring(0,
i); p.StartInfo.Arguments = pipe.Substring(i+1, pipe.Length-i-1);
}
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardInput = true;
try {
p.Start();
} catch (Exception e) {
Console.Error.WriteLine(could not
execute: {0}, pipe);
goto init_error;
}
TextWriter stdout = Console.Out;
Console.SetOut(p.StandardInput);
stdout.WriteLine(1);
p.StandardInput.WriteLine(hello world!);
stdout.WriteLine(2);
Console.SetOut(stdout);
p.StandardInput.Close();
if (p != null) {
p.WaitForExit();
}
} finally {
if (p != null) p.Close();
}
init_error:;
}
}
___
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-devel-list] Performance regression with XSP/Mono 1.1.8
On Fri, 2005-07-01 at 16:38 +0200, Luca wrote: Hello, I was doing some test on mono+XSP with web services. I was using the packages from debian/unstable (on the server): [...] I noticed that client performance was poor compared to the reference client, written in C with gSOAP (about 35 req/s versus 120 req/s). I tried upgrading mono on the *client* machine to 1.1.8.1-pre0 (debian): performance of the client went up to about 110 req/s. So I tried upgrading the server and weird things started to happen :( Performance of the C client is now at about 175 req/s, so it seems that mono 1.1.8-1 is indeed better than 1.1.5... but C# client is crawling at 22 req/s. I tried compiling XSP 1.0.9 (with Mono 1.1.8.1, without debug) but nothing changed. This is fixed in svn head r46896. Thanks. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] issue on runtime
Hello people, I'm newbie here, so correct me if I'm in the wrong place... The thing is that: After compile mono 1.1.8 in a Slack box I'm getting this with some projects (the ones i've compiled) on the runtime. I think i have some mistake in my setup; I have to hack Tomboy to seem alive. Thanks so much in advance. [tomboy] f-spot Unhandled Exception: System.DllNotFoundException: /usr/lib/f-spot/libfspot.so.0in (wrapper managed-to-native) FSpot.ImageView:f_image_view_new ()in 0x0001c FSpot.ImageView:.ctor ()in 0x0001f FSpot.PhotoImageView:.ctor (FSpot.PhotoQuery query)in 0x001ed PhotoView:.ctor (FSpot.PhotoQuery query, .PhotoStore photo_store)in 0x00abc MainWindow:.ctor (.Db db)in 0x00134 Driver:Main ( System.String[] args) [tomboy] tomboyTrying Plugin: ExportToHTML.dll ... ExportToHTMLPlugin. Done.Trying Plugin: PrintNotes.dll ... PrintPlugin. Done. Unhandled Exception: System.DllNotFoundException: libtomboy.soin (wrapper managed-to-native) Tomboy.TomboyTrayIcon:egg_tray_icon_new (string)in 0x0002b Tomboy.TomboyTrayIcon:.ctor (Tomboy.NoteManager manager) in 0x00022 Tomboy.TomboyTrayIcon:.ctor ()in 0x00019 Tomboy.Tomboy:StartTrayIcon ()in 0x000d8 Tomboy.Tomboy:Main (System.String[] args) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] mcs patch for precise location handling
Hi,
Martin gave some comments on the patch, so I made a few changes:
- removed dont_progress_location conditions in tokenizer
- fixed incorrectly modified public int token in location.cs
- renamed StringValue to Value in LocatedToken.
And merged the patch to the latest trunk as:
http://monkey.workarea.jp/tmp/20050704/precise-location-20050704.diff
Only where it is appropriate not for `if', `foreach', etc.
I think it will be easier to read and probably a little bit faster.
Like this
+LocatedToken lt = (LocatedToken) $1;
+LabeledStatement labeled = new LabeledStatement
(lt.StringValue, lt.Location);
or this
-CheckBinaryOperator ((Operator.OpType) $3);
+LocatedToken ltParam1 = (LocatedToken) $6;
+LocatedToken ltParam2 = (LocatedToken) $9;
+CheckBinaryOperator ((Operator.OpType) $3, (Location) $2);
Parameter [] pars = new Parameter [2];
Expression typeL = (Expression) $5;
Expression typeR = (Expression) $8;
- pars [0] = new Parameter (typeL, (string) $6,
Parameter.Modifier.NONE, null, lexer.Location);
- pars [1] = new Parameter (typeR, (string) $9,
Parameter.Modifier.NONE, null, lexer.Location);
+ pars [0] = new Parameter (typeL, ltParam1.StringValue,
Parameter.Modifier.NONE, null, ltParam1.Location);
+ pars [1] = new Parameter (typeR, ltParam2.StringValue,
Parameter.Modifier.NONE, null, ltParam2.Location);
I once thought about that, but it makes those constructors too
parser-specific while some of them are invoked inside some other
types (Iterators etc.) where we have dare
to create LocatedToken. So I felt that it won't be worthy of
making those changes just to make parser a bit readable. Especially
I was afraid that there might be need for LocatedToken-less
ctor()s in the future (or that could already happen in gmcs).
I think 99% are parser specific. Otherwise Iterator can always create
this container.
I cannot talk about gmcs as I don't know the sources.
Am so skeptical about the good effect (code readability) as
compared to the bad effect (performance, cost of work, and in
fact code readability also here). Sure, it might improve
readability for some readers, but on the other hand it introduces
extraneous new LocatedToken() in its internal processing stage.
Actally I tried to make such changes from reviewing all LocatedToken
usage in cs-parser.jay, but there were much more cases that I had
to change. For example when I changed LocalVariableReference.ctor()
to accept LocatedToken, it requires to introduce new LocatedToken()
in DoSimpleNameResolve() whose invocation count is not small in
the profiler result.
(Of course avoiding LocatedToken for such specific cases will
just make code inconsistent.)
The changes are also being so massive that I wonder if it is
really worthy of changing. It is far from mandatory changes.
If the majority of mcs hackers still want this change, I'll
restart this.
But you don't need to introduce the `LocatedToken' when you just reuse
`MemberName'.
It will simplify this mainly when you rewrite `VariableDeclaration' to
hold this MemberName then
we will have just 1 name container.
Yes, but I am not sure if member names and variable name are in
the same semantics (esp. am not sure if those constraints are/
will be the same) or not and thus if MemberName can be used or not.
MemberBase is derived from MemberCore
+Location GetLocation (object obj)
+{
+if (obj is MemberCore)
+return ((MemberCore) obj).Location;
+if (obj is MemberName)
+return ((MemberName) obj).Location;
Mmm, I couldn't understand what you meant. MemberBase will be
thus handled here, so I don't see possible improvements here.
+if (obj is MemberName)
This `if' never happens.
Well, I don't think MemberName is derived from MemberCore.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
