[Mono-dev] Boehm GC reaching max_map_count
Hi there, We're experiencing problems with a server running on a 64bits box with plenty of RAM. After a few hours it crashed and the problem was that it was reaching the max_map_count limit. We raised it to two times the default (64k) but it also crashed. The problem is the following: normally the process has a number close to 100 or 200 mappings, but then, in less than a second, it grows beyond the limit and crashes. The process is not allocating memory (it stays stable although quite high) at this point, so we think it must be related to BoehmGC doing some collection or something. The process is heavily multithreaded. Mono is built with --with-large-heap and runs on a 64 bits box (where the pointer guessing issues with BoehmGC don't hit us so strongly as it happens on 32 bit systems). Well, anyone has any idea why this is happening? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ir instructions.
On 02/22/10 Rodrigo Kumpera wrote:
On Sat, Feb 20, 2010 at 2:07 AM, Jerry Maine - KF5ADY crashfou...@gmail.com
I remember you talking about instead of having marcos and defines
describe certain attributes of IR instructions, having them be defined
in a single data structure like what is done for when calling LLVM. What
would that entail?
That would entail been able to encode more properties and relations of
instructions
without all the repetition that currently exist in our JIT.
All the repetition can be trivially eliminated: nobody did that yet
because it's mostly a waste of time at this point (and some invariants
in opcode order need to be maintained right now, so changing things
blindly could break code).
There are 3 different problems I think deserve been solved.
The first is encoding of instruction properties such as commutative or
side-effect free.
For this it would be a matter of adding an extra parameter to the MINI_OP
macro or'ing
those properties and then filling a table with this data.
Right, so there is no need for the bloat of tablegen for this (not
counting the build issues it would bring on).
The second is encode relations between instructions. For example,
op_to_op_dest_membase
is only enabled on x86/amd64 and to small amount of operations. Doing this
for all SIMD ops
would be a a lot of repetitive work.
See the attached program that will generate all the stuff you need there
and more. It can be trivially enhanced to generate also the backend
code or mono_op_to_op_imm() support.
The last is to reduce the amount of repetition between instructions
definitions, it has to be very
template oriented and support customization of the result. For example, I
want to define a single
template for binary SIMD ops that produce reg_reg, reg_membase, reg_memindex
variants, which
don't have side effects and, finally, can be easily instantiated for the
many vector elements.
This is asking for a lot. But it would simplify the JIT a lot and make it
produce better code easier.
See the attached program, it does already basically all the things you outlined.
All with half an hour of scripting and 60 lines of code.
So, no, there is no need for tablegen in mono, adapting it to hour needs
would require much more than half an hour and being so different is more
likely to introduce subtle issues.
Once the templates are defined, you can simply add a new SSE instruction
by addig its name to the proper list.
lupus
--
-
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
#!/usr/bin/perl -w
my %templates = (
# typical sse instructions
XREG XREG XREG - MEMBASE[2] = [qw (ADDPD DIVPD MULPD SUBPD MAXPD)],
# typical integer instruction
IREG IREG IREG - IMM[2:NONE] = [qw (IADD ISUB IMUL IDIV)],
);
my @data = (
# a more complex case: we generate several instructions
'COMPARE compare NONE IREG IREG - IMM[2:NONE], MEMBASE_REG[1], MEMBASE_IMM[1 2:NONE], REG_MEMBASE[2]',
);
foreach my $template (keys %templates) {
foreach my $op (@{$templates{$template}}) {
push @data, $op . lc($op) . $template;
}
}
sub output {
my @spec = @_;
print MONO_OP(OP_$spec[0], \$spec[1]\, $spec[2], $spec[3], $spec[4])\n;
}
sub output_variant {
my ($variant, @spec) = @_;
my @orig = @spec;
return unless $variant =~ /(\S+)\s*\[(.*)\]/;
my $name = $1;
my @regs = split (/\s/, $2);
$spec [0] .= _$name;
$spec [1] .= _ . lc $name;
my $membase;
foreach my $reg (@regs) {
my ($num, $new) = split (/:/, $reg);
$new = IREG unless defined $new;
$spec [2 + $num] = $new;
# we use the convention that the first one is the base pointer
$membase = $num unless defined $membase;
}
output (@spec);
my $orig = $spec[0];
$orig =~ s/_MEMBASE//;
# to be used in the switch in functions like op_to_op_* with something like:
# #define OP_2_OP_REG1_MEMBASE(a,b) case a: return b;
print OP_2_OP_REG${membase}_MEMBASE(OP_$orig,OP_$spec[0])\n if defined $membase $name =~ /MEMBASE/;
}
sub generate {
my $template = shift;
my ($opcode, $variant) = split (/-/, $template);
my @spec = split (/\s/, $opcode);
output (@spec);
return unless (defined $variant) and (length $variant);
foreach my $var (split (/,/, $variant)) {
# variants could go to a different output queue to
# maintain instruction order currently required in the JIT
output_variant ($var, @spec)
}
}
foreach my $op (@data) {
generate ($op);
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] WCP and ServiceHost
Hello, I have a strange problem with WCF and ServiceHost is seams my server is not listening sometimes (like 50/50). Has anyone had the same problem, Also my client hangs on trying to connect and does not throw and error after 5 sec like the config tells it to. Any comments? CODE Server: Uri uri = new Uri(ConfigurationManager.AppSettings[addr]); host = new ServiceHost(typeof(GlobalService), uri); host.Open(); //Returns always Config Server: appSettings add key=addr value=net.tcp://private:2/globalservice / /appSettings system.serviceModel services service name=com.PageFlipper.GlobalServer.GlobalService behaviorConfiguration=GlobalServer.GlobalServiceBehavior endpoint address= binding=netTcpBinding bindingConfiguration=DuplexBinding contract=GlobalServer.IGlobalService /endpoint /service /services behaviors serviceBehaviors behavior name=GlobalServer.GlobalServiceBehavior serviceThrottling maxConcurrentSessions=1 / /behavior /serviceBehaviors /behaviors bindings netTcpBinding binding name=DuplexBinding openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel Clinet CODE: var client = new Proxy.GlobalServiceClient(); client.Open(); // Hangs like 50/50 of the time Client config system.serviceModel client endpoint address=net.tcp://private:2/globalservice binding=netTcpBinding bindingConfiguration=DefaultBinding_IGlobalService contract=Proxy.IGlobalService name=DefaultBinding_IGlobalService_IGlobalService / /client bindings netTcpBinding binding name=DefaultBinding_IGlobalService openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
Just a reminder: If you've been assigned a bug or you know of a bug that's been fixed and needs to be backported please do so before the end of this week. There's a good chance we'll try to release 2.6.3 from the 2.6 branch early next week. The QA team is still testing this branch but testing doesn't fix bugs, it can only find them. Please do your part. On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote: Hello Happy Coders, We are planning to make a new release from the 2.6 branch in the near future (probably before the end of the month?). If there are bugs that you know ought to be backported (customer issues, regressions, and embarrassments especially) please do so in the next week or so. As you backport please keep in mind that we are trying to stabilize the 2.6 branch. Be conscientious and thorough and use your own best judgment in your area of expertise and consult your colleagues where you have doubts. Also don't neglect other platforms like Mac, Windows, and Linux s390x. 2.6.x will eventually be used as a Novell-supported release for the Mono Extension for SLE and other products. We will be doing some testing of the 2.6 branch during this time. If QA approaches you regarding a bug please remember that we will also need time to verify the fix after you check it in. In other words: please give us any priority you can. And don't forget to close bugs as you fix them and file them as you find them. Hmm, I should get someone to fix the booc crasher on x86_64... Oh and thanks so much to those who pitched in to get our Xen x86_64 crasher fixed! Best Regards, Andrew Jorgensen Release / Packaging Guy Novell, Inc. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
Any chance these can get in for IronRuby? The following ones are marked as resolved: http://bugzilla.novell.com/show_bug.cgi?id=566117 http://bugzilla.novell.com/show_bug.cgi?id=566106 http://bugzilla.novell.com/show_bug.cgi?id=566087 http://bugzilla.novell.com/show_bug.cgi?id=565152 http://bugzilla.novell.com/show_bug.cgi?id=565120 http://bugzilla.novell.com/show_bug.cgi?id=565143 http://bugzilla.novell.com/show_bug.cgi?id=577029 This one looks almost done yet not resolved yet: http://bugzilla.novell.com/show_bug.cgi?id=565129 And the status of the following hasn't changed yet, so I guess they won't make it: http://bugzilla.novell.com/show_bug.cgi?id=566241 http://bugzilla.novell.com/show_bug.cgi?id=566152 http://bugzilla.novell.com/show_bug.cgi?id=577346 Thanks, Tomas -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andrew Jorgensen Sent: Tuesday, February 23, 2010 9:33 AM To: ximian-mono-l...@lists.ximian.com Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 2.6.x Just a reminder: If you've been assigned a bug or you know of a bug that's been fixed and needs to be backported please do so before the end of this week. There's a good chance we'll try to release 2.6.3 from the 2.6 branch early next week. The QA team is still testing this branch but testing doesn't fix bugs, it can only find them. Please do your part. On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote: Hello Happy Coders, We are planning to make a new release from the 2.6 branch in the near future (probably before the end of the month?). If there are bugs that you know ought to be backported (customer issues, regressions, and embarrassments especially) please do so in the next week or so. As you backport please keep in mind that we are trying to stabilize the 2.6 branch. Be conscientious and thorough and use your own best judgment in your area of expertise and consult your colleagues where you have doubts. Also don't neglect other platforms like Mac, Windows, and Linux s390x. 2.6.x will eventually be used as a Novell-supported release for the Mono Extension for SLE and other products. We will be doing some testing of the 2.6 branch during this time. If QA approaches you regarding a bug please remember that we will also need time to verify the fix after you check it in. In other words: please give us any priority you can. And don't forget to close bugs as you fix them and file them as you find them. Hmm, I should get someone to fix the booc crasher on x86_64... Oh and thanks so much to those who pitched in to get our Xen x86_64 crasher fixed! Best Regards, Andrew Jorgensen Release / Packaging Guy Novell, Inc. ___ 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] Mono 2.6.x
Hello, Of the three you list as not having changed: I started to look at fixing http://bugzilla.novell.com/show_bug.cgi?id=566241 http://bugzilla.novell.com/show_bug.cgi?id=566241but it is a non-trivial fix and probably would not be backported. http://bugzilla.novell.com/show_bug.cgi?id=566152 should be easy to fix and backport, just by using the Windows APIs instead of glib for environment variable access. I can take a look if no one else has/will. Thanks, Jonathan On Tue, Feb 23, 2010 at 1:46 PM, Tomas Matousek tomas.matou...@microsoft.com wrote: Any chance these can get in for IronRuby? The following ones are marked as resolved: http://bugzilla.novell.com/show_bug.cgi?id=566117 http://bugzilla.novell.com/show_bug.cgi?id=566106 http://bugzilla.novell.com/show_bug.cgi?id=566087 http://bugzilla.novell.com/show_bug.cgi?id=565152 http://bugzilla.novell.com/show_bug.cgi?id=565120 http://bugzilla.novell.com/show_bug.cgi?id=565143 http://bugzilla.novell.com/show_bug.cgi?id=577029 This one looks almost done yet not resolved yet: http://bugzilla.novell.com/show_bug.cgi?id=565129 And the status of the following hasn't changed yet, so I guess they won't make it: http://bugzilla.novell.com/show_bug.cgi?id=566241 http://bugzilla.novell.com/show_bug.cgi?id=566152 http://bugzilla.novell.com/show_bug.cgi?id=577346 Thanks, Tomas -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto: mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andrew Jorgensen Sent: Tuesday, February 23, 2010 9:33 AM To: ximian-mono-l...@lists.ximian.com Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 2.6.x Just a reminder: If you've been assigned a bug or you know of a bug that's been fixed and needs to be backported please do so before the end of this week. There's a good chance we'll try to release 2.6.3 from the 2.6 branch early next week. The QA team is still testing this branch but testing doesn't fix bugs, it can only find them. Please do your part. On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote: Hello Happy Coders, We are planning to make a new release from the 2.6 branch in the near future (probably before the end of the month?). If there are bugs that you know ought to be backported (customer issues, regressions, and embarrassments especially) please do so in the next week or so. As you backport please keep in mind that we are trying to stabilize the 2.6 branch. Be conscientious and thorough and use your own best judgment in your area of expertise and consult your colleagues where you have doubts. Also don't neglect other platforms like Mac, Windows, and Linux s390x. 2.6.x will eventually be used as a Novell-supported release for the Mono Extension for SLE and other products. We will be doing some testing of the 2.6 branch during this time. If QA approaches you regarding a bug please remember that we will also need time to verify the fix after you check it in. In other words: please give us any priority you can. And don't forget to close bugs as you fix them and file them as you find them. Hmm, I should get someone to fix the booc crasher on x86_64... Oh and thanks so much to those who pitched in to get our Xen x86_64 crasher fixed! Best Regards, Andrew Jorgensen Release / Packaging Guy Novell, Inc. ___ 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] DragDrop to a DesignSurface
Hi all I've implemented a GUI designer using the DesignSurface class from the System.ComponentModel.Design namespace. I've also made an implementation of an iToolboxService and use the DragDrop functionality to add controls from there to the design surface. This works as expected using the .NET framework, but in Mono I can't get the DragDrop running. The drag operation starts correct, but the design surface doesn't seem to support the drop operation. Are you aware of such a problem and/or do you have any idea for a workaround? The application which I'm speaking of is open source. You could grab the code from here: http://sourceforge.net/projects/oscontrol/ Just make sure that you get the latest revision from the SVN, because the posted release doesn't even start under Mono. To reproduce the issue, just follow the tutorial in the getting started guide. Cheers /dominik ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Moonlight project compile error in MonoDevelop
I'm running Mono Develop 2.2.1 on openSUSE 11.1 (the VM from the mono tools distribution) and trying to compile a moonlight c# project. I have copied moonlight distribution folder from my MAC and put it on /usr/lib. The project has a class file that derives from Stream and I get the following error: Commons.Utils/IO/MultiBufferStream.cs(38,38): Error CS0505: ` MultiBufferStream.Seek(long, System.IO.SeekOrigin)': cannot override because `System.IO.Stream.Seek(long, int)' is not a method (CS0505) (Commons.Utils.SL) Any clues anyone? Compiles just fine under VS SL2. Thanks Peter Peter Shoebridge Founder CEO [cid:image001.gif@01CAB49B.E56CBE00] Boulder, Colorado, USA +1-303-882-6150 inline: image001.gif___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Portable phone apps
Jonathan Pryor wrote: It will instead be write the core once, write the UI once for each target platform, as (currently) the UI layers are platform specific (Silverlight for Windows Phone 7 Series, MonoTouch for iPhone, and MonoDroid for Android [0]). Is it not the case that Mono could provide a silverlight and XNA implementation on those platforms though? Isn't that (well, the XNA bit) what this (http://xnatouch.codeplex.com/) is all about? James ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Your help needed for our upcoming release.
Hello guys, I changed the subject of this email, since Andrew's call to action is important and it applies to everyone: Just a reminder: If you've been assigned a bug or you know of a bug that's been fixed and needs to be backported please do so before the end of this week. There's a good chance we'll try to release 2.6.3 from the 2.6 branch early next week. The QA team is still testing this branch but testing doesn't fix bugs, it can only find them. Please do your part. On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote: Hello Happy Coders, We are planning to make a new release from the 2.6 branch in the near future (probably before the end of the month?). If there are bugs that you know ought to be backported (customer issues, regressions, and embarrassments especially) please do so in the next week or so. As you backport please keep in mind that we are trying to stabilize the 2.6 branch. Be conscientious and thorough and use your own best judgment in your area of expertise and consult your colleagues where you have doubts. Also don't neglect other platforms like Mac, Windows, and Linux s390x. 2.6.x will eventually be used as a Novell-supported release for the Mono Extension for SLE and other products. We will be doing some testing of the 2.6 branch during this time. If QA approaches you regarding a bug please remember that we will also need time to verify the fix after you check it in. In other words: please give us any priority you can. And don't forget to close bugs as you fix them and file them as you find them. Hmm, I should get someone to fix the booc crasher on x86_64... Oh and thanks so much to those who pitched in to get our Xen x86_64 crasher fixed! Best Regards, Andrew Jorgensen Release / Packaging Guy Novell, Inc. ___ Ximian-mono-list mailing list ximian-mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/ximian-mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Portable phone apps
Hello, Is it really going to be that case that the ONLY way to write a mobile phone app once so that it can run on Winphone 7 and iPhone and Linux mobile and Android, will be to use mono/silverlight for the non-MS platforms? Oh dear, oh dear, oh dear ;-) We can certainly help a little bit here, the business logic can certainly be reused across all of those platforms. The UI on the other hand will probably have to be adjusted for each device. Long-term, I would like to port Moonlight to the iPhone and the Android so it would be possible to have the same code base at least across those two phones, not sure what Windows Mobile 7 will use for its GUI. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Portable phone apps
Hello, It will instead be write the core once, write the UI once for each target platform, as (currently) the UI layers are platform specific (Silverlight for Windows Phone 7 Series, MonoTouch for iPhone, and MonoDroid for Android [0]). Is it not the case that Mono could provide a silverlight and XNA implementation on those platforms though? Isn't that (well, the XNA bit) what this (http://xnatouch.codeplex.com/) is all about? XNA will be useful for a class of applications, but not every application would benefit from it. Many applications will need more business-y features like data-entry and that is not really XNA's strength. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCP and ServiceHost
Hello, As mentioned on [*1] you won't get NetTcpBinding working unless you are using trunk. Besides, 1) you use reliable session which is not implemented, and 2) those timeouts seem too short and I don't think they result in good connection. Basically NetTcpBinding is not very stable and it won't be suitable for those who cannot dig into its internals. [*1] http://veritas-vos-liberabit.com/monogatari/2009/12/mono-wcf-advent-day-11-nettcpbinding.html Atsushi Eno On 2010/02/24 2:15, Ásgeir Halldórsson wrote: Hello, I have a strange problem with WCF and ServiceHost is seams my server is not listening sometimes (like 50/50). Has anyone had the same problem, Also my client hangs on trying to connect and does not throw and error after 5 sec like the config tells it to. Any comments? CODE Server: Uri uri = new Uri(ConfigurationManager.AppSettings[addr]); host = new ServiceHost(typeof(GlobalService), uri); host.Open(); //Returns always Config Server: appSettings add key=addr value=net.tcp://private:2/globalservice / /appSettings system.serviceModel services service name=com.PageFlipper.GlobalServer.GlobalService behaviorConfiguration=GlobalServer.GlobalServiceBehavior endpoint address= binding=netTcpBinding bindingConfiguration=DuplexBinding contract=GlobalServer.IGlobalService /endpoint /service /services behaviors serviceBehaviors behavior name=GlobalServer.GlobalServiceBehavior serviceThrottling maxConcurrentSessions=1 / /behavior /serviceBehaviors /behaviors bindings netTcpBinding binding name=DuplexBinding openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel Clinet CODE: var client = new Proxy.GlobalServiceClient(); client.Open(); // Hangs like 50/50 of the time Client config system.serviceModel client endpoint address=net.tcp://private:2/globalservice binding=netTcpBinding bindingConfiguration=DefaultBinding_IGlobalService contract=Proxy.IGlobalService name=DefaultBinding_IGlobalService_IGlobalService / /client bindings netTcpBinding binding name=DefaultBinding_IGlobalService openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel ___ 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-semaphore.c broken on MacOSX in SVN
Mono-semaphore.c won't compile on Mac. I *think* the patch below will fix it in both cases, but my macros are pretty rusty. Basically, semaphore_timedwait doesn't take a mach_timespec_t* where as sem_timedwait does take a struct timespec * ws1048-snow:mono tom.philpot$ svn diff mono/utils/mono-semaphore.c Index: mono/utils/mono-semaphore.c === --- mono/utils/mono-semaphore.c (revision 152312) +++ mono/utils/mono-semaphore.c (working copy) @@ -17,7 +17,7 @@ #define WAIT_BLOCK(a,b) semaphore_timedwait (a, b) # else #define TIMESPEC struct timespec -#define WAIT_BLOCK(a,b) sem_timedwait (a, b) +#define WAIT_BLOCK(a,b) sem_timedwait (a, ##b) # endif gboolean @@ -32,7 +32,7 @@ tv.tv_sec = timeout_ms / 1000; tv.tv_nsec = (timeout_ms % 1000) * 100; - return (!WAIT_BLOCK (sem, tv)); + return (!WAIT_BLOCK (sem, tv)); } #else ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-semaphore.c broken on MacOSX in SVN
This is fixed in trunk, sorry I forgot to commit it before. -g On 2010-02-23, at 7:46 PM, Tom Philpot wrote: Mono-semaphore.c won't compile on Mac. I *think* the patch below will fix it in both cases, but my macros are pretty rusty. Basically, semaphore_timedwait doesn't take a mach_timespec_t* where as sem_timedwait does take a struct timespec * ws1048-snow:mono tom.philpot$ svn diff mono/utils/mono-semaphore.c Index: mono/utils/mono-semaphore.c === --- mono/utils/mono-semaphore.c (revision 152312) +++ mono/utils/mono-semaphore.c (working copy) @@ -17,7 +17,7 @@ #define WAIT_BLOCK(a,b) semaphore_timedwait (a, b) # else #define TIMESPEC struct timespec -#define WAIT_BLOCK(a,b) sem_timedwait (a, b) +#define WAIT_BLOCK(a,b) sem_timedwait (a, ##b) # endif gboolean @@ -32,7 +32,7 @@ tv.tv_sec = timeout_ms / 1000; tv.tv_nsec = (timeout_ms % 1000) * 100; - return (!WAIT_BLOCK (sem, tv)); + return (!WAIT_BLOCK (sem, tv)); } #else ___ 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] Announcing Mono 2.6.1 Solaris packages
Hi! I'm more than happy to announce that we've just released Mono 2.6.1 packages for Solaris 10 SPARC and OpenSolaris x86!! I expect Solaris 10 x86 to be following soon. They're both available at the Mono downloads page already! They're easy to build from sources, but even easier to install from a package!! :-P. Thanks Dick for making it happen. Feedback will be welcome. We'd like to see mono packages for all Unix flavors ready to install, and since we're successfully running on FreeBSD, it will probably be next... Enjoy, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
