Re: [Mono-dev] X509Certificate problem
Yes, absolutely! And there you go :) Certificate along with examples: https://bugzilla.novell.com/show_bug.cgi?id=396620 Best regards, Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono DTrace provider v2
Hi,
Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to the
prelink.sh script in Makefile.am as well, instead of creating it from
an .in file ?
Other than that, I think this is ok to check in. I still don't like
the makefile changes,
but at least they are inside an ifdef, so they won't break anything.
Zoltan
On Sat, May 31, 2008 at 12:09 AM, Andreas Färber [EMAIL PROTECTED] wrote:
Hello,
Here's an updated version of my patch, adding initial DTrace support to the
Mono runtime.
A new hand-crafted header file has been added, which is to be included in
place of the generated header file. It defines MONO_PROBE_* macros as
requested by Zoltan. The generated header file is then only needed iff
DTrace is enabled.
Ugly build steps for Solaris were moved to a shell script. It extracts
object files from their library to a temporary directory, patches them and
puts them back in. This helps keep Makefiles clean and provides a one-stop
resource to fix things, should they break. Tested on OpenSolaris 2008.05
i86. (Warning: I am not experienced in writing shell scripts.)
It appears the problem with the gc-end probe on Solaris was due to some kind
of compiler optimization or the like. Adding a trailing sleep(0) call made
it work; I have limited this workaround to when the gc-end probe is enabled
on Solaris, to minimize the impact. Better ideas welcome. If we do stick
with it and it turns out this is needed in more void functions, we could
consider turning this into a MONO_PROBE_* macro to keep source files clean.
Signed-off-by: Andreas Faerber [EMAIL PROTECTED]
Change Log v2:
* dtrace-prelink.sh.in: New
Script to prevent ugly Solaris hacks in Makefiles.
* configure.in:
Prepare support for OSX/x86_64 (untested)
Output dtrace-prelink.sh script.
* data/mono.d: Renamed (from mono-trace.d)
Added standard Mono header.
Added generation argument to gc-{begin,end} probes.
Added explicit stability attributes.
* mono/utils/dtrace.h: New
Wrapper around generated mono/utils/mono-dtrace.h.
Define MONO_PROBE_* macros.
* mono/utils/Makefile.am:
We no longer need to postprocess the generated header file.
* mono/metadata/Makefile.am,
mono/mini/Makefile.am:
Use new dtrace-prelink.sh script.
* mono/mini/mini.c,
mono/metadata/boehm-gc.c:
Use new macros
* mono/metadata/boehm-gc.c:
Add workaround to make gc-end probe work on Solaris.
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Next part of string patch (replace). Please test.
Thanks for testing. Good catch! Fixed and added more testcases to check for that. Happy Hacking Andreas Von: Konstantin Triger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 3. Juni 2008 13:38 An: Andreas Nahr Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Next part of string patch (replace). Please test. Hello all, To my understanding, The following line: if (count = maxValue) should be: if (count maxValue) 2008/6/2 Andreas Nahr [EMAIL PROTECTED]: This time the change is much smaller ;) Adds some additional Unittests and some explanatory LAMESPECS. For additional explanation see the last String patch mail or the original mailing-list discussion. For me all Unittests (including the new ones) pass. Did not observe regressions. Happy Hacking Andreas P.S. After that only split is missing... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Regards, Konstantin Triger RSS: http://feeds.feedburner.com/ktriger StringReplace.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono DTrace provider v3
Hi Zoltan,
Thanks again for your feedback.
v2 has been tested to work on Solaris 10 5/08 i86, too, in the
meantime. It requires the same workaround for the gc-end probe as
OpenSolaris.
Am 03.06.2008 um 18:32 schrieb Zoltan Varga:
Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to
the
prelink.sh script in Makefile.am as well, instead of creating it from
an .in file ?
Done. This eliminates calling config.status after changes to the script.
Other than that, I think this is ok to check in.
Has the issue of --enable-dtrace vs. --disable-dtrace been decided?
There appeared to be a disagreement between Miguel and you, and there
were no further comments.
One of Sun's DTrace developers writes that DTrace probes would work on
earlier versions of Solaris as no-ops.
http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better#comment-1148081088000
I don't have access to pre-10 Solaris systems to confirm this.
I verified it on OSX, by compiling a DTrace-enabled Hello World with
gcc-3.3 and running it on both v10.5 and v10.3.9. So it would seem
possible to enable DTrace support for the official Mono.framework 2.0,
in case this was Miguel's thought.
I still don't like
the makefile changes,
but at least they are inside an ifdef, so they won't break anything.
We have two options here. Either we commit the changes, allowing to
improve them later. Or we commit only the Mac OS X part for now. As
you like.
I've added new probes for the JIT, method-compile-begin and method-
compile-end. The MONO_PROBE_METHOD_COMPILE_* macros I've defined to
accept a MonoMethod* argument and to translate it to the final probe
arguments there. This avoids code duplication in mini.c.
Note that my patch shows four returns not handled by Mono's profiler,
for unsuccessful AOT generic sharing and for parts==1,2,3. Should that
be fixed, or is it not necessary for some reason?
Signed-off-by: Andreas Faerber [EMAIL PROTECTED]
ChangeLog v3:
* dtrace-prelink.sh: Renamed (from dtrace-prelink.sh.in)
Don't define AR, DTRACE, DTRACEFLAGS.
Removed debug output.
* configure.in:
Don't output dtrace-prelink.sh.
Move DTrace section up, to after the big-arrays section.
* data/mono.d,
mono/utils/dtrace.h,
mono/mini/mini.c:
Add new probes method-compile-{begin,end}.
* mono/metadata/Makefile.am,
mono/mini/Makefile.am:
dtrace-prelink.sh is now in $(top_srcdir).
Pass AR, DTRACE, DTRACEFLAGS as environment variables to dtrace-
prelink.sh.
Andreas
DTrace-USDT-3.diff
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
On Thu, 2008-05-29 at 16:54 -0700, C.J. Adams-Collier wrote: Aaron, Did you build this binding manually, or did you use gapi2? Mike, Is there any reason why gapi2 wouldn't work on gstreamer? My understanding is that the problem with a straight gapi binding was that there are proprietary gstreamer plugins which can't be GAPI-fied to identify all the APIs they expose, so there is need for more dynamic access to signals/events and properties of Gst.Elements. The gstreamer bindings effort undertaken during SoC a few years back was at least partially focused on this dynamic signal invocation and connection mechanism. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono DTrace provider v3
Hi,
I think this is ok to check in. If it works out, we can enable it by
default later.
Zoltan
On Tue, Jun 3, 2008 at 10:49 PM, Andreas Färber [EMAIL PROTECTED] wrote:
Hi Zoltan,
Thanks again for your feedback.
v2 has been tested to work on Solaris 10 5/08 i86, too, in the meantime. It
requires the same workaround for the gc-end probe as OpenSolaris.
Am 03.06.2008 um 18:32 schrieb Zoltan Varga:
Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to the
prelink.sh script in Makefile.am as well, instead of creating it from
an .in file ?
Done. This eliminates calling config.status after changes to the script.
Other than that, I think this is ok to check in.
Has the issue of --enable-dtrace vs. --disable-dtrace been decided? There
appeared to be a disagreement between Miguel and you, and there were no
further comments.
One of Sun's DTrace developers writes that DTrace probes would work on
earlier versions of Solaris as no-ops.
http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better#comment-1148081088000
I don't have access to pre-10 Solaris systems to confirm this.
I verified it on OSX, by compiling a DTrace-enabled Hello World with gcc-3.3
and running it on both v10.5 and v10.3.9. So it would seem possible to
enable DTrace support for the official Mono.framework 2.0, in case this was
Miguel's thought.
I still don't like
the makefile changes,
but at least they are inside an ifdef, so they won't break anything.
We have two options here. Either we commit the changes, allowing to improve
them later. Or we commit only the Mac OS X part for now. As you like.
I've added new probes for the JIT, method-compile-begin and
method-compile-end. The MONO_PROBE_METHOD_COMPILE_* macros I've defined to
accept a MonoMethod* argument and to translate it to the final probe
arguments there. This avoids code duplication in mini.c.
Note that my patch shows four returns not handled by Mono's profiler, for
unsuccessful AOT generic sharing and for parts==1,2,3. Should that be fixed,
or is it not necessary for some reason?
Signed-off-by: Andreas Faerber [EMAIL PROTECTED]
ChangeLog v3:
* dtrace-prelink.sh: Renamed (from dtrace-prelink.sh.in)
Don't define AR, DTRACE, DTRACEFLAGS.
Removed debug output.
* configure.in:
Don't output dtrace-prelink.sh.
Move DTrace section up, to after the big-arrays section.
* data/mono.d,
mono/utils/dtrace.h,
mono/mini/mini.c:
Add new probes method-compile-{begin,end}.
* mono/metadata/Makefile.am,
mono/mini/Makefile.am:
dtrace-prelink.sh is now in $(top_srcdir).
Pass AR, DTRACE, DTRACEFLAGS as environment variables to dtrace-prelink.sh.
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
