[Mono-dev] Behavior question / possible patch for NameValueCollection

Hello all,

In the process of tracking down an XSP crash I ran into what I *think*
is a misbehavior in the current implementation of NameValueCollection.
>From my reading of the MSDN documentation, if you Add ("foo", null) to a
collection, the null value should get stored. The attached simple patch
does that. However the documentation doesn't elsewhere saw how nulls are
treated -- eg, what do they become when stringifying, equivalent to ""?

If people think this patch has the right idea, I guess I'll make some
test cases (I haven't checked if the rest of the implementation can
handle stored nulls gracefully; probably not.) If not, then the
Add(NameValueFollection) implementation needs to be fixed to handle the
empty ArrayLists that Add("foo",null) can leave behind ...

Peter

--

-- 
Peter Williams / peter <at> newton.cx

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono.Cairo add Cairo.Surface.WriteToPng

>         Another small patch for Mono.Cairo to write a surface to a png along

Thank you. In SVN.

--

-- 
Hisham Mardam Bey
MSc (Computer Science)
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)

[Mono-dev] ** ERROR **: file exceptions-ia64.c:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [Patch] AssemblyName ctor (with corrections)

Last time I sent my AssemblyName ctor, Paolo addressed some important
points. I read the docs about the blob and I made the changes contained
in the attached patch.

Maybe the most important thing to review is the parse_public_key ()
function, which parses the public key char itself. Sebastien, could you
review that this section is ok?

Comments welcome,
Carlos.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] __ComObject should not be public

Hi,

I've done some research on .NET Framework versions 1.0, 1.1 and 2.0 Beta 2
and all of the Service Packs of them. System.__ComObject is internal in all
of them and I don't think it was public is any beta version after 1.0 was
released. If it was listed in mscorlib.xml it was a bug in the program that
generated mscorlib.xml.

I decided not to remove __ComObject as it is referenced in .NET Framework
SDK documentation so many times that the type itself may be used by
developers so it's better to preserve it. And if we ever want to implement
COM interop we have to use this type.

I committed a modified version that is internal and I added some comments
about the class.

Kornél

----- Original Message -----
From: "Sebastien Pouliot" <sebastien.pouliot <at> gmail.com>
To: "Kornél Pál" <kornelpal <at> hotmail.com>
Cc: <mono-devel-list <at> lists.ximian.com>
Sent: Wednesday, August 31, 2005 1:29 PM
Subject: Re: [Mono-dev] __ComObject should not be public

> On Wed, 2005-31-08 at 12:55 +0200, Kornél Pál wrote:
>> We have a public __ComObject in mscorlib. This is wrong. MS.NET has a
>> __ComObject but it's internal. If there is some reason to have Mono a
>> __ComObject as well we should mark it as internal.
>
> IIRC (have a look at the ChangeLog) it wasn't possible to compile
> __ComObject to "please" corcompare in every case (CLS compliance issue).
>
>> Do we need __ComObject?
>
> If it was (*) internal then it was added because something "needed" it
> (probably the status page as nothing, source wise, seems to depends on
> it right now).
>
> (*) That was prior to 1.1 SP1. Right now I can't find it in mscorlib.xml
> masterinfos (both 1.1 SP1 and 2.0 beta2).
>
> If this fixes the class status (extra) and doesn't change the tests
> results then please feel free to remove this file from the builds.
>
> Thanks
> --
> Sebastien
>
>

Re: [Mono-dev] C++ to C# to C++ interop, how can I do this in a mono-compliant way?

Hi,

> The C++ engine itself is OS agnostic (it works on windows, linux and
> mac), and I would love to make this C# wrapper work under mono, so
> that it is OS agnostic as well.

Prior to adding the managed C++, it would be platform agnostic. With the
managed stuff in there, not a chance.

> Is there any way to have this work under Mono?   Please realize that
> the basic need is to have 1 instance of a C++ exe call into a .NET
> dll, and have that DLL be able to then execute functions in the C++
> exe that called it.     So this requires a mono-equivlant of PInvoke,
> plus a way to have the C++ app call the C# app. 

