Re: [Mono-devel-list] autogen/bootstrap "variable not defined" errors
Hi, > I can build ok with the source tarballs (./configure, make, etc...) but > lately I've been trying to run bootstrap on the latest from svn to add > optional packages to the make and consistently have problems with variable > not defined errors. The latest is from gtk-sharp. The variable it's > looking for is VTE_LIBS. I have a folder /usr/lib/libvte4 which I assume is > what it's supposed to be set to. It'll also be looking for the headers. Did you compile vte from source or as a pre-packaged app? If it was pre-packaged, you need the -devel part as well. cd into the gtk-sharp directory, make distclean, ./bootstrap[-2.4] --prefix=[prefix], make, su, make install The -2.4 is if you're using mono built from svn and have the preview vsn 2 option set on it. TTFN Paul -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
On Thu, 2005-06-23 at 00:45 -0400, Miguel de Icaza wrote: > Also, to apply this kind of patch that will affect everything, I would > like to know in advance the memory footprint (running mono --profile > before/after should tell us this) and how much extra code is JITed at > startup (how much slower this becomes for a sample program). In terms of corlib code, Locale.GetText should actually be relatively rare: only used in exceptional code paths. So, I have the feeling that this is not as bad as it looks. Once you get a stack trace that will go to the console, it's not like an extra 50 ms will really make a difference :-). Anyways, the biggest source of jit'ing that i can see in that code is due to: typeof (Locale).Assembly.GetName ().Name Which, IIRC does a relatively wide range of stuff. -- 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] How to handle huge string collation resources?
On Thu, 2005-06-23 at 01:05 -0400, Miguel de Icaza wrote: > Hello, > > > > BTW doesn't that mean all that kind of culture resources had better > > > become managed resources, unless they are required at runtime? > > > We also have huge culture-info-table.h and char-conversions.h > > > in metadata. > > > > They are in C, where they are a const array. One advantage of having > > them there is that we don't have to do conversions for different endian > > systems. > > Cant the same be said about the table that Atsushi is creating? Do we > really worry about the 200k replicated between Mono and libmono.so. Not too much ;-). Well, it might make a difference if on the same box somebody is using mono and libmono.so -- but not a big issue. I've no idea what kind of data is in the table, and if it is endian dependent. If it's just a byte array, we'd be fine... > The resource approach has also the downside that access to it would be > through the Stream interface (even if mmapped) while getting a pointer > to a C-statically defined array would allow the corlib code to access it > without any wrapper code. Well, since we are in corlib, we can get the void* ;-). Anyways, I think the two approaches don't make much difference in terms of performance (except possibly the endian stuff). Where there is a difference is in terms of development model: If we want to include the stuff in the C runtime, we pretty much have to check in the generated file to SVN. We can't run C# code before the runtime is compiled. OTOH, if we include the stuff as a managed resource to corlib, we could run a mono app at that point to generate the file. While this stuff is in active development, checking in a large file to svn is probably going to make mono-patches-list a bit annoying. So maybe the best plan would be a managed resource for now, and once the table is stable, moving it into C if that makes a substantial performance difference. -- 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] How to handle huge string collation resources?
Hello, Just to follow up some more: since the tables generated contain various arrays of short and int sizes, I rather go down the path of embedding that into the C code, so we get the automatic endian adjustment rather than forcing the managed code to deal with it. We can add an internal call to get the pointers to the various tables and take it from there. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: System.Xml patch
Hi Andrew,
How about this patch? To save iterations, I made the same check in
ResolveExternalEntityReplacementText, please tell me, if it's unnecessary.
This patch looks fine. Let's check it in svn.
I'll apply the patch attached after your commit.
Index: DTDReader.cs
===
--- DTDReader.cs(revision 46238)
+++ DTDReader.cs(working copy)
@@ -641,8 +641,9 @@
private void ResolveExternalEntityReplacementText
(DTDEntityBase decl)
{
if (decl.LiteralEntityValue.StartsWith ("
What does this mean? I guess you have in mind that there are cases that
entities could be used inside attributes, but attribute content check
is less prohibiting and '<' characters are checked anyways.
(BTW we won't understand what "-AS" means there ;-)
Besides the comment itself.
In fact I also don't like that part of code. Actually, though
replacing entities with a simple string is good for performance
as compared to such code that loads entity possibly from external
files every time, it causes incorrect BaseURI resolution (that
results in incorrect not-wf error for XHTML 1.1 DTD; bug #51495).
So, basically rewriting that entity expansion part is the best
solution. But I haven't tried that since it will not be done as a
quick hack and it will first result in several breakage in
standalone tests.
Thanks,
Atsushi Eno
Index: Test/System.Xml/XmlTextReaderTests.cs
===
--- Test/System.Xml/XmlTextReaderTests.cs (revision 46370)
+++ Test/System.Xml/XmlTextReaderTests.cs (working copy)
@@ -1100,5 +1100,20 @@
AssertEquals ("#1", 0xf090, (int) r.Value [0]);
AssertEquals ("#1", 0x8080, (int) r.Value [1]);
}
+
+ [Test]
+ [ExpectedException (typeof (XmlException))]
+ public void EntityDeclarationNotWF ()
+ {
+ string xml = @"
+
+ '>
+ ]>
+ &e; ";
+ XmlTextReader xtr = new XmlTextReader (xml,
+ XmlNodeType.Document, null);
+ xtr.Read ();
+ }
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] How to handle huge string collation resources?
Hello, > > BTW doesn't that mean all that kind of culture resources had better > > become managed resources, unless they are required at runtime? > > We also have huge culture-info-table.h and char-conversions.h > > in metadata. > > They are in C, where they are a const array. One advantage of having > them there is that we don't have to do conversions for different endian > systems. Cant the same be said about the table that Atsushi is creating? Do we really worry about the 200k replicated between Mono and libmono.so. And the libmono.a is only shipped to those developing. The resource approach has also the downside that access to it would be through the Stream interface (even if mmapped) while getting a pointer to a C-statically defined array would allow the corlib code to access it without any wrapper code. Both approaches enjoy the mmap benefits. 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] [PATCH] Reworked unified Locale classes
Hello,
> So please tell me whether you want:
> - drop this patch
> - drop localization at all
> - or approve this patch
The patch only has one bug as it stands today: it uses a double check
lock, which is race prone:
if (x == null){
lock (...){
if (x == null){
x = Allocate ();
}
}
}
I have a few more questions: what happens if a translation does not
exist, or a catalog does not exist, do we have a fast-path?
So probably that variable needs to be allocated statically.
Also, to apply this kind of patch that will affect everything, I would
like to know in advance the memory footprint (running mono --profile
before/after should tell us this) and how much extra code is JITed at
startup (how much slower this becomes for a sample program).
Am starting to understand your point of view on the translation
technique, and it might be worth switching to the key/string translation
scheme.
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] How to handle huge string collation resources?
On Thu, 2005-06-23 at 12:41 +0900, Atsushi Eno wrote:
> Ben Maurer wrote:
> >> Here is a serious problem. In step 3 it makes 1.2MB of a C#
> >> source file that results in 500KB increase of mscorlib.dll.
> >
> > If you are generating a file in C#, you are going to be managing memory
> > badly. C# has no sense of a const array. When you say:
> >
> > static readonly int [] x = {
> > ...
> > }
> >
> > This array is actually allocated in the GC *at runtime*.
> >
> > Doing it in a header file would be an option. Not really ideal because
> > it gets into our package three times (once for the statically linked
> > mono binary, another for libmono.so, another for libmono.a).
> >
> > The best option is to have it as a resource in a dll. The runtime memory
> > maps that.
>
> Oh, I didn't know that resources are mmapped. Yeah, then that
> sounds the best way.
>
> BTW doesn't that mean all that kind of culture resources had better
> become managed resources, unless they are required at runtime?
> We also have huge culture-info-table.h and char-conversions.h
> in metadata.
They are in C, where they are a const array. One advantage of having
them there is that we don't have to do conversions for different endian
systems.
>
> >> And for about 200KB of data, they are just for CJK cultures
> >> so they won't be used unless we use those cultures to handle
> >> culture-sensitive CJK collation. That is mostly waste of memory.
> >
> > Not if the data doesn't get paged in ;-).
>
> > The memory system essentially does that via the mmap call, however it is
> > hidden from view.
>
> Well, they will be hidden from view, but don't they still eat
> memory when mscorlib.dll is loaded? Don't they still get paged?
Memory in a mapped file that is never touched never gets read from the
disk, nor is physical memory allocated for it.
-- 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] How to handle huge string collation resources?
Hey,
Ben Maurer wrote:
> On Wed, 2005-06-22 at 04:26 +0900, Atsushi Eno wrote:
>> 3. run "make". It will automatically downloads some files
>> from some sites. For now without this step the build
>> b0rks.
>
> Of course, this will need to be changed ;-).
duh ;-) It will be checked in when we decide how to handle it.
>> Here is a serious problem. In step 3 it makes 1.2MB of a C#
>> source file that results in 500KB increase of mscorlib.dll.
>
> If you are generating a file in C#, you are going to be managing memory
> badly. C# has no sense of a const array. When you say:
>
> static readonly int [] x = {
> ...
> }
>
> This array is actually allocated in the GC *at runtime*.
>
> Doing it in a header file would be an option. Not really ideal because
> it gets into our package three times (once for the statically linked
> mono binary, another for libmono.so, another for libmono.a).
>
> The best option is to have it as a resource in a dll. The runtime memory
> maps that.
Oh, I didn't know that resources are mmapped. Yeah, then that
sounds the best way.
BTW doesn't that mean all that kind of culture resources had better
become managed resources, unless they are required at runtime?
We also have huge culture-info-table.h and char-conversions.h
in metadata.
>> And for about 200KB of data, they are just for CJK cultures
>> so they won't be used unless we use those cultures to handle
>> culture-sensitive CJK collation. That is mostly waste of memory.
>
> Not if the data doesn't get paged in ;-).
> The memory system essentially does that via the mmap call, however it is
> hidden from view.
Well, they will be hidden from view, but don't they still eat
memory when mscorlib.dll is loaded? Don't they still get paged?
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] autogen/bootstrap "variable not defined" errors
Hi, I can build ok with the source tarballs (./configure, make, etc...) but lately I've been trying to run bootstrap on the latest from svn to add optional packages to the make and consistently have problems with variable not defined errors. The latest is from gtk-sharp. The variable it's looking for is VTE_LIBS. I have a folder /usr/lib/libvte4 which I assume is what it's supposed to be set to. I've tried exporting it in the env, adding it to vte/glue/Makefile.am and adding it to header-vars.am in the automake folder. When I add it to header-vars.am, I can see the definition show up in vte/glue/Makfile.in, but I still get the error. I can't think of anything else to try right now so any help is greatly appreciated. Thanks, Scott _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] How to handle huge string collation resources?
On Wed, 2005-06-22 at 04:26 +0900, Atsushi Eno wrote:
> 3. run "make". It will automatically downloads some files
> from some sites. For now without this step the build
> b0rks.
Of course, this will need to be changed ;-).
> Here is a serious problem. In step 3 it makes 1.2MB of a C#
> source file that results in 500KB increase of mscorlib.dll.
If you are generating a file in C#, you are going to be managing memory
badly. C# has no sense of a const array. When you say:
static readonly int [] x = {
...
}
This array is actually allocated in the GC *at runtime*.
Doing it in a header file would be an option. Not really ideal because
it gets into our package three times (once for the statically linked
mono binary, another for libmono.so, another for libmono.a).
The best option is to have it as a resource in a dll. The runtime memory
maps that.
> And for about 200KB of data, they are just for CJK cultures
> so they won't be used unless we use those cultures to handle
> culture-sensitive CJK collation. That is mostly waste of memory.
Not if the data doesn't get paged in ;-).
> - CompareInfo or whatever holds those tables as static
> variables.
> - If the variable is null, then it tries to load the
> "internally stored table" via runtime icall_1. However
> at this stage it returns null, since nothing is stored.
> - Then, CompareInfo or whatever loads "table-only assembly"
> via reflection and loads table into memory, and
> then invokes an icall_2 that sets the table as runtime
> internal table.
> - Next time CompareInfo tries to fill the table, icall_1
> will return the table.
The memory system essentially does that via the mmap call, however it is
hidden from view.
-- 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] Re: [Mono-patches] r46370 - in trunk/mcs/class/corlib: System.Collections.Generic Test/System.Collections.Generic
On Wed, 2005-06-22 at 19:27 -0600, David Waite wrote: > Enumerating needs to be locked, inserts need to be locked, but all > locking is external to the collection. But you can enumerate and read from multiple threads at the same time. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] MonoDevelop : looking for mozilla
Hi, When I launch Monodevellop, I get this message : which: no mozilla in (/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/maitrebn/bin) Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory ... Is there a way to use Monodevelop with FireFox ? ___ 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-patches] r46353 - trunk/mcs/class/System.XML/System.Xml
Ok, it is an interesting tip. Now checked in svn as r46380. Thanks. Atsushi Eno > I think this needs to be changed to make it optimal for the normal case. > Gonzalo's situation is a corner case: 1 huge field in the middle of tons > of stuff. However, normally, there are many, small, similarly sized > fields. So what happens is that the string builder does the standard > "double when there is too much data". Most strings will end up being (on > average) 25% larger than they need to be. > > Therefore, we should do something like this: > > if (sb.Capacity < 100) > return sb.Substring (0, sb.Length); > else > return sb.ToString (); > > That way, if the string is small, "substring" will be used. It will > create a string of the exact size we want. The stringbuilder buffer can > then be reused. > > -- Ben > > ___ > 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] Syslog support
On Wed, 2005-06-22 at 19:35 +0400, Vorobiev Maksim wrote: > Good day. > > Is there are any possibility to work with syslog daemon from Mono > without developing additional unmanaged code? I cann't find support > for syslog in any Mono namaspaces. Does it exists? http://www.go-mono.com/docs/monodoc.ashx?link=M%3aMono.Unix.Syscall.syslog%28Mono.Unix.SyslogLevel%2cSystem.String%29 ___ 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-patches] r46353 - trunk/mcs/class/System.XML/System.Xml
On Wed, 2005-06-22 at 04:12 -0400, Atsushi Enomoto ([EMAIL PROTECTED]) wrote: > Author: atsushi > Date: 2005-06-22 04:12:53 -0400 (Wed, 22 Jun 2005) > New Revision: 46353 > > Modified: >trunk/mcs/class/System.XML/System.Xml/ChangeLog >trunk/mcs/class/System.XML/System.Xml/XmlTextReader.cs > Log: > 2005-06-22 Atsushi Enomoto <[EMAIL PROTECTED]> > > * XmlTextReader.cs : use StringBuilder to store character values; that > saves 40% memory for large chunk of xml. Patch by Gonzalo. > > Don't remove ChangeLog entry BTW. > > > > Modified: trunk/mcs/class/System.XML/System.Xml/ChangeLog > === > --- trunk/mcs/class/System.XML/System.Xml/ChangeLog 2005-06-22 07:50:13 UTC > (rev 46352) > +++ trunk/mcs/class/System.XML/System.Xml/ChangeLog 2005-06-22 08:12:53 UTC > (rev 46353) > @@ -1,3 +1,8 @@ > +2005-06-22 Atsushi Enomoto <[EMAIL PROTECTED]> > + > + * XmlTextReader.cs : use StringBuilder to store character values; that > + saves 40% memory for large chunk of xml. Patch by Gonzalo. > + I think this needs to be changed to make it optimal for the normal case. Gonzalo's situation is a corner case: 1 huge field in the middle of tons of stuff. However, normally, there are many, small, similarly sized fields. So what happens is that the string builder does the standard "double when there is too much data". Most strings will end up being (on average) 25% larger than they need to be. Therefore, we should do something like this: if (sb.Capacity < 100) return sb.Substring (0, sb.Length); else return sb.ToString (); That way, if the string is small, "substring" will be used. It will create a string of the exact size we want. The stringbuilder buffer can then be reused. -- Ben ___ 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-patches] r46370 - in trunk/mcs/class/corlib: System.Collections.Generic Test/System.Collections.Generic
On Wed, 2005-06-22 at 10:42 -0400, Raja R Harinath wrote: > (GetSlot): Use _hcp to compare keys. Return the slot containing > the key, rather than the index. Avoid move-to-front heuristic > when there's an enumerator coursing through the table. There are probably races here. If one thread starts enumerating, another thread reads, blah etc. IMHO, this optimization should be removed for now. -- 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] Syslog support
Hi Vorobiev, You could have a look at Indy.Sockets. There is (AFAIK) support for SysLog. There's also support for many other protocols. Greets, Matthijs - Original Message - From: Vorobiev Maksim To: mono-devel-list@lists.ximian.com Sent: Wednesday, June 22, 2005 5:35 PM Subject: [Mono-devel-list] Syslog support Good day. Is there are any possibility to work with syslog daemon from Mono without developing additional unmanaged code? I cann't find support for syslog in any Mono namaspaces. Does it exists? Thank you. ___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://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] Syslog support
Hi, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vorobiev Maksim > Sent: Wednesday, June 22, 2005 5:35 PM > > Is there are any possibility to work with syslog daemon from Mono > without developing additional unmanaged code? I cann't find support > for syslog in any Mono namaspaces. Does it exists? You can use the Syscall.syslog call from Mono.Unix. This namespace is contained in Mono.Posix.dll. Joerg. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Syslog support
Good day. Is there are any possibility to work with syslog daemon from Mono without developing additional unmanaged code? I cann't find support for syslog in any Mono namaspaces. Does it exists? Thank you. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
Altough I modified the patch several times it's on the list for 2 weeks. It does exaclty what you want. Furthermore the current Locale.cs does no localization at all. I think this patch was commented enough to can be decided what to do. So please tell me whether you want: - drop this patch - drop localization at all - or approve this patch Kornél Locale.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: System.Xml patch
Atsushi Eno wrote:
Hi Andrew,
Good catch :-) However the fix does not look correct. Your patch
also avoids entity content evaluation, that means it sometimes
results in incorrect well-formedness.
Good catch, too ;-)
How about this patch? To save iterations, I made the same check in
ResolveExternalEntityReplacementText, please tell me, if it's unnecessary.
Cheers,
Andrew Skiba.
Index: DTDReader.cs
===
--- DTDReader.cs(revision 46238)
+++ DTDReader.cs(working copy)
@@ -641,8 +641,9 @@
private void ResolveExternalEntityReplacementText
(DTDEntityBase decl)
{
if (decl.LiteralEntityValue.StartsWith ("___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Satellite Assembly
Hi, What all information is inherited from the assebly when specified in the Al.exe /template: assembly_name option. MSDN documentation says this option is used to inherit metadat from the specified assembly. What all data inherited from the specified assembly in this option? Any idea? -Sri _ Claim your space online! http://www.msn.co.in/spaces Share your world for free! ___ 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-patches] r46353 - trunk/mcs/class/System.XML/System.Xml
Oops, am sorry that was my bad that I failed to commit the first patch and it was kept uncommitted :( Atsushi Eno Andrew Skiba wrote: Atsushi Enomoto ([EMAIL PROTECTED]) wrote: Don't remove ChangeLog entry BTW. I did not remove anything from ChangeLog: svn diff -r46346:46347 A bug in Subversion? :-) Andrew. ___ 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] Re: Find Object instance that called a method..
S Umadevi wrote:
I guess I phrased my question too simplicitly...:(
Anyway I found my answer with System.Diagonistics.StackFrame.
StackFrame will not provide you the object *instance*
of the caller, just the its MethodInfo and so its class.
BTW, you're calling for big trouble because methods often
get inlined at runtime. It this case the StackFrame will
omit the method and your code will probably break.
This happens reliably on MSFT's runtime in RELEASE mode
wenn runing the code w/out a debugger attached.
I suspect that Mono behaves similar.
Rob
Thanks
uma
Micha(B³ Ziemski <[EMAIL PROTECTED]> 06/21/05 2:53 PM >>>
Hi,
Is there a mechanism to figure out the object instance that called a
method..
Ex.
class A {
public void m1()
{
//some code..
}
}
Class B {
private m2()
{
A aa = new A();
aa.m1();
}
}
From method m1 in class A is it possible for me to figure out the
object instance aa?
Use "this" keyword (I hope this is what you are asking for).
public void m1() {
this.ToString();
}
Regards!
Michal Ziemski
___
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] Re: [Mono-patches] r46353 - trunk/mcs/class/System.XML/System.Xml
Atsushi Enomoto ([EMAIL PROTECTED]) wrote: Don't remove ChangeLog entry BTW. I did not remove anything from ChangeLog: svn diff -r46346:46347 A bug in Subversion? :-) Andrew. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] BIg Problem with webservices (client)
Have you got some news about this major bug... In fact, I can't use svn mono, because it is unable to understand MS.NET assembly (***cannot load type) I can't use Mono 1.1.8 (stable) because there's problem with fileencoding... Le Vendredi 17 Juin 2005 11:44, vous avez écrit : > Can you please file a bug report in bugzilla.ximian.com for this? and > please attach the code of the web service that fails (if possible) or > the wsdl document? > > Thanks, > Lluis. > > El dv 17 de 06 del 2005 a les 11:27 +0200, en/na Hubert FONGARNAND va > > escriure: > > I've a simple Web Application which make a call to a webservice method... > > (client side) > > Since this morning, It crashes when calling the constructor of the > > webservice... > > > > the trace is here : > > I think it's a problem with XML Serialization! > > > > Hubert > > > > Server error in '/FicheClient' application > > Description: Error processing request. > > > > Error Message: HTTP 500. > > > > Stack Trace: > > > > System.ArgumentNullException: Argument cannot be null. > > Parameter name: type > > in <0x00291> > > System.Xml.Serialization.XmlReflectionImporter:ImportTypeMapping > > (System.Type type, System.Xml.Serialization.XmlRootAttribute root, > > System.String defaultNamespace) > > in <0x0008e> > > System.Xml.Serialization.XmlReflectionImporter:ImportIncludedTypes > > (System.Type type, System.String defaultNamespace) > > in <0x0062e> > > System.Xml.Serialization.XmlReflectionImporter:ImportClassMapping > > (System.Type type, System.Xml.Serialization.XmlRootAttribute root, > > System.String defaultNamespace) > > in <0x00268> > > System.Xml.Serialization.XmlReflectionImporter:ImportClassMapping > > (System.Type type, System.Xml.Serialization.XmlRootAttribute root, > > System.String defaultNamespace) > > in <0x00094> > > System.Xml.Serialization.XmlReflectionImporter:ImportTypeMapping > > (System.Type type, System.Xml.Serialization.XmlRootAttribute root, > > System.String defaultNamespace) > > in <0x0073e> > > System.Xml.Serialization.XmlReflectionImporter:ImportListMapping > > (System.Type type, System.Xml.Serialization.XmlRootAttribute root, > > System.String defaultNamespace, System.Xml.Serialization.XmlAttributes > > atts, Int32 nestingLevel) > > in <0x008e7> > > System.Xml.Serialization.XmlReflectionImporter:CreateMapMember > > (System.Type declaringType, System.Xml.Serialization.XmlReflectionMember > > rmember, System.String defaultNamespace) > > in <0x00070> > > System.Xml.Serialization.XmlReflectionImporter:ImportMembersMapping > > (System.String elementName, System.String ns, > > System.Xml.Serialization.XmlReflectionMember[] members, Boolean > > hasWrapperElement) > > in <0x0062e> System.Web.Services.Protocols.SoapMethodStubInfo:.ctor > > (System.Web.Services.Protocols.TypeStubInfo typeStub, > > System.Web.Services.Protocols.LogicalMethodInfo source, System.Object > > kind, System.Xml.Serialization.XmlReflectionImporter xmlImporter, > > System.Xml.Serialization.SoapReflectionImporter soapImporter) > > in <0x000c6> > > System.Web.Services.Protocols.SoapTypeStubInfo:CreateMethodStubInfo > > (System.Web.Services.Protocols.TypeStubInfo parent, > > System.Web.Services.Protocols.LogicalMethodInfo lmi, Boolean > > isClientProxy) in <0x0010d> > > System.Web.Services.Protocols.TypeStubInfo:BuildTypeMethods () in > > <0x00014> System.Web.Services.Protocols.TypeStubInfo:Initialize () in > > <0x00068> > > System.Web.Services.Protocols.LogicalTypeInfo:CreateTypeStubInfo > > (System.Type type) > > in <0x0005f> System.Web.Services.Protocols.LogicalTypeInfo:GetTypeStub > > (System.String protocolName) > > in <0x0001d> System.Web.Services.Protocols.TypeStubManager:GetTypeStub > > (System.Type t, System.String protocolName) > > in <0x00025> System.Web.Services.Protocols.SoapHttpClientProtocol:.ctor > > () in <0x00012> FicheClient.ADServices.ADWS:.ctor () > > in (wrapper remoting-invoke-with-check) FicheClient.ADServices.ADWS:.ctor > > () in <0x000d5> FicheClient.Logon:btnValider_Click (System.Object sender, > > System.EventArgs e) > > in (wrapper delegate-invoke) > > System.MulticastDelegate:invoke_void_object_EventArgs > > (object,System.EventArgs) > > in <0x0006e> System.Web.UI.WebControls.Button:OnClick (System.EventArgs > > e) in <0x00040> > > System.Web.UI.WebControls.Button:System.Web.UI.IPostBackEventHandler.Rais > >ePostBackEvent (System.String eventArgument) > > in <0x00016> System.Web.UI.Page:RaisePostBackEvent (IPostBackEventHandler > > sourceControl, System.String eventArgument) > > in <0x00033> System.Web.UI.Page:RaisePostBackEvents () > > in <0x00238> System.Web.UI.Page:InternalProcessRequest () > > in <0x000a6> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext > > context) > > in <0x00233> System.Web.HttpApplication+ExecuteHandlerState:Execute () > > in <0x0007c> System.Web.HttpApplication+StateMachine:ExecuteState > > (IStateHandler state, System.Boolean readysync) > > > > ___ > > Ce
