I'm trying to add a '?' token to the parser, and weird things are happening. I've added a #define to token.h, an entry to _PyParser_TokenNames in tokenizer.c and case for it in PyToken_OneChar(). But it's behaving as though the tokenizer is not recognising my token. I put in some printfs to find out whether PyToken_OneChar() is recognising it. The results are confusing: while running pgen, PyToken_OneChar() is being called and recognising the new token correctly. However, it doesn't seem to be getting called *at all* when parsing Python code. I don't see how this can happen, because pgen seems to use the same tokenizing code as Python itself. Is there anything else I need to do? Does some file need to be manually re-made? -- Greg
Benjamin Peterson wrote:
Why do you even have to add a new token? You can just put the literal '?' in the grammar.
I don't see how that can be sufficient. All the other tokens have entries in the three places I mentioned, and there's no way that pgen can generate those automatically just from seeing a '?' in the grammar. I just tried an experiment -- I changed the grammar to accept '?' as an alternative to '+', and tried to use the parser module to parse "1?2". It reported a SyntaxError. -- Greg
Aaargh, I think I've found out what the problem is. I'm using framework builds on MacOSX. I have two experimental builds of Python 3.1 around, plus a standard one installed in /Library. It's picking up the version of Python.framework in /Library/Frameworks instead of the one in the local build directory that python.exe was explicitly linked with. Now I'm confused about why my *other* experimental build worked -- the one I've been using for yield-from and codef -- because it should have suffered from the same problem. And when I tried to use it again just now, it did indeed not work. Does anyone know if there's a way to tell Apple's linker to use a framework from a specific location and not go looking anywhere else? In the meantime, I think I'll switch to a non-framework build for this project. -- Greg
On Aug 7, 2010, at 9:15 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Does anyone know if there's a way to tell Apple's linker to use a framework from a specific location and not go looking anywhere else?
$ DYLD_FRAMEWORK_PATH=<path> <command> See dyld(1) for other relevant magic. Cheers, -- Ivan Krstić, via mobile
In article <4C5E2F7D.5080203@canterbury.ac.nz>, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Does anyone know if there's a way to tell Apple's linker to use a framework from a specific location and not go looking anywhere else?
I haven't tested it myself but you should be able to prevent problems like that by specifying a non-default framework name with the --with-framework-name= option to configure. See Mac/README. -- Ned Deily, nad@acm.org
On 8 Aug, 2010, at 6:15, Greg Ewing wrote:
Aaargh, I think I've found out what the problem is.
I'm using framework builds on MacOSX. I have two experimental builds of Python 3.1 around, plus a standard one installed in /Library. It's picking up the version of Python.framework in /Library/Frameworks instead of the one in the local build directory that python.exe was explicitly linked with.
Check the RUNPY definition in the Makefile, you should start python.exe using DYLD_FRAMEWORK_PATH=$PWD ./python.exe (Assuming your running from the build directory, adjusting this for other situations should be easy)
Now I'm confused about why my *other* experimental build worked -- the one I've been using for yield-from and codef -- because it should have suffered from the same problem. And when I tried to use it again just now, it did indeed not work.
Does anyone know if there's a way to tell Apple's linker to use a framework from a specific location and not go looking anywhere else?
Use the '--with-framework-name' option to configure, this enables you to build the framework with an alternate name and therefore have two framework installs side-by-side. I use this to have a regular python build as well as a --with-pydebug build. Ronald
participants (5)
-
Benjamin Peterson -
Greg Ewing -
Ivan Krstić -
Ned Deily -
Ronald Oussoren