Re: [Mono-dev] problem compiling 1.9.1 on OpenBSD
Were you able to build it? pablo Andreas Färber escribió: > Hello, > > Try configuring --with-gc=none first. Then try --with-gc=boehm and use > a recent Boehm GC such as 7.1 or 7.0 (with appropriate CPPFLAGS and > LDFLAGS if necessary). If the "sigaltstack" feature is enabled by > default, try --with-sigaltstack=no. That's some of the things I needed > to do on Solaris. > > libgdiplus has definitely nothing to do with this. > > Andreas > > Am 17.06.2008 um 18:53 schrieb Genadijus Paleckis: > > >> Forgot to mention that when build freezes when mini-mono compiling >> something it consumes 100% CPU. >> >> Genadijus Paleckis wrote: >> >>> Hello list. >>> >>> I have a problem while compiling 1.9.1 on OpenBSD 4.3. >>> >>> I must say that I am compiling it without having libgdiplus (because >>> /Compiling_Mono says I must have it as other dependencies, I think >>> it is >>> not big deal because I don't want to have any drawing support, >>> well... >>> at least for now). >>> >>> because it is running from OpenBSD ports subsystem I will display >>> what >>> ENV it is using now. >>> >>> configure script is running with environment: >>> CC="cc" >>> ac_cv_path_CC="cc" >>> CFLAGS="-O2 -pipe" >>> CXX="c++" >>> ac_cv_path_CXX="c++" >>> CXXFLAGS="-O2 -pipe" >>> INSTALL="/usr/bin/install -c -o root -g bin" >>> ac_given_INSTALL="/usr/bin/install -c -o root -g bin" >>> INSTALL_PROGRAM="install -c -s -o root -g bin -m 555 >>> INSTALL_MAN="install -c -o root -g bin -m 444" >>> INSTALL_SCRIPT="install -c -o root -g bin -m 555" >>> INSTALL_DATA="install -c -o root -g bin -m 444" >>> YACC="yacc" >>> CFLAGS="-O2 -pipe -ggdb -I/usr/local/include" >>> LDFLAGS=" -L/usr/local/lib" >>> CONFIG_SITE='/usr/ports/infrastructure/db/config.site" >>> LIBTOOL="/usr/local/bin/libtool " >>> PATH=/home/rwx/works/ports/mystuff/lang/mono/w-mono-1.9.1/bin:/usr/ >>> bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/usr/X11R6/bin >>> >>> arguments for configure script is following: ./configure >>> --prefix='/usr/local' --sysconfdir='/etc' --mandir='/usr/local/man' >>> --infodir='/usr/local/info' >>> >>> configure output can be found http://84.32.234.78/mono.configure.gz >>> >>> and build output can be found http://84.32.234.78/mono.build.gz >>> >>> compressed port (skeleton with patches adopted for OpenBSD build) >>> can be >>> found http://84.32.234.78/mono.tar.gz >>> >>> at some point build stops and ps shows me that mono is trying to >>> compile? something? anyway I've tried to attach gdb into process and >>> that's what I've got: >>> >>> GNU gdb 6.3 >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, >>> and you are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for >>> details. >>> This GDB was configured as "i386-unknown-openbsd4.3"... >>> Attaching to program: >>> /home/rwx/works/ports/mystuff/lang/mono/w-mono-1.9.1/mono-1.9.1/ >>> mono/mini/mono, >>> process 16986 >>> Reading symbols from /usr/lib/libpthread.so.9.0...done. >>> Loaded symbols for /usr/lib/libpthread.so.9.0 >>> Reading symbols from /usr/local/lib/libgthread-2.0.so.1400.3...done. >>> Loaded symbols for /usr/local/lib/libgthread-2.0.so.1400.3 >>> Reading symbols from /usr/local/lib/libglib-2.0.so.1400.3...done. >>> Loaded symbols for /usr/local/lib/libglib-2.0.so.1400.3 >>> Reading symbols from /usr/local/lib/libpcre.so.2.1...done. >>> Loaded symbols for /usr/local/lib/libpcre.so.2.1 >>> Reading symbols from /usr/local/lib/libintl.so.4.0...done. >>> Loaded symbols for /usr/local/lib/libintl.so.4.0 >>> Reading symbols from /usr/local/lib/libiconv.so.4.0...done. >>> Loaded symbols for /usr/local/lib/libiconv.so.4.0 >>> Symbols already loaded for /usr/lib/libpthread.so.9.0 >>> Reading symbols from /usr/lib/libm.so.2.3...done. >>> Loaded symbols for /usr/lib/libm.so.2.3 >>> Reading symbols from /usr/lib/libc.so.43.0...done. >>> Loaded symbols for /usr/lib/libc.so.43.0 >>> Reading symbols from /usr/libexec/ld.so...done. >>> Loaded symbols for /usr/libexec/ld.so >>> 0x1c0d3d13 in GC_mark_from (mark_stack_top=0x3c0ac000, >>> mark_stack=0x3c0ac000, mark_stack_limit=0x3c0b4000) at mark.c:759 >>> 759 deferred = *limit; >>> (gdb) >>> >>> >>> So, any pointing's where to look would be very appreciated. >>> >>> -- >>> GP >>> ___ >>> 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.x
Re: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data
Hey Veerapuram,
I've attached a patch for the changes I mentioned. However, I found out that
on the 1.0 profile we should still allow the value to be set to null if the
datatype of the column is string. This matches the behavior before r107145.
Let me know if it's ok to commit.
Gert
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Veerapuram
Varadhan
Sent: vrijdag 4 juli 2008 12:18
To: Gert Driesen
Cc: 'mono-devel-list'
Subject: Re: [Mono-dev] [Mono-patches] r107145 -
trunk/mcs/class/System.Data/System.Data
Hi Gert,
On Thu, 2008-07-03 at 18:19 +0200, Gert Driesen wrote:
> Hey Veerapuram,
>
> I don't think this change is correct. I've done some more tests, and this
is
> the behavior I'm seeing:
>
> * on 1.0 profile, you are never allowed to set value to NULL.
> * on 2.0 profile, you are only allowed to set value to NULL if the column
is
> backed by a reference type.
>
> I'll add unit tests for this to DataRowTest2.cs in a few minutes, and mark
> them NotWorking.
>
> Let me know if you want me to submit a patch that changes our
implementation
> accordingly.
>
That would be great. Feel free to submit tests and the patch.
Thanks,
V. Varadhan
> Gert
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Veerapuram
> Varadhan ([EMAIL PROTECTED])
> Sent: donderdag 3 juli 2008 15:38
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data
>
> Author: varadhan
> Date: 2008-07-03 09:38:09 -0400 (Thu, 03 Jul 2008)
> New Revision: 107145
>
> Modified:
>trunk/mcs/class/System.Data/System.Data/ChangeLog
>trunk/mcs/class/System.Data/System.Data/DataRow.cs
> Log:
> Use DBNull value instead of throwing an exception
>
>
> Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog
> ===
> --- trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:37:14
> UTC (rev 107144)
> +++ trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:38:09
> UTC (rev 107145)
> @@ -1,3 +1,7 @@
> +2008-07-03 Marek Habersack <[EMAIL PROTECTED]>
> +
> + * DataRow.cs (this []): Use DBNull instead of throwing an exception
> +
> 2008-07-01 Rodrigo Kumpera <[EMAIL PROTECTED]>
>
> * DataTable.cs: Kill some foreach loops.
>
> Modified: trunk/mcs/class/System.Data/System.Data/DataRow.cs
> ===
> --- trunk/mcs/class/System.Data/System.Data/DataRow.cs2008-07-03
13:37:14
> UTC (rev 107144)
> +++ trunk/mcs/class/System.Data/System.Data/DataRow.cs2008-07-03
13:38:09
> UTC (rev 107145)
> @@ -178,9 +178,8 @@
> DataColumn column =
> _table.Columns[columnIndex];
> _table.ChangingDataColumn (this, column,
> value);
>
> - if (value == null && column.DataType !=
> typeof(string)) {
> - throw new ArgumentException("Cannot
> set column " + column.ColumnName + " to be null, Please use DBNull
> instead");
> - }
> + if (value == null && column.DataType !=
> typeof(string))
> + value = DBNull.Value;
> _rowChanged = true;
>
> CheckValue (value, column);
>
> ___
> Mono-patches maillist - [EMAIL PROTECTED]
> 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
datarow.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] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
> > This is used thousands of times throughout the class libraries.
> > But in *THIS* case with void * it does not seem to work. So this was
> the easiest way to fix the problem.
>
> Ok, I used a class and int as type. So here a test using an unsafe
> struct and void* as member, just like IntPtr does:
>
> [EMAIL PROTECTED]:~$ cat test.cs
> using System;
>
> unsafe class Test
> {
> int value;
>
> Test(int value)
> {
> this.value = value;
> }
>
> public static void Main ()
> {
> Test t = new Test(123);
> Console.WriteLine(t.value);
>
> AnotherTest at = new AnotherTest(123);
> Console.WriteLine((int) at.value);
> }
> }
>
> public unsafe struct AnotherTest
> {
> internal void* value;
>
> public AnotherTest(int value)
> {
> this.value = (void*) value;
> }
> }
>
> [EMAIL PROTECTED]:~$ mono test.exe
> 123
> 123
Although it is interesting that this seems to work (by the way the problem was
that I couldn't even compile it). I still do not see the use of showing a test
that shows that there are situations in which it works. If you want to
reproduce the problem then I suggest that you take the Version of IntPtr (it’s
a small and simple type anyways) before my changes and then change the values
accordingly and then you will hopefully see the problem.
Then reduce it to the smallest case possible.
Then you would have to analyze the reason for it.
That (which could easily take one or more days) then leads you to maybe fix a
corner-case that probably nobody ever used (well exaggerating a little bit ;)
except the IntPtr struct.
> >
> > Greetings Andreas
> >
> > P.S. If you want to make further "tests" maybe mail me private and
> not through the list to keep the noise low.
>
> I don't think this is noise as you had issues with a possible compiler
> bug, so allow other developers to join the discussion and comment on
> the test-code.
I will not research any further here because imho it's just not worth my time
and there are far more important things to fix. Feel free to do if you like.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
On Fri, 2008-07-04 at 16:53 +0200, Andreas Nahr wrote:
>
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
> > [EMAIL PROTECTED] Im Auftrag von Mirco Bauer
> > Gesendet: Freitag, 4. Juli 2008 12:59
> > An: Andreas Nahr
> > Cc: mono-devel-list@lists.ximian.com
> > Betreff: Re: [Mono-dev] [Mono-patches] r107198 -
> > trunk/mcs/class/corlib/System
> > > > >
> > > > > public static readonly IntPtr Zero;
> > > > >
> > > > > #if NET_2_0
> > > > > [ReliabilityContract (Consistency.MayCorruptInstance,
> > > > Cer.MayFail)]
> > > > > #endif
> > > > > - public IntPtr (int i32)
> > > > > + public IntPtr (int value)
> > > > > {
> > > > > - value = (void *) i32;
> > > > > + m_value = (void *) value;
> > > >
> > > > afaik the goal can also be archived using this.value = value;
> > >
> > > Did you try that? I actually had it this way and it refused to
> > compile
> > > because the value was deemed not initialized. I've got to admit that
> > I
> > > wasn't exactly sure why it didn't. Potential issue with the compiler
> > maybe?
> >
> > At least for me it works, using gmcs 1.9.1:
> >
> > [EMAIL PROTECTED]:~$ cat test.cs
> > using System;
> >
> > class Test
> > {
> > int value;
> >
> > Test(int value)
> > {
> > this.value = value;
> > }
> >
> > public static void Main ()
> > {
> > Test t = new Test(123);
> > Console.WriteLine(t.value);
> > }
> > }
>
> Are you trying to make a joke? ;)
> Of course this works with "normal" types.
I didn't test exactly the same situation, but I prooved the way it
should work like.
> This is used thousands of times throughout the class libraries.
> But in *THIS* case with void * it does not seem to work. So this was the
> easiest way to fix the problem.
Ok, I used a class and int as type. So here a test using an unsafe
struct and void* as member, just like IntPtr does:
[EMAIL PROTECTED]:~$ cat test.cs
using System;
unsafe class Test
{
int value;
Test(int value)
{
this.value = value;
}
public static void Main ()
{
Test t = new Test(123);
Console.WriteLine(t.value);
AnotherTest at = new AnotherTest(123);
Console.WriteLine((int) at.value);
}
}
public unsafe struct AnotherTest
{
internal void* value;
public AnotherTest(int value)
{
this.value = (void*) value;
}
}
[EMAIL PROTECTED]:~$ mono test.exe
123
123
>
> Greetings Andreas
>
> P.S. If you want to make further "tests" maybe mail me private and not
> through the list to keep the noise low.
I don't think this is noise as you had issues with a possible compiler
bug, so allow other developers to join the discussion and comment on the
test-code.
--
Regards,
Mirco 'meebey' Bauer
PGP-Key ID: 0xEEF946C8
FOSS Developer[EMAIL PROTECTED] http://www.meebey.net/
PEAR Developer[EMAIL PROTECTED] http://pear.php.net/
Debian Developer [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: This is a digitally signed message part
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
> [EMAIL PROTECTED] Im Auftrag von Mirco Bauer
> Gesendet: Freitag, 4. Juli 2008 12:59
> An: Andreas Nahr
> Cc: mono-devel-list@lists.ximian.com
> Betreff: Re: [Mono-dev] [Mono-patches] r107198 -
> trunk/mcs/class/corlib/System
> > > >
> > > > public static readonly IntPtr Zero;
> > > >
> > > > #if NET_2_0
> > > > [ReliabilityContract (Consistency.MayCorruptInstance,
> > > Cer.MayFail)]
> > > > #endif
> > > > - public IntPtr (int i32)
> > > > + public IntPtr (int value)
> > > > {
> > > > - value = (void *) i32;
> > > > + m_value = (void *) value;
> > >
> > > afaik the goal can also be archived using this.value = value;
> >
> > Did you try that? I actually had it this way and it refused to
> compile
> > because the value was deemed not initialized. I've got to admit that
> I
> > wasn't exactly sure why it didn't. Potential issue with the compiler
> maybe?
>
> At least for me it works, using gmcs 1.9.1:
>
> [EMAIL PROTECTED]:~$ cat test.cs
> using System;
>
> class Test
> {
> int value;
>
> Test(int value)
> {
> this.value = value;
> }
>
> public static void Main ()
> {
> Test t = new Test(123);
> Console.WriteLine(t.value);
> }
> }
Are you trying to make a joke? ;)
Of course this works with "normal" types. This is used thousands of times
throughout the class libraries.
But in *THIS* case with void * it does not seem to work. So this was the
easiest way to fix the problem.
Greetings Andreas
P.S. If you want to make further "tests" maybe mail me private and not through
the list to keep the noise low.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Streaming with Moonlight/Silverlight vs Flash
On Fri, 2008-07-04 at 12:31 +0200, Federico Di Gregorio wrote: > Hi everybody, > > I am about to choose the technology that will be used during the next > two years to build the ESOF2010 web site (if you're curious about ESOF > just check this year website, http://www.esof2008.org/). The project for > 2010 includes a lot of streaming using preferably open protocols and > open source software (mandatory on the servers, the client code should > work at least on Windows and Linux and may use proprietary plugins). The > tools to create the streams should be free software. > > We choosed to use feng as the streaming server because it supports > RTP/RTSP and RTMP (now mostly free) with fallback on HTTP encapsulation > and a lot of different non-proprietary codecs. > > Looking at MS website for Silverlight specifications it seems to me that > streaming using the standard protocols cited above is not supported and > that only MS codecs (that we don't like to use) can be used. We also > investigated the possibility of writing a a managed RTP implementation > but it seems that UDP is not supported in Silverlight. And even if we > manage to have a working implementation of RTP it is not clear how you > can decode the data and send it to the multimedia part of the framework. > > So it seems that while we would much better like to work with > Mono/Moonlight and keep compatibility with Silverlight in the end will > be forced to use Adobe Flash (RTMP + one of the non-free codecs: at > least there are open source tools to do the authoring and the encoding > conversions). > > I am writing to this list because I _hope_ we missed something and that > Silverlight/Moonlight can be used to play streams using open protocols > and codecs. I /believe/ that Silverlight/Moonlight can do RTSP and RSTPT (and obviously MMS), but I'm not 100% sure. I don't know too much about the protocols but at one point I was helping out with the media streaming code and noticed code to handle those 2 protocol schemes (although it's possible that the code just did immediate fallback to http or something, I can't remember). Hopefully one of the moonlight media people can answer this more accurately. However, in the end, if you aren't happy with the codecs that Silverlight supports, then even if we add support for your preferred codec into Moonlight, it wouldn't solve your codec problem. Out of curiosity, which codec do you plan on using? Jeff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
Hi Andreas,
my reply is inline, see below.
On Fri, 2008-07-04 at 08:59 +0200, Andreas Nahr wrote:
> In Text
>
> > -Ursprüngliche Nachricht-
> > Von: Mirco Bauer [mailto:[EMAIL PROTECTED]
> > Gesendet: Freitag, 4. Juli 2008 01:52
> > An: mono-devel-list@lists.ximian.com
> > Cc: [EMAIL PROTECTED]
> > Betreff: Re: [Mono-patches] r107198 - trunk/mcs/class/corlib/System
> >
> > On Thu, 2008-07-03 at 18:23 -0400, Andreas Nahr
> > ([EMAIL PROTECTED]) wrote:
> > > Author: andreas
> > > Date: 2008-07-03 18:23:54 -0400 (Thu, 03 Jul 2008)
> > > New Revision: 107198
> > >
> > > Modified:
> > >trunk/mcs/class/corlib/System/ChangeLog
> > >trunk/mcs/class/corlib/System/IntPtr.cs
> > > Log:
> > > 2008-07-04 Andreas Nahr <[EMAIL PROTECTED]>
> > >
> > > * IntPtr: Fix parameter names, change internal name to accomodate
> > for parameter changes
> > >
> > > Modified: trunk/mcs/class/corlib/System/ChangeLog
> > > ===
> > > --- trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:22:43 UTC
> > (rev 107197)
> > > +++ trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:23:54 UTC
> > (rev 107198)
> > > @@ -1,5 +1,9 @@
> > > 2008-07-04 Andreas Nahr <[EMAIL PROTECTED]>
> > >
> > > + * IntPtr: Fix parameter names, change internal name to accomodate
> > for parameter changes
> > > +
> > > +2008-07-04 Andreas Nahr <[EMAIL PROTECTED]>
> > > +
> > > * Predicate.cs:
> > > * Object.cs:
> > > * Nullable.cs
> > >
> > > Modified: trunk/mcs/class/corlib/System/IntPtr.cs
> > > ===
> > > --- trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:22:43 UTC
> > (rev 107197)
> > > +++ trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:23:54 UTC
> > (rev 107198)
> > > @@ -57,44 +57,44 @@
> > > #endif
> > > public unsafe struct IntPtr : ISerializable
> > > {
> > > - private void *value;
> > > + private void *m_value;
> >
> > I am not sure, but doesn't this break binary serialization
> > compatibility?
>
> It shouldn't. IntPtr has an explicit Serializer implementation that deals
> with setting correct names. I did not change those.
Oh ok, didn't see that (from the patch).
>
> > >
> > > public static readonly IntPtr Zero;
> > >
> > > #if NET_2_0
> > > [ReliabilityContract (Consistency.MayCorruptInstance,
> > Cer.MayFail)]
> > > #endif
> > > - public IntPtr (int i32)
> > > + public IntPtr (int value)
> > > {
> > > - value = (void *) i32;
> > > + m_value = (void *) value;
> >
> > afaik the goal can also be archived using this.value = value;
>
> Did you try that? I actually had it this way and it refused to compile
> because the value was deemed not initialized. I've got to admit that I
> wasn't exactly sure why it didn't. Potential issue with the compiler maybe?
At least for me it works, using gmcs 1.9.1:
[EMAIL PROTECTED]:~$ cat test.cs
using System;
class Test
{
int value;
Test(int value)
{
this.value = value;
}
public static void Main ()
{
Test t = new Test(123);
Console.WriteLine(t.value);
}
}
[EMAIL PROTECTED]:~$ mono test.exe
123
[EMAIL PROTECTED]:~$
I just find a bit intrusive/overkill to rename class members because of
parameter names of some ctor or method... (especially when they come
from MS .NET) as it might have side-effects like serialization comp for
classes that don't have an explicit implementation.
Thanks for your effort.
--
Regards,
Mirco 'meebey' Bauer
PGP-Key ID: 0xEEF946C8
FOSS Developer[EMAIL PROTECTED] http://www.meebey.net/
PEAR Developer[EMAIL PROTECTED] http://pear.php.net/
Debian Developer [EMAIL PROTECTED] http://www.debian.org/
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] Streaming with Moonlight/Silverlight vs Flash
Hi everybody, I am about to choose the technology that will be used during the next two years to build the ESOF2010 web site (if you're curious about ESOF just check this year website, http://www.esof2008.org/). The project for 2010 includes a lot of streaming using preferably open protocols and open source software (mandatory on the servers, the client code should work at least on Windows and Linux and may use proprietary plugins). The tools to create the streams should be free software. We choosed to use feng as the streaming server because it supports RTP/RTSP and RTMP (now mostly free) with fallback on HTTP encapsulation and a lot of different non-proprietary codecs. Looking at MS website for Silverlight specifications it seems to me that streaming using the standard protocols cited above is not supported and that only MS codecs (that we don't like to use) can be used. We also investigated the possibility of writing a a managed RTP implementation but it seems that UDP is not supported in Silverlight. And even if we manage to have a working implementation of RTP it is not clear how you can decode the data and send it to the multimedia part of the framework. So it seems that while we would much better like to work with Mono/Moonlight and keep compatibility with Silverlight in the end will be forced to use Adobe Flash (RTMP + one of the non-free codecs: at least there are open source tools to do the authoring and the encoding conversions). I am writing to this list because I _hope_ we missed something and that Silverlight/Moonlight can be used to play streams using open protocols and codecs. Thank you for your time, federico -- signify error: can't use imaginary (1+0.191071i) weight! signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data
Hi Gert,
On Thu, 2008-07-03 at 18:19 +0200, Gert Driesen wrote:
> Hey Veerapuram,
>
> I don't think this change is correct. I've done some more tests, and this is
> the behavior I'm seeing:
>
> * on 1.0 profile, you are never allowed to set value to NULL.
> * on 2.0 profile, you are only allowed to set value to NULL if the column is
> backed by a reference type.
>
> I'll add unit tests for this to DataRowTest2.cs in a few minutes, and mark
> them NotWorking.
>
> Let me know if you want me to submit a patch that changes our implementation
> accordingly.
>
That would be great. Feel free to submit tests and the patch.
Thanks,
V. Varadhan
> Gert
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Veerapuram
> Varadhan ([EMAIL PROTECTED])
> Sent: donderdag 3 juli 2008 15:38
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: [Mono-patches] r107145 - trunk/mcs/class/System.Data/System.Data
>
> Author: varadhan
> Date: 2008-07-03 09:38:09 -0400 (Thu, 03 Jul 2008)
> New Revision: 107145
>
> Modified:
>trunk/mcs/class/System.Data/System.Data/ChangeLog
>trunk/mcs/class/System.Data/System.Data/DataRow.cs
> Log:
> Use DBNull value instead of throwing an exception
>
>
> Modified: trunk/mcs/class/System.Data/System.Data/ChangeLog
> ===
> --- trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:37:14
> UTC (rev 107144)
> +++ trunk/mcs/class/System.Data/System.Data/ChangeLog 2008-07-03 13:38:09
> UTC (rev 107145)
> @@ -1,3 +1,7 @@
> +2008-07-03 Marek Habersack <[EMAIL PROTECTED]>
> +
> + * DataRow.cs (this []): Use DBNull instead of throwing an exception
> +
> 2008-07-01 Rodrigo Kumpera <[EMAIL PROTECTED]>
>
> * DataTable.cs: Kill some foreach loops.
>
> Modified: trunk/mcs/class/System.Data/System.Data/DataRow.cs
> ===
> --- trunk/mcs/class/System.Data/System.Data/DataRow.cs2008-07-03
> 13:37:14
> UTC (rev 107144)
> +++ trunk/mcs/class/System.Data/System.Data/DataRow.cs2008-07-03
> 13:38:09
> UTC (rev 107145)
> @@ -178,9 +178,8 @@
> DataColumn column =
> _table.Columns[columnIndex];
> _table.ChangingDataColumn (this, column,
> value);
>
> - if (value == null && column.DataType !=
> typeof(string)) {
> - throw new ArgumentException("Cannot
> set column " + column.ColumnName + " to be null, Please use DBNull
> instead");
> - }
> + if (value == null && column.DataType !=
> typeof(string))
> + value = DBNull.Value;
> _rowChanged = true;
>
> CheckValue (value, column);
>
> ___
> Mono-patches maillist - [EMAIL PROTECTED]
> 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] Mono.Addins suppress console window showing
I'll commit the fix. Thanks!!! El dv 04 de 07 de 2008 a les 10:10 +0300, en/na Vladimir Dimitrov va escriure: > Thanks Brad, > > Yes that worked and I don't see any problems with the line that I talked > about being added so if the developer of this library is somewhere around he > could add the change to the main source so everybody can get the fix. > > - Vlad > > -Original Message- > From: Brad Taylor [mailto:[EMAIL PROTECTED] > Sent: Friday, July 04, 2008 5:31 AM > To: Vladimir Dimitrov > Cc: Mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] Mono.Addins suppress console window showing > > Hey Vlad, > > > Recently I started using Mono.Addins in my application and it looks > > very good. But as the application is primary used under windows > > (should be working fine under Linux too) I get an annoying console > > window showing when I run: > > > You can also compile Mono.Addins as a "winexe" target to suppress the > console. You'll probably have to rename it to a .dll afterwards if you > compile under Windows. > > Hope this helps, > > -Brad > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.134 / Virus Database: 270.4.4/1531 - Release Date: 02.7.2008 г. > 19:02 > > ___ > 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] Sortkey.cs weirdness in corlib
I've seen that the SortKey class in System.Globalization is not used/compiled at all. Instead a identically named class from Mono.Globalization is used. My suggestion would be to a) delete the SortKey in the System.Globalization directory of corlib b) move the class from Mono.Globalization to System.Globalization any objections? Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins suppress console window showing
Thanks Brad, Yes that worked and I don't see any problems with the line that I talked about being added so if the developer of this library is somewhere around he could add the change to the main source so everybody can get the fix. - Vlad -Original Message- From: Brad Taylor [mailto:[EMAIL PROTECTED] Sent: Friday, July 04, 2008 5:31 AM To: Vladimir Dimitrov Cc: Mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono.Addins suppress console window showing Hey Vlad, > Recently I started using Mono.Addins in my application and it looks > very good. But as the application is primary used under windows > (should be working fine under Linux too) I get an annoying console > window showing when I run: You can also compile Mono.Addins as a "winexe" target to suppress the console. You'll probably have to rename it to a .dll afterwards if you compile under Windows. Hope this helps, -Brad No virus found in this incoming message. Checked by AVG. Version: 8.0.134 / Virus Database: 270.4.4/1531 - Release Date: 02.7.2008 г. 19:02 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
