- User Since
- Jul 1 2017, 5:02 PM (207 w, 18 h)
Mon, May 24
Oh wow - I never would have thought that the presence of this symbol would affect linking behavior. But I suppose it makes sense. The functions are probably left as unresolved references but the static variable reference forces early binding or something. I'm not an expert on how PE does symbol binding/resolution. But this patch shouldn't change behavior and if it fixes the problem, it fixes the problem.
May 15 2021
May 10 2021
May 9 2021
May 7 2021
I'll need to release a new version of PyOxidizer to fix wonky behavior due to interaction of file mtimes and pip (https://github.com/indygreg/PyOxidizer/commit/a0bdde179aaed8521d3a668e518554814bcffdba).
Yeah, I was hitting this zip file error too. I'm not sure what's causing it. But I'm actively looking into fixing it!
Turns out Python's distutils isn't smart enough to use Visual Studio 2019, even though its toolchain is ABI compatible with 2017. Boo.
May 6 2021
@mharbison72 You may be interested in this series starting at approximately this patch. Version 0.15 of PyOxidizer supports building MSIs "natively." I implemented enough features to port Mercurial's MSI generation to it. I need to have a go at porting TortoiseHg to use PyOxidizer. But I'm optimistic it is doable. Note that you don't need to use the "build a Python binary" pieces of PyOxidizer with MSI generation: they are completely separate.
Feb 6 2021
Jan 24 2021
I'm not going to review this right now, but I have prior art at https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/093657.html and https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097960.html that might be worth a read. I believe the wiki page on this format only contains a subset of the deficiencies I outlined in the 1st link.
The -- also bothers me and I came here to see if it had been discussed before accepting this patch.
Shouldn't this patch be checking for the existence of the windows_curses package instead?
I'm -0 on this change. Caches are caches and IMO should only be populated on demand.
I mostly support this change. However, a supposed no-op upgrade may still result in differences! For example, if we change the algorithm for computing how revlog deltas are computed without actually changing the storage semantics, performing a no-op upgrade would migrate the store to use the new code.
Jan 22 2021
Dec 4 2020
Nov 18 2020
Nov 11 2020
Are the Rust extensions considered stable? I'm honestly unsure. I'd love to ship these. But I'd like confirmation from the people maintaining them before we sign off.
Nov 10 2020
I think this should work.
Nov 9 2020
Nov 7 2020
Let's refactor the playback code to read from the journal file [handle]. That will preserve the order. There should be no meaningful performance implications here.
Why do we have to maintain the in-memory records at all? Don't we write these to the journal and journal.backupfiles files? What's wrong with reading this file handle? We only need to perform a findoffset() when incurring a split revlog or during rollback, right? Is there a noticeable performance overhead to performing that linear scan?