Hi Bruno,
On 4/22/24 7:33 AM, Bruno Haible wrote:
> OK, patch welcome. I assume that when Dmitry used this style of assignments,
> the Python 2.7 / 3.0 imports were not so well developed as they are today.
Here is a patch that removes all the module-specific variables and
imports the functions di
Collin Funk wrote:
> > The first workaround should fix trouble similar to what we regularly
> > see with 'autom4te.cache': Unnecessary difference while comparing source
> > trees, unnecessary "git status" noise. Clutter.
>
> I don't think the Python stuff should clutter 'git status' atleast.
>
>
Collin Funk wrote:
> >> I have no clue if this has a noticeable performance impact or not.
> >
> > Can you measure it, please? For example, with
> > GNULIB_TOOL_IMPL=py time ./test-all.sh
> >
> > I measure a difference in the 2% range, but it's not clear to me whether
> > -B slows down or speed
On 4/22/24 4:22 AM, Bruno Haible wrote:
> The first workaround should fix trouble similar to what we regularly
> see with 'autom4te.cache': Unnecessary difference while comparing source
> trees, unnecessary "git status" noise. Clutter.
I don't think the Python stuff should clutter 'git status' atl
On 4/22/24 4:38 AM, Bruno Haible wrote:
> Collin Funk wrote:
>> I have no clue if this has a noticeable performance impact or not.
>
> Can you measure it, please? For example, with
> GNULIB_TOOL_IMPL=py time ./test-all.sh
>
> I measure a difference in the 2% range, but it's not clear to me whet
Janneke Nieuwenhuizen wrote:
> For the current situtation (that's less than great and are
> working on to resolve), making essential GNU packages less
> bootstrappable is of no consequence.
OK. That's what I conjectured. Thanks for confirming.
> Cleaning-up the full-source
> bootstrap and making
Hi Collin,
> I want to make the imports and use of functions from other modules
> consistent. This patch makes all files use absolute imports like
> main.py. So this:
>
>from pygnulib.GLEmiter import GLEmiter
>
> instead of:
>
>from .GLEmiter import GLEmiter
Consistency is not a good e
On Montag, 22. April 2024 09:27:47 CEST Paul Eggert wrote:
> >- off_t changes depending on whether gl_LARGEFILE is in use or not;
> > thus it's a bad idea to use it in the API of any shared library or
> > (more generally) any independently-built component.
>
> That ship sailed long a
Collin Funk wrote:
> I have no clue if this has a noticeable performance impact or not.
Can you measure it, please? For example, with
GNULIB_TOOL_IMPL=py time ./test-all.sh
I measure a difference in the 2% range, but it's not clear to me whether
-B slows down or speeds up things :)
Bruno
Janneke Nieuwenhuizen writes:
>> Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap
>> uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So,
>> even if newer versions of 'make' or 'gcc' will use a Python-based
>> gnulib-tool,
>> there won't be a pro
Thanks for the report, Paul.
Thanks for the preliminary investigation, Collin.
> > ./bootstrap
> > ./configure
> > make -k distclean
> > git submodule foreach git pull origin master
> > git commit -m 'build: update gnulib submodule to latest' gnulib
> > ./bootstrap --no-git --gnulib-sr
Simon Josefsson wrote:
> If we want to minimize the work for full-source bootstrap people we
> increase the cost of people maintaining modern software, and vice versa,
+1
> Consider the
> extreme situation where gnulib-tool version A would require coreutils
> verison B, and coreutils version B+1
Bruno Haible writes:
Hi!
> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
> "Even more recent
On 4/22/24 1:23 AM, Collin Funk wrote:
> It looks like it can be turned off with 'python3 -B' or setting the
> PYTHONDONTWRITEBYTECODE environment variable to a non-empty string [1]
> [2].
I was able to reproduce the issue. Modifying the 'gnulib-tool.py'
shell script in the 'gnulib' submodule so t
Hi Paul,
On 4/22/24 12:56 AM, Paul Eggert wrote:> export GNULIB_TOOL_IMPL=sh+py
> ./bootstrap
> ./configure
> make -k distclean
> git submodule foreach git pull origin master
> git commit -m 'build: update gnulib submodule to latest' gnulib
> ./bootstrap --no-git --gnulib-srcdir=gnul
Thank you very much Bruno and Paul,
I will look into the links.
It is great that gnulib-tool does not use Python packages, but only the
core of Python from its own tarball :-).
Cheers,
Mohammad
On 2024-04-21 03:52, Bruno Haible wrote:
5. Regenerate the fetched and generated files of your package. Depending on
the package, this may be a command such as
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
I had a failure with this step when using current GNU diffutils
(3d1a56b906
Bruno Haible writes:
> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
> "Even more recently (
On 2024-04-21 14:36, Bruno Haible wrote:
But direct use of off_t has two problems:
- off_t is not defined by ISO C; thus it's an odd return type for things
like zsprintf.
I was thinking that zsprintf should return ptrdiff_t and zprintf would
return off_t. off_t is defined by POSIX , s
On 2024-04-21 15:27, Bruno Haible wrote:
ISO C, btw, is also "ever-changing"
Yes, plus if a language is not "ever-changing" it's dead.
The main thing to worry about is when old code stops working not when
new language features get added. Since Python 3 came out Python has been
reasonably goo
On 2024-04-21 15:38, Bruno Haible wrote:
Hi Paul,
But the concepts of the shell are stuck in the 40-years-ago past.
True, but keeping things simple allows for optimizations like PaSH that
can't reasonably be done to Python.
https://binpa.sh/
Well, I did try PaSh on gnulib-tool — this issue
21 matches
Mail list logo
