Peter Williams | 1 Sep 07:49 2005

[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

Attachment (nvc.diff): text/x-patch, 1180 bytes
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Hisham Mardam Bey | 1 Sep 10:26 2005
Picon

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)
Kevin | 1 Sep 10:06 2005
Picon

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


Jonathan, thanks for the tip on monolite.
I should have read more of the README myself.

I am now facing an assertion problem and was wondering whether anyone came across the following?


** ERROR **: file exceptions-ia64.c: line 581 (mono_arch_handle_exception): assertion failed: (res >= 0)
aborting...
make[7]: *** [../class/lib/net_1_1_bootstrap/mcs.exe] Aborted
make[7]: Leaving directory `/home/veragoo/mono/mcs/mcs'
make[6]: *** [do-all] Error 2
make[6]: Leaving directory `/home/veragoo/mono/mcs/mcs'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory `/home/veragoo/mono/mcs'
make[4]: *** [profile-do--net_1_1_bootstrap--all] Error 2
make[4]: Leaving directory `/home/veragoo/mono/mcs'
make[3]: *** [profiles-do--all] Error 2
make[3]: Leaving directory `/home/veragoo/mono/mcs'
make[2]: *** [all-local] Error 1
make[2]: Leaving directory `/home/veragoo/mono/mono/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/veragoo/mono/mono'
make: *** [all] Error 2

-----------------------
Thanks
Kevin






On 8/26/05, Jonathan S. Chambers <Jonathan.Chambers <at> ansys.com > wrote:
Did you get monolite; i.e. 'make get-monolite-latest'?

- Jonathan


-----Original Message-----
From:   mono-devel-list-bounces <at> lists.ximian.com on behalf of Kevin
Sent:   Thu 8/25/2005 8:57 PM
To:     mono-devel-list <at> lists.ximian.com
Cc:
Subject:        [Mono-dev] mono on IA64 - help compiling
Hello all,

I have tried to compile mono on one of the Itanium2 machines at work, but at
some point it asks for an existing mcs compiler. I am not sure how to solve
this, as i am guessing that installing the binaries won't work there, or
will they?

Could anyone please advise.

PS: I have pasted the error below.

Thanks in advance
Kevin

------------------------------ ------------START
ERROR---------------------------------------------------
make[3]: Entering directory `/home/veragoo/mono/mcs'
make profile-do--default--all profile-do--net_2_0--all
make[4]: Entering directory `/home/veragoo/mono/mcs'
make PROFILE=basic all
make[5]: Entering directory `/home/veragoo/mono/mcs'
*** The compiler 'mcs' doesn't appear to be usable.
*** You need a C# compiler installed to build MCS (make sure mcs works from
the command line)
*** Read INSTALL.txt for information on how to bootstrap a Mono
installation.
make[5]: *** [do-profile-check] Error 1
make[5]: Leaving directory `/home/veragoo/mono/mcs'
make[4]: *** [profile-do--basic--all] Error 2
make[4]: Leaving directory `/home/veragoo/mono/mcs'
make[3]: *** [profiles-do--all] Error 2
make[3]: Leaving directory `/home/veragoo/mono/mcs'
make[2]: *** [all-local] Error 1
make[2]: Leaving directory `/home/veragoo/mono/mono/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/veragoo/mono/mono'
make: *** [all] Error 2
------------------------------------------------END
ERROR------------------------------------------


--
Cheers,
Kevin ( http://www. )
Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of
this entire article are permitted worldwide without royalty in any medium
provided this notice is preserved.



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



--
Cheers,
Kevin          ( http://www.  )
Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved.


--
Cheers,
Kevin          ( http://www.  )
Copyright 2005 Kevin Parama Veragoo. Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Carlos Alberto Cortez | 1 Sep 09:41 2005
Picon

[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.
Attachment (AssemblyName.cs.diff): text/x-patch, 1255 bytes
Attachment (metadata.diff): text/x-patch, 8 KiB
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Kornél Pál | 1 Sep 16:31 2005
Picon

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
>
>
Paul F. Johnson | 1 Sep 10:18 2005
Picon

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
Mario Sopena | 1 Sep 11:17 2005
Picon

[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
Attachment (search.tar.gz): application/x-gzip, 11 KiB
_______________________________________________
Mono-docs-list maillist  -  Mono-docs-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-docs-list
Ring, Kevin | 1 Sep 16:39 2005

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

Hi Jason,

 

I have a similar situation, except that I’m planning to address it on Windows using COM interop rather than mixed-mode C++.  I posted to this list last week asking for advice on how to best do something similar with Mono.

 

Jonathan Pryor pointed me to the Mono embedding API (http://www.mono-project.com/Embedding_Mono), which can probably be used to do exactly what you want.  The page describes a way to call managed methods from C and also to call back into C from the managed world.  It is quite a bit clunkier than either mixed-mode C++ or COM interop, though.  He also pointed me to a Mono utility called cilc which can be used to generate C wrappers for the classes and methods in an assembly, which helps with some of the clunkyness.  Eventually I’d like to extend cilc to generate full C++ wrappers, complete with marshalling between CLR and C++ types, to create something a lot like COM interop for Mono.  Even better, I’d like to arrange for my company to pay an interested person to create something like this, as it is pretty far outside of our core area of expertise.

 

Some other folks had some interesting suggestions as well.  Check the August archives of this list for a thread called “COM Interop, or something like it”.

 

Hope this helps!

Kevin Ring

 

 

From: mono-devel-list-bounces <at> lists.ximian.com [mailto:mono-devel-list-bounces <at> lists.ximian.com] On Behalf Of J
Sent: Monday, August 29, 2005 7:02 PM
To: mono-devel-list <at> lists.ximian.com
Subject: [Mono-dev] C++ to C# to C++ interop,how can I do this in a mono-compliant way?

 

Hello,

 

I am looking for a way of having a C++ exe integrate with a .NET dll.  I have a solution working under Windows (Microsoft.NET 1.1) however I would like to make this function under Mono.

 

Here are the details:

 

I currently am writing a C# wrapper of a C++ game engine.  (T2D by garagegames)  I wrote this on Windows (CLR v1.1) and the main way this works is by adding Managed code to the C++ engine (so now it is mixed Managed/Unmanaged C++) so it can directly call into my C# DLL, and using PInvoke to have the C# DLL talk balk to the C++ engine.

 

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.

 

However, http://www.go-mono.com/faq.html#63  informs me that Mixed mode assemblies do not work under mono.

 

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. 

 

Help on this would be appreciated, otherwise it'll be Windows only!

 

-Jason

__________________________________________________
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 <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Jonathan S. Chambers | 1 Sep 20:00 2005

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
John Luke | 1 Sep 20:23 2005
Picon

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.

Gmane