Hello Eno,
Could you write some tests to cover this functionality. I mean e.g.
simple test file with UTF header.
Thanks,
Marek
Hi again,
Agreed. In fact, I was also fixing bug #75065, maybe duplicate.
I have a fix for UTF8Encoding, but it uncovered another mcs bug
which does not handle fil
think
using a
simple SBCS latin code page is better.
Kornél
- Original Message -
From: "Atsushi Eno" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>
Cc: "mono-devel mailing list"
Sent: Monday, August 22, 2005 11:13 AM
Subject: Re: [M
Hi again,
Agreed. In fact, I was also fixing bug #75065, maybe duplicate.
I have a fix for UTF8Encoding, but it uncovered another mcs bug
which does not handle files with BOM with specific encoding.
To summarize the situation:
- Currently driver.cs does not process source files with
d
al Message -
From: "Atsushi Eno" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>
Cc: "mono-devel mailing list"
Sent: Monday, August 22, 2005 11:13 AM
Subject: Re: [Mono-dev] Re: [Mono-devel-list] mcs patch for default
encoding
Hi,
I think usin
simple SBCS latin code page is better.
Kornél
- Original Message -
From: "Atsushi Eno" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>
Cc: "mono-devel mailing list"
Sent: Monday, August 22, 2005 11:13 AM
Subject: Re: [Mono-dev] Re: [Mono-
Hi,
I think using 1252 as a fallback is better than UTF-8 as it is a regular
single-byte code page. UTF-8 should be detected (and I think it is
detected)
using byte order marks anyway.
I agree that using 28591 as the default encoding is is a bad decission.
This guess is "Western centric" ;-
Hi Marek,
Marek Safar wrote:
Hello Eno,
Any comments on this patch? If we leave this problem as is, most
of native-language dependent applications won't compile fine
(as I experienced on many Japanese sources).
Probably, we will have to fix this bug first.
http://bugzilla.ximian.com/show_
instead of
CultureInfo.CurrentCulture.TextInfo.ANSICodePage as it is really based on
system code page?
Kornél
- Original Message -
From: "Atsushi Eno" <[EMAIL PROTECTED]>
To: "mono-devel mailing list"
Sent: Monday, August 22, 2005 7:59 AM
Subject: [Mono-dev] Re: [
Hello Eno,
>Any comments on this patch? If we leave this problem as is, most
>of native-language dependent applications won't compile fine
>(as I experienced on many Japanese sources).
>
>
Probably, we will have to fix this bug first.
http://bugzilla.ximian.com/show_bug.cgi?id=73086
Marek
>At
Any comments on this patch? If we leave this problem as is, most
of native-language dependent applications won't compile fine
(as I experienced on many Japanese sources).
Atsushi Eno
Atsushi Eno wrote:
> Hello,
>
> I've attached a fix for mcs to not use Latin1 encoding everywhere.
> I think it s
Hello,
My precise location patch for mcs (to report line/column, where it
used to report incorrect locations) is now checked in svn.
If any of you found such case that mcs does not report error location,
please file a bug and/or report it here, with an example.
Thanks,
Atsushi Eno
__
Hello,
I've attached a fix for mcs to not use Latin1 encoding everywhere.
I think it should be default encoding of current culture (for
example the codepage is 932 on my Japanese environment, neither
28591 nor 1252).
But in case we really don't have the corresponding encoding that
CultureInfo.Cur
Hello,
> As part of a project I have to study the mcs, especially those
> structures corresponding to a symbol table, which shall later be used
> in a source code analyzer. In the mcs, those symbol-table-like data
> structures are just parts of the tree created when parsing. To get
> some
Hi!
As part of a project I have to study the mcs, especially those
structures corresponding to a symbol table, which shall later be used
in a source code analyzer. In the mcs, those symbol-table-like data
structures are just parts of the tree created when parsing. To get
some snapshots of
Hello,
I finally see where the point is ;-)
Unfortunately I have to say our hierarchy structure seems to be broken.
From my point of view the MemberName should be introduced in
DeclSpace class and not in MemberCore
where should be only your LocatedToken. But this change is not
simple. Then we
Hello,
I finally see where the point is ;-)
Unfortunately I have to say our hierarchy structure seems to be broken.
From my point of view the MemberName should be introduced in DeclSpace
class and not in MemberCore
where should be only your LocatedToken. But this change is not simple.
Then we
Hello,
Martin gave some comments on the patch, so I made a few changes:
- removed "dont_progress_location" conditions in tokenizer
- fixed incorrectly modified "public int token" in location.cs
- renamed "StringValue" to "Value" in LocatedToken.
And merged the patch to the latest t
Hi,
Martin gave some comments on the patch, so I made a few changes:
- removed "dont_progress_location" conditions in tokenizer
- fixed incorrectly modified "public int token" in location.cs
- renamed "StringValue" to "Value" in LocatedToken.
And merged the patch to the
Hello Eno,
Thanks, as usual. I put a revised patch here:
http://monkey.workarea.jp/tmp/20050630/precise-location-20050630.diff
I think can be useful make 'public class LocatedToken' struct as is
passed only as an argument.
And use this class in similar way as MemberName for every relevant
con
Hi Marek,
Thanks, as usual. I put a revised patch here:
http://monkey.workarea.jp/tmp/20050630/precise-location-20050630.diff
I think can be useful make 'public class LocatedToken' struct as is
passed only as an argument.
And use this class in similar way as MemberName for every relevant
cons
Hello Eno,
Sorry, the last patch actually didn't include the fix for bug
#57047. This time it should be included (I found it running diff
against two diff files).
This time the patch changes only a few things than before:
http://monkey.workarea.jp/tmp/20050627/precise-location-20050628_2.diff
I
Does anyone in the mono project keep a comprehensive list of what is
implemented in Windows.Forms and what is not. I have been playing with
porting Infragistics to Linux and it is just not clear what will run and
what won't.
Thanks,
Allan
Atsushi Eno wrote:
Hi Marek,
Thanks for the comment
Hi,
Sorry, the last patch actually didn't include the fix for bug
#57047. This time it should be included (I found it running diff
against two diff files).
This time the patch changes only a few things than before:
http://monkey.workarea.jp/tmp/20050627/precise-location-20050628_2.diff
You coul
Hello Eno,
Now as you moved Location to MemberName
public class MemberName {
public readonly string Name;
public readonly MemberName Left;
+ public readonly Location Location;
You could remove loc from MemberCore and add only property as
Lo
Hi Marek,
Thanks for the comments.
That is massive ;-)
Well, I can split the patch into maybe two parts: 1) make changes
to Location, Report and tokenizer, and 2) make changes to parser
(lexer.Location elimination). But 1) won't make sense as a
standalone patch. And in fact most of the change
Hi,
Atsushi Eno <[EMAIL PROTECTED]> writes:
[snip]
> - I changed tokenizer to return Location for keywords, and
> new "LocatedToken" for IDENTIFIERS, unary operators and
> some symbols such as SEMICOLON. And modified cs-parser.jay
> to cast correct types (especially
Hello Eno,
That is massive ;-)
In the most cases we don't need to pass Location as extra parameter now.
It would be nice to remove also this redundant casts and arguments.
For example.
$$ = new ComposedCast ((Expression) $1, "*", ((Expression) $1).Location);
or
$$ = new Invocation ((Expression
Hello,
I once posted a patch but it seems waiting for approval and
Miguel still could not see, so am reposting the message without
patch. The patch itself is here:
http://monkey.workarea.jp/tmp/20050627/precise-location-20050627.diff
Here is the latest mcs patch for precise location handlin
Hello, I created a asp application at my home computer which runs
linux, runs ok with XSP. But when I try to run it on windows (using
mono/xsp as well) I get a message saying "The parent type does not
derive from System.Web.UI.Page".
I find no prior reference to this issue anywhere (google, go-mon
29 matches
Mail list logo
