[Mono-dev] Re: What would you like to see in Mono? [.wapi-less config]
Joachim Ante wrote: Hello, What i'd like to see in mono is the ability to start up an application without it needing a .WAPI folder. I understand why mono needs the wapi folder, but i'm sure there are application for which one wouldn't need one at all. Yeah that would really useful. For that, try using MONO_DISABLE_SHM=1 on your environment As far as i can see this environment variable doesn't exist anymore. Is there another way to disable wapi? No, there isn't. Indeed, it would be nice to have a .wapi-less config or at least to make the current implementation setuid(2) safe. This means that all shm ops have to be configurable, unless there is a way to make them working with setuid, which doesn't work in all Linux kernel versions, AFAIK. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is crossplatform ?
Hi, On Mon, 2006-04-03 at 14:18 -0300, Flavio Medeiros wrote: >Hi, we are starting a (large) project that needs to be cross > platform (windows/linux) and we are discussing about the .NET (MS > framework and Mono) and the Java technology. > Anyone can point me to any interesting information about projects > developed under windows using VS.NET (language C#) ? I know that the > ASP.NET support of Mono is great, but we know none about Winforms > support. Is there any project that uses WinForms developed using > VS.NET that runs in Windows and Linux without problems ? > Is it possible or only using GTK# ? > Mono is realy crossplatform today on desktop apps ? > I like the C# solution but ... > > Thanks, I can't say much about SWF (never used it on windows neither linux, the API looks horrible though IMHO), but I have experience in developing and deploying cross-plattform desktop applications. We use Mono + Gtk# + Glade# + Glade UI designer + MonoDevelop for developing the applications on Linux workstations, and test them and deploy them on Windows with MS .NET + Gtk#, which works very good. But you have to test your applications from time to time, sometimes the API behaves a bit different on Mono than MS .NET (which is usually a bug and becomes fixed once you reported it), but that has to be kept in mind, but thats also the case for free Java runtimes. I guess you could also do for development: MS .NET + Gtk# + Glade# + Glade UI designer + VS.NET, or replace VS.NET with SharpDevelop. The project we use this for is large, it's an allround insurance broker software. All applications that are developed now are written in C# instead of C++ as we did before. The project is not complete cross-plattform yet because there are still parts written in C++ using Borland's VCL which is even less cross-platform than SWF. But soon the complete suite will run on Linux too. IMHO writing cross-platform applications in C# (or any other CLI implemented language) is easier than writing them in other languages. -- Regards, Mirco 'meebey' Bauer PGP-Key: http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8 -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d s-:+ a-- C++ UL$ P L++$>+++$ E- W+++$ N o? K- w++>! O M- V? PS PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y? --END GEEK CODE BLOCK-- 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
[Mono-dev] mod_mono and Apache warning for FC5 users
Hi, Fedora Core 5 ships with Apache 2.2 and apr-1.x. Currently, this means that mod_mono *will not* compile under FC5. While the apr problem is not that hard to sort out (I have a fix at home, but the network is down there at the moment, basically, it's a hack to the configure script), the problems with Apache2.2 are not as trivial to sort out. I'll be having a look at both of them again tonight, but unless there is something defined for Apache2.2 in Apache (or someway I can differentiate between them in the config script), mod_mono may need porting to Apache2.2 which will take more time. mod_mono will still work with FC4, but I would not recommend downgrading from FC4 to 5 because of this one thing! I've contacted the maintainer of apr for FC and it seems that apr-config applied to version < 1.0, whereas the version shipped with FC5 has version > 1, and therefore apr-config and /usr/include/apr have now become apr-1-config and /usr/include/apr-1. A symlink sorts the problem, but mod_mono still fails to compile due to changes in Apache. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: mod_mono and Apache warning for FC5 users
Paul, Fedora Core 5 ships with Apache 2.2 and apr-1.x. Currently, this means that mod_mono *will not* compile under FC5. Did you try SVN head or the new 1.2 beta? Both already have support for Apache 2.2. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Continuations and MicroThreads
On 04/04/06 Tomi Valkeinen wrote: > Attached is a small patch to mono runtime that implements continuations > for amd64 and x86 linux, two C# files that implement basic > MicroThread-stuff, and some C# test programs. You can also get a full Wow! Nice:) > About the overall implementation: IT'S A HACK! =). It works, but I know > many ways to break it. It lacks sanity checks. It probably misses a few > arguments every now and then. It kinda ignores GC, which probably will > also break it. The new GC will probably break it even more. I haven't even If you allocate the area where you store the stack with with mono_gc_alloc_fixed (size, NULL), both the old and the new GC will conservatively scan the area for pointers (but make sure that when you copy it the values are properly aligned (start and top of the copied stack must be pointer-sized aligned)). You currently use malloc/g_new, so even the current GC won't see the objects and collect them. The effect on the new GC will be mostly to slow it down, since it won't be able to move the objects that may be referenced by the saved stack (this of course depends on how many objects are referenced and how large they are). > thought about CAS. Not forgetting the millions of things that I don't know > about that will also break it. But still, the tests I've included work, > and it's been great fun playing with them. You should likely have the size of the saved stack as a param and of course you'd need to check for overflows on it. Also, for continuations that include managed->unmanaged->managed transitions, you need to save and restore the LMF chain (I haven't checked all your code, so maybe you handle that already). > My first question to the list is: is anyone else interested in this, using > continuations and/or developing them further? Shall I keep quiet from this > on or do you want to hear more? I think every interesting and clever development with mono is on topic for this list:) I would love if people would contribute to and enhance your version. We always envisioned mono as a virtual machine that enables such projects and support for continuations would enable also more languages to be targeted at running on the mono runtime... > My second question is: how to make the native code better? I don't know > much about Mono internals, this was my first mono runtime project so all > feedback is appreciated. Also I'd very much like to hear if someone can > point out why this way of implementing continuations to Monois > fundamentally flawed. This requires reading the code, but if some of you > Mono-gurus have the time and can educate me... See above for a way to deal with GC issues. Eventually also security info in the stack frames would need to be saved and you'd have to deal with cross-appdomain transitions. This mechanism can't work in some scenarios, but they are not easily accessed in C# code anyway (passing the address of a local var to a real subthread that is supposed to store or read from it: the stack is saved and restored bu the subthread doesn't know it ...). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [PATCH] ShellExecuteEx ProcessId support for Windows 2000 and Windows XP RTM
Could someone please review this patch. Thanks. Kornél - Original Message - From: "Kornél Pál" <[EMAIL PROTECTED]> To: Sent: Friday, March 31, 2006 3:40 PM Subject: Re: [PATCH] ShellExecuteEx ProcessId support for Windows 2000 and Windows XP RTM I experienced some problems and I realized that some libc functions were imported from ntdll.dll rather than msvcrt.dll that caused the problems. Explicitly referencing msvcrt before ntdll solved the problem but I'm not sure whether this is the best solution. Kornél - Original Message - From: "Kornél Pál" <[EMAIL PROTECTED]> To: Sent: Friday, March 31, 2006 2:50 PM Subject: [PATCH] ShellExecuteEx ProcessId support for Windows 2000 and Windows XP RTM Hi, GetProcessId is supported only by Windows XP SP1 and Windows Server 2003 or later. Unlike stated in the comment ProcessId can be obtained without GetProcessId as well. On NT this is quite easy as NtQueryInformationProcess will return it. On Win9x it needs some more hack but as we only support Windows 2000+ there is no need to do that. NtQueryInformationProcess is documented but is said to be internal. I'm sure that it won't be changed as it is widely used. The only possible problem is that cygwin has different include file names than Platform SDK. Please review the patch. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Speed and Intermediate Language
On 04/03/06 Rusmin Susanto wrote: > 1. Is Mono slower than MS .NET? I have a C# program that runs around 9 > second in > Mono. I tried to compile it with /optimize flag. But I couldn't see any > speed > increase. The same program run around 6 second in .NET (debug mode) and > around 4.8 second (release mode) > Is this the expected outcome? Or I made some mistake? What should I do > to > improve performance? Sometimes mono is slower, sometimes it is faster. If you have a test where mono is significantly slower than the MS runtime, please file it in a bug report in bugzilla so we can see what's up. > 2. Is it possible to put inline assembly (Mono assembly which is the > intermediate > languange) in C#? If yes, how do we do it? You could certainly develop an extension to C# and modify our compiler to recognize it and output the inline IL assembly code. > 3. Let's say I go a useful package that was written in Microsoft C#. I > don't have the > source code, only the assembly (IL).Can I use it in Mono? If yes, > how do I do it? Sure, provided it doesn't use Platform/invoke to win32 binary libraries and references assemblies that are implemented in mono. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is crossplatform ?
On 04/03/06 Jonel Rienton wrote: > I've had very great experience with VS 2005. It actually made me more > productive and get almost all of my projects done faster. > > I'm not sure where you're getting your statistics. VS 2005 is not on topic for this list, which is about mono development. Please use private emails for that stuff. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is crossplatform ?
On 04/03/06 Flavio Medeiros wrote: > I follow the Mono project since pre 1.0 and the question is only about a > WinForms desktop app that runs fine on both Windows and Linux. > The focus in this moment is not the cost or risk, but the functionality. > In our tests a simple app with a main menu, a toolbar and a richtext box > chashes on both stable and development versions of mono under linux (Suse > 10). The way to have your app work in mono is to file a bug report in bugzilla. Include the source code of your test app so that the SWF developers can use it and make it work. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] .NET application compilation problem - could not found the ObjectQuery and ManagementObjectSearcher
Dear All,
I am newbie to this mono frame work.
I download the source files from the following link and
installed them on a Fedora Core 3 box.
http://go-mono.com/sources/mono-1.1/mono-1.1.13.4.tar.gz
I was able to compile and run the simple hello world program
which look likes as
using System;
using System.IO;
using System.Text;
namespace HelloNameSpace
{
public class Hello
{
static
void Main(string[] args)
{
Console.WriteLine("What we think, we become.");
}
}
}
I was compiled the above program using the following command
# mcs hello.cs
I ran the program using the following command.
# mono hello.exe
It is ok. But when I try to compile a .NET application (written
like hello.cs) I got the following compilation errors.
I compiled the .NET application using # mcs –pkg:
dotnet
I included the System.Managemet
SampleObjectQuery.cs(8,9):
error CS0246: The type or namespace name `ObjectQuery' could not be found. Are
you missing a using directive or an assembly reference?
SampleObjectQuery.cs(25,9):
error CS0246: The type or namespace name `ManagementObjectSearcher' could not
be found. Are you missing a using directive or an assembly reference?
In my .NET application I
used the ObjectQuery and ManagementObjectSearcher
methods to create objects.
I have gone through the
class directory where we can find the methods. But I could not find the above
mentioned class methods. But I found the ObjectGetOptions
method.
What could be the problem?
Could any one give a hint?
Thanks in advance.
Regards,
Srinivas
G
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono profiler agent for jitted code
On 04/03/06 Willibald Krenn wrote: > So this kind of functionality is still on your whishlist? As I was working > on exactly that kind of stuff, response/interest seemed *very* little. We have always been interested in this feature. We'll have it eventually, but the implementations details are important: what is fine for a research/thesis project may not be right for a production VM. In particular I think the mono implementation must have a very low overhead (especially in terms of memory and system resources used): the best effects will be achieved if the optimization is turned on by default. > However, the initial experiments I conducted tend to support recompilation > at least for SciMark: From 178,29 +/- 0,12 [normal mode] to 204,00 +/- 1,57 > with recompilation enabled. (204,86 +/- 0,18 was maximum when always > applying all optimizations upfront.) Yep, thanks to your work we know it's worthwhile to implement it. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: [PATCH] ShellExecuteEx ProcessId support for Windows 2000 and Windows XP RTM
On Tue, 2006-04-04 at 12:01 +0200, Kornél Pál wrote: > Could someone please review this patch. I was on holiday, and you didn't seem too confident about this patch anyway; but here goes: The GetProcessId check should remain in configure.in, and HAVE_GETPROCESSID be used by the code to check if its available or not. Remember, check for features not platforms. Check that interdependencies between msvcrt.dll and ntdll.dll can be _reliably_ solved by the link order. Then I'll review an updated patch. Thanks, - Dick 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
[Mono-dev] Re: .NET application compilation problem - could not found the ObjectQuery and ManagementObjectSearcher
Srinivas G. wrote: It is ok. But when I try to compile a .NET application (written like hello.cs) I got the following compilation errors. I compiled the .NET application using # mcs -pkg: dotnet I included the System.Managemet Mono doesn't implement System.Management because Microsoft's implementation is just a wrapper around WMI which in turn doesn't exist on Linux. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is crossplatform ?
We are doing some tests against Mono 1.1.14. Before this I will file a bug report and post the numbers here (Peter already requested this). On 4/4/06, Paolo Molaro <[EMAIL PROTECTED]> wrote: On 04/03/06 Flavio Medeiros wrote:> I follow the Mono project since pre 1.0 and the question is only about a > WinForms desktop app that runs fine on both Windows and Linux.> The focus in this moment is not the cost or risk, but the functionality.> In our tests a simple app with a main menu, a toolbar and a richtext box > chashes on both stable and development versions of mono under linux (Suse> 10).The way to have your app work in mono is to file a bug report inbugzilla. Include the source code of your test app so that the SWF developers can use it and make it work.lupus---[EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better-- Flavio Medeiros Sales www.flaviomedeiros.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Thread Abort() sometimes fails in mono
Hi,
I've come into another funny.
When going after a web page using code previously posted on the
list, if I call the thread abort code, it will say the web page timed
out (through the console.writeline in the catch{} section below),
and will keep going. In other words, the application quits but
the thread stays running and printing its results.
Sometimes it aborts just fine. It appears I have to catch
it just right for it to fail or succeed. It may be the abort is
called during the Console.Writeline() code and fails, it may be it is
called
during the web page fetch and fails with a timeout.
In Microsoft .NET, it always aborts.
I've also noticed a difference between the font
computations on MS Windows and Ubuntu. In Ubuntu, the fonts are
huge for label controls, in Microsoft, they are smaller. don't
know why yet, but it is a pain.
application quit code
--
if (MessageBox.Show ("Are
you sure you want to quit the application?", "System Status",
MessageBoxButtons.YesNo, MessageBoxIcon.Question)
== DialogResult.Yes)
{
/*doesn't always work >*/ Global.WebThread.Abort();
GetWebPageClass.QuitNow = true;// added this so
abort would always work
Application.Exit();
}
I set up a static in the class so that I could write to it and
it would abort. If I leave the QuitNow flag alone, the thread
does not always abort. This is with 1.1.14, downloaded yesterday.
Following is relevant (I hope) sections of code.
Note the web page comes back *immediately*, but the port the web page
is on is 2001.
-
I can hear the screams now, but I've created a global object so that
we have certain items with visibility across threads and objecs, and whose
values are *not* on the stack. It makes it easier to write the code to navigate
between forms for people used to windows. You just call Global.MainForm.Show(), etc.
--
public class Global
{
public static GetWebPageClass WP;
public static Thread WebThread ;
public static StatisticsForm StatForm;
public static WinForm MainForm;
public static DebugForm DbgForm;
public static int DebugFlag;
public Global()
{
//
// TODO: Add constructor logic here
//
DebugFlag = 0;
}
}
-
the class constructor sets the web page and port
-
// host
url
port
Global.WP = new GetWebPageClass("ampro2","shm/gdsp.php",2001);
Global.WebThread = new Thread(new ThreadStart(Global.WP.Run));
Global.WebThread.Start();
while (!Global.WebThread.IsAlive);
Application.Run(Global.MainForm = new WinForm());
---
The fetch web page object fragment
public string GetWebPage()
{
try
{
UriBuilder uri = new UriBuilder("http",host,port,url);
HttpWebRequest webRequest =
(HttpWebRequest)WebRequest.Create(uri.ToString());
webRequest.Timeout = 1000;
if (Debug)
{
string MyUri = uri.ToString();
Console.WriteLine("Polling: ");
Console.WriteLine(MyUri);
//Console.WriteLine("\n");
}
HttpWebResponse webResponse =
(HttpWebResponse)webRequest.GetResponse();
Stream responseStream = webResponse.GetResponseStream();
string responseEncoding="";
// responseEncoding = webResponse.ContentEncoding.Trim();
if (responseEncoding.Length == 0)
responseEncoding="us-ascii";
StreamReader responseReader = new StreamReader(responseStream,
System.Text.Encoding.GetEncoding(responseEncoding));
return(responseReader.ReadToEnd());
}
catch
{
if (Debug)
Console.WriteLine("Web site timed out\n"); //
return("Web Site Timed Out\nSorry!\n");
}
}
public void Run()
{
string Name="";
int Value=0;
string Page="";
Tokens t ;
int TokenCounter=0;
MyDspPanelInfo = new RemoteInfoClass();
while(true)
{
Page = GetWebPage();
//--
// look
[Mono-dev] Bug?: Mcs Custom Attribute Handling
Hi all,
After compiling 'mono-tools-1.1.11' by 'mcs-1.1.14' I ran into some
trouble during execution of 'browser.exe'. IMHO recent version(s) of mcs
(1.1.14 and may be earlier) introduce a bug custom attribute handling.
E.g.: In a declaration of the form
class SomeClass {
[SomeCustomAttribute] int x, y;
}
the field 'x' does not have any 'SomeCustomAttribute' attached to it,
but the field 'y' does have two 'SomeCustomAttribute' attached to it.
One may proof by compiling the following small snippet.
--
using System;
using System.Reflection;
[AttributeUsage(AttributeTargets.Field)]
class SomeCustomAttribute : Attribute {
public SomeCustomAttribute ()
{
}
}
class MainClass {
// Here, the custom attribute is attached correctly
[SomeCustomAttribute]
public int a;
// Here, the custom attribute attachment has a flaw
[SomeCustomAttribute]
public int x, y;
public static void Main ()
{
Type t = typeof (MainClass);
FieldInfo[] fia = t.GetFields();
foreach (FieldInfo fi in fia) {
object[] ca = fi.GetCustomAttributes(false);
System.Console.WriteLine ("Field: {0} [{1}]", fi.Name, ca.Length);
foreach (Attribute a in ca)
System.Console.WriteLine (" Attribute: {0}", a);
}
}
}
--
--
Norbert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.NullReferenceException, what does it mean?
thanks!On 4/3/06, Chris Toshok <[EMAIL PROTECTED]> wrote: I've just checked in a fix for this to svn.Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono is crossplatform ?
Take it easy dude, i'm not the one who brought it up :-) On 4/4/06, Paolo Molaro <[EMAIL PROTECTED]> wrote: > On 04/03/06 Jonel Rienton wrote: > > I've had very great experience with VS 2005. It actually made me more > > productive and get almost all of my projects done faster. > > > > I'm not sure where you're getting your statistics. > > VS 2005 is not on topic for this list, which is about mono development. > Please use private emails for that stuff. > > lupus > > -- > - > [EMAIL PROTECTED] debian/rules > [EMAIL PROTECTED] Monkeys do it better > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Jonel Rienton mailto:[EMAIL PROTECTED] powered by: google ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread Abort() sometimes fails in mono
Em Ter, 2006-04-04 às 08:26 -0600, Wade Maxfield escreveu:
> Hi,
Hi! Correct me if I'm wrong but...
> /*doesn't always work >*/Global.WebThread.Abort();
You shouldn't be using Thread.Abort, right? AFAIK, this is a bad way of
killing threads.
> while (!Global.WebThread.IsAlive);
Why do you make the CPU go to 100% here? At least some Sleep should be
better, no?
--
I didn't read all of your code, but I suspect you should be using
another thread abortion method. I have some code that uses a thread with
some web requests, and to abort it I do 2 things:
1) Create a variable that is marked false when I want the thread to die.
The thread's code periodically checks for the variable.
2) Save the WebRequest on a private variable to try to abort it, if
possible.
The relevant abortion method:
public void Abort() {
this.aborted = true;
try {
if (this.abortable) {
this.webRequest.Abort();
Logger.Log(this, "WebRequest aborted with (apparent)
success!");
} else
Logger.Log(this, "WebRequest is not abortable.");
} catch (Exception e) {
Logger.Log(this, "Failed to abort the WebRequest:\n" +
e.ToString());
}
}
The method name is "Abort" because this class does not derive from
Thread. Also, you can safely ignore all Logger::Log calls.
abortable is a variable that is set to false when the code starts an
operation on the WebRequest that would probably crash the program if it
was aborted.
It's also worth noting that we just try to abort the WebRequest and
ignore any exceptions -- the code will stop anyway sometime soon as we
set the aborted variable.
HTH,
--
Felipe.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Monocov patch
Hi.
I am currently looking a bit at the monocov code as I would like to
make a coverage add-in for MonoDevelop. To better understand what is
going on, I am trying to simplify things a bit. The attached patch
removes two (seemingly) redundant for loops.
Does this look good to commit? Should I even ask on this list as it
seems monocov is more or less unmaintained? I would also like to add
some unit tests. Anyone did some for monocov?
/Jacob
Index: CoverageModel.cs
===
--- CoverageModel.cs (revision 59019)
+++ CoverageModel.cs (working copy)
@@ -326,7 +326,8 @@
//
private bool GetSourceRangeFor (int offset, MethodCoverageItem method,
LineNumberEntry[] lines,
- ref int startLine, ref int endLine) {
+ ref int startLine, ref int endLine)
+ {
/**
* The line number info generated by mcs is pretty strange sometimes... :)
@@ -339,66 +340,28 @@
* entries.
*/
- int beginOffset = 0;
- int endOffset = 0;
- int i;
-
- for (i = 0; i < lines.Length; ++i) {
+ for (int i = 0; i < lines.Length; ++i) {
if (offset >= lines [i].Offset)
if (i == lines.Length - 1) {
- beginOffset = lines [i].Offset;
- endOffset = lines [i].Offset;
- break;
+ startLine = lines [i].Row;
+ endLine = lines [i].Row;
+ return true;
}
else if (offset < lines [i + 1].Offset) {
- beginOffset = lines [i].Offset;
- endOffset = lines [i + 1].Offset - 1;
- break;
+ startLine = lines [i].Row;
+ endLine = lines [i + 1].Row - 1;
+ return true;
}
}
- /*
- if (method.Name.IndexOf ("Find") != -1) {
- Console.WriteLine ("OFFSET: " + offset + " " + beginOffset + " " + endOffset);
+ if (offset <= lines [0].Offset) {
+ return false;
}
- */
-
- if (i == lines.Length) {
- if (offset <= lines [0].Offset) {
-return false;
- }
- else {
-for (i = 0; i < lines.Length; ++i)
- Console.WriteLine (lines [i]);
-throw new Exception ("Unable to determine source range for offset " + offset + " in " + method.name);
- }
- }
-
- /* Find start line */
- for (i = 0; i < lines.Length; ++i)
- if (lines [i].Offset == beginOffset) {
-startLine = lines [i].Row;
-break;
- }
-
- // g_assert (i < num_line_numbers);
-
- /* Find end line */
- if (lines.Length == 1)
- endLine = lines [0].Row;
else {
- for (i = 0; i < lines.Length; ++i)
-if (i == lines.Length - 1) {
- endLine = lines [i].Row;
- break;
-}
-else if (lines [i + 1].Offset > endOffset) {
- endLine = lines [i + 1].Row - 1;
- break;
-}
+ for (int i = 0; i < lines.Length; ++i)
+Console.WriteLine (lines [i]);
+ throw new Exception ("Unable to determine source range for offset " + offset + " in " + method.name);
}
-
- return true;
}
private ClassCoverageItem ProcessClass (Type t) {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: Thread Abort() sometimes fails in mono
Felipe Almeida Lessa wrote: Em Ter, 2006-04-04 às 08:26 -0600, Wade Maxfield escreveu: Hi, Hi! Correct me if I'm wrong but... /*doesn't always work >*/Global.WebThread.Abort(); You shouldn't be using Thread.Abort, right? AFAIK, this is a bad way of killing threads. Thread.Abort() is harmless and more like an exception than a killer. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread Abort() sometimes fails in mono
Hi Felipe,
First, thank you.
Second, yes, I did use a variable to do what you stated (it was
in the code fragments). When I found the abort() did not work all
the time, I set a variable to true, which caused my thread to abort.
Now, in regards to programming practices. I believe you
are correct. I agree in principal with everything you
state. I typically practice those things, as unbelievable as that
might sound. I'm more into systems now, but I've written real
time sw for years.
However, if you look at Microsoft's .NET programming in C#
examples and tutorials, their C# tutorial (see Microsoft .NET SDK, C#
Programming Reference, "Threading Tutorial") on threads shows you to
1) Spin while thread is not alive
2) call abort for thread to be closed
I agree that a sleep() is a good thing while waiting for
thread to start running. However, I thought one of the points of
"managed" code was to allow this sort of thing, not necessarily paying
attention to cpu loading issues, as well as memory issues? That
is why I swallowed MS's tutorial hook line and sinker.
In any case, regardless of the efficacy of the program I've
written, the point that mono developers must ponder is that other
coders following my footsteps will code exactly the same way, the way
that Microsoft Tutorial states it should. When it fails to abort
under mono, but always aborts under .NET, they will claim it is a bug
in Mono.
It does appear I overlooked a join() call, which forces the
first thread to deadlock until the abort happens. However, I
never had the problem of a failing abort in .NET. In this case, I
could care less if the thread aborted a few hundred milliseconds to one
second later than the main thread.
As I indicated earlier, I set a variable which caused my
routine to bail, causing the thread to naturally abort (similar to your
proposal, but more crude). This method will work in all versions,
.NET and Mono.
I was wondering if perhaps the abort() routine in Mono
might need tweaking. I was assuming that in most cases, (except for
System.Managed and other issues of similar ilk) that Mono would
typically want to work the same way as .NET.
I think Mono is great! I'm very, very happy to see
it. The work thus far has been astounding and
exciting. If the way abort() works is the one of the few
differences, I don't have any problems using Mono. It would need
to be documented, however, for future folks blindly following MS
recommendations.
BTW, the original .NET code ran in Mono without recompile,
except for one small issue. I'm tracking down some other issues
now.
thanks again,
wade
On 4/4/06, Felipe Almeida Lessa <[EMAIL PROTECTED]> wrote:
Em Ter, 2006-04-04 às 08:26 -0600, Wade Maxfield escreveu:> Hi,Hi! Correct me if I'm wrong but...> /*doesn't always work >*/Global.WebThread.Abort();You shouldn't be using Thread.Abort
, right? AFAIK, this is a bad way ofkilling threads.> while (!Global.WebThread.IsAlive);Why do you make the CPU go to 100% here? At least some Sleep should bebetter, no?--
I didn't read all of your code, but I suspect you should be usinganother thread abortion method. I have some code that uses a thread withsome web requests, and to abort it I do 2 things:1) Create a variable that is marked false when I want the thread to die.
The thread's code periodically checks for the variable.2) Save the WebRequest on a private variable to try to abort it, ifpossible.The relevant abortion method:public void Abort() {
this.aborted = true;try {if (this.abortable) {this.webRequest.Abort();Logger.Log(this,
"WebRequest aborted with (apparent) success!");} elseLogger.Log(this,
"WebRequest is not abortable.");} catch (Exception e) {Logger.Log(this,
"Failed to abort the WebRequest:\n" + e.ToString());}}The method name is "Abort" because this class does not derive fromThread. Also, you can safely ignore all Logger::Log calls.
abortable is a variable that is set to false when the code starts anoperation on the WebRequest that would probably crash the program if itwas aborted.It's also worth noting that we just try to abort the WebRequest and
ignore any exceptions -- the code will stop anyway sometime soon as weset the aborted variable.HTH,--Felipe.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Thread Abort() sometimes fails in mono
Em Ter, 2006-04-04 às 19:23 +0200, Robert Jordan escreveu: > Felipe Almeida Lessa wrote: > > Em Ter, 2006-04-04 às 08:26 -0600, Wade Maxfield escreveu: > >> Hi, > > > > Hi! Correct me if I'm wrong but... > > > >> /*doesn't always work >*/Global.WebThread.Abort(); > > > > You shouldn't be using Thread.Abort, right? AFAIK, this is a bad way of > > killing threads. > > Thread.Abort() is harmless and more like an exception than a killer. Or not. A quick Google search[1] yields as the second result http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation (and the first result cited this one). Yes, as the article states, it *may* work very well. But it also may not. I don't like to let the mood of the computer change the behavior of my programs, so I take a conservative approach. [1] http://www.google.com.br/search?num=100&q=thread.abort()%20%22.net% 22%20%7C%20%22c%23%22%20%7C%20%22mono%22 Cya, -- Felipe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread Abort() sometimes fails in mono
Em Ter, 2006-04-04 às 11:50 -0600, Wade Maxfield escreveu: >I agree that a sleep() is a good thing while waiting for thread to > start running. However, I thought one of the points of "managed" code > was to allow this sort of thing, not necessarily paying attention to > cpu loading issues, as well as memory issues? That is why I swallowed > MS's tutorial hook line and sinker. No. Really. Managed code help you in loads of usual problems while programming and deploying, but paying attention to CPU and memory issues is something you need in *every* language currently available. If you don't mind those you may end up with a bloated and slow program. > In any case, regardless of the efficacy of the program I've written, > the point that mono developers must ponder is that other coders > following my footsteps will code exactly the same way, the way that > Microsoft Tutorial states it should. When it fails to abort under > mono, but always aborts under .NET, they will claim it is a bug in > Mono. I don't know why the Mono implementation does not work as the MS one, but even in MS .NET I would use the pattern described in my last e-mail, so I wouldn't even notice the difference. Is there any Mono guru reading this e-mail? > It does appear I overlooked a join() call, which forces the first > thread to deadlock until the abort happens. However, I never had the > problem of a failing abort in .NET. In this case, I could care less > if the thread aborted a few hundred milliseconds to one second later > than the main thread. > > As I indicated earlier, I set a variable which caused my routine to > bail, causing the thread to naturally abort (similar to your proposal, > but more crude). This method will work in all versions, .NET and > Mono. IIRC, you can also #ifdef for the appropriate action. But that would turn .NET's binaries incompatible with Mono. Cheers, -- Felipe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: r58871 - trunk/mono/mono/metadata
Hey,
May I backport this?
Robert
Author: miguel
Date: 2006-03-31 19:14:16 -0500 (Fri, 31 Mar 2006)
New Revision: 58871
Modified:
trunk/mono/mono/metadata/ChangeLog
trunk/mono/mono/metadata/icall.c
Log:
2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
* icall.c
(ves_icall_System_Environment_InternalSetEnvironmentVariable): Fix
build on pre glib 2.4 systems.
Modified: trunk/mono/mono/metadata/ChangeLog
===
--- trunk/mono/mono/metadata/ChangeLog 2006-03-31 23:25:18 UTC (rev 58870)
+++ trunk/mono/mono/metadata/ChangeLog 2006-04-01 00:14:16 UTC (rev 58871)
@@ -1,3 +1,9 @@
+2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
+
+ * icall.c
+ (ves_icall_System_Environment_InternalSetEnvironmentVariable): Fix
+ build on pre glib 2.4 systems.
+
2006-03-31 Zoltan Varga <[EMAIL PROTECTED]>
* icall.c (ves_icall_System_Environment_InternalSetEnvironmentVariable): New icall.
Modified: trunk/mono/mono/metadata/icall.c
===
--- trunk/mono/mono/metadata/icall.c2006-03-31 23:25:18 UTC (rev 58870)
+++ trunk/mono/mono/metadata/icall.c2006-04-01 00:14:16 UTC (rev 58871)
@@ -5542,6 +5542,14 @@
return names;
}
+/*
+ * If your platform lacks setenv/unsetenv, you must upgrade your glib.
+ */
+#if !GLIB_CHECK_VERSION(2,4,0)
+#define g_setenv(a,b,c) setenv(a,b,c)
+#define g_unsetenv(a,b,c) unsetenv(a,b,c)
+#endif
+
static void
ves_icall_System_Environment_InternalSetEnvironmentVariable (MonoString *name,
MonoString *value)
{
___
Mono-patches maillist - Mono-patches@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-patches
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monocov patch
Hey, As I said before, feel free to check in stuff to monocov. That particular function is there to deal with the sometimes strange line number info emitted to mcs. Because of this, the function is a bit of a hack/mess. Try checking whenever the output of that function is identical before and after your patch for some large body of code like mcs or mscorlib. If it is, then the loops were really redundant. Zoltan On 4/4/06, Jacob Ilsø Christensen <[EMAIL PROTECTED]> wrote: > Hi. > > I am currently looking a bit at the monocov code as I would like to > make a coverage add-in for MonoDevelop. To better understand what is > going on, I am trying to simplify things a bit. The attached patch > removes two (seemingly) redundant for loops. > > Does this look good to commit? Should I even ask on this list as it > seems monocov is more or less unmaintained? I would also like to add > some unit tests. Anyone did some for monocov? > > /Jacob > > > ___ > 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-dev] Re: r58871 - trunk/mono/mono/metadata
Yes.
Zoltan
On 4/4/06, Robert Jordan <[EMAIL PROTECTED]> wrote:
> Hey,
>
> May I backport this?
>
> Robert
>
> > Author: miguel
> > Date: 2006-03-31 19:14:16 -0500 (Fri, 31 Mar 2006)
> > New Revision: 58871
> >
> > Modified:
> >trunk/mono/mono/metadata/ChangeLog
> >trunk/mono/mono/metadata/icall.c
> > Log:
> > 2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> >
> > * icall.c
> > (ves_icall_System_Environment_InternalSetEnvironmentVariable): Fix
> > build on pre glib 2.4 systems.
> >
> > Modified: trunk/mono/mono/metadata/ChangeLog
> > ===
> > --- trunk/mono/mono/metadata/ChangeLog2006-03-31 23:25:18 UTC (rev
> > 58870)
> > +++ trunk/mono/mono/metadata/ChangeLog2006-04-01 00:14:16 UTC (rev
> > 58871)
> > @@ -1,3 +1,9 @@
> > +2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > +
> > + * icall.c
> > + (ves_icall_System_Environment_InternalSetEnvironmentVariable): Fix
> > + build on pre glib 2.4 systems.
> > +
> > 2006-03-31 Zoltan Varga <[EMAIL PROTECTED]>
> >
> > * icall.c
> > (ves_icall_System_Environment_InternalSetEnvironmentVariable): New icall.
> >
> > Modified: trunk/mono/mono/metadata/icall.c
> > ===
> > --- trunk/mono/mono/metadata/icall.c 2006-03-31 23:25:18 UTC (rev 58870)
> > +++ trunk/mono/mono/metadata/icall.c 2006-04-01 00:14:16 UTC (rev 58871)
> > @@ -5542,6 +5542,14 @@
> > return names;
> > }
> >
> > +/*
> > + * If your platform lacks setenv/unsetenv, you must upgrade your glib.
> > + */
> > +#if !GLIB_CHECK_VERSION(2,4,0)
> > +#define g_setenv(a,b,c) setenv(a,b,c)
> > +#define g_unsetenv(a,b,c) unsetenv(a,b,c)
> > +#endif
> > +
> > static void
> > ves_icall_System_Environment_InternalSetEnvironmentVariable (MonoString
> > *name, MonoString *value)
> > {
> >
> > ___
> > Mono-patches maillist - Mono-patches@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-patches
> >
>
> ___
> 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-dev] Re: Thread Abort() sometimes fails in mono
Felipe Almeida Lessa wrote: Em Ter, 2006-04-04 às 19:23 +0200, Robert Jordan escreveu: Felipe Almeida Lessa wrote: Em Ter, 2006-04-04 às 08:26 -0600, Wade Maxfield escreveu: Hi, Hi! Correct me if I'm wrong but... /*doesn't always work >*/Global.WebThread.Abort(); You shouldn't be using Thread.Abort, right? AFAIK, this is a bad way of killing threads. Thread.Abort() is harmless and more like an exception than a killer. Or not. A quick Google search[1] yields as the second result http://www.interact-sw.co.uk/iangblog/2004/11/12/cancellation (and the first result cited this one). Calling someOtherThread.Abort() is of course evil. I was not aware that Abort() is not static. But Thread.CurrentThread.Abort() is really harmless ;-) Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Solaris x86 and mono
I was trying to build 1.1.14 in Solaris 10 and Solaris 8, both x86, and I got this message from both builds. http://pastebin.com/640528 I also got the same message building from svn. Previous versions up to 1.1.13.6 builds ok. Should i file a bug report? -- Jonel Rienton mailto:[EMAIL PROTECTED] powered by: google ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Solaris x86 and mono
I think this is caused by this change: extern MonoDefaults mono_defaults MONO_INTERNAL; in class-internals.h. Lupus ? Zoltan On 4/4/06, Jonel Rienton <[EMAIL PROTECTED]> wrote: > I was trying to build 1.1.14 in Solaris 10 and Solaris 8, both x86, > and I got this message from both builds. > > http://pastebin.com/640528 > > I also got the same message building from svn. Previous versions up to > 1.1.13.6 builds ok. Should i file a bug report? > > -- > Jonel Rienton > mailto:[EMAIL PROTECTED] > powered by: google > ___ > 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-dev] Thread Abort() sometimes fails in mono
Well, to get back to the original question... When doing a web request, or perhaps when printing to the console, sometimes the Abort() call from the main thread to the webthread does not abort the webthread. Is this a bug, or is it expected? thanks, wade P.S. I read the article Felipe pointed to. There is a well taken point in the article. That point is you don't know what state the thread is in when doing the abort. Abort() creates an exception and can leave things hanging. In all the programs I've written, when I leave the world, I don't care what the code was doing, I sometimes just want it to stop. Generally, with a well managed OS, you'll have files closed and memory released. The files may be incomplete, but that is what happens if you quit too soon. If you are writing a "monitor" application whose job is to monitor but not change the state of things, Abort() is acceptable when exiting. If you are writing a financial package, Abort() is not acceptable during a disk write of your bank's latest transaction to your checking account. Abort() should guarantee exiting, IMHO, due to historical usage of abort in the computing world. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
This causes me trouble building in VS. It doesn't find setenv or
unsetenv. Should I be using something else like SetEnvironmentVariable
on Windows, or do I just have something wrong?
Thanks,
Jonathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zoltan
Varga
Sent: Tuesday, April 04, 2006 2:48 PM
To: Robert Jordan
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
Yes.
Zoltan
On 4/4/06, Robert Jordan <[EMAIL PROTECTED]> wrote:
> Hey,
>
> May I backport this?
>
> Robert
>
> > Author: miguel
> > Date: 2006-03-31 19:14:16 -0500 (Fri, 31 Mar 2006)
> > New Revision: 58871
> >
> > Modified:
> >trunk/mono/mono/metadata/ChangeLog
> >trunk/mono/mono/metadata/icall.c
> > Log:
> > 2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> >
> > * icall.c
> > (ves_icall_System_Environment_InternalSetEnvironmentVariable):
Fix
> > build on pre glib 2.4 systems.
> >
> > Modified: trunk/mono/mono/metadata/ChangeLog
> > ===
> > --- trunk/mono/mono/metadata/ChangeLog2006-03-31 23:25:18
UTC (rev 58870)
> > +++ trunk/mono/mono/metadata/ChangeLog2006-04-01 00:14:16
UTC (rev 58871)
> > @@ -1,3 +1,9 @@
> > +2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > +
> > + * icall.c
> > + (ves_icall_System_Environment_InternalSetEnvironmentVariable):
Fix
> > + build on pre glib 2.4 systems.
> > +
> > 2006-03-31 Zoltan Varga <[EMAIL PROTECTED]>
> >
> > * icall.c
(ves_icall_System_Environment_InternalSetEnvironmentVariable): New
icall.
> >
> > Modified: trunk/mono/mono/metadata/icall.c
> > ===
> > --- trunk/mono/mono/metadata/icall.c 2006-03-31 23:25:18 UTC (rev
58870)
> > +++ trunk/mono/mono/metadata/icall.c 2006-04-01 00:14:16 UTC (rev
58871)
> > @@ -5542,6 +5542,14 @@
> > return names;
> > }
> >
> > +/*
> > + * If your platform lacks setenv/unsetenv, you must upgrade your
glib.
> > + */
> > +#if !GLIB_CHECK_VERSION(2,4,0)
> > +#define g_setenv(a,b,c) setenv(a,b,c)
> > +#define g_unsetenv(a,b,c) unsetenv(a,b,c)
> > +#endif
> > +
> > static void
> > ves_icall_System_Environment_InternalSetEnvironmentVariable
(MonoString *name, MonoString *value)
> > {
> >
> > ___
> > Mono-patches maillist - Mono-patches@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-patches
> >
>
> ___
> 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
[Mono-dev] RE: Thread Abort() sometimes fails in mono
Hmm. I'm getting closer to answering my own question, of what is happening.
It *appears* that Abort() is throwing an exception when it is in the WebRequest object, causing the catch{} to catch it.
If the code is in the while() loop processing code, then Abort()
doesn't throw an exception, it just marks the thread for
aborting, and the thread does abort, without going through the catch{}
wade
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
Hi,
You might be using a glib version older than 2.4.0, which was
released more than
two years ago.
Zoltan
On 4/4/06, Jonathan S. Chambers <[EMAIL PROTECTED]> wrote:
> This causes me trouble building in VS. It doesn't find setenv or
> unsetenv. Should I be using something else like SetEnvironmentVariable
> on Windows, or do I just have something wrong?
>
> Thanks,
> Jonathan
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan
> Varga
> Sent: Tuesday, April 04, 2006 2:48 PM
> To: Robert Jordan
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
>
> Yes.
>
> Zoltan
>
> On 4/4/06, Robert Jordan <[EMAIL PROTECTED]> wrote:
> > Hey,
> >
> > May I backport this?
> >
> > Robert
> >
> > > Author: miguel
> > > Date: 2006-03-31 19:14:16 -0500 (Fri, 31 Mar 2006)
> > > New Revision: 58871
> > >
> > > Modified:
> > >trunk/mono/mono/metadata/ChangeLog
> > >trunk/mono/mono/metadata/icall.c
> > > Log:
> > > 2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > >
> > > * icall.c
> > > (ves_icall_System_Environment_InternalSetEnvironmentVariable):
> Fix
> > > build on pre glib 2.4 systems.
> > >
> > > Modified: trunk/mono/mono/metadata/ChangeLog
> > > ===
> > > --- trunk/mono/mono/metadata/ChangeLog2006-03-31 23:25:18
> UTC (rev 58870)
> > > +++ trunk/mono/mono/metadata/ChangeLog2006-04-01 00:14:16
> UTC (rev 58871)
> > > @@ -1,3 +1,9 @@
> > > +2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > > +
> > > + * icall.c
> > > + (ves_icall_System_Environment_InternalSetEnvironmentVariable):
> Fix
> > > + build on pre glib 2.4 systems.
> > > +
> > > 2006-03-31 Zoltan Varga <[EMAIL PROTECTED]>
> > >
> > > * icall.c
> (ves_icall_System_Environment_InternalSetEnvironmentVariable): New
> icall.
> > >
> > > Modified: trunk/mono/mono/metadata/icall.c
> > > ===
> > > --- trunk/mono/mono/metadata/icall.c 2006-03-31 23:25:18 UTC (rev
> 58870)
> > > +++ trunk/mono/mono/metadata/icall.c 2006-04-01 00:14:16 UTC (rev
> 58871)
> > > @@ -5542,6 +5542,14 @@
> > > return names;
> > > }
> > >
> > > +/*
> > > + * If your platform lacks setenv/unsetenv, you must upgrade your
> glib.
> > > + */
> > > +#if !GLIB_CHECK_VERSION(2,4,0)
> > > +#define g_setenv(a,b,c) setenv(a,b,c)
> > > +#define g_unsetenv(a,b,c) unsetenv(a,b,c)
> > > +#endif
> > > +
> > > static void
> > > ves_icall_System_Environment_InternalSetEnvironmentVariable
> (MonoString *name, MonoString *value)
> > > {
> > >
> > > ___
> > > Mono-patches maillist - Mono-patches@lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-patches
> > >
> >
> > ___
> > 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
Fw: [Mono-dev] [PATCH]: Avoid --with-static_mono=no problems on Linux/Sparc
Ping? --- Begin Message --- Currently, on sparc*-*-linux*, libgc uses _etext to try and figure out where the data section starts. This is problematic for two reasons. There is a more portable and better performing version of this being used by other Linux platforms, so Sparc should use it as well. Using _etext is problematic for another reason. We end up with a reference to _etext in the libgc shared object, and when the mono JIT binary is build non-static, we end up with a funny versioned symbol entry for _etext in the binary because of the versioning linker scripts used. This causes problems for the glibc dynamic linker, and in fact a crash. I am working that glibc dynamic linker issue out with the libc folks independantly, it could very well be a binutils bug. This patch cures both issues. I intend to pass this up to the main Boehm-GC sources and into gcc's copy eventually as well. Thanks. 2006-03-28 David S. Miller <[EMAIL PROTECTED]> * include/private/gcconfig.h (LINUX and SPARC): Do not use _etest and GC_SysVGetDataStart() to figure out DATASTART. Instead use either SEARCH_FOR_DATA_START or __environ, based upin GLIBC version. --- libgc/include/private/gcconfig.h.~1~2005-12-26 10:45:29.0 -0800 +++ libgc/include/private/gcconfig.h2006-03-29 04:10:35.0 -0800 @@ -907,17 +907,28 @@ # else Linux Sparc/a.out not supported # endif +# define SVR4 +# include +# if defined(__GLIBC__) && __GLIBC__ >= 2 +# define SEARCH_FOR_DATA_START +# else + extern char **__environ; +# define DATASTART ((ptr_t)(&__environ)) + /* hideous kludge: __environ is the first */ + /* word in crt0.o, and delimits the start */ + /* of the data segment, no matter which */ + /* ld options were passed through.*/ + /* We could use _etext instead, but that */ + /* would include .rodata, which may */ + /* contain large read-only data tables*/ + /* that we'd rather not scan. */ +# endif extern int _end[]; - extern int _etext[]; # define DATAEND (_end) -# define SVR4 - extern ptr_t GC_SysVGetDataStart(); # ifdef __arch64__ -# define DATASTART GC_SysVGetDataStart(0x10, _etext) /* libc_stack_end is not set reliably for sparc64 */ # define STACKBOTTOM ((ptr_t) 0x800ULL) # else -# define DATASTART GC_SysVGetDataStart(0x1, _etext) # define LINUX_STACKBOTTOM # endif # endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list --- End Message --- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]: Fix lexical block reading when UNALIGNED or big-endian
From: "Zoltan Varga" <[EMAIL PROTECTED]> Date: Tue, 28 Mar 2006 12:52:31 +0200 > This issue is tracked in > > http://bugzilla.ximian.com/show_bug.cgi?id=75056 > > which somehow got closed despite the fact that the problems are still there. How much longer will this sit or has my fix been applied already? If my fix is incorrect or incomplete, what's wrong with it? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_sparc_lock
Zoltan, what about a compromise patch that does my new code when GCC is being used and we'll do the old _wapi_sparc_lock stuff for non-GCC. Would you apply that? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
Yes, I am. I will upgrade.
Thanks.
-Original Message-
From: Zoltan Varga [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 3:43 PM
To: Jonathan S. Chambers
Cc: Robert Jordan; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
Hi,
You might be using a glib version older than 2.4.0, which was
released more than
two years ago.
Zoltan
On 4/4/06, Jonathan S. Chambers <[EMAIL PROTECTED]> wrote:
> This causes me trouble building in VS. It doesn't find setenv or
> unsetenv. Should I be using something else like SetEnvironmentVariable
> on Windows, or do I just have something wrong?
>
> Thanks,
> Jonathan
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan
> Varga
> Sent: Tuesday, April 04, 2006 2:48 PM
> To: Robert Jordan
> Cc: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Re: r58871 - trunk/mono/mono/metadata
>
> Yes.
>
> Zoltan
>
> On 4/4/06, Robert Jordan <[EMAIL PROTECTED]> wrote:
> > Hey,
> >
> > May I backport this?
> >
> > Robert
> >
> > > Author: miguel
> > > Date: 2006-03-31 19:14:16 -0500 (Fri, 31 Mar 2006)
> > > New Revision: 58871
> > >
> > > Modified:
> > >trunk/mono/mono/metadata/ChangeLog
> > >trunk/mono/mono/metadata/icall.c
> > > Log:
> > > 2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > >
> > > * icall.c
> > >
(ves_icall_System_Environment_InternalSetEnvironmentVariable):
> Fix
> > > build on pre glib 2.4 systems.
> > >
> > > Modified: trunk/mono/mono/metadata/ChangeLog
> > >
===
> > > --- trunk/mono/mono/metadata/ChangeLog2006-03-31 23:25:18
> UTC (rev 58870)
> > > +++ trunk/mono/mono/metadata/ChangeLog2006-04-01 00:14:16
> UTC (rev 58871)
> > > @@ -1,3 +1,9 @@
> > > +2006-03-31 Miguel de Icaza <[EMAIL PROTECTED]>
> > > +
> > > + * icall.c
> > > +
(ves_icall_System_Environment_InternalSetEnvironmentVariable):
> Fix
> > > + build on pre glib 2.4 systems.
> > > +
> > > 2006-03-31 Zoltan Varga <[EMAIL PROTECTED]>
> > >
> > > * icall.c
> (ves_icall_System_Environment_InternalSetEnvironmentVariable): New
> icall.
> > >
> > > Modified: trunk/mono/mono/metadata/icall.c
> > >
===
> > > --- trunk/mono/mono/metadata/icall.c 2006-03-31 23:25:18 UTC (rev
> 58870)
> > > +++ trunk/mono/mono/metadata/icall.c 2006-04-01 00:14:16 UTC (rev
> 58871)
> > > @@ -5542,6 +5542,14 @@
> > > return names;
> > > }
> > >
> > > +/*
> > > + * If your platform lacks setenv/unsetenv, you must upgrade your
> glib.
> > > + */
> > > +#if !GLIB_CHECK_VERSION(2,4,0)
> > > +#define g_setenv(a,b,c) setenv(a,b,c)
> > > +#define g_unsetenv(a,b,c) unsetenv(a,b,c)
> > > +#endif
> > > +
> > > static void
> > > ves_icall_System_Environment_InternalSetEnvironmentVariable
> (MonoString *name, MonoString *value)
> > > {
> > >
> > > ___
> > > Mono-patches maillist - Mono-patches@lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-patches
> > >
> >
> > ___
> > 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-dev] _wapi_sparc_lock
I already checked in that patch :). It should be in mono 1.1.14. Zoltan On 4/4/06, David S. Miller <[EMAIL PROTECTED]> wrote: > > Zoltan, what about a compromise patch that does my new code when GCC > is being used and we'll do the old _wapi_sparc_lock stuff for non-GCC. > Would you apply that? > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread Abort() sometimes fails in mono
El mar, 04-04-2006 a las 13:16 -0600, Wade Maxfield escribió: > > Well, to get back to the original question... > > When doing a web request, or perhaps when printing to the console, > sometimes the Abort() call from the main thread to the webthread does > not abort the webthread. > >Is this a bug, or is it expected? This might be a bug. If you have a simple test app that can be used to reproduce the problem, file a bug in bugzilla.ximian.com and attach it there. > > thanks, > wade > P.S. > >I read the article Felipe pointed to. > >There is a well taken point in the article. That point is you > don't know what state the thread is in when doing the abort. Abort() > creates an exception and can leave things hanging. > > In all the programs I've written, when I leave the world, I don't > care what the code was doing, I sometimes just want it to stop. > Generally, with a well managed OS, you'll have files closed and memory > released. The files may be incomplete, but that is what happens if > you quit too soon. > >If you are writing a "monitor" application whose job is to monitor > but not change the state of things, Abort() is acceptable when > exiting. If you are writing a financial package, Abort() is not > acceptable during a disk write of your bank's latest transaction to > your checking account. > > Abort() should guarantee exiting, IMHO, due to historical usage of > abort in the computing world. > > ___ > 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-dev] Re: Thread Abort() sometimes fails in mono
Em Ter, 2006-04-04 às 20:49 +0200, Robert Jordan escreveu: > Calling someOtherThread.Abort() is of course evil. I was not aware > that Abort() is not static. Static? Uh? How? You mean... you call Thread.Abort() and it closes the current thread? The whole application? > But Thread.CurrentThread.Abort() is > really harmless ;-) I'm sure I can't change your mind on this one :-). -- Felipe. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] compile error on WIN32 (libgdiplus)
Hello - I am getting these errors when trying to compile libgdiplus on WIN32... this is the latest code from SVN. From what I can see icint.h is trying to use __int64. See below for second error in cairoint.hAll 3 problems seem to be related to header definitions: __int64 in icint.hpthread.hINT32 in Xmd.h vs. basetsd.h>uname -aCYGWIN_NT-5.1 Fardalay 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 CygwinI am building from ./autogen.sh; make Any help for getting mono compiled on WIN32 would be greatly appreciated.Thanks,Duanemake all-recursivemake[1]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus'Making all in cairo make[2]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo'make all-recursivemake[3]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo'Making all in pixmanmake[4]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman' Making all in srcmake[5]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman/src'if /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I. -I/usr/local/include -g -O2 -MT fbpict.lo -MD -MP -MF ".deps/fbpict.Tpo" -c -o fbpict.lo fbpict.c; \then mv -f ".deps/fbpict.Tpo" ".deps/fbpict.Plo"; else rm -f ".deps/fbpict.Tpo"; exit 1; fi gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I. -I/usr/local/include -g -O2 -MT fbpict.lo -MD -MP -MF .deps/fbpict.Tpo -c fbpict.c -DPIC -o .libs/fbpict.oIn file included from pixman-xserver-compat.h:47, from fbpict.c:29:icint.h:1009: error: parse error before "xFixed_32_32" icint.h:1009: warning: data definition has no type or storage classicint.h:1027: error: parse error before "xFixed_48_16"icint.h:1027: warning: data definition has no type or storage classmake[5]: *** [ fbpict.lo] Error 1make[5]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman/src'make[4]: *** [all-recursive] Error 1make[4]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman' make[3]: *** [all-recursive] Error 1make[3]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo'make[2]: *** [all] Error 2make[2]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo' make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus'make: *** [all] Error 2-->> second error make[4]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman'Making all in srcmake[4]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/src'if /bin/sh ../libtool --tag=CC --mode=compile gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../pixman/src -I/usr/include/libpng12-Id:/PROGRA~1/MONO-1~1.14/include -Id:/PROGRA~1/MONO-1~1.14/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/local/include -g -O2 -MT cairo.lo -MD -MP -MF ".deps/cairo.Tpo" -c -o cairo.lo cairo.c; \then mv -f ".deps/cairo.Tpo" ".deps/cairo.Plo"; else rm -f ".deps/cairo.Tpo"; exit 1; fi gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../pixman/src -I/usr/include/libpng12 "-Id:/PROGRA~1/MONO-1~1.14/include" "-Id:/PROGRA~1/MONO-1~1.14/include/freetype2" -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/local/include -g -O2 -MT cairo.lo -MD -MP -MF .deps/cairo.Tpo -c cairo.c -DPIC -o .libs/cairo.oIn file included from cairoint.h:134, from cairo.c:38:/usr/include/pthread.h:75: error: parse error before '*' token/usr/include/pthread.h:76: error: parse error before '*' token /usr/include/pthread.h:77: error: parse error before '*' token/usr/include/pthread.h:78: error: parse error before '*' token/usr/include/pthread.h:79: error: parse error before '*' token/usr/include/pthread.h:80: error: parse error before '*' token /usr/include/pthread.h:81: error: parse error before '*' token/usr/include/pthread.h:82: error: parse error before '*' token/usr/include/pthread.h:83: error: parse error before '*' token/usr/include/pthread.h:84: error: parse error before '*' token /usr/include/pthread.h:85: error: parse error before '*' token/usr/include/pthread.h:86: error: parse error before '*' token/usr/include/pthread.h:125: error: parse error before '*' token/usr/include/pthread.h:126: error: parse error before '*' token /usr/include/pthread.h:127: error: parse error before '*' token/usr/include/pthread.h:128: error: parse error before '*' token/usr/include/pthread.h:129: error: parse error before '*' token/usr/include/pthread.h:131: error: parse error before '*' token /usr/include/pthread.h:132: error: parse error before '*' token/usr/include/pthread.h:133: error: parse error before '*' token/usr/include/pthread.h:134: error: parse error before '*' token/usr/include/pthread.h:135:
Re: [Mono-dev] _wapi_sparc_lock
From: "Zoltan Varga" <[EMAIL PROTECTED]>
Date: Tue, 4 Apr 2006 22:18:50 +0200
> I already checked in that patch :). It should be in mono 1.1.14.
Great, thanks. Will there be a mono-1-1-14 branch or will that
simply come from the trunk?
The only major issue I have now is a crash in f-spot when trying
to start an import. The test case boils down to:
port_info_list = new PortInfoList ();
port_info_list.Load ();
in the constructor for the GPhotoCamera() class in f-spot.
The implementation of these two methods is pretty simple,
from libgphoto2-sharp/PortInfoList.cs:
[DllImport ("libgphoto2.so")]
internal static extern ErrorCode gp_port_info_list_new (out
IntPtr handle);
public PortInfoList()
{
IntPtr native;
Error.CheckError (gp_port_info_list_new (out native));
this.handle = new HandleRef (this, native);
}
...
[DllImport ("libgphoto2.so")]
internal static extern ErrorCode gp_port_info_list_load
(HandleRef handle);
public void Load ()
{
ErrorCode result = gp_port_info_list_load (this.Handle);
if (Error.IsError (result))
throw Error.ErrorException (result);
}
The pointer passed into gp_port_info_list_load() is bogus. I added
some debugging to libgphoto2-port and mini-sparc.c and this is the
log that I capture:
("cc" means "calling_convention" and "sp" is "sentinelpos")
mono_arch_call_opcode(): name[gp_port_info_list_new] pcount[1] hasthis[0] cc[0]
sp[-1]
mono_arch_call_opcode(): arg[0] storage[0] reg[0] off[0]
mono_arch_call_opcode(): PARAMS[0] ISSTRUCT(0)
ARG[0]: type[24]
gp_port_info_list_new: list[0xff17bf8c] *list[(nil)]
gp_port_info_list_new: *list is now 0x67c390
Ok, that was the call to gp_port_info_list_new().
mono_arch_call_opcode(): name[gp_port_info_list_load] pcount[1] hasthis[0]
cc[0] sp[-1]
mono_arch_call_opcode(): arg[0] storage[0] reg[0] off[0]
mono_arch_call_opcode(): PARAMS[0] ISSTRUCT(1)
ARG[0]: type[17]
class_value_size: size[8] align[4]
gp_port_info_list_load: list[0xff17bee4]
And that's the call to gp_port_info_list_load(). The argument should
have been 0x67c390 but somehow we end up with a pass-by-reference of
an object that gets placed onto the stack. That's very weird.
I'm surprised something so simple like this fails, the whole UI can
get drawn and that calls into many GTK# dll imports which pass
pointers etc. :-)
Any ideas?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] compile error on WIN32 (libgdiplus)
Uh, you should never ever compile libgdiplus on win32. It's not meant to do that. And you already have libgdiplus on Windows. It ships with the OS. Cheers, Peter -Original Message- From: "Duane Wandless" <[EMAIL PROTECTED]> To: Date: 04 April, 2006 15:07 Subject: [Mono-dev] compile error on WIN32 (libgdiplus) Hello - I am getting these errors when trying to compile libgdiplus on WIN32... this is the latest code from SVN. From what I can see icint.h is trying to use __int64. See below for second error in cairoint.h All 3 problems seem to be related to header definitions: __int64 in icint.h pthread.h INT32 in Xmd.h vs. basetsd.h >uname -a CYGWIN_NT-5.1 Fardalay 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin I am building from ./autogen.sh; make Any help for getting mono compiled on WIN32 would be greatly appreciated. Thanks, Duane make all-recursive make[1]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus' Making all in cairo make[2]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo' make all-recursive make[3]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo' Making all in pixman make[4]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman' Making all in src make[5]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman/src' if /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I. -I/usr/local/include -g -O2 -MT fbpict.lo -MD -MP -MF ".deps/fbpict.Tpo" -c -o fbpict.lo fbpict.c; \ then mv -f ".deps/fbpict.Tpo" ".deps/fbpict.Plo"; else rm -f ".deps/fbpict.Tpo"; exit 1; fi gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I. -I/usr/local/include -g -O2 -MT fbpict.lo -MD -MP -MF .deps/fbpict.Tpo -c fbpict.c -DPIC -o .libs/fbpict.o In file included from pixman-xserver-compat.h:47, from fbpict.c:29: icint.h:1009: error: parse error before "xFixed_32_32" icint.h:1009: warning: data definition has no type or storage class icint.h:1027: error: parse error before "xFixed_48_16" icint.h:1027: warning: data definition has no type or storage class make[5]: *** [fbpict.lo] Error 1 make[5]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo' make[2]: *** [all] Error 2 make[2]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus' make: *** [all] Error 2 -->> second error make[4]: Leaving directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/pixman' Making all in src make[4]: Entering directory `/download/mono-src/libgdiplusSVN/libgdiplus/cairo/src' if /bin/sh ../libtool --tag=CC --mode=compile gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../pixman/src -I/usr/include/libpng12-Id:/PROGRA~1/MONO-1~1.14/include -Id:/PROGRA~1/MONO-1~1.14/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/local/include -g -O2 -MT cairo.lo -MD -MP -MF ".deps/cairo.Tpo" -c -o cairo.lo cairo.c; \ then mv -f ".deps/cairo.Tpo" ".deps/cairo.Plo"; else rm -f ".deps/cairo.Tpo"; exit 1; fi gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../pixman/src -I/usr/include/libpng12 "-Id:/PROGRA~1/MONO-1~1.14/include" "-Id:/PROGRA~1/MONO-1~1.14/include/freetype2" -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/local/include -g -O2 -MT cairo.lo -MD -MP -MF .deps/cairo.Tpo -c cairo.c -DPIC -o .libs/cairo.o In file included from cairoint.h:134, from cairo.c:38: /usr/include/pthread.h:75: error: parse error before '*' token /usr/include/pthread.h:76: error: parse error before '*' token /usr/include/pthread.h:77: error: parse error before '*' token /usr/include/pthread.h:78: error: parse error before '*' token /usr/include/pthread.h:79: error: parse error before '*' token /usr/include/pthread.h:80: error: parse error before '*' token /usr/include/pthread.h:81: error: parse error before '*' token /usr/include/pthread.h:82: error: parse error before '*' token /usr/include/pthread.h:83: error: parse error before '*' token /usr/include/pthread.h:84: error: parse error before '*' token /usr/include/pthread.h:85: error: parse error before '*' token /usr/include/pthread.h:86: error: parse error before '*' token /usr/include/pthread.h:125: error: parse error before '*' token /usr/include/pthread.h:126: error: parse error before '*' token /usr/include/pthread.h:127: error: parse error before '*' token /usr/include/pthread.h:12
Re: [Mono-dev] Bug?: Mcs Custom Attribute Handling
Hello Norbert, After compiling 'mono-tools-1.1.11' by 'mcs-1.1.14' I ran into some trouble during execution of 'browser.exe'. IMHO recent version(s) of mcs (1.1.14 and may be earlier) introduce a bug custom attribute handling. Yes, you are right. Could you please fill a bug report. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: Fw: [Mono-dev] [PATCH]: Avoid --with-static_mono=no problems on Linux/Sparc
Hey, The patch no longer applies cleanly to gcconfig.h in mono SVN. Zoltan On 4/4/06, David S. Miller <[EMAIL PROTECTED]> wrote: > > Ping? > > > > -- Forwarded message -- > From: "David S. Miller" <[EMAIL PROTECTED]> > To: mono-devel-list@lists.ximian.com > Date: Tue, 28 Mar 2006 23:55:15 -0800 (PST) > Subject: [Mono-dev] [PATCH]: Avoid --with-static_mono=no problems on > Linux/Sparc > > Currently, on sparc*-*-linux*, libgc uses _etext to try and figure > out where the data section starts. This is problematic for two > reasons. > > There is a more portable and better performing version of this > being used by other Linux platforms, so Sparc should use it as > well. > > Using _etext is problematic for another reason. We end up with a > reference to _etext in the libgc shared object, and when the mono JIT > binary is build non-static, we end up with a funny versioned symbol > entry for _etext in the binary because of the versioning linker > scripts used. This causes problems for the glibc dynamic linker, and > in fact a crash. > > I am working that glibc dynamic linker issue out with the libc folks > independantly, it could very well be a binutils bug. > > This patch cures both issues. I intend to pass this up to the > main Boehm-GC sources and into gcc's copy eventually as well. > > Thanks. > > 2006-03-28 David S. Miller <[EMAIL PROTECTED]> > > * include/private/gcconfig.h (LINUX and SPARC): Do not > use _etest and GC_SysVGetDataStart() to figure out DATASTART. > Instead use either SEARCH_FOR_DATA_START or __environ, based > upin GLIBC version. > > --- libgc/include/private/gcconfig.h.~1~2005-12-26 10:45:29.0 > -0800 > +++ libgc/include/private/gcconfig.h2006-03-29 04:10:35.0 -0800 > @@ -907,17 +907,28 @@ > # else >Linux Sparc/a.out not supported > # endif > +# define SVR4 > +# include > +# if defined(__GLIBC__) && __GLIBC__ >= 2 > +# define SEARCH_FOR_DATA_START > +# else > + extern char **__environ; > +# define DATASTART ((ptr_t)(&__environ)) > + /* hideous kludge: __environ is the first */ > + /* word in crt0.o, and delimits the start */ > + /* of the data segment, no matter which */ > + /* ld options were passed through.*/ > + /* We could use _etext instead, but that */ > + /* would include .rodata, which may */ > + /* contain large read-only data tables*/ > + /* that we'd rather not scan. */ > +# endif >extern int _end[]; > - extern int _etext[]; > # define DATAEND (_end) > -# define SVR4 > - extern ptr_t GC_SysVGetDataStart(); > # ifdef __arch64__ > -# define DATASTART GC_SysVGetDataStart(0x10, _etext) > /* libc_stack_end is not set reliably for sparc64 */ > # define STACKBOTTOM ((ptr_t) 0x800ULL) > # else > -# define DATASTART GC_SysVGetDataStart(0x1, _etext) > # define LINUX_STACKBOTTOM > # endif > # endif > ___ > 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
[Mono-dev] mono 1.1.14 WIN32 runtime error
First thanks for reading... then thanks for helping if you can!Trying to run a simple System.Windows.Forms app (see very bottom for code) gives this:$ which gdiplus.dll/cygdrive/c/WINDOWS/system32/gdiplus.dll
$ MONO_DEBUG_LEVEL=debug mono test.exeMono-INFO: DllImport attempting to load: 'gdiplus.dll'.Mono-INFO: DllImport loading location: 'gdiplus.dll'.Mono-INFO: Searching for 'GdipLoadImageFromDelegate_linux'.
Mono-INFO: Probing 'GdipLoadImageFromDelegate_linux'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.Mono-INFO: Probing '[EMAIL PROTECTED]'.
< this continues for awhileUnhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.Form
---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidProgramException: Invalid IL code in (wrapper managed-to-native) System.Drawing.GDIPlus:GdipLoadImageFromStream
(System.Runtime.InteropServices.UCOMIStream,intptr&): IL_0010: call 0x0002in <0x0> in <0x001d3> System.Drawing.Image:InitFromStream (System.IO.Stream stream)
in <0x000fb> System.Drawing.Bitmap:.ctor (System.Runtime.Serialization.SerializationInfo info, StreamingContext context)in <0x0> in (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke
(object,object[])in <0x0008d> System.Reflection.MonoCMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)--- End of inner exception stack trace ---
in <0x0010e> System.Reflection.MonoCMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)in <0x0001a>
System.Reflection.MethodBase:Invoke (System.Object obj, System.Object[] parameters)in <0x001db> System.Runtime.Serialization.ObjectRecord:LoadData (System.Runtime.Serialization.ObjectManager manager, ISurrogateSelector selector, StreamingContext context)
in <0x00110> System.Runtime.Serialization.ObjectManager:DoFixups ()in <0x00042> System.Runtime.Serialization.Formatters.Binary.ObjectReader:ReadNextObject (System.IO.BinaryReader reader)in <0x000a3>
System.Runtime.Serialization.Formatters.Binary.ObjectReader:ReadObjectGraph (System.IO.BinaryReader reader, Boolean readHeaders, System.Object result, System.Runtime.Remoting.Messaging.Header[] headers)in <0x0011f>
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter:NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler)in <0xf> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter:Deserialize
(System.IO.Stream serializationStream)in <0x00032> System.Resources.ResourceReader:ReadNonPredefinedValue (System.Type exp_type)in <0x0031e> System.Resources.ResourceReader:ReadValueVer1 (System.Type type)
in <0x00163> System.Resources.ResourceReader:ResourceValue (Int32 index)in <0x00028> System.Resources.ResourceReader+ResourceEnumerator:get_Value ()in <0x0007e> System.Resources.ResourceSet:ReadResources
()in <0x00049> System.Resources.ResourceSet:GetObject (System.String name, Boolean ignoreCase)in <0x0007a> System.Resources.ResourceManager:GetObject (System.String name, System.Globalization.CultureInfo
culture)in <0x00010> System.Resources.ResourceManager:GetObject (System.String name)in <0x00017> System.Windows.Forms.Locale:GetResource (System.String name)in <0x00011> System.Windows.Forms.Form:.cctor
()--- End of inner exception stack trace ---in <0x0> in <0xb> WindowsApplication1.Form1:.ctor ()in (wrapper remoting-invoke-with-check) WindowsApplication1.Form1:.ctor
()in <0x00018> WindowsApplication1.Program:Main ()===source codeusing System;using System.Windows.Forms;namespace WindowsApplication1{ public partial class Form1 : Form
{ public Form1() { } } static class Program { /// /// The main entry point for the application. ///
static void Main() { Application.Run(new Form1()); } }}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH]: Avoid --with-static_mono=no problems on Linux/Sparc
From: "Zoltan Varga" <[EMAIL PROTECTED]> Date: Wed, 5 Apr 2006 00:28:25 +0200 > The patch no longer applies cleanly to gcconfig.h in mono SVN. Here's an updated version: 2006-04-04 David S. Miller <[EMAIL PROTECTED]> * include/private/gcconfig.h (LINUX and SPARC): Do not use _etest and GC_SysVGetDataStart() to figure out DATASTART. Instead use either SEARCH_FOR_DATA_START or __environ, based upin GLIBC version. --- include/private/gcconfig.h.~1~ 2006-04-04 14:14:58.0 -0700 +++ include/private/gcconfig.h 2006-04-04 15:31:57.0 -0700 @@ -990,16 +990,24 @@ # else Linux Sparc/a.out not supported # endif - extern int _end[]; - extern int _etext[]; -# define DATAEND (_end) # define SVR4 - extern ptr_t GC_SysVGetDataStart(); -# ifdef __arch64__ -# define DATASTART GC_SysVGetDataStart(0x10, _etext) +# include +# if defined(__GLIBC__) && __GLIBC__ >= 2 +# define SEARCH_FOR_DATA_START # else -# define DATASTART GC_SysVGetDataStart(0x1, _etext) + extern char **__environ; +# define DATASTART ((ptr_t)(&__environ)) + /* hideous kludge: __environ is the first */ + /* word in crt0.o, and delimits the start */ + /* of the data segment, no matter which */ + /* ld options were passed through.*/ + /* We could use _etext instead, but that */ + /* would include .rodata, which may */ + /* contain large read-only data tables*/ + /* that we'd rather not scan. */ # endif + extern int _end[]; +# define DATAEND (_end) # define LINUX_STACKBOTTOM # endif # ifdef OPENBSD ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono 1.1.14 WIN32 runtime error
Already logged here:
http://bugzilla.ximian.com/show_bug.cgi?id=77896
Many people are running into this. Seems to pretty much render Winforms
useless on Win32. Waiting for Paolo on that one.
Cheers,
Peter
-Original Message-
From: "Duane Wandless" <[EMAIL PROTECTED]>
To:
Date: 04 April, 2006 16:37
Subject: [Mono-dev] mono 1.1.14 WIN32 runtime error
First thanks for reading... then thanks for helping if you can!
Trying to run a simple System.Windows.Forms app (see very bottom for code)
gives this:
$ which gdiplus.dll
/cygdrive/c/WINDOWS/system32/gdiplus.dll
$ MONO_DEBUG_LEVEL=debug mono test.exe
Mono-INFO: DllImport attempting to load: 'gdiplus.dll'.
Mono-INFO: DllImport loading location: 'gdiplus.dll'.
Mono-INFO: Searching for 'GdipLoadImageFromDelegate_linux'.
Mono-INFO: Probing 'GdipLoadImageFromDelegate_linux'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
Mono-INFO: Probing '[EMAIL PROTECTED]'.
< this continues for awhile
Unhandled Exception: System.TypeInitializationException: An exception
was thrown by the type initializer for System.Windows.Forms.Form --->
System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation. ---> System.InvalidProgramException:
Invalid IL code in (wrapper managed-to-native)
System.Drawing.GDIPlus:GdipLoadImageFromStream
(System.Runtime.InteropServices.UCOMIStream,intptr&): IL_0010: call
0x0002
in <0x0>
in <0x001d3> System.Drawing.Image:InitFromStream (System.IO.Stream stream)
in <0x000fb> System.Drawing.Bitmap:.ctor
(System.Runtime.Serialization.SerializationInfo info, StreamingContext
context)
in <0x0>
in (wrapper managed-to-native)
System.Reflection.MonoCMethod:InternalInvoke (object,object[])
in <0x0008d> System.Reflection.MonoCMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo
culture)--- End of inner exception stack trace ---
in <0x0010e> System.Reflection.MonoCMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
in <0x0001a> System.Reflection.MethodBase:Invoke (System.Object obj,
System.Object[] parameters)
in <0x001db> System.Runtime.Serialization.ObjectRecord:LoadData
(System.Runtime.Serialization.ObjectManager manager,
ISurrogateSelector selector, StreamingContext context)
in <0x00110> System.Runtime.Serialization.ObjectManager:DoFixups ()
in <0x00042>
System.Runtime.Serialization.Formatters.Binary.ObjectReader:ReadNextObject
(System.IO.BinaryReader reader)
in <0x000a3>
System.Runtime.Serialization.Formatters.Binary.ObjectReader:ReadObjectGraph
(System.IO.BinaryReader reader, Boolean readHeaders, System.Object
result, System.Runtime.Remoting.Messaging.Header[] headers)
in <0x0011f>
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter:NoCheckDeserialize
(System.IO.Stream serializationStream,
System.Runtime.Remoting.Messaging.HeaderHandler handler)
in <0xf>
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter:Deserialize
(System.IO.Stream serializationStream)
in <0x00032> System.Resources.ResourceReader:ReadNonPredefinedValue
(System.Type exp_type)
in <0x0031e> System.Resources.ResourceReader:ReadValueVer1 (System.Type
type)
in <0x00163> System.Resources.ResourceReader:ResourceValue (Int32 index)
in <0x00028> System.Resources.ResourceReader+ResourceEnumerator:get_Value ()
in <0x0007e> System.Resources.ResourceSet:ReadResources ()
in <0x00049> System.Resources.ResourceSet:GetObject (System.String
name, Boolean ignoreCase)
in <0x0007a> System.Resources.ResourceManager:GetObject (System.String
name, System.Globalization.CultureInfo culture)
in <0x00010> System.Resources.ResourceManager:GetObject (System.String name)
in <0x00017> System.Windows.Forms.Locale:GetResource (System.String name)
in <0x00011> System.Windows.Forms.Form:.cctor ()--- End of inner
exception stack trace ---
in <0x0>
in <0xb> WindowsApplication1.Form1:.ctor ()
in (wrapper remoting-invoke-with-check) WindowsApplication1.Form1:.ctor ()
in <0x00018> WindowsApplication1.Program:Main ()
===source code
using System;
using System.Windows.Forms;
namespace WindowsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
}
}
static class Program
{
///
/// The main entry point for the application.
///
static void Main()
{
Application.Run(new Form1());
Re: [Mono-dev] [PATCH]: Avoid --with-static_mono=no problems on Linux/Sparc
Hey, This one is now checked in. Zoltan On 4/5/06, David S. Miller <[EMAIL PROTECTED]> wrote: > From: "Zoltan Varga" <[EMAIL PROTECTED]> > Date: Wed, 5 Apr 2006 00:28:25 +0200 > > > The patch no longer applies cleanly to gcconfig.h in mono SVN. > > Here's an updated version: > > 2006-04-04 David S. Miller <[EMAIL PROTECTED]> > > * include/private/gcconfig.h (LINUX and SPARC): Do not > use _etest and GC_SysVGetDataStart() to figure out DATASTART. > Instead use either SEARCH_FOR_DATA_START or __environ, based > upin GLIBC version. > > --- include/private/gcconfig.h.~1~ 2006-04-04 14:14:58.0 -0700 > +++ include/private/gcconfig.h 2006-04-04 15:31:57.0 -0700 > @@ -990,16 +990,24 @@ > # else >Linux Sparc/a.out not supported > # endif > - extern int _end[]; > - extern int _etext[]; > -# define DATAEND (_end) > # define SVR4 > - extern ptr_t GC_SysVGetDataStart(); > -# ifdef __arch64__ > -# define DATASTART GC_SysVGetDataStart(0x10, _etext) > +# include > +# if defined(__GLIBC__) && __GLIBC__ >= 2 > +# define SEARCH_FOR_DATA_START > # else > -# define DATASTART GC_SysVGetDataStart(0x1, _etext) > + extern char **__environ; > +# define DATASTART ((ptr_t)(&__environ)) > + /* hideous kludge: __environ is the first */ > + /* word in crt0.o, and delimits the start */ > + /* of the data segment, no matter which */ > + /* ld options were passed through.*/ > + /* We could use _etext instead, but that */ > + /* would include .rodata, which may */ > + /* contain large read-only data tables*/ > + /* that we'd rather not scan. */ > # endif > + extern int _end[]; > +# define DATAEND (_end) > # define LINUX_STACKBOTTOM > # endif > # ifdef OPENBSD > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: [PATCH] ShellExecuteEx ProcessId support forWindows 2000 and Windows XP RTM
Hi, I'm only unsure about the configure part when specifying library (DLL) dependencies. I know that the solution is the link order but I don't know how to solve it. The submitted patch is correct but I'm not sure whether it is the best solution. I'm not going to submit another patch as I don't know other solution. If you have a better one please let me know. I consider the actual code patch to be complete, stable and safe so I'm not going to modify it either. I'm confident regarding modifications made to process.c. I'm sure that modifications made to configure.in are correct but there may be some other solution as well. Checking for GetProcessId in header files is a bad idea as Windows (Platform SDK) header files are universal so if you define the appropriate WINVER (and/or _WIN32_WINNT, _WIN32_WINDOWS, _WIN32_IE) version you can link to the API (including GetProcessId) of that version regardless of the Windows version in use. Unlike the header files of Linux header files of Windows are not describing the actual operating system version. But anyway this new code is not using GetProcessId on Windows and is using io-layer's implementation everywhere else so there is no need to check for GetProcessId. Kornél - Original Message - From: "Dick Porter" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 04, 2006 2:18 PM Subject: Re: [Mono-dev] Re: [PATCH] ShellExecuteEx ProcessId support forWindows 2000 and Windows XP RTM On Tue, 2006-04-04 at 12:01 +0200, Kornél Pál wrote: Could someone please review this patch. I was on holiday, and you didn't seem too confident about this patch anyway; but here goes: The GetProcessId check should remain in configure.in, and HAVE_GETPROCESSID be used by the code to check if its available or not. Remember, check for features not platforms. Check that interdependencies between msvcrt.dll and ntdll.dll can be _reliably_ solved by the link order. Then I'll review an updated patch. Thanks, - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
