My experience has been that it's easier to run make clean before
updating svn. Does this make sense? If configure.in or any
Makefile template changes then one can't make clean after updating
without re-autogen'ing. Of course, if any of those have changed,
then autogen will be required anyway, bu
works fine without USR1 and USR2
on all FreeBSD > 5.3.
Bill
On 6/7/05, Gonzalo Paniagua Javier <[EMAIL PROTECTED]> wrote:
On Sun, 2005-06-05 at 12:45 +0200, Bill Middleton wrote:>> There's a mention in libgc/include/private/gc_priv.h about> USR
On 6/7/05, Gonzalo Paniagua Javier <[EMAIL PROTECTED]> wrote:
On Sun, 2005-06-05 at 12:45 +0200, Bill Middleton wrote:>> There's a mention in libgc/include/private/gc_priv.h about> USR2 already being used by linuxthreads when SIG_SUSPEND is> redefine
There's a mention in libgc/include/private/gc_priv.h about USR2
already being used by linuxthreads when SIG_SUSPEND is redefined as
SIGPWR. I have no idea if thats relevant anymore, though. I
recall this only because FreeBSD had a problem with USR2 and USR2 that
had to be changed there in libgc
There's a mention in libgc/include/private/gc_priv.h about USR2
already being used by linuxthreads when SIG_SUSPEND is redefined as
SIGPWR. I have no idea if thats relevant anymore, though. I
recall this only because FreeBSD had a problem with USR2 and USR2 that
had to be changed there in libgc
On 5/11/05, Jérôme Laban <[EMAIL PROTECTED]> wrote:
I also noted that redefining register indices is not needed if
HAVE_WORKING_SIGALTSTACK is defined. But since it can be disabled using
--with-sigaltstack=no, it would break the compatibility with NetBSD's sigcontext. I think
its best to
On 5/11/05, Jérôme Laban <[EMAIL PROTECTED]> wrote:
I can
leave the default netbsd. However, I am sure mono will never run properly on
NetBSD 1.6 because of the lack of native threads support. I'll make the
changes anyway.[...]
Indeed, these redefinitions are odd, but the register indic
On 5/10/05, Jérôme Laban <[EMAIL PROTECTED]> wrote:
Indeed, the link was incorrect but I have fixed
this.
I've also attached the patch to this message, for the
archive. I'll open a bug too.
Thanks Bill.
--
Jérôme Laban
{Epitech.}
http://msdn.labtech.epitech.net
I'm interested in seeing this, but the link doens't work.
Consider attaching the patch to the mail or perhaps better, opening a bug for it and attaching the patch there.
Bill
On 5/10/05, Jérôme Laban <[EMAIL PROTECTED]> wrote:
Hi everyone,I've been developing a patch for Mono for a while now and
I figured this one out on my own (surprise), and yes, I was wrong.
See the bug if you're really interested, but suffice to say that I should've listened to Dick.
/me slinks back to the car wash
Bill
On 4/27/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
Hello group,
I'v
On 4/27/05, Andrew Gleave <[EMAIL PROTECTED]> wrote:
I have tried it on Debian and it is now working fine. But is stillbroken on OS X. See the bug report
I've now attached a patch to bug 74732 which should fix the problem on OSX, and which passes Unit testing ok.
Try it out and let me know. Not
Hello group,
I've been trying to help work out bug number 74732:
http://bugzilla.ximian.com/show_bug.cgi?id=74732
I suspect that, in spite of his immense capacity to deliver excellent
works, (or possibly because of that) I may be starting to irritate the
developer in charge of fixing the problem
I think the problem is that your machine does not have procfs(5) enabled. Could you verify this?
Bill
On 4/26/05, Andrew Gleave <[EMAIL PROTECTED]> wrote:
I have posted a bug
report (http://bugzilla.ximian.com/show_bug.cgi?id=74732)
with source and will wait and see what happens as I know
Looks like a bug to me. At least insofar as it doesn't throw an
exception running under .NET or Mono Windows.
Bill
On 4/25/05, Andrew Gleave <[EMAIL PROTECTED]> wrote:
>
> Hi,
> We have an app that uses a StreamWriter to write logging and debugging
> info to a file. If I terminate the a
Is it possible to exclude the VB tests somehow in a unit testing run?
Thanks.
Bill
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
We can work on this offline until there's a successful build, ok?
Bill
On 4/18/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
> Ikke noe problem.
>
> I need a copy of your /usr/include/sys/ucontext.h and mcontext.h
>
> Then I may be able to help you work this out.
&g
On 4/18/05, Erik Dahlstrand <[EMAIL PROTECTED]> wrote:
> Hi! Are you talking about xsp or mono now? Is there a version 1.1.17 of xsp?
> Or do you mean the 1.1.7 version of mono?
Er, yes. I was referring to mono 1.1.7,not 1.1.17. Sorry for the confusion.
> When trying to compile mono from the
Consider waiting for the 1.1.17 release, due out RSN, or try the svn
version, which should work better on NetBSD. Run 1.1.17 configure
with the sigaltstack option, and let me know how it goes.
Bill
On 4/17/05, Erik Dahlstrand <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm trying to get xsp 1.0.4 to
Woops. I thought I had made a successful switch back to mainline from
your branch, but checking out a new copy of mainline shows it's fixed.
My bad.
Nice layer, btw.
Bill
On 4/14/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
> Still broken in the mainline. :|
>
>
Still broken in the mainline. :|
Bill
On 4/14/05, Dick Porter <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-04-14 at 10:10 +0200, Bill Middleton wrote:
> > Here's a better patch. I hope I'm getting closer here... :)
>
> I fixe
My guess is that the gtk-sharp list might have your answers.
Subscribe (or browse its archives) at
http://mono-project.com/Mailing_Lists or even better:
http://lists.ximian.com/mailman/listinfo
Bill
On 4/14/05, Pablo Cardona <[EMAIL PROTECTED]> wrote:
> Hello, I'm developing an applicati
ndClose (handle);
SetLastError (ERROR_NO_MORE_FILES);
- find_ret = INVALID_HANDLE_VALUE;
+ return(INVALID_HANDLE_VALUE);
}
return (handle);
On 4/14/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
> On 4/13/05, Bill Middleton <[EMAIL PRO
On 4/13/05, Bill Middleton <[EMAIL PROTECTED]> wrote:
> When this happens, metadata/file-io.c happily calls FindNextFile again,
A slight correction, file-io.c calls convert_win32_file_attribute() on
the data, after calling FindFirstFile(), since r is true and the
handle didn'
This patch fixes a gnarly little bug with the new io-layer, and it's
interaction with metadata/file-io.c. The problem is that FindNextFile()
in io-layer/io.c doesn't set the cFileName at all in the WapiFindData struct,
if there aren't any files to look at - either an empty directory, or an
unmatch
Hi,
I had to remove the followiing line from threadpool.c to get it to
build here on FreeBSD, where we have no epoll().
Index: threadpool.c
===
--- threadpool.c(revision 42886)
+++ threadpool.c(working copy)
@@ -622
While working to get mono up and running on FreeBSD, I discovered that
there were no tests for System.Diagnostics which were being run.
There are, however, a couple of tests in the group which use
System.Diagnostics, but they weren't as portable as they could have
been, and lacked information for
On Apr 12, 2005 12:32 AM, Miguel de Icaza <[EMAIL PROTECTED]> wrote:
> Preview=yes will become the new default.
Ah. Thanks for the clarification. I guess the logic will have to be
reversed in that test.
And speaking of PREVIEW, I've been getting some strange errors lately
when building the 2.0
Hi Lupus,
I will work up another patch to implement your suggestions. I based
the original on the principle of "do the least harm", but I will
remove the #ifdefs where you have suggested, and setup a check for
ucontext.h in configure.in.
See below.
On Apr 11, 2005 7:17 PM, Paolo Molaro <[EMAIL
t; - PREVIEW=yes
> + if test x$with_preview = xno; then
> + PREVIEW=no
> fi
>
> Zoltan
>
> On Apr 11, 2005 12:48 PM, Bill Middleton <[EMAIL PROTECTED]> wrote:
> > And one more. Thats what
And one more. Thats what I get for doing last-minute touchups.
313c313
< +#if def(__FreeBSD__)
---
> +#if defined(__FreeBSD__)
Thanks for your patience, Complete, working patch attached.
Bill
Index: libgc/include/private/gcconfig.h
==
Some last minute touch-ups broke the patch to exceptions-x86.c, in the
patch, please change the following:
286c286
< +#if def(__FreeBSD__)
---
> +#if defined(__FreeBSD__)
Sorry about that. Updated patch attached
Bill
Index: libgc/include/private/gcconfig.h
=
This patch to HEAD (along with Dick's great new io-layer) gets
everything working under FreeBSD for 1.1.17. Here we add support
for MONO_ARCH_USE_SIGACTION, fix libgc, support freebsd6, and
clean up a nit that crept in from a bad archive patch.
Detailed descriptions follow, and the patch is attac
ts. However, there are no tests for System.Diagnostics yet.
:)
Regards,
Bill Middleton
Index: handles.c
===
--- handles.c (revision 42643)
+++ handles.c (working copy)
@@ -712,6 +712,22 @@
* now, but pthrea
Hi,
Looks like a good plan to me, fwiw.
I'd like to add Just a small feature request though, if you have
time. I'd really like to have xsp provide a configurable output
for errors. Right now it pretty much just does console.write()
for everything, making it difficult to catch errors, especiall
Zoltan Varga wrote:
For the sigcontext stuff, I think it would be easier to define
MONO_ARCH_USE_SIGACTION in mini-x86.h for *BSD as well. Could you try
this ?
Both NetBSD and FreeBSD seem to be on their way towards ucontext{} and
away from sigcontext. NetBSD completely hides sigcontext{} in
the patchfile is attached and appended.
Your feedback is welcome.
Regards, and thanks for your work on Mono.
Bill Middleton
Index: libgc/include/private/gcconfig.h
===
--- libgc/include/private/gcconfig.h(revision 42489)
+++ li
36 matches
Mail list logo