Simplest way is to sit on top of the engine and catch the calls in and
out (basically, provide an interface layer). As to getting that to work
I've not a clue.

Calling the other apps from C++ is simple enough. The only caveat is
knowing what platform you're using. If you're on a non-MS platform, find
is mono is there, if it is then just use system("mono cpp.exe). For
Win32, these should have the .NET framework already tacked on, so see if
it does, then system ("cpp.exe") otherwise find mono (as above) or else
fail.

I'm not sure how you'd go the other way.

TTFN

Paul
--

-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who

[PATCH] Searching for Monodoc

Hey,

  A patch that I promised to send some time ago. The patch would
require that you download my own stripped version of Lucene from
here[1]. That version is just the Lucene you can download from
http://www.dotlucene.net/ but modified to be in a Monodoc.Lucene...
namespace, which let us keep monodoc.dll in the GAC without breaking
the Golden Rules [2].
 The process to make the index is similar to the actual index. The
important method is PopulateSearchableIndex which fills
SearchableDocuments that are added to the Lucene index. It is
implemented for the ecmaspec and the ecma providers.
 The SearchableDocuments have 5 fields:
- title: nice title to show to the user
- url: to retrieve the node later
- hottext: the most important bits in this node
- text: a big piece of text
- examples: the code examples found
The ones used for searching are the last 3 in the following order of
importance: hottext > text > examples.

 The important missing things  are:
- The modifications made by the user aren't added to the index
- Nodes added with the --edit parameter won't be searchable either
- Right now, the whole Lucene is compiled in monodoc. Will it be
better a lighter version of Lucene?

Comments please!

[1] http://personales.ya.com/msopena/Monodoc.Lucene.Net.tar.gz
[2] http://www.mono-project.com/Assemblies_and_the_GAC

_______________________________________________
Mono-docs-list maillist  -  Mono-docs-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-docs-list

RE: [Mono-dev] C++ to C# to C++ interop, how can I do this in a mono-compliant way?

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

RE: [Mono-dev] Type.GetType inside of dynamic assembly

I had a bug in my code. I've fixed it and everything works as expected now. Sorry for the false bug.
 
- Jon

	-----Original Message----- 
	From: mono-devel-list-bounces <at> lists.ximian.com on behalf of Robert Jordan 
	Sent: Wed 8/31/2005 4:32 AM 
	To: mono-devel-list <at> lists.ximian.com 
	Cc: 
	Subject: Re: [Mono-dev] Type.GetType inside of dynamic assembly
	
	

	Hi Jon,
	
	>       Might be a simple question, but I'll ask anyway. I have a small
	> program that calls Type.GetType("MyType, MyAssembly"). This works fine.
	> The program references "MyAssembly" at compile time.
	>       I also reference another assembly (say "MyAssembly2") in the
	> executable. MyAssembly2 doesn't reference MyAssembly. I pass the string
	> "MyType, MyAssembly" to a method in MyAssembly2 that calls
	> Type.GetType() with the string. This call fails.
	>       This all works on Windows under MS.Net, and I'm wondering what I
	> need to do differently on Linux with Mono. All files are in the same
	> directory.
	
	Since Linux file systems are usually case sensitive, the name
	of the assembly must match the file system name.
	Are you sure your assembly has exactly the file name "MyAssembly2.dll"?
	
	Rob.
	
	_______________________________________________
	Mono-devel-list mailing list
	Mono-devel-list <at> lists.ximian.com
	http://lists.ximian.com/mailman/listinfo/mono-devel-list

	

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono.Cairo add Cairo.Surface.WriteToPng

Hey,
Miguel de Icaza wrote:

>Hello,
>
>  
>
>>	Another small patch for Mono.Cairo to write a surface to a png along
>>with an example to test it with.
>>    
>>
>
>Could you provide documentation as well?
>
>  
>
I added docs to monodoc for this method.