profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/indygreg/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

indygreg/collectd-carbon 147

collectd plugin to write to Carbon (frontend for Graphite's Whisper storage format)

indygreg/collectd-diskstats 15

collectd plugin for detailed disk I/O stats via /proc/diskstats

indygreg/clanalyze 6

C/C++ code analyzer framework built on top of Clang

indygreg/clang 6

Personal copy of Clang for feature work

indygreg/collectd 2

Mirror of the official repository.

indygreg/github-webhooks-firehose 2

Consume GitHub webhooks requests

indygreg/hg-git 2

mercurial to git bridge, pushed to directly from the hg-git plugin in Hg

indygreg/docker-build-python 1

Build standalone and reusable Python installations from Docker

indygreg/dotfiles 1

configuration files for my home directory

indygreg/hg 1

Unofficial Git conversion of Mercurial repository

push eventindygreg/portable-clang

Gregory Szorc

commit sha 1b720f8eb7adf512dcc51919670504d7a1338f1b

Functionality for building Clang This entails building a modern GCC, as the GCC in Jessie is too old to build modern Clang. There's probably a lot of tweaking that will need to be done here. But it is a start. A lot of the code has been borrowed from python-build-standalone. I was the exclusive author of said code, so there shouldn't be any licensing concerns.

view details

push time in 5 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 4f1dfd750ccd3757767cb518ecbd2a037f37eb86

Functionality for building Clang This entails building a modern GCC, as the GCC in Jessie is too old to build modern Clang. There's probably a lot of tweaking that will need to be done here. But it is a start. A lot of the code has been borrowed from python-build-standalone. I was the exclusive author of said code, so there shouldn't be any licensing concerns.

view details

push time in 6 days

issue commentindygreg/python-build-standalone

pip not executable

This should be fixed as of commit 92fe187a43f77a6a5e03581f4944225b94b1b328. It will make it in the next release.

Wissperwind

comment created time in 6 days

issue closedindygreg/python-build-standalone

pip not executable

Hi, I can execute ./python3 cool! Python works. But pip does not. I can't execute ./pip3


osboxes@osboxes:~/Documents/resource/python/install/bin$ ./pip3
bash: ./pip3: /build/out/python/install/bin/python3: bad interpreter: No such file or directory

closed time in 6 days

Wissperwind

PR closed indygreg/python-build-standalone

Took care of the bad shebangs quirk

Make all python scripts in install/bin portable as well

+47 -19

3 comments

2 changed files

zsimic

pr closed time in 6 days

pull request commentindygreg/python-build-standalone

Took care of the bad shebangs quirk

92fe187a43f77a6a5e03581f4944225b94b1b328 implements a rewriting of the shebangs. The implementation is a bit different from this PR. But it was inspired by it and credited in the commit message (and by this comment).

This PR is no longer needed.

zsimic

comment created time in 6 days

PR closed indygreg/python-build-standalone

ncurses: make build ABI-compatible with version 5

I built Mercurial on Mac with PyOxidizer. I then ran hg commit -i and quit without changing anything. That resulted in a segfault. It seems that the issue is an ABI compatibility between the ncurses version compiled against (6.1 or 6.2, I don't remember which) and the version dynamically linked on macOS. On Big Sur, the ncurses version seems to be 5.4. Adding --with-abi-version=5 to the configure script fixed the problem for me.

+1 -0

3 comments

1 changed file

martinvonz

pr closed time in 6 days

pull request commentindygreg/python-build-standalone

ncurses: make build ABI-compatible with version 5

I think 07a9f2272cfb21909f270a6ae2a355505148afbb will fix this by removing the modern ncurses from the macOS build.

I'm open to using a modern ncurses and libedit on macOS. But since the system libraries were the intended versions in existing code, I decided to preserve that behavior for the time being.

martinvonz

comment created time in 6 days

push eventindygreg/python-build-standalone

Gregory Szorc

commit sha 83319f710ce453fdea4e25b572aaa32a53962d9a

downloads: upgrade LLVM/Clang to 12.0.1

view details

Gregory Szorc

commit sha 7f5dcf45a0add83ae67f36fb04d0fcda352ed456

downloads: upgrade CPython 3.8.10 to 3.8.11

view details

Gregory Szorc

commit sha 28a4469b79c8555580bd74a3d215a1be2cc304c5

downloads: upgrade CPython 3.9.5 to 3.9.6

view details

Gregory Szorc

commit sha 1aca322e5f3660f6dd465fb8afe20d92e92c9359

downloads: upgrade libedit 20210216-3.1 to 20210714-3.1

view details

Gregory Szorc

commit sha 62eb0d292eb37c2aa8a8f9cd2c1961d25b6f7067

downloads: upgrade LibreSSL 3.2.5 to 3.3.3

view details

Gregory Szorc

commit sha 20211c52ba9ad28a300cb3653d0849d54656821a

downloads: upgrade pip 21.1.1 to 21.1.3

view details

Gregory Szorc

commit sha e8e0c74c4fd38cce94f2b4d3d6fe92965a9ca201

downloads: upgrade setuptools 56.1.0 to 57.2.0

view details

Gregory Szorc

commit sha 53146e7fc7118ac73e34c1dc191778760c3a740e

downloads: upgrade SQLite 3.35.5 to 3.36.0

view details

Gregory Szorc

commit sha a37cd3d0d03a78c457033c12a56718713bfc026a

downloads: upgrade CPython 3.10.0a5 to 3.10.0b4 This required a minor patch to no longer apply a patch against 3.10.

view details

Gregory Szorc

commit sha 92fe187a43f77a6a5e03581f4944225b94b1b328

unix: rewrite shebangs of Python scripts to reference local interpreter Before, the shebangs referenced a path in the build environment, which likely didn't exist in the run-time environment. After this change, the shebang uses a multiline shell script to call `exec` on the `python*` binary in the same directory as the script. The solution is similar to #61 but the technical approach is a bit different. We perform the rewrite inside the build environment, so this should work when building in Docker containers. And we use binary I/O everywhere, ensuring bytes are preserved. We also always exec the canonical `python*` binary to avoid symlink overhead.

view details

Gregory Szorc

commit sha 07a9f2272cfb21909f270a6ae2a355505148afbb

unix: stop building libedit and ncurses on macOS Our static-modules files link against the system ncurses. But we were building a custom ncurses. This could lead to confusion where our modern ncurses was "leaking" into build state / configuration, leading to run-time crashes (see #83). This commit drops building ncurses for macOS. Because libedit and ncurses are closely related and we were also linking against the system libedit, we drop building modern libedit as well.

view details

push time in 6 days

pull request commentindygreg/python-build-standalone

ncurses: make build ABI-compatible with version 5

Ahh - I think the root cause is macOS linker arguments are referencing -lncurses instead of -lncursesw. I'd say this was an oversight from 102fb0d029e902c1568c8fa0c2b9c927801c9069. However, that commit explicitly says we purposefully link against the system ncurses on macOS.

So I guess we have a choice: drop libedit/ncurses from our macOS builds or prevent linking against the system variants.

martinvonz

comment created time in 6 days

push eventindygreg/python-build-standalone

Gregory Szorc

commit sha 83319f710ce453fdea4e25b572aaa32a53962d9a

downloads: upgrade LLVM/Clang to 12.0.1

view details

Gregory Szorc

commit sha 7f5dcf45a0add83ae67f36fb04d0fcda352ed456

downloads: upgrade CPython 3.8.10 to 3.8.11

view details

Gregory Szorc

commit sha 28a4469b79c8555580bd74a3d215a1be2cc304c5

downloads: upgrade CPython 3.9.5 to 3.9.6

view details

Gregory Szorc

commit sha 1aca322e5f3660f6dd465fb8afe20d92e92c9359

downloads: upgrade libedit 20210216-3.1 to 20210714-3.1

view details

Gregory Szorc

commit sha 62eb0d292eb37c2aa8a8f9cd2c1961d25b6f7067

downloads: upgrade LibreSSL 3.2.5 to 3.3.3

view details

Gregory Szorc

commit sha 20211c52ba9ad28a300cb3653d0849d54656821a

downloads: upgrade pip 21.1.1 to 21.1.3

view details

Gregory Szorc

commit sha e8e0c74c4fd38cce94f2b4d3d6fe92965a9ca201

downloads: upgrade setuptools 56.1.0 to 57.2.0

view details

Gregory Szorc

commit sha 3200d31d0744dcc4dacc7de67fbacff9a059fc09

downloads: upgrade SQLite 3.35.5 to 3.36.0

view details

push time in 6 days

issue commentindygreg/python-build-standalone

.tar.gz artefacts (for Bazel)

If bazel toolchain support is what you are after, I think a reasonable feature request would be to provide artifacts that can be used explicitly as a bazel toolchain. These would likely be .tar.gz archives with just the Python installation (not the object files and other build artifacts/metadata).

Would it be sufficient to publish a .tar.gz with just the contents of the python/install directory to serve as bazel toolchains? Should there be a root directory (like python/) or should we just move everything in python/install to the root directory (e.g. bin/python3.9)?

jheaff1

comment created time in 6 days

pull request commentindygreg/python-build-standalone

ncurses: make build ABI-compatible with version 5

This patch surprises me because we are supposed to be building our own ncurses for macOS and not relying on the system library!

However, both /usr/lib/libedit.3.dylib and /usr/lib/libncurses.5.4.dylib are annotated as allowed libraries in the Rust validation code. They are likely listed because something is referencing them.

Either we should be linking against the system libraries and not building libedit/ncurses or we should be building these libraries and not linking against the system libraries. More investigation is needed.

martinvonz

comment created time in 6 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha b523afa9a967e6ab8a2dd4876424dbf2e6fdbb1f

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 4b1d3b564e155d12bf169f911ee46c02094aa563

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha f7886ad9e2c72068192287b1c67c24219da152aa

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha b853c529cfe0ec0f337856d3561f3f2dcf28b695

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 9108af5a877cdac2cfb7ef018521131d85ef4108

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha ad46823954ca3750215b24678a349a2476b88072

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations and producing a tarball with all glibc configurations inside.

view details

push time in 13 days

issue commentindygreg/python-zstandard

Allow setting the Frame size after writes are complete

The frame content size is written in the zstd frame header (https://github.com/facebook/zstd/blob/dev/doc/zstd_compression_format.md). So if you are streaming output and have already written the frame header, there's no way to retroactively go back and set the frame size.

If you are actually streaming, leaving the frame size as undefined should be fine. But if you insist on writing it in the included zstd frame, you'll need to buffer incoming data first (to know its final size) then perform a new compression operation, specifying that now known size.

Does that make sense?

cbenning

comment created time in 15 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 78cef0de21089e014e19a1108d11405ed5a92b0b

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations.

view details

push time in 16 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha f5a287a482175988f4e34b79f81a38c198da602a

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations.

view details

push time in 17 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 650d9df57e938c9d2a374d9e0f6984c12f72f32a

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations.

view details

push time in 17 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha 935c4cbf9f83b0fc97f76937596f3a6438442587

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations.

view details

push time in 17 days

push eventindygreg/portable-clang

Gregory Szorc

commit sha c4b9b2db6715c2169ded2e545aba1cbf5f7c43f9

Functionality for building glibc This adds some scripts and GitHub Actions CI for building various glibc configurations.

view details

push time in 18 days

PublicEvent

push eventindygreg/python-zstandard

Gregory Szorc

commit sha 1baf8778e7fc2db81177964b414e66aeafd98a55

ci: build Linux and Windows wheels with --py-limited-api=cp36 This enables us to produce wheels that are compatible with CPython 3.6+, since they are guaranteed to only target the stable Python ABI.

view details

push time in 18 days

push eventindygreg/python-zstandard

Gregory Szorc

commit sha 65853f1cde79e02ce1d7258d03f9b514523f03c9

ci: build Linux wheels with --py-limited-api=cp36 This enables us to produce wheels that are compatible with CPython 3.6+, since they are guaranteed to only target the stable Python ABI.

view details

push time in 18 days

push eventindygreg/python-zstandard

Gregory Szorc

commit sha f8db5a2ded3f28c6bccbf057abef86f557999f83

tests: change estimated compression context size Behavior appears to have changed between zstd 1.4.8 and 1.5.0. This commit reflects that change in behavior. As of this commit, tests pass against the C backend on Linux after the 1.5.0 upgrade.

view details

Gregory Szorc

commit sha 34df06d1dba84e26884ebe8321e3c3bfe3125d26

cffi: support building against 1.5.0 The header file layout changed. So we had to reflect that. In addition, the deprecated __attribute__ syntax changed slightly. So we had to adopt our preprocessor normalizer accordingly to prevent the cdef parser from being confused. As of this commit, the cffi backend passes all tests against 1.5.0.

view details

Gregory Szorc

commit sha f00ab988cbf5768add74e7a95525b8b7e96a6c03

rust: update zstd and dependency crates to latest This commit updates the zstd crates to use a version with zstd 1.5.0. This effectively keeps the Rust backend in sync with the recently performed zstd 1.5.0 upgrade. As of this commit, all tests pass against the Rust backend.

view details

Gregory Szorc

commit sha a1191adceb0f798203a1d74066b7a782497c6a61

c-ext: use ZSTD_DCtx_setParameter ZSTD_DCtx_setFormat() is deprecated in favor of this function. This avoids a compiler warning against 1.5.0.

view details

Gregory Szorc

commit sha 633bd71a030d98bfa125910c4b6e767449bdfa0d

cffi: disable deprecation warnings when building main library We were already doing this for ZDICT symbols. We need to do it for the main library as well to avoid a bunch of compiler warnings when building the CFFI backend.

view details

Gregory Szorc

commit sha 3dde64bfe4789d5d784bb43f42d3ea46dca1bd95

docs: document 1.5.0 upgrade The last several commits upgraded the bundled library to 1.5.0 and fixed a handful of build and test failures. As of this commit, I think 1.5.0 can be considered stable. As part of this we also document new APIs in 1.5.0 we could potentially expose.

view details

odidev

commit sha f9bb88918a113a6dc3aa733045a79002a38a6a8c

ci: add linux aarch64 wheel support Closes #144 and #145.

view details

Petr Viktorin

commit sha 4495cbe2faf0cd20fcd8735f4f519d4eb4c4f7a1

doc: fix train_dictionary reST syntax Closes #146.

view details

Gregory Szorc

commit sha 61e92296d15fdcc22e2cf07ddc0d4331042377e1

global: drop support for Python 3.5 It is no longer supported upstream as of September 2020. Let's stop supporting this old Python version.

view details

Gregory Szorc

commit sha b251391f44a841773fa5a42209339650b712781f

ci: consolidate Linux matrix Dropping Python 3.5 support made this possible.

view details

Gregory Szorc

commit sha 386e5c64e49f4dd40845e67e858dc02055ab7989

ci: build Linux wheels with --py-limited-api=cp36 This enables us to produce wheels that are compatible with CPython 3.6+, since they are guaranteed to only target the stable Python ABI.

view details

push time in 18 days

PR closed indygreg/python-zstandard

Add linux aarch64 wheel support

Added linux aarch64 wheel support. Related to #144. @indygreg Could you please review this PR?

+8 -0

4 comments

2 changed files

odidev

pr closed time in 18 days