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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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#,
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 ());
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.
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
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
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
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
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
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
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
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
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
: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
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
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
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
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
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
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
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
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
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
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 ):
==
40 matches
Mail list logo
