Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr wrote: I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
I believe that's true. Actually, after the first Python error I had with 1.4.4, the first thing I did was to install a full version of Python. I also believe you should reconsider this decision. On 2/20/07, Georg Baum [EMAIL PROTECTED] wrote: Uwe Stöhr wrote: I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg -- - Julio Rojas [EMAIL PROTECTED]
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr wrote: I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
I believe that's true. Actually, after the first Python error I had with 1.4.4, the first thing I did was to install a full version of Python. I also believe you should reconsider this decision. On 2/20/07, Georg Baum [EMAIL PROTECTED] wrote: Uwe Stöhr wrote: I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg -- - Julio Rojas [EMAIL PROTECTED]
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr wrote: > I think I found the bug: A missing python file. It should work when you > copy the attached file to LyX's \bin\Lib folder and then restart LyX. > > I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
I believe that's true. Actually, after the first Python error I had with 1.4.4, the first thing I did was to install a full version of Python. I also believe you should reconsider this decision. On 2/20/07, Georg Baum <[EMAIL PROTECTED]> wrote: Uwe Stöhr wrote: > I think I found the bug: A missing python file. It should work when you > copy the attached file to LyX's \bin\Lib folder and then restart LyX. > > I'll release a new installer version tomorrow including this fix. IMO you should reconsider the decision to ship a stripped down python. This is causing endless hours of work for users, you and people who try to help on the list. The download size is not an issue if you use the full installer only for the first time, and for later updates only the minimal installer. I am pretty sure that this case will not be the last one of a missing python file if you continue to ship a stripped down python. We rely heavily on python for lyx2lyx and other helper scripts, and nobody who changes one of these is going to look whether the change will require another python file in the windows installer. Georg -- - Julio Rojas [EMAIL PROTECTED]
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr schrieb: I have discovered that the same error also occurs when i go to tools Tex information and do a rescan. The problem occurs when there is no spaces in the directory too. and I'm not running from a usb stick. I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. regards Uwe Record of phased-in incompatible language changes. Each line is of the form: FeatureName = _Feature( OptionalRelease , MandatoryRelease , CompilerFlag ) where, normally, OptionalRelease MandatoryRelease, and both are 5-tuples of the same form as sys.version_info: (PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int PY_MINOR_VERSION, # the 1; an int PY_MICRO_VERSION, # the 0; an int PY_RELEASE_LEVEL, # alpha, beta, candidate or final; string PY_RELEASE_SERIAL # the 3; an int ) OptionalRelease records the first release in which from __future__ import FeatureName was accepted. In the case of MandatoryReleases that have not yet occurred, MandatoryRelease predicts the release in which the feature will become part of the language. Else MandatoryRelease records when the feature became part of the language; in releases at or after that, modules no longer need from __future__ import FeatureName to use the feature in question, but may continue to use such imports. MandatoryRelease may also be None, meaning that a planned feature got dropped. Instances of class _Feature have two corresponding methods, .getOptionalRelease() and .getMandatoryRelease(). CompilerFlag is the (bitfield) flag that should be passed in the fourth argument to the builtin function compile() to enable the feature in dynamically compiled code. This flag is stored in the .compiler_flag attribute on _Future instances. These values must match the appropriate #defines of CO_xxx flags in Include/compile.h. No feature line is ever to be deleted from this file. all_feature_names = [ nested_scopes, generators, division, absolute_import, with_statement, ] __all__ = [all_feature_names] + all_feature_names # The CO_xxx symbols are defined here under the same names used by # compile.h, so that an editor search will find them here. However, # they're not exported in __all__, because they don't really belong to # this module. CO_NESTED= 0x0010 # nested_scopes CO_GENERATOR_ALLOWED = 0# generators (obsolete, was 0x1000) CO_FUTURE_DIVISION = 0x2000 # division CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default CO_FUTURE_WITH_STATEMENT = 0x8000 # with statement class _Feature: def __init__(self, optionalRelease, mandatoryRelease, compiler_flag): self.optional = optionalRelease self.mandatory = mandatoryRelease self.compiler_flag = compiler_flag def getOptionalRelease(self): Return first release in which this feature was recognized. This is a 5-tuple, of the same form as sys.version_info. return self.optional def getMandatoryRelease(self): Return release in which this feature will become mandatory. This is a 5-tuple, of the same form as sys.version_info, or, if the feature was dropped, is None. return self.mandatory def __repr__(self): return _Feature + repr((self.optional, self.mandatory, self.compiler_flag)) nested_scopes = _Feature((2, 1, 0, beta, 1), (2, 2, 0, alpha, 0), CO_NESTED) generators = _Feature((2, 2, 0, alpha, 1), (2, 3, 0, final, 0), CO_GENERATOR_ALLOWED) division = _Feature((2, 2, 0, alpha, 2), (3, 0, 0, alpha, 0), CO_FUTURE_DIVISION) absolute_import = _Feature((2, 5, 0, alpha, 1), (2, 7, 0, alpha, 0), CO_FUTURE_ABSOLUTE_IMPORT) with_statement = _Feature((2, 5, 0, alpha, 1), (2, 6, 0, alpha, 0), CO_FUTURE_WITH_STATEMENT)
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr schrieb: I have discovered that the same error also occurs when i go to tools Tex information and do a rescan. The problem occurs when there is no spaces in the directory too. and I'm not running from a usb stick. I think I found the bug: A missing python file. It should work when you copy the attached file to LyX's \bin\Lib folder and then restart LyX. I'll release a new installer version tomorrow including this fix. regards Uwe Record of phased-in incompatible language changes. Each line is of the form: FeatureName = _Feature( OptionalRelease , MandatoryRelease , CompilerFlag ) where, normally, OptionalRelease MandatoryRelease, and both are 5-tuples of the same form as sys.version_info: (PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int PY_MINOR_VERSION, # the 1; an int PY_MICRO_VERSION, # the 0; an int PY_RELEASE_LEVEL, # alpha, beta, candidate or final; string PY_RELEASE_SERIAL # the 3; an int ) OptionalRelease records the first release in which from __future__ import FeatureName was accepted. In the case of MandatoryReleases that have not yet occurred, MandatoryRelease predicts the release in which the feature will become part of the language. Else MandatoryRelease records when the feature became part of the language; in releases at or after that, modules no longer need from __future__ import FeatureName to use the feature in question, but may continue to use such imports. MandatoryRelease may also be None, meaning that a planned feature got dropped. Instances of class _Feature have two corresponding methods, .getOptionalRelease() and .getMandatoryRelease(). CompilerFlag is the (bitfield) flag that should be passed in the fourth argument to the builtin function compile() to enable the feature in dynamically compiled code. This flag is stored in the .compiler_flag attribute on _Future instances. These values must match the appropriate #defines of CO_xxx flags in Include/compile.h. No feature line is ever to be deleted from this file. all_feature_names = [ nested_scopes, generators, division, absolute_import, with_statement, ] __all__ = [all_feature_names] + all_feature_names # The CO_xxx symbols are defined here under the same names used by # compile.h, so that an editor search will find them here. However, # they're not exported in __all__, because they don't really belong to # this module. CO_NESTED= 0x0010 # nested_scopes CO_GENERATOR_ALLOWED = 0# generators (obsolete, was 0x1000) CO_FUTURE_DIVISION = 0x2000 # division CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default CO_FUTURE_WITH_STATEMENT = 0x8000 # with statement class _Feature: def __init__(self, optionalRelease, mandatoryRelease, compiler_flag): self.optional = optionalRelease self.mandatory = mandatoryRelease self.compiler_flag = compiler_flag def getOptionalRelease(self): Return first release in which this feature was recognized. This is a 5-tuple, of the same form as sys.version_info. return self.optional def getMandatoryRelease(self): Return release in which this feature will become mandatory. This is a 5-tuple, of the same form as sys.version_info, or, if the feature was dropped, is None. return self.mandatory def __repr__(self): return _Feature + repr((self.optional, self.mandatory, self.compiler_flag)) nested_scopes = _Feature((2, 1, 0, beta, 1), (2, 2, 0, alpha, 0), CO_NESTED) generators = _Feature((2, 2, 0, alpha, 1), (2, 3, 0, final, 0), CO_GENERATOR_ALLOWED) division = _Feature((2, 2, 0, alpha, 2), (3, 0, 0, alpha, 0), CO_FUTURE_DIVISION) absolute_import = _Feature((2, 5, 0, alpha, 1), (2, 7, 0, alpha, 0), CO_FUTURE_ABSOLUTE_IMPORT) with_statement = _Feature((2, 5, 0, alpha, 1), (2, 6, 0, alpha, 0), CO_FUTURE_WITH_STATEMENT)
Re: problem with bibtex using LyXWinInstaller for LyX 1.4.4 - bug found
Uwe Stöhr schrieb:
I have discovered that the same error also occurs when i go to "tools
> Tex information" and do a
rescan. The problem occurs when there is no spaces in the directory
too. and I'm not running from
a usb stick.
I think I found the bug: A missing python file. It should work when you copy the attached file to
LyX's \bin\Lib folder and then restart LyX.
I'll release a new installer version tomorrow including this fix.
regards Uwe
"""Record of phased-in incompatible language changes.
Each line is of the form:
FeatureName = "_Feature(" OptionalRelease "," MandatoryRelease ","
CompilerFlag ")"
where, normally, OptionalRelease < MandatoryRelease, and both are 5-tuples
of the same form as sys.version_info:
(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
PY_MINOR_VERSION, # the 1; an int
PY_MICRO_VERSION, # the 0; an int
PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
PY_RELEASE_SERIAL # the 3; an int
)
OptionalRelease records the first release in which
from __future__ import FeatureName
was accepted.
In the case of MandatoryReleases that have not yet occurred,
MandatoryRelease predicts the release in which the feature will become part
of the language.
Else MandatoryRelease records when the feature became part of the language;
in releases at or after that, modules no longer need
from __future__ import FeatureName
to use the feature in question, but may continue to use such imports.
MandatoryRelease may also be None, meaning that a planned feature got
dropped.
Instances of class _Feature have two corresponding methods,
.getOptionalRelease() and .getMandatoryRelease().
CompilerFlag is the (bitfield) flag that should be passed in the fourth
argument to the builtin function compile() to enable the feature in
dynamically compiled code. This flag is stored in the .compiler_flag
attribute on _Future instances. These values must match the appropriate
#defines of CO_xxx flags in Include/compile.h.
No feature line is ever to be deleted from this file.
"""
all_feature_names = [
"nested_scopes",
"generators",
"division",
"absolute_import",
"with_statement",
]
__all__ = ["all_feature_names"] + all_feature_names
# The CO_xxx symbols are defined here under the same names used by
# compile.h, so that an editor search will find them here. However,
# they're not exported in __all__, because they don't really belong to
# this module.
CO_NESTED= 0x0010 # nested_scopes
CO_GENERATOR_ALLOWED = 0# generators (obsolete, was 0x1000)
CO_FUTURE_DIVISION = 0x2000 # division
CO_FUTURE_ABSOLUTE_IMPORT = 0x4000 # perform absolute imports by default
CO_FUTURE_WITH_STATEMENT = 0x8000 # with statement
class _Feature:
def __init__(self, optionalRelease, mandatoryRelease, compiler_flag):
self.optional = optionalRelease
self.mandatory = mandatoryRelease
self.compiler_flag = compiler_flag
def getOptionalRelease(self):
"""Return first release in which this feature was recognized.
This is a 5-tuple, of the same form as sys.version_info.
"""
return self.optional
def getMandatoryRelease(self):
"""Return release in which this feature will become mandatory.
This is a 5-tuple, of the same form as sys.version_info, or, if
the feature was dropped, is None.
"""
return self.mandatory
def __repr__(self):
return "_Feature" + repr((self.optional,
self.mandatory,
self.compiler_flag))
nested_scopes = _Feature((2, 1, 0, "beta", 1),
(2, 2, 0, "alpha", 0),
CO_NESTED)
generators = _Feature((2, 2, 0, "alpha", 1),
(2, 3, 0, "final", 0),
CO_GENERATOR_ALLOWED)
division = _Feature((2, 2, 0, "alpha", 2),
(3, 0, 0, "alpha", 0),
CO_FUTURE_DIVISION)
absolute_import = _Feature((2, 5, 0, "alpha", 1),
(2, 7, 0, "alpha", 0),
CO_FUTURE_ABSOLUTE_IMPORT)
with_statement = _Feature((2, 5, 0, "alpha", 1),
(2, 6, 0, "alpha", 0),
CO_FUTURE_WITH_STATEMENT)
