[Mono-dev] Mono RHEL5
I'm looking for mono RPM for Red Enterprise Linux 5... I didn't find this on the mono website... It could be great to have RPM for RHEL5? I'm trying to compile mono myself on this platform... ___ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CSS-Friendly support?
Hi, I've developed a site which I plan to run on mono mod_mono, and it works almost flawlessly. There is however one thing which bugs me, sure I can make it work anyways but it would be really nice to get it working. I cannot get the CSS Friendly controls available at http://www.asp.net/cssadapters/ to work in Mono. I'm using the adapters in what I percieve to be it's default mode, bu specifying them in the App_Browsers/CSSFriendlyAdapters.browser file. I'm using a precompiled site, so the binary is called, and located in, bin/App_Browsers.dll If you want more information please let me know - I have no idea what is needed and havn't found a hint anywhere. Thanks for any help // Fredrik ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CSS-Friendly support?
On Fri, 25 May 2007 09:28:15 +0200, Fredrik Elestedt [EMAIL PROTECTED] scribbled: Hi, Hello, I've developed a site which I plan to run on mono mod_mono, and it works almost flawlessly. There is however one thing which bugs me, sure I can make it work anyways but it would be really nice to get it working. I cannot get the CSS Friendly controls available at http://www.asp.net/cssadapters/ to work in Mono. I'm using the adapters in what I percieve to be it's default mode, bu specifying them in the App_Browsers/CSSFriendlyAdapters.browser file. I'm using a precompiled site, so the binary is called, and located in, bin/App_Browsers.dll Browsing the 2.0 .browsers XML database is not supported under Mono yet. It is planned, but not at a very high priority right now. Unfortunately, CSS Adapters require the support in order to specify which classes to use to adapt the output to the current browser. I hope I will be able to implement the support in the upcoming months, can't promise when exactly, though. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack?
Hi, Fixed the issue in SVN trunk - revision 77937. Thanks Nagappan Nagappan A [EMAIL PROTECTED] Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready™ http://www.novell.com/linux Mads Bondo Dydensborg [EMAIL PROTECTED] 05/16/07 2:56 PM onsdag 16 maj 2007 11:08 skrev A Nagappan: Hi, From the stack trace it looks like the issue is in System.DateTime, How did you determine this? My impression was that the ODBC stack hands over a frational second value in nanoseconds, and DateTime expects the fractional value to be in milliseconds? If that is the case, I can hardly blame DateTime for expecting a millisecond value, can I? Please advise. Regards, Mads could you please file a bug on that ? With a generic test-case to reproduce this bug. http://bugzilla.ximian.com/enter_bug.cgi?product=Mono%3A%20Class%20Libraries and Component as System. Thanks Nagappan Nagappan A [EMAIL PROTECTED] Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com Novell, Inc. SUSE* Linux Enterprise 10 Your Linux is ready* http://www.novell.com/linux On Fri, May 4, 2007 at 6:15 PM, in message [EMAIL PROTECTED], Mads Bondo Dydensborg [EMAIL PROTECTED] wrote: fredag 04 maj 2007 10:56 skrev A Nagappan: Hi, Could you please send me a test.cs file to reproduce this bug ? Please find it attached. Running select PublishedTime from PublishingJob from isql returns: 2007- 05- 03 10:57:15.000 2007- 05- 03 10:57:15.920 2007- 05- 03 10:57:15.000 2007- 05- 03 10:57:15.000 And, the output from the test.cs program is: $ mono -- debug test.exe Creating connection Opening connection Executing command Reading data Column 0: 5/3/2007 10:57:15 AM Unhandled Exception: System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: Parameters describe an unrepresentable DateTime. at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond) [0x0] at System.Data.Odbc.OdbcDataReader.GetValue (Int32 ordinal) [0x00415] in /home/compile/Compile/Mono/mcs/class/System.Data/System.Data.Odbc/OdbcDataRea der.cs:730 at System.Data.Odbc.OdbcDataReader.get_Item (Int32 index) [0x0] in /home/compile/Compile/Mono/mcs/class/System.Data/System.Data.Odbc/OdbcDataRea der.cs:153 at Test.OdbcTest.OdbcTest.Main (System.String[] args) [0x00057] in /home/madsdyd/Tests/OdbcDateTime/test.cs:26 So, the first row is correctly made into a DateTime, the next is not. Stripping the fractional of all dates in the database works, but is not really what I want :- ) Regards thanks in advance for your help. Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CSS-Friendly support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek, Good to know that it is planned. Perhaps I could help in some way to get it done? I do have a small self-interest in getting it working :D Should it be implemented entierly in C#? Do you know _how_ to get the support in there, but simply do not have the time to write it? I'll be glad to help, if I'm able to. // Fredrik Marek Habersack wrote: On Fri, 25 May 2007 09:28:15 +0200, Fredrik Elestedt [EMAIL PROTECTED] scribbled: Hi, Hello, I've developed a site which I plan to run on mono mod_mono, and it works almost flawlessly. There is however one thing which bugs me, sure I can make it work anyways but it would be really nice to get it working. I cannot get the CSS Friendly controls available at http://www.asp.net/cssadapters/ to work in Mono. I'm using the adapters in what I percieve to be it's default mode, bu specifying them in the App_Browsers/CSSFriendlyAdapters.browser file. I'm using a precompiled site, so the binary is called, and located in, bin/App_Browsers.dll Browsing the 2.0 .browsers XML database is not supported under Mono yet. It is planned, but not at a very high priority right now. Unfortunately, CSS Adapters require the support in order to specify which classes to use to adapt the output to the current browser. I hope I will be able to implement the support in the upcoming months, can't promise when exactly, though. best regards, marek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGVukc6vo41heZew4RAhRjAJ4/4i6GiIfJtRjy/ENP2os33idxJgCfVGH0 L03cn0lsTbA0PlkVKMQUH4c= =1h47 -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: javascript compiler for Moonlight.
Hello Olivier, I have just start to done a compiler of javascript in C# for Moonlight. It is just to ask if someone is ever working on it... and if there is a place in svn to commit in order to make it open to community for dev ;) Is this using the DLR? I suggest that you do two things: * That you ensure that your publicly visible API matches the Silverlight Javascript compiler, either using the object browser in Visual Studio or using monop2: Use monop2 -r Microsoft.Javascript.dll And then dump each type with: monop2 -r:Microsoft.Javascript.dll Some.Type * You should check this work into the olive module, in the olive/class directory. * You should write a tokenizer/parser from scratch based on the public spec instead of the one that we did in the past, I suggest a manually written recursive descendant parser or even jay, but I would stay away from antlr which is a pretty large dependency to put in the tree Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] CSS-Friendly support?
On Fri, 25 May 2007 16:58:56 +0200, Fredrik Elestedt [EMAIL PROTECTED] scribbled: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek, Fredrik, Good to know that it is planned. Perhaps I could help in some way to get it done? I do have a small self-interest in getting it working :D Should it be implemented entierly in C#? Do you know _how_ to get the support in there, but simply do not have the time to write it? Yes, I know how to do it - it's a time+priority issue. But, if you want to take a stab - you're by all means welcome. Basically, we need two things - a private class in the System.Web assembly to _compile_ the XML description into C# code (for an example of a similar compiler, see the source of the culevel compiler in the mcs sources) and a build provider which will expose the class to the world. MS.NET ships the precompiled database as a binary assembly and never recompiles it dynamically. We won't even do that - we aren't going to ship any predefined database, we'll continue to use browscaps.ini instead. The only use of the compiler class and the build provider will be when the user puts a .browser file in ~/App_Code/, to dynamically build the C# code out of the description _and_ plug it into the browser properties lookup pipeline. Since we're going to keep using browscaps.ini for the main properties, I believe the .browser-based property lookup should take precedence over the browscaps.ini one. This is in short words what needs to be done. I can't stress enough that we do not want to use this code as the main method of property lookup (since it's slow, because of regexps it can use, header/field matches etc.) - it will only be used when the adapter information is required. I'll be glad to help, if I'm able to. if you have any questions, send me a mail off-list so we can discuss the implementation details. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: javascript compiler for Moonlight.
Hi, First, I have done a lexer and start the jay for parser. But I really prefer to done it manually but it help to understand all part of code. I have name the project Mono.JScript.Compiler for moment. My Lexer work and NUNIT test work on it but for parser it an other thing... I use ECMA-262 v3 to do the lexer and parser. OK to change to have the same public interface than M$ compiler. I will see it and try to go manually now ;) thanks for feed back ;) bye, Olivier Dufour 2007/5/25, Miguel de Icaza [EMAIL PROTECTED]: Hello Olivier, I have just start to done a compiler of javascript in C# for Moonlight. It is just to ask if someone is ever working on it... and if there is a place in svn to commit in order to make it open to community for dev ;) Is this using the DLR? I suggest that you do two things: * That you ensure that your publicly visible API matches the Silverlight Javascript compiler, either using the object browser in Visual Studio or using monop2: Use monop2 -r Microsoft.Javascript.dll And then dump each type with: monop2 -r:Microsoft.Javascript.dll Some.Type * You should check this work into the olive module, in the olive/class directory. * You should write a tokenizer/parser from scratch based on the public spec instead of the one that we did in the past, I suggest a manually written recursive descendant parser or even jay, but I would stay away from antlr which is a pretty large dependency to put in the tree Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: javascript compiler for Moonlight.
Hi Olivier, I've been looking for a parser to use in our wiki software, but all the ones I have found (lua, boo, ...) didn't quite fit for different reasons. Will your parser expose the AST so that it can plugged into a custom compilation/execution environment? - Steve -- Steve G. Bjorg http://www.mindtouch.com http://www.opengarden.org On May 25, 2007, at 9:16 AM, olivier dufour wrote: Hi, First, I have done a lexer and start the jay for parser. But I really prefer to done it manually but it help to understand all part of code. I have name the project Mono.JScript.Compiler for moment. My Lexer work and NUNIT test work on it but for parser it an other thing... I use ECMA-262 v3 to do the lexer and parser. OK to change to have the same public interface than M$ compiler. I will see it and try to go manually now ;) thanks for feed back ;) bye, Olivier Dufour 2007/5/25, Miguel de Icaza [EMAIL PROTECTED]: Hello Olivier, I have just start to done a compiler of javascript in C# for Moonlight. It is just to ask if someone is ever working on it... and if there is a place in svn to commit in order to make it open to community for dev ;) Is this using the DLR? I suggest that you do two things: * That you ensure that your publicly visible API matches the Silverlight Javascript compiler, either using the object browser in Visual Studio or using monop2: Use monop2 -r Microsoft.Javascript.dll And then dump each type with: monop2 -r:Microsoft.Javascript.dll Some.Type * You should check this work into the olive module, in the olive/class directory. * You should write a tokenizer/parser from scratch based on the public spec instead of the one that we did in the past, I suggest a manually written recursive descendant parser or even jay, but I would stay away from antlr which is a pretty large dependency to put in the tree Miguel. ___ 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] Fwd: javascript compiler for Moonlight.
I've been looking for a parser to use in our wiki software, but all the ones I have found (lua, boo, ...) didn't quite fit for different reasons. Will your parser expose the AST so that it can plugged into a custom compilation/execution environment? For a Javascript compiler that we can use (and that is usable for Silverlight) he will need to use the DLR AST. I would personally wait for the next IronPython release as they mentioned during the conference that the DLR was changing and being tuned. - Steve -- Steve G. Bjorg http://www.mindtouch.com http://www.opengarden.org On May 25, 2007, at 9:16 AM, olivier dufour wrote: Hi, First, I have done a lexer and start the jay for parser. But I really prefer to done it manually but it help to understand all part of code. I have name the project Mono.JScript.Compiler for moment. My Lexer work and NUNIT test work on it but for parser it an other thing... I use ECMA-262 v3 to do the lexer and parser. OK to change to have the same public interface than M$ compiler. I will see it and try to go manually now ;) thanks for feed back ;) bye, Olivier Dufour 2007/5/25, Miguel de Icaza [EMAIL PROTECTED]: Hello Olivier, I have just start to done a compiler of javascript in C# for Moonlight. It is just to ask if someone is ever working on it... and if there is a place in svn to commit in order to make it open to community for dev ;) Is this using the DLR? I suggest that you do two things: * That you ensure that your publicly visible API matches the Silverlight Javascript compiler, either using the object browser in Visual Studio or using monop2: Use monop2 -r Microsoft.Javascript.dll And then dump each type with: monop2 -r:Microsoft.Javascript.dll Some.Type * You should check this work into the olive module, in the olive/class directory. * You should write a tokenizer/parser from scratch based on the public spec instead of the one that we did in the past, I suggest a manually written recursive descendant parser or even jay, but I would stay away from antlr which is a pretty large dependency to put in the tree Miguel. ___ 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] Simple method devirtualization patch
The following patch perform simple devirtualization based on the sealed flag of methods and types. The patch makes pystone 4% faster with IronPython 2.0 and 1% faster with IronPython 1.0. It should improve other benchmarks as well, since it main contribution is statically dispatching delegate.Invoke. To provide more broad results a sse pass that perform type propagation is needed. The only thing I'm not sure about this patch is if it should handle remoting wrappers is some sort of way. devirt.patch Description: Binary data devirtualization.cs 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] Simple method devirtualization patch
Hey,
Rodrigo Kumpera wrote:
The following patch perform simple devirtualization based on the sealed
flag
of methods and types.
The patch makes pystone 4% faster with IronPython 2.0 and 1% faster with
IronPython 1.0. It should improve other benchmarks as well, since it main
contribution is statically dispatching delegate.Invoke. To provide more
broad results a sse pass that perform type propagation is needed.
The only thing I'm not sure about this patch is if it should handle
remoting
wrappers is some sort of way.
--- inssel.brg(revision 77933)
+++ inssel.brg(working copy)
@@ -1690,6 +1690,17 @@
method = ((MonoCallInst*)tree)-method =
mono_marshal_get_remoting_invoke_with_check (method);
}
+ MONO_EMIT_NEW_UNALU (cfg, OP_CHECK_THIS, -1, this_reg);
+
+ tree-dreg = state-reg1;
+ tree-opcode = novirtop;
+ mono_bblock_add_inst (cfg-cbb, tree);
+ return;
+ }
+
+ if ((method-flags METHOD_ATTRIBUTE_VIRTUAL)
+ ((method-klass-flags TYPE_ATTRIBUTE_SEALED) ||
+ (method-klass-flags TYPE_ATTRIBUTE_SEALED))) {
One of the TYPE_ATTRIBUTE_SEALED checks is redundant.
You probably want method-flags METHOD_ATTRIBUTE_FINAL.
if (!method-string_ctor)
The string ctor is probably not virtual, so you should leave the check
where it was.
I'd rather remove the 2nd branch at all and put the
method-klass-flags TYPE_ATTRIBUTE_SEALED check in the existing one.
I didn't test it, though.
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Simple method devirtualization patch
Hi Robert,
I was revisiting the code and there must be 2 checks, but one is for sealed
class and one for sealed method, but obviously the patch is wrong, thanks
for spoting!
About the string_ctor check should be removed as well.
Rodrigo
On 5/25/07, Robert Jordan [EMAIL PROTECTED] wrote:
Hey,
Rodrigo Kumpera wrote:
The following patch perform simple devirtualization based on the sealed
flag
of methods and types.
The patch makes pystone 4% faster with IronPython 2.0 and 1% faster with
IronPython 1.0. It should improve other benchmarks as well, since it
main
contribution is statically dispatching delegate.Invoke. To provide more
broad results a sse pass that perform type propagation is needed.
The only thing I'm not sure about this patch is if it should handle
remoting
wrappers is some sort of way.
--- inssel.brg(revision 77933)
+++ inssel.brg(working copy)
@@ -1690,6 +1690,17 @@
method = ((MonoCallInst*)tree)-method =
mono_marshal_get_remoting_invoke_with_check (method);
}
+ MONO_EMIT_NEW_UNALU (cfg, OP_CHECK_THIS, -1, this_reg);
+
+ tree-dreg = state-reg1;
+ tree-opcode = novirtop;
+ mono_bblock_add_inst (cfg-cbb, tree);
+ return;
+ }
+
+ if ((method-flags METHOD_ATTRIBUTE_VIRTUAL)
+ ((method-klass-flags TYPE_ATTRIBUTE_SEALED) ||
+ (method-klass-flags TYPE_ATTRIBUTE_SEALED))) {
One of the TYPE_ATTRIBUTE_SEALED checks is redundant.
You probably want method-flags METHOD_ATTRIBUTE_FINAL.
if (!method-string_ctor)
The string ctor is probably not virtual, so you should leave the check
where it was.
I'd rather remove the 2nd branch at all and put the
method-klass-flags TYPE_ATTRIBUTE_SEALED check in the existing one.
I didn't test it, though.
Robert
___
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
