Re: [Mono-dev] gmcs and The Future
This sounds like the macro system discussed here : http://cheddar.wik.is/Macro_system. Anyway, better to brainstorm on the wiki now than the mailing list imho ;-) . -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com 2009/2/17 Stefan Noack noackste...@googlemail.com Hi, Anyway, am not completely against the idea, I already wrote about how I'd like to have a more extensible mcs, but in the current state of affairs, again, I'd very cautious. Some time ago, I had the idea of an extensible compiler. One with kind of a plugin system. Or even better, a keyword keyword that allows you to define new keywords by providing classes that implement certain Interfaces that allow the compiler to parse and emit your new language feature. I already have a name for that language - it would be Sugar (lot's of syntactic sugar included ;-) How do you think about that idea? (I wish I had more time for such stuff :-/ ) Stefan ___ 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] gmcs and The Future
Hi, Anyway, am not completely against the idea, I already wrote about how I'd like to have a more extensible mcs, but in the current state of affairs, again, I'd very cautious. Some time ago, I had the idea of an extensible compiler. One with kind of a plugin system. Or even better, a keyword keyword that allows you to define new keywords by providing classes that implement certain Interfaces that allow the compiler to parse and emit your new language feature. I already have a name for that language - it would be Sugar (lot's of syntactic sugar included ;-) How do you think about that idea? (I wish I had more time for such stuff :-/ ) Stefan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Doesn't it make more sense to add something like a macro system (see Boo, Nemerle, Scheme, ...) ? That way you would only change the compiler once (for the macro resolution) and then you can extend the language at your wish in external libraries (as with Mono.Rocks). The three main advantages I see with this approach are : 1) it's less burden on compiler maintenance (only one component to care about), 2) people can more properly select the feature they wish to use (simply choosing what to link in their project), 3) it can make contribution easier (no need to know the compiler inner-working). Anyway, my two cents. -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Wed, Feb 11, 2009 at 6:18 AM, Scott Peterson sc...@ssblack.co.nz wrote: This should get things started: http://cheddar.wik.is/ We can move hosts later it we want. ___ 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] gmcs and The Future
Sounds to me like you should suggest that on the wiki ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Any word on a wiki? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: Any word on a wiki? If we don't use the mono-project one, on http://wik.is/ you can create one easily, and it turns out it's using Deki (powered by Mono) ;) Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
This should get things started: http://cheddar.wik.is/ We can move hosts later it we want. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
That crtical part you can code in Boo, using Boo Macros, which would perform just as you want, and have only the external API paying the call cost. Just an idea to leverage the multilanguage abilities in Mono/.NET. Fun, On Wed, Feb 4, 2009 at 2:18 PM, russell@realtimeworlds.com wrote: Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
I wonder (may be a silly idea but) if there is any chance that mono team can take the initiative to derive the ECMA C# standard in future 2009/2/6 Rafael Teixeira mono...@gmail.com: That crtical part you can code in Boo, using Boo Macros, which would perform just as you want, and have only the external API paying the call cost. Just an idea to leverage the multilanguage abilities in Mono/.NET. Fun, On Wed, Feb 4, 2009 at 2:18 PM, russell@realtimeworlds.com wrote: Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ 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] gmcs and The Future
Whatever the format of the forum, I would like it to be easy for anyone to participate. A wiki fits the bill, but it might be best to keep this program separate from the primary Mono wiki so that account permissions don't become conflated. What does someone in charge of the Mono site/wiki think (Miguel)? Like I mentioned, Google Groups is another option: it's easy for people to join the fray. It also allows you to organize information with pages, but those cannot be edited collaboratively like a wiki. In the mean time, interested parties, be thinking about your language ideas. Some good things to think about and/or write down might include: * What other languages have this feature, if any? * Example code of your language feature. * The code it would be replacing (i.e. how would I accomplish the same thing today, if possible). * Does this break backwards compatibility in any way (i.e. add a new keyword or such)? * What are the corner cases? Be thinking, and hopefully we'll all be able to share our ideas soon. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hi,
Thank you for tracking this down. Could you fill a bug report at
http://www.mono-project.com/Bugs so we can address the issue.
Marek
I try to use these voodoo keywords and have a small report:
1) gmcs currently supports only __arglist keyword, but sometimes
generates incorrect CIL. That code works while compiling with csc.exe,
but leads to segmentation fault after gmsc (I try it on Mac OS 10.5,
Mono 2.2 ):
== CODE ===
private static void TestArglistMethod()
{
ArglistMethod( __arglist( 1, 2, 3 ) );
}
private static void ArglistMethod(__arglist )
{
var iter = new ArgIterator( __arglist );
for( var n = iter.GetRemainingCount(); n 0; n-- )
Console.WriteLine( TypedReference.ToObject( iter.GetNextArg() ) );
}
===
2) Mono VES currently supports mkrefany, refanyval, refanytype,
arglist instructions for non-P/Invoke scenario.
3) Mono JIT P/Invoke layer don't like __arglist parameters and
reports something like this: Invalid IL code in
NObjective.Program:Main (string[]): IL_0021: ret
== CODE ===
[DllImport( libc.dylib )]
public extern static void printf( string format, __arglist );
...
printf( ytu, __arglist( 44 ) );
===
If compiler will be able generate correct CIL it will be useful for
debugging future P/Invoke layer that will able to work with __arglist
NObjective contains about of 43000 generated methods (generated from
Objective-C method signatures) accessible by user that looks like:
== CODE ===
unsafe public static bool writeToURL_atomically_( this NSData ___this,
NSURL url, bool atomically ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.writeToURL_atomically_( ___this,
CachedSelectors.writeToURL_atomically_, out ___occuredException,
sizeof( NSURL ) + sizeof( bool ), url, atomically );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
unsafe public static bool writeToURL_options_error_( this NSData
___this, NSURL url, uint options, ref NSError error ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.writeToURL_options_error_( ___this,
CachedSelectors.writeToURL_options_error_, out ___occuredException,
sizeof( NSURL ) + sizeof( uint ) + sizeof( IntPtr ), url, options, ref
error );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
===
Each generated method have a generated P/Invoke counterpart with same
entry point and nearly same signature (another 43000 methods!):
== CODE ===
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool writeToURL_atomically_( RuntimeObject
___object, Selector ___selector, out RuntimeObject
___occuredException, int ___stackSize, NSURL url, bool atomically );
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool writeToURL_options_error_( RuntimeObject
___object, Selector ___selector, out RuntimeObject
___occuredException, int ___stackSize, NSURL url, uint options, ref
NSError error );
===
With proper __arglist support in VES/gmcs unnecessary P/Invokes can be
easily removed ( -43000 methods = assembly will hold much less
metadata ) and calls redirected to SINGLE __arglist method:
== CODE ===
unsafe public static bool writeToURL_atomically_( this NSData ___this,
NSURL url, bool atomically ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.FutureArglistMethod( ___this,
CachedSelectors.writeToURL_atomically_, out ___occuredException,
sizeof( NSURL ) + sizeof( bool ), __arglist( url, atomically ) );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
unsafe public static bool writeToURL_options_error_( this NSData
___this, NSURL url, uint options, ref NSError error ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.FutureArglistMethod( ___this,
CachedSelectors.writeToURL_options_error_, out ___occuredException,
sizeof( NSURL ) + sizeof( uint ) + sizeof( IntPtr ), __arglist( url,
options, ref error ) );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
...
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool FutureArglistMethod( RuntimeObject
___object, Selector ___selector, out RuntimeObject
___occuredException, int
Re: [Mono-dev] gmcs and The Future
It sounds like the general reaction is cautiously favorable. New language features would be nice, but they would require a commitment to maintenance. As I see it, whether we are willing to invest ongoing effort in a feature depends on the strength of the feature. A sufficiently killer feature will motivate its own upkeep. So what is (are) the killer feature(s)? I would be interested in organizing a forum for proposing and discussing language features. If for no other reason than as an excuse to talk about language design with smart people. This forum could start as an informal bake-off of ideas and brainstorms. If momentum builds behind a particular feature, we could formalize a proposal for its inclusion in the compiler. This allows the exploration of many ideas without the looming specter of feature-creep. If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: It sounds like the general reaction is cautiously favorable. New language features would be nice, but they would require a commitment to maintenance. As I see it, whether we are willing to invest ongoing effort in a feature depends on the strength of the feature. A sufficiently killer feature will motivate its own upkeep. So what is (are) the killer feature(s)? I would be interested in organizing a forum for proposing and discussing language features. If for no other reason than as an excuse to talk about language design with smart people. This forum could start as an informal bake-off of ideas and brainstorms. If momentum builds behind a particular feature, we could formalize a proposal for its inclusion in the compiler. This allows the exploration of many ideas without the looming specter of feature-creep. If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? I really like this proposal. (Although I see why the people is worried about maintaining the features, this may be worth it because it may be an interesting incubator of proposals to Anders H. for next versions, no?). I have a big pile of ideas that I was gathering in order to blog as a 'C# wishlist', so I could contribute them to this discussion. My suggestion is to use the wiki hosted in mono-project. We could create a page with an index with links to all ideas (sub-pages). Every idea could be voted up (+1) or down (-1) by the community, giving comments or feedback about the vote, maybe causing the idea to mutate. And after some time, the best ideas could be then created in Bugzilla and tracked there... Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, Feb 5, 2009 at 2:54 PM, Scott Peterson sc...@ssblack.co.nz wrote: If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? You might want to take a look at how the Scheme community manages this process: http://srfi.schemers.org/ bye Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, Feb 5, 2009 at 8:54 AM, Scott Peterson sc...@ssblack.co.nz wrote: So what is (are) the killer feature(s)? I would be interested in organizing a forum for proposing and discussing language features. If for no other reason than as an excuse to talk about language design with smart people. This forum could start as an informal bake-off of ideas and brainstorms. If momentum builds behind a particular feature, we could formalize a proposal for its inclusion in the compiler. This allows the exploration of many ideas without the looming specter of feature-creep. If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? I may not have a lot to contribute, but I would enjoy reading such a forum :) Have you looked at uservoice.com? It's not open source, but it's free to use, and their UI is really excellent for handling feature suggestions. Of course, in an open source project, feature suggestions aren't nearly as valuable as working implementations of those features. FWIW, I really like Miguel's idea to have Ruby-style inline string substitutions. And my own idea: add support for # line style preprocessor tags, as produced by cpp. I have a few programs that need to run through cpp before compiling, and the lack of # line support means that (unless I'm almost impossibly careful and do some strange tricks) the line numbers reported in error/warning messages will be screwed up by the preprocessor. (The reason I use cpp, incidentally, is so I can implement C-style assert() and check() macros that actually print the condition being tested as part of the assertion message. There seems to be no other way to do this in C#, which is too bad.) Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, Feb 5, 2009 at 12:19 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote: (The reason I use cpp, incidentally, is so I can implement C-style assert() and check() macros that actually print the condition being tested as part of the assertion message. There seems to be no other way to do this in C#, which is too bad.) There is now. It's not the most performant technique around, but your Assert() or Check() methods could take an ExpressionT. The ExpressionT can then be converted into a string for diagnostic messages, and converted into a delegate for the actual condition check, Hey, wow, I totally forgot about that. I'm going to have to learn more about ExpressionT now. I guess I was planning to anyway... :) Thanks! Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote:
(The reason I use cpp, incidentally, is so I can implement C-style
assert() and check() macros that actually print the condition being
tested as part of the assertion message. There seems to be no other
way to do this in C#, which is too bad.)
There is now. It's not the most performant technique around, but your
Assert() or Check() methods could take an ExpressionT. The
ExpressionT can then be converted into a string for diagnostic
messages, and converted into a delegate for the actual condition check,
e.g.:
[Conditional(DEBUG)]
static void AssertT(T value, ExpressionFuncT, bool e)
{
FuncT,bool d = e.Compile();
if (!d (value)) {
// Convert `e' to a string and log
}
}
// ...
Assert(self, v = v != null);
All that's really needed for this is a way to convert the Expression
into a usable string, which may already exist for all I know...
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hi,
On Thu, 2009-02-05 at 12:10 -0500, Avery Pennarun wrote:
(The reason I use cpp, incidentally, is so I can implement C-style
assert() and check() macros that actually print the condition being
tested as part of the assertion message. There seems to be no other
way to do this in C#, which is too bad.)
There is now. It's not the most performant technique around, but your
Assert() or Check() methods could take an ExpressionT. The
ExpressionT can then be converted into a string for diagnostic
messages, and converted into a delegate for the actual condition check,
e.g.:
[Conditional(DEBUG)]
static void AssertT(T value, ExpressionFuncT, bool e)
{
FuncT,bool d = e.Compile();
if (!d (value)) {
// Convert `e' to a string and log
}
}
// ...
Assert(self, v = v != null);
Here is slightly simplified version
[Conditional(DEBUG)]
static void Assert (ExpressionFuncbool e)
{
var d = e.Compile ();
if (!d ()) {
Console.WriteLine (((LambdaExpression)e).Body.ToString ());
}
}
public static void Main ()
{
object self = null;
Assert (() = self != null);
}
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, 2009-02-05 at 18:54 +, Marek Safar wrote:
Here is slightly simplified version
[Conditional(DEBUG)]
static void Assert (ExpressionFuncbool e)
{
var d = e.Compile ();
if (!d ()) {
Console.WriteLine (((LambdaExpression)e).Body.ToString ());
}
}
public static void Main ()
{
object self = null;
Assert (() = self != null);
}
Nice. I didn't know that there was existing support already.
There's one problem, though: this prints out (null != null), which
isn't terribly helpful. :-)
This is one advantage to the parameter based version:
[Conditional(DEBUG)]
static void AssertT(T value, ExpressionFuncT,bool e)
{
if (!d.Compile() (value))
Console.WriteLine(
((LambdaExpression)e).Body.ToString ());
}
When it fails, it prints out (v != null) instead, which is somewhat
more useful (except that `v' won't be something the user knows about).
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Might another language like Boo be a better place for the non-standard future features? If in C#, a different flag from future should be used to diffentuate nonstandard from true future stuff (minor implmentation detail) This is not a vote or even a suggestion, just some random thoughts. Dennis ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
And my own idea: add support for # line style preprocessor tags, as produced by cpp. I have a few programs that need to run through cpp before compiling, and the lack of # line support means that (unless I'm almost impossibly careful and do some strange tricks) the line numbers reported in error/warning messages will be screwed up by the preprocessor. mcs does support #line, that is what we use to generate symbols for ASP.NET pages for example. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Thu, Feb 5, 2009 at 6:49 PM, Miguel de Icaza mig...@novell.com wrote: And my own idea: add support for # line style preprocessor tags, as produced by cpp. I have a few programs that need to run through cpp before compiling, and the lack of # line support means that (unless I'm almost impossibly careful and do some strange tricks) the line numbers reported in error/warning messages will be screwed up by the preprocessor. mcs does support #line, that is what we use to generate symbols for ASP.NET pages for example. I admit I haven't tried it in a while - my workarounds date back to mono 1.2.6 or so. Was it added recently? Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
I admit I haven't tried it in a while - my workarounds date back to mono 1.2.6 or so. Was it added recently? That is a few years old. You might want to upgrade. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Il giorno mer, 04/02/2009 alle 22.56 +1300, Scott Peterson ha scritto: Da: Scott Peterson sc...@ssblack.co.nz Rispondi-a: sc...@ssblack.co.nz A: mono-devel-list@lists.ximian.com Oggetto: [Mono-dev] gmcs and The Future Data: Wed, 4 Feb 2009 22:56:40 +1300 (10.56 CET) Generic type variance has landed in gmcs SVN [1]. This is a C# 4 feature. It can be enabled by passing -langversion:future. While type variance is cool, I want to talk about -langversion:future. I see this as being a sentinel langversion for features as yet unreleased by Microsoft. Those features could be announced additions to the language (as with generic type variance, or the dynamic keyword) but they need not be. Mcs has done an excellent job of tracking the official C# language, and it will continue to do so, but the Mono project has a world-class compiler entirely at its disposal. We need not confine ourselves to the blessed specs of Microsoft or Ecma. We could trick out C#, indulging in sugars of our own device, so long as we keep our creations in -langversion:future. Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. I have just one comment: use two different keywords, one for future features blessed by MS and one (-langversion:mono maybe?) for features that are specific of mcs implementation. This will make possible to differentiate code that probably will be compatible with csc and VS from code that will absolutely need mcs (unless the people at MS start tracking mono features, eheh :).) federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developerf...@debian.org INIT.D Developer f...@initd.org If a process is potentially good, but 90%+ of the time smart and well-intentioned people screw it up, then it's a bad process. -- Steve Yegge 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] gmcs and The Future
Hi,
static readonly MethodInfo methodInfo = typeof(Foo).GetMethod(Bar, new
Type [] { typeof(string), typeof(int) });
Not only is this an eyesore, but we have a method name in a string. If
I refactor that method, I will have to remember to update this code as
well.
Solution: The reflect keyword. This is like the typeof keyword, but
you can use it to reflect upon anything.
No need for that, C# 4.0 will support dynamic binding which means you
will able to write
Foo.Bar (a, 1);
directly in your C# code.
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hey, On 2/4/09, Scott Peterson sc...@ssblack.co.nz wrote: Mcs has done an excellent job of tracking the official C# language, and it will continue to do so, but the Mono project has a world-class compiler entirely at its disposal. We need not confine ourselves to the blessed specs of Microsoft or Ecma. We could trick out C#, indulging in sugars of our own device, so long as we keep our creations in -langversion:future. Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. I'd be very cautious with that idea. I've been told enough that mcs is a `production` compiler :) I mean, sure it's fun to experiment language changes and improvement. But who decides what will go in and what not? And when it's in, who is going to maintain it? Most people that will work on a patch for the fun of it won't maintain the feature for a long time. If it's perfectly ok for a feature that is needed, or for some libraries, it's not really the case of mcs. Then it triggers some questions, like what if a change to the parser (or some place else) for a `future` feature gets in the way of a fix for the normal version of mcs? Anyway, am not completely against the idea, I already wrote about how I'd like to have a more extensible mcs, but in the current state of affairs, again, I'd very cautious. -- Jb Evain j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hi, gmcs Compiler already not 100% compatible with csc - __arglist http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __refvalue http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __makeref http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx not supported ( it can significatly reduce P/Invokes in bridging code of NObjective http://code.google.com/p/nobjective/) __arglist is fully supported. We have not implemented __reftype/__makeref mainly because nobody raised any interested in these undocumented keyword. If you missing this support please fill a bug report. Marek reflect is great idea for refactoring but may be better to call it __memberinfo =)? 2009/2/4 Jb Evain j...@nurv.fr mailto:j...@nurv.fr Hey, On 2/4/09, Scott Peterson sc...@ssblack.co.nz mailto:sc...@ssblack.co.nz wrote: Mcs has done an excellent job of tracking the official C# language, and it will continue to do so, but the Mono project has a world-class compiler entirely at its disposal. We need not confine ourselves to the blessed specs of Microsoft or Ecma. We could trick out C#, indulging in sugars of our own device, so long as we keep our creations in -langversion:future. Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. I'd be very cautious with that idea. I've been told enough that mcs is a `production` compiler :) I mean, sure it's fun to experiment language changes and improvement. But who decides what will go in and what not? And when it's in, who is going to maintain it? Most people that will work on a patch for the fun of it won't maintain the feature for a long time. If it's perfectly ok for a feature that is needed, or for some libraries, it's not really the case of mcs. Then it triggers some questions, like what if a change to the parser (or some place else) for a `future` feature gets in the way of a fix for the normal version of mcs? Anyway, am not completely against the idea, I already wrote about how I'd like to have a more extensible mcs, but in the current state of affairs, again, I'd very cautious. -- Jb Evain j...@nurv.fr mailto:j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- WBR, Eugeny Grishul ___ 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] gmcs and The Future
Could we please get a __forceinline for the compiler allowing us to make
decisions at compile time to help us with optimisation.
I know that the long term and correct answer is to put this sort of
thing in the Jit but in the short term can we please be treated like
grownups and get some way of telling the compiler that this property or
method really really should be inlined.
I would even go for adding an attribute to functions where I want
everything to be inlined inside i.e.
[InlineEverything(MyNamespace)]
Void Foo()
{
MyClass a = new MyClass();
MyClass b = new MyClass();
MyClass c = a + b;
Console.WriteLine( C = {0}, c.ToString() );
}
This would inline the constructor for MyClass, the operator+ for MyClass
and the ToString, but leave intact the call to Console.WriteLine.
And to go one step further, control over the level of inlining would be
good to, i.e. default level is 1 so only the immediate function would be
inlined, 2 would inline up to 2 calls deep, -1 would inline everything.
This would greatly enhance optimising of things like Maths intensive
operations
Regards
Russell
-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Scott
Peterson
Sent: 04 February 2009 09:57
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] gmcs and The Future
Generic type variance has landed in gmcs SVN [1]. This is a C# 4
feature. It can be enabled by passing -langversion:future. While type
variance is cool, I want to talk about -langversion:future. I see this
as being a sentinel langversion for features as yet unreleased by
Microsoft. Those features could be announced additions to the language
(as with generic type variance, or the dynamic keyword) but they
need not be. Mcs has done an excellent job of tracking the official C#
language, and it will continue to do so, but the Mono project has a
world-class compiler entirely at its disposal. We need not confine
ourselves to the blessed specs of Microsoft or Ecma. We could trick
out C#, indulging in sugars of our own device, so long as we keep our
creations in -langversion:future. Those projects which are willing to
sacrifice compatibility with csc in order to partake of our forbidden
fruit can write code in this New C#. This C#++. This
-langversion:future.
To be clear, I am not advocating VM changes. Anything to come out of
this compiler would remain binary-compatible with the .NET runtime.
Language features and APIs only. I have loads of ideas - I actually
keep a list where I jot down every language feature idea I come up
with - but I want to hear from the list. Do you like the idea? Do you
have concerns? Do you have a language feature you've always wanted?
I will start the ball rolling with a simple feature:
Problem: While the 'typeof' keyword is very convenient for getting
Type objects, it is much more difficult to get any other kind of
reflection data. For example, to get a MethodInfo object, one usually
does:
static readonly MethodInfo methodInfo = typeof(Foo).GetMethod(Bar,
new Type [] { typeof(string), typeof(int) });
Not only is this an eyesore, but we have a method name in a string. If
I refactor that method, I will have to remember to update this code as
well.
Solution: The reflect keyword. This is like the typeof keyword, but
you can use it to reflect upon anything.
Examples:
Type fooType = reflect(Foo);
MethodInfo barMethod1 = reflect(Foo.Bar(string));
MethodInfo barMethod2 = reflect(Foo.Bar(string,int));
FieldInfo batField = reflect(Foo.bat);
PropertyInfo bazProperty = reflect(Foo.Baz);
ConstructorInfo fooCtor1 = reflect(new Foo());
ConstructorInfo fooCtor2 = reflect(new Foo(string));
ConstructorInfo staticFooCtor = reflect(static Foo());
EventInfo fooEvent = reflect(Foo.Changed);
And if I refactor any of these members or types, my IDE will update
this code as well.
Your turn.
- scottp
[1] http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
This email has been scanned by the MessageLabs Email Security System
DISCLAIMER
This message and any attachments contain privileged and confidential
information intended for the use of the addressee named above. If you are not
the intended recipient of this message, you are hereby notified that any use,
dissemination, distribution or reproduction of this message is prohibited.
Please note that we cannot guarantee that this message or any attachment is
virus free or that it has not been intercepted and amended. The views of the
author may not necessarily reflect those of Realtime Worlds Ltd.
Realtime Worlds Ltd is registered in Scotland, number
Re: [Mono-dev] gmcs and The Future
On Wed, Feb 4, 2009 at 3:35 PM, russell@realtimeworlds.com wrote: Could we please get a __forceinline for the compiler allowing us to make decisions at compile time to help us with optimisation. I know that the long term and correct answer is to put this sort of thing in the Jit but in the short term can we please be treated like grownups and get some way of telling the compiler that this property or method really really should be inlined. I'm not sure how you expect this to work. Inlining is the responsibility of the JIT and there is no way for GMCS to force the JIT to inline something without a change in the JIT. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
I just want the compiler to inline the functions in IL in a similar way that a C++ compiler would do it, I know that the correct way is for the JIT to do this, but this has other semantic problems that need to be overcome. In the short term however having the ability to do this easily through the compiler would be a boon. So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 15:49 To: Russell Kay Cc: sc...@ssblack.co.nz; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 3:35 PM, russell@realtimeworlds.com wrote: Could we please get a __forceinline for the compiler allowing us to make decisions at compile time to help us with optimisation. I know that the long term and correct answer is to put this sort of thing in the Jit but in the short term can we please be treated like grownups and get some way of telling the compiler that this property or method really really should be inlined. I'm not sure how you expect this to work. Inlining is the responsibility of the JIT and there is no way for GMCS to force the JIT to inline something without a change in the JIT. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hey, On 2/4/09, russell@realtimeworlds.com russell@realtimeworlds.com wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. -- Jb Evain j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Well it was a thought, we are looking for something like this in the future for our own classes (particularly maths heavy functions), so this is something that we can overcome ourselves (we are planning on using something like Cecil to rewrite the assemblies), but if it was available within the compiler then it would be much better. Even if it only did it within the security constraints that it has and knows about. Russell -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Jb Evain Sent: 04 February 2009 16:10 To: Russell Kay Cc: sc...@ssblack.co.nz; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] gmcs and The Future Hey, On 2/4/09, russell@realtimeworlds.com russell@realtimeworlds.com wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. -- Jb Evain j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hi, gmcs Compiler already not 100% compatible with csc - __arglisthttp://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __refvalue http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __makeref http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspxnot supported ( it can significatly reduce P/Invokes in bridging code of NObjective http://code.google.com/p/nobjective/) reflect is great idea for refactoring but may be better to call it __memberinfo =)? 2009/2/4 Jb Evain j...@nurv.fr Hey, On 2/4/09, Scott Peterson sc...@ssblack.co.nz wrote: Mcs has done an excellent job of tracking the official C# language, and it will continue to do so, but the Mono project has a world-class compiler entirely at its disposal. We need not confine ourselves to the blessed specs of Microsoft or Ecma. We could trick out C#, indulging in sugars of our own device, so long as we keep our creations in -langversion:future. Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. I'd be very cautious with that idea. I've been told enough that mcs is a `production` compiler :) I mean, sure it's fun to experiment language changes and improvement. But who decides what will go in and what not? And when it's in, who is going to maintain it? Most people that will work on a patch for the fun of it won't maintain the feature for a long time. If it's perfectly ok for a feature that is needed, or for some libraries, it's not really the case of mcs. Then it triggers some questions, like what if a change to the parser (or some place else) for a `future` feature gets in the way of a fix for the normal version of mcs? Anyway, am not completely against the idea, I already wrote about how I'd like to have a more extensible mcs, but in the current state of affairs, again, I'd very cautious. -- Jb Evain j...@nurv.fr ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- WBR, Eugeny Grishul ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hi Russell, You can use Cecil to modify assembly - perform manual inlining of IL code from one methods to others. .NET compilers should not make ANY optimizations (except listed in ECMA) but VES should. WBR, Eugeny Grishul 2009/2/4 russell@realtimeworlds.com Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- WBR, Eugeny Grishul ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
On Wed, 2009-02-04 at 22:56 +1300, Scott Peterson wrote:
I will start the ball rolling with a simple feature:
Problem: While the 'typeof' keyword is very convenient for getting
Type objects, it is much more difficult to get any other kind of
reflection data. For example, to get a MethodInfo object, one usually
does:
static readonly MethodInfo methodInfo = typeof(Foo).GetMethod(Bar, new
Type [] { typeof(string), typeof(int) });
This can already be improved upon:
MethodInfo methodInfo =
new Funcstring, int, RetType(Foo.Bar).Method;
// or Actionstring, int depending on return type
Ideally, this could be improved upon *further*:
MethodInfo methodInfo = Lambda.F(Foo.Bar).Method;
Lambda comes from Mono.Rocks, and has methods such as:
static class Lambda {
public static FuncT1, T2, TResult FT1, T2, TResult (
FuncT1, T2, TResult lambda)
{
return lambda;
}
}
Alas, this doesn't work for two reasons:
1. Foo.Bar() could be overloaded, and the above Lambda.F() doesn't allow
specifying the overload. This can be fixed by explicitly
specifying parameters:
MethodInfo mi = Lambda.Fstring, int, RetType(Foo.Bar);
// or MethodInfo m = Lambda.Astring, int(Foo.Bar);
2. C#'s type inferencing *sucks*. It's nice, but compared to e.g. F#
it's *very* limited. For example:
var f = Lambda.F(Console.ReadLine);
There is only one Console.ReadLine() method, so you'd *hope* that C#
could infer the return type of Console.ReadLine and thus call
Lambda.FTResult(FuncTResult), as it's the only possible match.
Alas, gmcs can't make this inference.
So interesting as `reflect' is, it would be ~easily handled with normal
libraries IF ONLY C#'s type inferencing didn't suck balls.
(The downside to the above is that it only works for methods, not
properties, events, or constructors, so `reflect' could still be useful,
though it would be nice if a new keyword wasn't needed.)
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hello, Those projects which are willing to sacrifice compatibility with csc in order to partake of our forbidden fruit can write code in this New C#. This C#++. This -langversion:future. The problem is not only one of making the code conditional, but certain features come with a heavy maintenance cost, so the cost of adding features is not just the new define and the extra checks in the compiler source code. Obviously any new innovation first needs to be prototyped in a branch and when we are happy with the results we could discuss its introduction into the mainline compiler under a flag like the one you mentioned. For example, I would like to see a Ruby-like string interpolation system instead of String.Format, but such a prototype would have to be experimented on its own branch. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Hello, gmcs Compiler already not 100% compatible with csc - __arglist http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __refvalue http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx, __makeref http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx not supported ( it can significatly reduce P/Invokes in bridging code of NObjective http://code.google.com/p/nobjective/) __arglist is fully supported. We have not implemented __reftype/__makeref mainly because nobody raised any interested in these undocumented keyword. If you missing this support please fill a bug report. I agree. Until today I did not even know those existed. What is their use case and how do you use these in NObjective? I would like to know more about this. As Marek said, please file a bug report, that will help us track this task. miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
I try to use these voodoo keywords and have a small report:
1) gmcs currently supports only __arglist keyword, but sometimes generates
incorrect CIL. That code works while compiling with csc.exe, but leads to
segmentation fault after gmsc (I try it on Mac OS 10.5, Mono 2.2 ):
== CODE ===
private static void TestArglistMethod()
{
ArglistMethod( __arglist( 1, 2, 3 ) );
}
private static void ArglistMethod(__arglist )
{
var iter = new ArgIterator( __arglist );
for( var n = iter.GetRemainingCount(); n 0; n-- )
Console.WriteLine( TypedReference.ToObject( iter.GetNextArg() ) );
}
===
2) Mono VES currently supports mkrefany, refanyval, refanytype, arglist
instructions for non-P/Invoke scenario.
3) Mono JIT P/Invoke layer don't like __arglist parameters and reports
something like this: Invalid IL code in NObjective.Program:Main (string[]):
IL_0021: ret
== CODE ===
[DllImport( libc.dylib )]
public extern static void printf( string format, __arglist );
...
printf( ytu, __arglist( 44 ) );
===
If compiler will be able generate correct CIL it will be useful for
debugging future P/Invoke layer that will able to work with __arglist
NObjective contains about of 43000 generated methods (generated from
Objective-C method signatures) accessible by user that looks like:
== CODE ===
unsafe public static bool writeToURL_atomically_( this NSData ___this, NSURL
url, bool atomically ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.writeToURL_atomically_( ___this,
CachedSelectors.writeToURL_atomically_, out ___occuredException, sizeof(
NSURL ) + sizeof( bool ), url, atomically );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
unsafe public static bool writeToURL_options_error_( this NSData ___this,
NSURL url, uint options, ref NSError error ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.writeToURL_options_error_( ___this,
CachedSelectors.writeToURL_options_error_, out ___occuredException, sizeof(
NSURL ) + sizeof( uint ) + sizeof( IntPtr ), url, options, ref error );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
===
Each generated method have a generated P/Invoke counterpart with same entry
point and nearly same signature (another 43000 methods!):
== CODE ===
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool writeToURL_atomically_( RuntimeObject ___object,
Selector ___selector, out RuntimeObject ___occuredException, int
___stackSize, NSURL url, bool atomically );
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool writeToURL_options_error_( RuntimeObject
___object, Selector ___selector, out RuntimeObject ___occuredException, int
___stackSize, NSURL url, uint options, ref NSError error );
===
With proper __arglist support in VES/gmcs unnecessary P/Invokes can be
easily removed ( -43000 methods = assembly will hold much less metadata )
and calls redirected to SINGLE __arglist method:
== CODE ===
unsafe public static bool writeToURL_atomically_( this NSData ___this, NSURL
url, bool atomically ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.FutureArglistMethod( ___this,
CachedSelectors.writeToURL_atomically_, out ___occuredException, sizeof(
NSURL ) + sizeof( bool ), __arglist( url, atomically ) );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
unsafe public static bool writeToURL_options_error_( this NSData ___this,
NSURL url, uint options, ref NSError error ) {
RuntimeObject ___occuredException;
var ___result = NativeMethods.FutureArglistMethod( ___this,
CachedSelectors.writeToURL_options_error_, out ___occuredException, sizeof(
NSURL ) + sizeof( uint ) + sizeof( IntPtr ), __arglist( url, options, ref
error ) );
if( ___occuredException != RuntimeObject.Null ) throw
RuntimeException.Create( ___occuredException );
return ___result;
}
...
[DllImport(Runtime.InteropLibrary, EntryPoint = objc_msgSend_eh2)]
public static extern bool FutureArglistMethod( RuntimeObject ___object,
Selector ___selector, out RuntimeObject ___occuredException, int
___stackSize, __arglist );
===
WBR,
Eugeny Grishul
2009/2/5 Miguel de Icaza mig...@novell.com
Hello,
gmcs Compiler already not 100% compatible with csc - __arglist
http://bartdesmet.net/blogs/bart/archive/2006/09/28/4473.aspx,
