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] How to handle huge string collation resources?
Hi, 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. They are not only 200KB tables (that number is just for CJK support which is rarely required) but about 500KB as a whole. 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... Well, I need more clarification for them. - For standard collation support (numbers are in length): - byte[] : 153360. - int[] : 13552. - some extent of additional byte[] : maybe less than 5000 - for CJK support which is rarely used: - ushort[] : 2 * 3 + 3 - byte[] : 2 - for String.Normalize() which is only for .NET 2.0: - byte[] : 3 - int[] : 2700 - short[] : 17600 - maybe additional int[] : 4000 So, they are mostly byte for collation, except for CJK support which is not referenced unless we use CompareInfo methods from CJK cultures. So I think managed resources won't be bad here. For String Normalization related stuff, I still think it would be better to have them in mscorlib.dll since they are unused in the default profile. 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. I agree. 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. Ok, then right now I need to hack on corlib Makefile to run make under Mono.Globalization.Unicode. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
I believe the answer is no, you have to install Mozilla. Martin On 6/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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 -- Martin Hinks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Patch for standardizing Mainsoft DataSetTest tests for System.Data
Eyal Alaluf wrote: Hi, all. The attached patch replaces the Mainsoft System.Data.DataSet tests with a standardized Mono tests style test - collecting a lot of separate per-method test classes into one test class that tests DataSet. One issue that I'd like to mention is that I used as namespace 'MonoTests_System.Data' rather then 'MonoTests.System.Data' for the test. The reason is that ptherwise code like the following: System.Text.StringBuilder resultXML = new System.Text.StringBuilder(); does not compile. It gives the error Test\System.Data\DataSetTest2.cs(350,11): error CS0234: The type or namespace name 'Text' does not exist in the class or namespace 'MonoTests.System' (are you missing an assembly reference?) The problem is that the compiler interprets the use of 'System' as MonoTests.System and not as the root 'System'. I consider adding a using directive and not using a full scope as a workaround to the problem and not a solution. IMO, using is the right solution as we have not used full scoped classes anywhere in other tests. StringBuilder resultXML = new StringBuilder(); is simpler than full scoped one. Apart from that, feel free to commit. suresh. ___ 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
From: Miguel de Icaza
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 ();
}
}
}
The actual code:
private static ResourceManager GetResourceManager ()
{
if (resources == null)
lock (resourcesLock) {
if (resources == null)
resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName
().Name, typeof (Locale).Assembly);
}
return resources;
}
I think this is good, because it is intended to initialize resources only
once. I did not wanted to use static constructor because of the thing
explained in the source code. (I don't want any TypeInitializationException,
and it even could not be catched by SafeGetText) If resources is already
initialized it does not lock at all that results in faster execution. But
the second check is required because when two threads are waiting to acrique
resourcesLock one of the will initialize resources while the other should
not replace the existing one.
If you still think that this is a race prone, please tell me why because I
don't know the reason.
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.
The ResourceManager does not load anything at the time of construction. It
loads ResourceSets when they are needed by a GetString or GetObject call.
Furthermore it falls back to InvariantCulture whose ResourceSet is
GetTextResourceSet that simply retrurns the string passed as argument and
uses no Hashtable to cache string resources. It's better to use a custom
ResourceSet because this let us to take advantage all the features of
ResourceManager.
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).
I agree with Ben that string are localized only several time and the little
performance overhead caused by localization can be ignored. (The overhead
should be little.)
And also note that currently there will be little difference because there
are no other languages just English that is in the code of assemblies so not
caching will be done. MWF uses object resources as well but it will not
result in overhead because it currently uses the same ResourceManager and
ResourceSet that will be used by this Locale.cs.
And as I told several times in this topic the current ResourceSet is not
efficient. ResourceManager of MS.NET uses a custom resource set called
RuntimeResourceSet (private type, ResourceSet of MS.NET does the same as
Mono's one) that loads each resource (either string or object) when it is
needed instead of loading all of them at construction. It caches resource
once they was loaded. This could be used in Mono as well or if we want we
could use a ResourceSet that does no caching at all. But the advantages and
disadvantages of using no cache should be compared in real life before
making a decission.
Note that the above problem will not cause any CPU or memory overhead yet
because we have only English texts yet without .resources files.
Am starting to understand your point of view on the translation
technique, and it might be worth switching to the key/string translation
scheme.
It's good.:) By the way, the most important thing: key/string technique will
have the same performance and memory requirements if you use the same
ResourceManager and ResourceSet classes. The only difference will be that it
will look up even English resources in a file that means some performance
overhead but I think it's so little that it can be ignored.
The problem of resource caching is the same for both techniques: If you
cache resources they will be faster to retrieve the next time but will need
memory to cache them. And of course neither of these techniques require
caching at all.
And of course ResourceManager can use both techniques. Andreas Nahr was
talking about a custom infrastructure instead of ResourceManager but I think
it's useless to use different resource format because .resources files are
efficient.
The most important difference is that while identifiers are permanent
English texts may change that requires new satellite assemblies for all of
the languages altough the texts of the other languages are not changed.
From: Ben Maurer
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.
This is required to can use the same name for .resources file as the
assembly has. If you have a better code please let me know. By the way this
is called only once so I think if it has no critical drawbacks it's not a
big problem.
Kornél
___
Mono-devel-list
Re: [Fwd: Re: [Mono-devel-list] System.Data.DataSet.ReadXml reimplementation]
Hi Eno,
I made the changes we talked about, bt it turns out they probably won't
make a big diff (see attached patch)
The problem is that I have to collect almost always:
XmlReadMode.InferSchema: in order to be able to skip if schema is found.
XmlReadMode.Auto: as I don't know what's gonna be.
XmlReadMode.DiffGram: wait for diffgram - very uncommon case, but have a
test (MonoTests.System.Data.DataSetTest.ReadWriteXmlDiffGram).
XmlReadMode.IgnoreSchema: to be able to ignore the schema if it's found.
From the other side in most cases the schema or diffgram element will
be as root or its child, so nothing would be collected anyway.
Regards,
Konstantin Triger
Atsushi Eno wrote:
Hello Konstantin,
Konstantin Triger wrote:
Hi Eno,
I committed the code before I saw your comments on Boris email.
Actually I missed it at all and Boris forwarded it to me. In any case
I didn't want to ignore it and would like, with your help, create the
best implementation possible.
The new implementation solves some bugs, little bit cleaner as it
does not have gotos, but performs worse. I think that with a very
small effort it can perform better. I really need your help to make
this change safe.
Can you please give your opinion on an assumption that right after
the schema must reside data? If you agree, with a small change I can
make a real perf improvement and we will have a really better
implementation.
I don't think you could quote my post without seeing it. Anyways,
Am not seeing what you see. Maybe it would be the best if you
post testcases that shows why the patch is required. Next, the
patch has several changes in one file. There are things that could
be justified and that might not be. They do not look tied
together, so it is better if they are split.
Without them I don't think any of discussions can go efficiently.
Depending on the testcases that performant way might not be
possible. As long as I know MS.NET implementation is so cheap
that always reads document into DOM or something.
If XML schema is the document root, then there is no data content.
Existing implementation did handle content schema (at least it was
designed to do that) as long as it is the top-level content of the
document element. I am not aware of practical cases that such
schemas in further depth are consumed (since 99.999% of .NET
DataSet users is not likely to have such documents).
Atsushi Eno
Index: System.Data/DataSet.cs
===
--- System.Data/DataSet.cs (revision 46217)
+++ System.Data/DataSet.cs (working copy)
@@ -1023,9 +1023,17 @@
continue;
}
- //collect data
- XmlNode n = doc.ReadNode(reader);
- root.AppendChild(n);
+ if (mode == XmlReadMode.InferSchema ||
+ mode == XmlReadMode.Auto ||
+ mode == XmlReadMode.DiffGram ||
+ mode == XmlReadMode.IgnoreSchema) {
+ //collect data
+ XmlNode n = doc.ReadNode(reader);
+ root.AppendChild(n);
+ continue;
+ }
+
+ XmlDataReader.ReadXml (this, reader, mode);
}
if (reader.NodeType == XmlNodeType.EndElement)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Character encoding problem
I have an issue with accentued characters encoding (in french) in APS.NET I've a little VS 2003 Project attached ... With MS.NET the result is : Label Dynamique : accent aigu : é accent grâve è Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR With mono, i get : Label Dynamique : accent aigu : é accent grâve èglobalization requestEncoding=utf-8 responseEncoding=utf-8 fileEncoding=iso-8859-1 / Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR In my web.config I specify : globalization requestEncoding=utf-8 responseEncoding=utf-8 fileEncoding=iso-8859-1 culture=fr-FR / Apparently : i get problems only with accent in aspx pages. The dynamically generated accents are correctly encoded in utf-8. It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly Thank ___ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. testaccents.tar.gz Description: application/tgz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[mono-devel-list] Patch to standardize Mainsoft DataSet tests
Hi, all. Attched is a patch (gzipped so it won't be too big) that collects the various data set tests from Mainsoft (we had one test class per method) into one test class. One issue I'd like to mention is that I used 'MonoTests_System.Data' namespace instead of 'MonoTests.System.Data' since when using code like: System.Text.StringBuilder resultXML = new System.Text.StringBuilder(); I get the following error: Test\System.Data\DataSetTest2.cs(350,11): error CS0234: The type or namespace name 'Text' does not exist in the class or namespace 'MonoTests.System' (are you missing an assembly reference?) The problem is that the compiler understands 'System' as 'MonoTests.System'. Trying 'MonoTests.System_Data' didn't work either since it was enough that once file uses 'MonoTests.System.Data' to cause the error. I consider removing the full scope usage and adding a 'using' directive as a workaround, since this problem can happen to any test developer. Any coments are welcome. I'd like move ahead as soon as possible since I'd like to standradize the other disconnected tests we contributed. Eyal. patch.diff.gz Description: Binary data ___ 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 11:18 +0200, Kornél Pál wrote:
private static ResourceManager GetResourceManager ()
{
if (resources == null)
lock (resourcesLock) {
if (resources == null)
resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName
().Name, typeof (Locale).Assembly);
}
return resources;
}
I think this is good, because it is intended to initialize resources only
once.
It looks good. It acts good. It isn't good.
See:
http://galactus.ximian.com/pipermail/mono-devel-list/2004-February/004101.html
http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx
In short, it will work correctlyon x86. *Maybe* on other
processors. But it won't work *everywhere*. The problem is that the
memory model that the CLI defines has looser semantics than x86
provides, so you can't actually hit the race condition on x86, but it
will exist on Itanium (I think).
Where's the race? It's between the processor, cache, and main memory on
a multi-CPU machine. Dragons be there; be afraid. :-)
There are four solutions:
- Make `resources' `volatile', which disables any caching the
processor might do. This effectively makes reads writes
a memory barrier operation, slowing things down
- Always acquire a lock before reading `resources' -- also
slow, due to the locking required.
- If it's safe to create multiple instances of
GetTextResourceManager, you could use an
Interlocked.CompareExchange to set `resource' for lock-free
thread-safe code. See:
http://mono.myrealbox.com/source/trunk/mcs/class/System/System.Diagnostics/TraceImpl.cs
And search for `#if !NO_LOCK_FREE' for an example.
- Place `resource' into a different class and use a static
constructor. GetResourceManager can then catch for the
TypeInitializationException and provide fallback behavior.
Personally, I'd go for the static constructor, as it's easier to get
right. I think the Interlocked.CompareExchange code is correct (I wrote
it), but I'm no lock-free expert, so there may be issues with it (but I
did sleep at a Holiday Inn last night. :-)
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] C# Threading : libgcc_s.so.1 must be installed for pthread_cancel to work
Hi,We have mono 1.1.7 installed on Redhat Linux version
9.0. We have implemented a basic threading code in C#. The code is attached at
the end of the mail.The output of the code is as follows:The
Main() thread calls this after starting the new InstanceCaller thread.The
Main () thread calls this after starting the new StaticCaller threads.You
are Back in InstanceMethod.Running on Thread Alibgcc_s.so.1 must be
installed for pthread_cancel to workWe get an error something related to
pthread_cancel.We wrote a sample code in C which invokes pthread_cancel.
The program works fine.We have the following under our PATH and
LD_LIBRARY_PATH
respectively/usr/bin:/usr/bin:/usr/bin:/usr/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/lib:/usr/lib:..:/usr/tibco/tibrv/lib:/lib:/usr/libwe
have libgcc_s.so.1 already installed.Please suggest us what we need to
do.Best RegardsPrashanth
Kalvala---Thread.cs---using
System;using System.Threading;namespace
Test{ public class
Simple
{
// The method that will be called
when the thread is started.
public void
InstanceMethod()
{
try
{
// Pause for a moment to provide a
delay to make threads more
apparent.
Thread.
Sleep(3000);
Console.WriteLine ("You are Back in
InstanceMethod.Running on Thread
A");
}
catch(Exception
ex)
{
Console.WriteLine
("asdasdadasd");
}
}
public static void
StaticMethod()
{
Console.WriteLine("You are in
StaticMethod. Running on Thread
B.");
// Pause for a moment to provide a
delay to make threads more
apparent.
Console.WriteLine("Thread B Going to
Sleep Zzzz");
Thread.Sleep(5000);
Console.WriteLine("You are back in
static method. Running on Thread
B");
}
public void
Run()
{
// Create the thread object, passing
in the
// serverObject.InstanceMethod method
using a ThreadStart delegate.
Thread InstanceCaller = new
Thread(new
ThreadStart(InstanceMethod));
// Start the
thread.
InstanceCaller.Start();
Console.WriteLine("The Main() thread
calls this " + "after starting the new InstanceCaller
thread.");
}
public static int Main(String[]
args)
{
Console.WriteLine ("Thread Simple
Sample");
new
Simple().Run();
// Create the thread object, passing
in the
// serverObject.StaticMethod method
using a ThreadStart delegate.
//Thread StaticCaller = new
Thread(new
ThreadStart(ServerClass.StaticMethod));
// Start the
thread.
//StaticCaller.Start();
Console.WriteLine("The Main () thread
calls this " + "after starting the new StaticCaller
threads.");
return
0;
} }}
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
___
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
Hi all, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Pryor There are four solutions: - Make `resources' `volatile', which disables any caching the processor might do. This effectively makes reads writes a memory barrier operation, slowing things down - Always acquire a lock before reading `resources' -- also slow, due to the locking required. - If it's safe to create multiple instances of GetTextResourceManager, you could use an Interlocked.CompareExchange to set `resource' for lock-free thread-safe code. See: http://mono.myrealbox.com/source/trunk/mcs/class/System/System .Diagnostics/TraceImpl.cs And search for `#if !NO_LOCK_FREE' for an example. - Place `resource' into a different class and use a static constructor. GetResourceManager can then catch for the TypeInitializationException and provide fallback behavior. How about using Thread.MemoryBarrier how it's been suggested in Brad Abrams' blog: http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx Is this supposed to work on Mono? Joerg. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Character encoding problem
On Thu, 2005-06-23 at 13:06 +0200, Hubert FONGARNAND wrote: I have an issue with accentued characters encoding (in french) in APS.NET I've a little VS 2003 Project attached ... With MS.NET the result is : Label Dynamique : accent aigu : é accent grâve è Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR [...] Apparently : i get problems only with accent in aspx pages. The dynamically generated accents are correctly encoded in utf-8. It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly It was a regression in CodeDom. Before June 11th, it used Encoding.UTF8 when writing its temporary files, but a patch that day removed the encoding accidentally. It's fixed in svn now. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Windows shares and FileStream
Hi, Does the FileStream class support file shares of this type \\computer\share\file. I think not? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] configure.in patch
Continuing on with x86 Darwin work; any major objections to this: Index: configure.in === --- configure.in(revision 46409) +++ configure.in(working copy) @@ -1524,7 +1524,7 @@ libsuffix=.so case $host in - powerpc-*-darwin*) + *-*-darwin*) libsuffix=.dylib LIBC=libc.dylib INTL=libintl.dylib -kangaroo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
Hi No it is not possible to use firefox, firefox is compiled in static mode, and gecko-sharp needs a shared compiled mode. Witch mozilla is. /Mikkel I think there is a way. Just set MOZILLA_FIVE_HOME environment variable to path where you have Firefox. Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): I believe the answer is no, you have to install Mozilla. Martin On 6/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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 ___ 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] Character encoding problem
Le Jeudi 23 Juin 2005 15:07, Gonzalo Paniagua Javier a écrit : On Thu, 2005-06-23 at 13:06 +0200, Hubert FONGARNAND wrote: I have an issue with accentued characters encoding (in french) in APS.NET I've a little VS 2003 Project attached ... With MS.NET the result is : Label Dynamique : accent aigu : é accent grâve è Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR [...] Apparently : i get problems only with accent in aspx pages. The dynamically generated accents are correctly encoded in utf-8. It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly It was a regression in CodeDom. Before June 11th, it used Encoding.UTF8 when writing its temporary files, but a patch that day removed the encoding accidentally. It's fixed in svn now. Ok there's no more problems for labels... but, I'm sorry but this bug is not yet closed... Maybe it's another problem but... I'm working for DropDownList in ASP.NET On MS.NET the compiled html is : select name=DropDownList1 id=DropDownList1 style=Z-INDEX: 102; LEFT: 40px; POSITION: absolute; TOP: 112px option value=Accent aigu : éAccent aigu : #233;/option option value=Accent grâve : èAccent gr#226;ve : #232;/option /select On Mono the compiled html is : select name=DropDownList1 id=DropDownList1 style=height:24px;width:280px;Z-INDEX: 102; LEFT: 40px; POSITION: absolute; TOP: 112pxoption value=Accent aigu : #64769;Accent aigu : #64769;/option option value=Accent gr#64762;ve : #64768;Accent gr#64762;ve : #64768;/option /select There's two problems in fact: the html encoding is bad and the value parameter is bad encoded... See my attachment -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Ce message et les �ventuels documents joints peuvent contenir des informations confidentielles. Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce message non conforme � sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour responsable de son contenu. testaccents.tar.gz Description: application/tgz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Fwd: Re: [Fwd: Re: [Mono-devel-list] System.Data.DataSet.ReadXml reimplementation]]
Hi Eno,
I don't see it in mailing list so resending.
I made the changes we talked about, bt it turns out they probably won't
make a big diff (see attached patch)
The problem is that I have to collect almost always:
XmlReadMode.InferSchema: in order to be able to skip if schema is found.
XmlReadMode.Auto: as I don't know what's gonna be.
XmlReadMode.DiffGram: wait for diffgram - very uncommon case, but have a
test (MonoTests.System.Data.DataSetTest.ReadWriteXmlDiffGram).
XmlReadMode.IgnoreSchema: to be able to ignore the schema if it's found.
From the other side in most cases the schema or diffgram element will
be as root or its child, so nothing would be collected anyway.
Regards,
Konstantin Triger
Atsushi Eno wrote:
Hello Konstantin,
Konstantin Triger wrote:
Hi Eno,
I committed the code before I saw your comments on Boris email.
Actually I missed it at all and Boris forwarded it to me. In any case
I didn't want to ignore it and would like, with your help, create the
best implementation possible.
The new implementation solves some bugs, little bit cleaner as it
does not have gotos, but performs worse. I think that with a very
small effort it can perform better. I really need your help to make
this change safe.
Can you please give your opinion on an assumption that right after
the schema must reside data? If you agree, with a small change I can
make a real perf improvement and we will have a really better
implementation.
I don't think you could quote my post without seeing it. Anyways,
Am not seeing what you see. Maybe it would be the best if you
post testcases that shows why the patch is required. Next, the
patch has several changes in one file. There are things that could
be justified and that might not be. They do not look tied
together, so it is better if they are split.
Without them I don't think any of discussions can go efficiently.
Depending on the testcases that performant way might not be
possible. As long as I know MS.NET implementation is so cheap
that always reads document into DOM or something.
If XML schema is the document root, then there is no data content.
Existing implementation did handle content schema (at least it was
designed to do that) as long as it is the top-level content of the
document element. I am not aware of practical cases that such
schemas in further depth are consumed (since 99.999% of .NET
DataSet users is not likely to have such documents).
Atsushi Eno
--
Regards,
Konstantin Triger
Index: System.Data/DataSet.cs
===
--- System.Data/DataSet.cs (revision 46217)
+++ System.Data/DataSet.cs (working copy)
@@ -1023,9 +1023,17 @@
continue;
}
- //collect data
- XmlNode n = doc.ReadNode(reader);
- root.AppendChild(n);
+ if (mode == XmlReadMode.InferSchema ||
+ mode == XmlReadMode.Auto ||
+ mode == XmlReadMode.DiffGram ||
+ mode == XmlReadMode.IgnoreSchema) {
+ //collect data
+ XmlNode n = doc.ReadNode(reader);
+ root.AppendChild(n);
+ continue;
+ }
+
+ XmlDataReader.ReadXml (this, reader, mode);
}
if (reader.NodeType == XmlNodeType.EndElement)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Default:ChangeType, MonoType, dynamically loaded assemblies and MonoCMethod:Invoke on constructors
I'm back in town and have had a chance to look into this issue and it
looks like the problem is not related to the assemblies and loading them
(which is good news). Is there information about how complete the
SortedList class is? I notice a comment in the documentation of 1.1.7
that implied that it was not fully implemented, but that was about it.
I am using 1.1.8.1. I would really love to get my hands on MonoDevelop
for this version (I've tried to build it but no luck). Thanks for the
information.
Gary M. Smithrud
Haley Systems, Inc.
Phone: 724-934-7853
[EMAIL PROTECTED]
www.haley.com
Moving at the Speed of Change
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gary M.
Smithrud
Sent: Thursday, June 16, 2005 7:55 PM
To: mono-devel-list
Subject: [Mono-devel-list] Default:ChangeType, MonoType,dynamically
loaded assemblies and MonoCMethod:Invoke on constructors
I have the following two assemblies that are being loaded dynamically
from within an application. In the constructor for a class in the first
assembly, it has a parameter that is an instance of a class in the
second assembly. When attempting to call the constructor for the first
class (using reflection), I get the exception System.ArgumentException:
parameters (by the way, this exception could really provide more
information or the outer one should so that way it is a little easier to
track the problem down).
Looking at the trace, it looks like the compile MonoType is different
than the MonoType for the same class when loading the assembly
dynamically (determined this by the tracing/debugging output). The
application does not have access to the assemblies when it is built, nor
does it know the order in which they are loaded. The first assembly
does reference the second one when it is built, of course. In the
trace, the object that is passed in the array has the correct type, but
the type's are different when they are compared in Default:ChangeType (I
do not know what type Mono believes it is, because I have not been able
to get Mono-Develop to build. I am not sure that I can get that
information from gdb either.)
The question is, Has this been tested and the problem is in my code or
does Mono have an issue with this? Unfortunately, I am leaving town
tomorrow and do not have time right now to provide an example. Below is
code that sort of shows the issue:
using B;
namespace A {
public abstract class ClassA {
ClassC _foo; // In B.
double _value;
int number;
public ClassA(ClassC foo, double value, int number) {
_foo = _foo;
_value = value;
_number = number;
}
}
public ClassB : ClassA {
public ClassB(ClassC foo, double value, int number) :
base(foo,value,number) {
// do whatever
}
}
}
namespace B {
public ClassC {
}
}
The exception occurs when you pass an instance of B.ClassC to the
constructor of ClassB.
Thanks for any information (again, I will be out of town until Tuesday,
if you have any questions),
Gary.
___
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] MonoDevelop : looking for mozilla
Dnia 23-06-2005, czw o godzinie 16:22 +0200, Mikkel Kruse Johnsen napisał(a): Hi No it is not possible to use firefox, firefox is compiled in static mode, and gecko-sharp needs a shared compiled mode. Witch mozilla is. You mean firefox from www.mozilla.org site? I mean ie. mozilla-firefox package in Ubuntu. In my case it works. (gecko-sharp from svn). I guess mozilla-firefox was compiled to shared binaries. I think there is a way. Just set MOZILLA_FIVE_HOME environment variable to path where you have Firefox. Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): -- Marek Sieradzki [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] [PATCH] Reworked unified Locale classes
On Thu, 2005-06-23 at 12:16 -0400, Miguel de Icaza wrote: Hello, 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). I agree with Ben that string are localized only several time and the little performance overhead caused by localization can be ignored. (The overhead should be little.) Yes, but Ben limited himself to speculation. [EMAIL PROTECTED] corlib]$ find -name \*.cs | xargs grep Locale.GetText | wc -l 712 [EMAIL PROTECTED] corlib]$ find -name \*.cs | xargs grep Locale.GetText | grep -v Exception | wc -l 194 Most of those 194 seem to be cases where Locale was put on a different line than the throw statement for cosmetic reasons. I want to know the real impact (we have the tools, it should take a few minutes at most to find out the numbers). The best way for Kornel to do that (just as an FYI since he has probably never used the tools) is to run: mono --stats foo.exe mono --profile foo.exe where `foo.exe' is a program that exercises the Locale code, but doesn't do much else, and send the output for each before and after the change. -- 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] Double-locking and thread safety
Note that I changed subject because this dicussion is not specific to my
patch altough it applies to my patch.
First of all: If any of my conclusions are wrong please let me know.
From: Jonathan Pryor
private static ResourceManager GetResourceManager ()
{
if (resources == null)
lock (resourcesLock) {
if (resources == null)
resources = new GetTextResourceManager (typeof
(Locale).Assembly.GetName
().Name, typeof (Locale).Assembly);
}
return resources;
}
I think this is good, because it is intended to initialize resources only
once.
It looks good. It acts good. It isn't good.
See:
http://galactus.ximian.com/pipermail/mono-devel-list/2004-February/004101.html
http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx
Using the following code as the example:
if (a == null)
{
lock(obj)
{
if (a == null) a = new A();
}
}
I see the problem as the following:
1. Declaring a as volatile would solve the problem but it results in
performance loss because of memory barriers for each read.
2. Removing the check outside the lock would solve the problem but it
results in performance loss because of memory barriers for each read.
3. It is not a problem that a may be seen as null even if it was already
created because lock will do memory barrier.
4. The problem is that a may be assigned before it's content is stored
(has the same side effects as using the object without executing the
constructor) because reordering and this will cause problems if a processor
did not cached value of a and wants to read it from the shared memory then
it will see the object in a but will see an uninitialized object.
5. Using a memory barrier after the object was created but before it is
assigned to a solves the problem and does not result in performance loss
when the object is already created.
So the following code is good:
if (a == null)
{
lock(obj)
{
if (a == null)
{
object newA = new A();
Thread.MemoryBarrier();
a = newA;
}
}
}
I think using a lock is better than constructing a new instance because the
new instance would be dropped if it's already created as we want to use a
single instance so it's better to suspend the thread by doing a wait than
creating a new instance because the CPU time can be used for useful
operations instead of wating time.
http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx:
Realize that synchronization is expensive. The full fence implied by
Interlocked.Increment can be many 100’s of cycles on modern hardware. That
penalty may continue to grow, in relative terms.
I think this applies to Interlocked.CompareExchange as well.
So I suggest to use this model instead of Interlocked.CompareExchange.
Furthermore I think using two Thread.MemoryBarrier() is less effective than
using lock and and a single Thread.MemoryBarrier() because there will be not
useless object creation, Thread.MemoryBarrier() allways does a full barrier
while lock does acrique at the begining and release at the end and
Interlocked.CompareExchange does barriers as well so there are more barriers
and thus locks in your lock-free code than in the locked code.
From: Jörg Rosenkranz
How about using Thread.MemoryBarrier how it's been suggested
in Brad Abrams' blog:
http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx
This code does the same as the above code so this code should be good.
Is this supposed to work on Mono?
Thread.MemoryBarrier is not implemented by Mono yet (no exception but does
nothing), but it seems that it is required only by IA64 that is not
supported by Mono yet so you can already use it but will be implemented only
when it will be necessary.
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
On Thu, 2005-06-23 at 19:03 +0200, Kornél Pál wrote: 1. Declaring a as volatile would solve the problem but it results in performance loss because of memory barriers for each read. Well, the performance loss here isn't all that bad. On an x86 machine there is basically no loss. 2. Removing the check outside the lock would solve the problem but it results in performance loss because of memory barriers for each read. The real problem is that the lock can result in contention which is orders of magnitude worse than a memory barrier. I think using a lock is better than constructing a new instance because the new instance would be dropped if it's already created as we want to use a single instance so it's better to suspend the thread by doing a wait than creating a new instance because the CPU time can be used for useful operations instead of wating time. That issue only happens in the *VERY* rare case that two threads are contending. http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx: Realize that synchronization is expensive. The full fence implied by Interlocked.Increment can be many 100’s of cycles on modern hardware. That penalty may continue to grow, in relative terms. I think this applies to Interlocked.CompareExchange as well. But that only gets run once per program. Anyways the cost of reading a page in from the disk to do the Locale stuff is orders of magnitude more expensive. So I suggest to use this model instead of Interlocked.CompareExchange. Furthermore I think using two Thread.MemoryBarrier() is less effective than using lock and and a single Thread.MemoryBarrier() because there will be not useless object creation, Thread.MemoryBarrier() allways does a full barrier while lock does acrique at the begining and release at the end and Interlocked.CompareExchange does barriers as well so there are more barriers and thus locks in your lock-free code than in the locked code. It depends on how commonly this code is used. The code is going to become horrible to maintain if we have MemoryBarriers scattered around. We should really stick to obvious locking patterns except where performance is an issue. Now, given that this code is only used in exceptional code paths (and in SWF -- but there, speed is measured in UI responsiveness, and none of the solutions are slow enough to make a difference there), the simple lock-then-check should suffice 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] Double-locking and thread safety
From: Ben Maurer On Thu, 2005-06-23 at 19:03 +0200, Kornél Pál wrote: 1. Declaring a as volatile would solve the problem but it results in performance loss because of memory barriers for each read. Well, the performance loss here isn't all that bad. On an x86 machine there is basically no loss. You are right but although on x86 machines the original code without volatile and MemoryBarrier works correctly we care about this problem. As the problem may occur only on MP IA64 (according to referenced articles) the solution itself has to be shaped for MP IA64 as well (as long as it does not cause performance loss on other architectures). And I think using no lock for read results in better performance than locking or doing memory barriers anyway. 2. Removing the check outside the lock would solve the problem but it results in performance loss because of memory barriers for each read. The real problem is that the lock can result in contention which is orders of magnitude worse than a memory barrier. You are right, but memory barriers should be done by lock as well so it's very inefficient. I think using a lock is better than constructing a new instance because the new instance would be dropped if it's already created as we want to use a single instance so it's better to suspend the thread by doing a wait than creating a new instance because the CPU time can be used for useful operations instead of wating time. That issue only happens in the *VERY* rare case that two threads are contending. You are right but if we know a better solution we should use that. And of course the problem because of using the original form of the code will occur only in very rare cases as well and we don't say that it's unimportant. These rare cases exist anyway and I think it's better to wait and let the CPU do something useful than doing someting useless just not to lock. And note that it even may need more time to create a new instance than waiting for the other thread to create the instance so I don't see any advantages of creating the multiple instances simultaneously. http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx: Realize that synchronization is expensive. The full fence implied by Interlocked.Increment can be many 100’s of cycles on modern hardware. That penalty may continue to grow, in relative terms. I think this applies to Interlocked.CompareExchange as well. But that only gets run once per program. Anyways the cost of reading a page in from the disk to do the Locale stuff is orders of magnitude more expensive. You are right but if we care about performance we should care about this rare situations as well. Doing expensive research for these situations is not recommented but if we know that one solution is better than the other we should use the better instead of saying it's not important. So I suggest to use this model instead of Interlocked.CompareExchange. Furthermore I think using two Thread.MemoryBarrier() is less effective than using lock and and a single Thread.MemoryBarrier() because there will be not useless object creation, Thread.MemoryBarrier() allways does a full barrier while lock does acrique at the begining and release at the end and Interlocked.CompareExchange does barriers as well so there are more barriers and thus locks in your lock-free code than in the locked code. It depends on how commonly this code is used. The code is going to become horrible to maintain if we have MemoryBarriers scattered around. We should really stick to obvious locking patterns except where performance is an issue. Now, given that this code is only used in exceptional code paths (and in SWF -- but there, speed is measured in UI responsiveness, and none of the solutions are slow enough to make a difference there), the simple lock-then-check should suffice for now. It's sufficient but I can't understand why not to use a more sufficient solution if we already know that solution. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
From: Ben Maurer
Anyways, there is no use arguing about this stuff. If you can show that
more complex code results in a measurable speedup, feel free to bring it
up ;-).
Although the current code is not complex lock, MemoryBarrier and
CompareExchange could be invoked a hundreds of times but to get proper
results they should be executed on the right architecture (multi-processor
system, threads on different processors, probably on IA64). I think it's
difficult to make a managed thread to use a specific processor and
MemoryBarrier is not implemented at all by Mono so it cannot be tested. And
of course the runtime does not support IA64. I don't want to argue about
this because it seems to be nearly impossible to test it.:)
But you can make sure that creating a new instance requires more time than
waiting for another thread to create it because:
1. We can assume that creating an object requires the same time because
alhough it's slower to create the first instance (static constructors, file
loading from disk, ...) the second thread has to wait these static
constructors so the second instance cannot be created faster.
2. Usually one of the threads start to create the instance earlier so one of
them will be created earlier.
3. Thus one of the threads will create the instance while all the other
threads will not create their instance before the first thread.
4. Usually the other threads will finish later so it's wasting of time.
And doing this has no drawbacks because if all of the threads finish the
same time only one of them did usefull work and all the others were wasting
CPU cycles so it sill has the advantage of CPU cycles.
This theoritically seems to be better than doing the reverse.
In the meanwhile, I've done a few data-collection things:
[EMAIL PROTECTED] ~]$ mono --trace=T:Locale install/lib/monodoc/browser.exe
ENTER: Locale:GetText (string)([STRING:0x42720:EST], )
LEAVE: Locale:GetText (string)[STRING:0x42720:EST]
ENTER: Locale:GetText (string)([STRING:0x42738:EDT], )
LEAVE: Locale:GetText (string)[STRING:0x42738:EDT]
(this is after browsing about for a bit).
So, it looks like it is possible the people using DateTime will
experience a bit of slowness. However, I wonder if for this specific
case, we can rely on the OS's database of time zones.
You were right I did not know or used these tools.
Note that these strings are localized by the TimeZone class rather than
DateTime.
I don't know whether they should be localized but it is a bad practicle to
localize names in the constructor. They should be localized when the string
is returned because you can use different CurrentUICultures to retrive them
than you used to create the class.
On mcs, there were *no* calls to Locale.GetText except when I tried to
compile a non-existent file. In that case, the exception was caught,
however it was still localized. Can this be avoided?
No. The problem is that the message (and not a key or format pattern) has to
be passed to the constructor of Exception. As MS.NET uses keys they have to
pass the localized message thus the message will be in the language used to
throw the Exception. This should be done by Mono to preserve compatibility.
Furthermore the message cannot contain any parameters ({0}, {1}, ...) it has
to contain a message with parameters filled in. And as applications can use
any messages (that may be localized by themselves) and probably they don't
want the class library to localize their messages.
As for the expense of the reflection stuff you used, I have this test
case:
using System;
using System.Text;
class X {
static void Main ()
{
Console.WriteLine (X);
//Console.WriteLine (typeof (X).Assembly.GetName
().Name);
}
}
My only problem is that I don't know how much penalty does this mean (I
don't know how to interpret the results).
I don't insist on using this code if you have a better solution please let
me know.
Kornél
___
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
From: Miguel de Icaza From: Ben Maurer I want to know the real impact (we have the tools, it should take a few minutes at most to find out the numbers). The best way for Kornel to do that (just as an FYI since he has probably never used the tools) is to run: mono --stats foo.exe mono --profile foo.exe You are right I have never used these tools.:) I tested internal static string GetText (string message) without INSIDE_CORLIB. It is a very common code. getTextLock and SafeGetText are required anyway. GetResource is not changed significantly. I tested GetTextResourceManager without resource files (just used the transparent GetTextResourceSet) because the current ResourceManager and ResourceSet implementations are not currently effective enough and there are no localized resources yet. And of course localizing resources from files will result in worse performance anyway but it depends on ResourceManager and not Locale. I attached the source files and the results: mcs /out:OldLocaleBenchmark.exe LocaleBenchmark.cs OldLocale.cs mcs /out:NewLocaleBenchmark.exe LocaleBenchmark.cs NewLocale.cs mono --stats OldLocaleBenchmark.exe OldLocaleBenchmark.stats mono --profile OldLocaleBenchmark.exe OldLocaleBenchmark.profile mono --stats NewLocaleBenchmark.exe NewLocaleBenchmark.stats mono --profile NewLocaleBenchmark.exe NewLocaleBenchmark.profile I have runned this on Windows. Kornél LocaleBenchmark.tar.gz Description: GNU Zip compressed data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Going from C/GTK to C#/GTK#
Hello Paul, I think it would much easier to port than it has been to be written in C/GTK+. C#/GTK# _do_ accelerate development a lot but you have to familirize with the APIs first, because the approach is much more OO oriented. A good place to start reading is http://www.mono-project.com/Monkeyguide or if you can afford it, buy the book Mono: A Developers Notebook by Edd Dumbill. If you need any help, you can post on this mailing list. Regards On Thu, 2005-06-23 at 00:58 +0100, Paul wrote: Hi, I have a nice little app here which is written in C and used Gnome/GTK for the UI. Is it grossly hard to port this to C#/GTK# and if it isn't too bad, are there any websites around which can help me doing this? TTFN Paul ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Milen Dzhumerov Iroxa Creative Technology / Iroxa.net ICQ# / 230197935 Email / [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Going from C/GTK to C#/GTK#
The port would be a fairly large re-write due to the nature of C Sharp being completely OOP, a different set of commands/API structure. The GTK component is less hard to port but some elements would still need changing. To get started google about .NET Framework API structure, Mono and C Sharp as a language. Martin On 6/23/05, Paul [EMAIL PROTECTED] wrote: Hi, I have a nice little app here which is written in C and used Gnome/GTK for the UI. Is it grossly hard to port this to C#/GTK# and if it isn't too bad, are there any websites around which can help me doing this? 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). BodyID:13822364.2.n.logpart (stored separately) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Martin Hinks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mod_mono Web Service Problem
Hi I've got a huge problem with Web Services under mod_mono right now. I have updated mono to 1.1.8 and subsequently to 1.1.8.1 and both give me the same problem. Basically, if I try to run a WebMethod using the WsdlHelpGenerator page, the page stalls for a long time and in the end throws the error: Thread Was being aborted. A .NET Client is able to connect to the Web Service and call the WebMethods so I'm guessing the problem is in the WebService client implementation in Mono. Looking at the error_log in apache I see: Unhandled Exception: System.Net.WebException: Read error in 0x00350 System.Net.WebConnection:EndRead (IAsyncResult result) in 0x000ac System.Net.WebConnectionStream:EndRead (IAsyncResult r) Can anyone help me with this? Configuration: Gentoo Linux mono-1.1.8.1 xsp + mod_mono 1.0.9 apache 2.0.54 kernel-2.6.7 I would like to mention also that it used to work under mono 1.1.7 Adrian Dinu Technical Manager Dream Team Software ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mod_mono install question
I've been developing ASP.NET apps in C# using M$ Visual Studio 2003 for some time now, but am just getting started using Mono 1.1.8.1on SuSE Pro9.2 and Red HatEnterprise AS 4.0with Apache httpd 2.0.54. The Mono source was no prob to d/l, compile and install, but the Mono Apache module is a mystery to me. The link on Apache takes me to a CVS branch, but I can find nothing to download (granted, I'm also a CVS newbie). A clue would be appreciated. thx, ~mark This email and any file transmitted with it may be confidential and is intended solely for the use of the individual or entity to whom it is addressed. If you received this email in error please notify the DBM Service Desk by forwarding this message to [EMAIL PROTECTED] This email has been scanned by networkMaryland Antivirus Service for the presence of computer viruses. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mod_mono install question
For Suse there should be a version here: http://www.go-mono.com/download/suse-92-i586/ If you want to manual compile Download the sources here: http://go-mono.com/sources/ If you want really fresh sources get them from SVN:(==subversion cvs) svn co svn://mono.myrealbox.com/source/trunk/mod_mono svn co svn://mono.myrealbox.com/source/trunk/xsp Configuration(Assumes that you have mod_mono tars): http://primates.ximian.com/~gonzalo/mono/blog/files/mod_mono.html Mark Galbreath wrote: I've been developing ASP.NET apps in C# using M$ Visual Studio 2003 for some time now, but am just getting started using Mono 1.1.8.1 on SuSE Pro 9.2 and Red Hat Enterprise AS 4.0 with Apache httpd 2.0.54. The Mono source was no prob to d/l, compile and install, but the Mono Apache module is a mystery to me. The link on Apache takes me to a CVS branch, but I can find nothing to download (granted, I'm also a CVS newbie). A clue would be appreciated. thx, ~mark This email and any file transmitted with it may be confidential and is intended solely for the use of the individual or entity to whom it is addressed. If you received this email in error please notify the DBM Service Desk by forwarding this message to [EMAIL PROTECTED] This email has been scanned by networkMaryland Antivirus Service for the presence of computer viruses. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
AW: [Mono-list] mod_mono install question
Hi Mark, Try using red carpet for install (works for me on Suse 9.2). And there are rpms For Suse 9.2 http://www.go-mono.com/download/suse-92-i586/ For Red Hat Enterprise 4 http://www.go-mono.com/download/rhel-4-i386/ --Matt -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Mark Galbreath Gesendet: Donnerstag, 23. Juni 2005 14:06 An: mono-list@lists.ximian.com Betreff: [Mono-list] mod_mono install question I've been developing ASP.NET apps in C# using M$ Visual Studio 2003 for some time now, but am just getting started using Mono 1.1.8.1on SuSE Pro9.2 and Red HatEnterprise AS 4.0with Apache httpd 2.0.54. The Mono source was no prob to d/l, compile and install, but the Mono Apache module is a mystery to me. The link on Apache takes me to a CVS branch, but I can find nothing to download (granted, I'm also a CVS newbie). A clue would be appreciated. thx, ~mark This email and any file transmitted with it may be confidential and is intended solely for the use of the individual or entity to whom it is addressed. If you received this email in error please notify the DBM Service Desk by forwarding this message to [EMAIL PROTECTED] This email has been scanned by networkMaryland Antivirus Service for the presence of computer viruses. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: mod_mono ignoring DirectoryIndex?
On Wed, 2005-06-22 at 20:01 -0700, benjamin van der veen wrote: Gonzalo, Thanks for your suggestion and speedy update of the wiki. One thing, though: In the wiki, you are saying one *needs* to modify web.config *in addition* to using AddHandler and DirectoryIndex in the Apache config if one wants index.html to be the directory index. That doesn't seem to be the case based on what my server is doing at the moment. I think maybe this is a problem with the way you worded it in the wiki, either that or I'm confused. The way I understand it based on this email is that you can do either one. With the web.config way, xsp handles index.html (as opposed to apache handling it). I don't see why one would want to do it like this, since handing static html to xsp is unnecessary overhead. Right. I modified the wiki again. Let me know if there's anything wrong. Thanks. -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Embedded
Greetings. I only dowonloaded test-invoke project and i tried make it using the headers and libs included in Windows mono installation, so i didnt read that README, I think that information will be enough! Thanks for all Sebastien. -- No hay viento favorable para el que no sabe donde va. Pablo Iñigo Blasco - GeuS - www.geus.es.vg ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] jpeg2000
Wherecani get informationabout jpeg2000 mono programing. THANKS ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mono for Solaris?
Title: Message Is there a ported version of mono for Solaris? I'd be interested in running asp.net on apache under Solaris 9/10 I guess the source code could be tweaked to work there, but would rather use a ready solution. Thanks, -Alex ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono for Solaris?
I was able to build mono on Solaris (Sparc). However I can't seem to have a parallel build on the x86 platform, I was trying to port it for CSW but still to no avail since it requires me to have builds for both x86 and sparc. Building it on the Sparc platform was straight forward. I have also written a short guide for building mono in Solaris 10: http://home.comcast.net/~jonel.rienton/2005/04/solaris-10-x86-and- mono.html Good luck, regards, Jonel On Jun 23, 2005, at 12:06 PM, Alex Kriegel wrote: Is there a ported version of mono for Solaris? I'd be interested in running asp.net on apache under Solaris 9/10 I guess the source code could be tweaked to work there, but would rather use a ready solution. Thanks, -Alex ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
