[Python-Dev] msvccompiler and .NET sdk version
Maybe this is fixed somewhere already, but just fyi:
I have the .NET sdk 2.0 installed (but not 1.1)
I'm running ActivePython 2.5.1
When I was building Mercurial from sources, I got this error:
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate
compatible binaries.
Visual Studio 2003 was not found on this system. If you have
Cygwin installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
This is in spite of the fact that I had DISTUTILS_USE_SDK and MSSDK
set properly.
The problem was that msvccompiler.py was looking for
sdkinstallrootv1.1, and bailing when it couldn't be found.
I made a small change and it works fine for me now.
In load_macros, I put this:
if version > 7.0:
try:
self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1")
except KeyError, exc:
self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv2.0")
I had no problems with it - thought it might be useful for someone else.
I do however think that if I have DISTUTILS_USE_SDK set it shouldn't
be demanding registry entries of me in the first place.
But load_macros gets called in the constructor of MacroExpander before
the enclosing MSVCCompiler checks for the env vars, which seems not
quite right.
I don't use the VStuido installers so much, I just rearrange my
environment as needed so I'm used to being bitten by these registry
checks and such. For me, and other developers who need to switch
between toolsets (VC98, 2003, 2005, etc), running installers each time
that stomp on each others' registry entries and install different SDKs
is a major pain.
In this view of things, the original error message could be seen as
slightly misleading as well. I would say that Visual Studio 2003 could
in fact be found on my system, just not .NET sdk 1.1. If you ran the
installer there's no distinction, but in my case there is.
-John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] NEWLINE sentinel behavior in CPython's PEG grammar
I am writing a Rust version of Python for fun and I am at the parser stage
of development.
I copied and modified a PEG grammar ruleset from another open source
project and I've already noticed some problems (ex Newline vs NL) with how
they transcribed things.
I am suspecting that CPython's grammar NEWLINE is a builtin rule for the
parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to
sanity check if that is right before I figure out how to hack in a NEWLINE
rule and update my grammar ruleset.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar
Pablo,
Nl and Newline are tokens but I am interested in NEWLINE's behavior in
the Python grammar, note the casing.
For example in simple_stmts @
https://github.com/python/cpython/blob/main/Grammar/python.gram#L107
Is that NEWLINE some sort of built in rule to the grammar? In my project
I am running into problems where the parser crashes any time there is some
double like NL & N or Newline & NL but I want to nail down NEWLINE's
behavior in CPython's PEG grammar.
On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado
wrote:
> Hi,
>
> I am not sure I understand exactly what you are asking but NEWLINE is a
> token, not a parser rule. What decides when NEWLINE is emitted is the lexer
> that has nothing to do with PEG. Normally PEG parsers also acts as
> tokenizers but the one in cpython does not.
>
> Also notice that CPython’s parser uses a version of the tokeniser written
> in C that doesn’t share code with the exposed version. You will find that
> the tokenizer module in the standard library actually behaves differently
> regarding what tokens are emitted in new lines and indentations.
>
> The only way to be sure is check the code unfortunately.
>
> Hope this helps.
>
> Regards from rainy London,
> Pablo Galindo Salgado
>
> > On 26 Oct 2022, at 19:12, David J W wrote:
> >
> >
> > I am writing a Rust version of Python for fun and I am at the parser
> stage of development.
> >
> > I copied and modified a PEG grammar ruleset from another open source
> project and I've already noticed some problems (ex Newline vs NL) with how
> they transcribed things.
> >
> > I am suspecting that CPython's grammar NEWLINE is a builtin rule for the
> parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to
> sanity check if that is right before I figure out how to hack in a NEWLINE
> rule and update my grammar ruleset.
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LTDXZ4DS2GLICZRWYZ5PVLPBJHVGQPSS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: NEWLINE sentinel behavior in CPython's PEG grammar
Following up, Pablo spotted my problem with the mixup of NL & NEWLINE
tokens. I was using tokenize.py in cPython's stdlib with a simple python
script to build ridiculously strict unit tests.
My solution to that problem was originally to figure out how to access
cPython's internal c tokenizer but someone else did that in 3.11. The
parser is passing basic tests but I need to redo all of the tests for my
tokenizer as they are flawed and also do some major housekeeping to clean
up all the warnings and TODO's sprinkled throughout my code base.
To hopefully avoid future problems, is Lib/symtable.py trustworthy as a way
of building unit tests when I start implementing my own symbols graph/table?
Thanks,
David
On Wed, Oct 26, 2022 at 11:57 PM Matthieu Dartiailh
wrote:
> If you look at pegen, that uses the stdlib tokenizer as input, you will
> see that the obejct us3d to implement memoization on top of a token stream
> simply swallow NL (
> https://github.com/we-like-parsers/pegen/blob/main/src/pegen/tokenizer.py#L49).
> This is safe since NL has no syntactic meaning only NEWLINE does.
>
> Best
>
> Matthieu
>
> On Thu, Oct 27, 2022, 01:59 Matthias Görgens
> wrote:
>
>> Hi David,
>>
>> Could you share what you have so far, perhaps ok GitHub or so? That way
>> it's easier to diagnose your problems. I'm reasonably familiar with Rust.
>>
>> Perhaps also add a minimal crashing example?
>>
>> Cheers,
>> Matthias.
>>
>> On Thu, 27 Oct 2022, 04:52 David J W, wrote:
>>
>>> Pablo,
>>> Nl and Newline are tokens but I am interested in NEWLINE's behavior
>>> in the Python grammar, note the casing.
>>>
>>> For example in simple_stmts @
>>> https://github.com/python/cpython/blob/main/Grammar/python.gram#L107
>>>
>>> Is that NEWLINE some sort of built in rule to the grammar? In my
>>> project I am running into problems where the parser crashes any time there
>>> is some double like NL & N or Newline & NL but I want to nail down
>>> NEWLINE's behavior in CPython's PEG grammar.
>>>
>>> On Wed, Oct 26, 2022 at 12:51 PM Pablo Galindo Salgado <
>>> pablog...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am not sure I understand exactly what you are asking but NEWLINE is a
>>>> token, not a parser rule. What decides when NEWLINE is emitted is the lexer
>>>> that has nothing to do with PEG. Normally PEG parsers also acts as
>>>> tokenizers but the one in cpython does not.
>>>>
>>>> Also notice that CPython’s parser uses a version of the tokeniser
>>>> written in C that doesn’t share code with the exposed version. You will
>>>> find that the tokenizer module in the standard library actually behaves
>>>> differently regarding what tokens are emitted in new lines and
>>>> indentations.
>>>>
>>>> The only way to be sure is check the code unfortunately.
>>>>
>>>> Hope this helps.
>>>>
>>>> Regards from rainy London,
>>>> Pablo Galindo Salgado
>>>>
>>>> > On 26 Oct 2022, at 19:12, David J W wrote:
>>>> >
>>>> >
>>>> > I am writing a Rust version of Python for fun and I am at the parser
>>>> stage of development.
>>>> >
>>>> > I copied and modified a PEG grammar ruleset from another open source
>>>> project and I've already noticed some problems (ex Newline vs NL) with how
>>>> they transcribed things.
>>>> >
>>>> > I am suspecting that CPython's grammar NEWLINE is a builtin rule for
>>>> the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to
>>>> sanity check if that is right before I figure out how to hack in a NEWLINE
>>>> rule and update my grammar ruleset.
>>>> > ___
>>>> > Python-Dev mailing list -- python-dev@python.org
>>>> > To unsubscribe send an email to python-dev-le...@python.org
>>>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>>>> > Message archived at
>>>> https://mail.python.org/archives/list/python-dev@python.org/message/NMCMEDMEBKATYKRNZLX2NDGFOB5UHQ5A/
>>>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe
