Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upTest project on Windows with MINGW git (conda2.7&3.4/cpy-3.5) #519
Conversation
|
@ankostis Totally awesome ! Even though I won't be of much help, I do hope that fixing the windows issues work out in the end. That would restore windows platform support and keep it, after all these years of supporting it just on a best-effort basis, which meant not to obviously use non-windows APIs. |
ankostis
force-pushed the
ankostis:appveyor
branch
2 times, most recently
from
1774f98
to
d773d40
|
Yes, that's a start. |
ankostis
force-pushed the
ankostis:appveyor
branch
3 times, most recently
from
5899c59
to
d12fdca
|
@Byron the |
+ Pump once, so when input larger than `mmap.PAGESIZE`, stream is not emptied.
+ Pump once, so when input larger than `mmap.PAGESIZE`, stream is not emptied.
+ Pump once, so when input larger than `mmap.PAGESIZE`, stream is not emptied.
+ Pump code reads only once streams per `_read_lines_from_fno()` invocation, so when input larger than `mmap.PAGESIZE`, bytes are forgotten in the stream.
+ The code in `_read_lines_from_fno()` was reading the stream only once per invocation, so when input was larger than `mmap.PAGESIZE`, bytes were forgotten in the stream. + Also set deamon-threads.
+ The code in `_read_lines_from_fno()` was reading the stream only once per invocation, so when input was larger than `mmap.PAGESIZE`, bytes were forgotten in the stream. + Replaced buffer-banging code with iterate-on-file-descriptors. + Also set deamon-threads.
+ The code in `_read_lines_from_fno()` was reading the stream only once per invocation, so when input was larger than `mmap.PAGESIZE`, bytes were forgotten in the stream. + Replaced buffer-building code with iterate-on-file-descriptors. + Also set deamon-threads.
|
@Byron that was a tough one! I replaced the buffer-assembly code with iterate-on-file-descriptors. Actually the code is so simple that it maybe worth to replace the select-poll with the 2-pumps code, for all OSs? Many A side question:
Is that possible? I would expect any language allowing such "gap" to be considered outright broken. |
…`assertRaisesRegexp`
…`assertRaisesRegexp`
+ Just to see Apveyor all green and merge; the TCs HAVE TO BE FIXED.
|
@ankostis I agree, the errors you mention seem to be rooted in smmap and would thus have to be fixed there. Especially the one with the incompatible type appears like something that is relatively easy reproduce and fix via smmap. A hint I have not right now, just because it was years ago that I have touched the project for the last time. However, I could believe it is riddled with resource-related issues as I was banking on deterministic destructors back then. For now I will just merge the PR and try to setup the appveyor hooks. Maybe as a contributor, you can even do that yourself in case it doesn't work for me. |
Byron
merged commit 9d6b417
into
gitpython-developers:master
+ Just to see Apveyor all green and merge; the TCs HAVE TO BE FIXED.
|
Just pushed one last commit with those 3 TCs appropriately skipped.
Actually quite the contrary: I can only reproduce it when i run the full harness; if i launch these 2 TCs alone, they pass! So practically, I cannot enter debug-mode - I have to wait 2' just to reach this point.
Have not received an invitation yet. |
|
This is odd: I have just re-invited you, maybe it comes through. Otherwise you would just have to visit https://github.com/gitpython-developers to see the invitation. Your last commit was not part of my merge, I will fetch it separately. |
+ Just to see Apveyor all green and merge; the TCs HAVE TO BE FIXED.
|
@ankostis I think it worked ! The last commit has been cherry-picked and AppVeyor is on its way to all-green ! Even though it's not the real thing just yet, I call it an impressive piece of work! Thanks so much ! Right now I wouldn't know how to tackle the smmap issue, just as it's hard to fix anything in a project that is installed as a dependency. Probably it would be easiest if it would be reproducible locally, which I can't even do. |
|
@Byron many of the fixes in this PR can be applied also on gitdb, and as you said (haven't checked) on smmp. Is there a chance to tackle these issues in these projects? Or are they "frozen" somehow? I mean, a lot of problems just go away if resource classes are retrofitted as What do you think, is it worth the effort (but cna't promise anything)? |
ankostis
changed the title
|
For reference, reporting the CORRECT Appveyor results after #521 fixes by yarikoptic & ankostis restored skipped TCs: PY27: 5 errors: |
…preferredencoding()` + On Windows, this is the default encoding (usually, the mate-encoding `mcbs' which points to the current code-page (i.e. `cp1252` for Europe).
|
@ankostis With the latest upgrade of gitdb and smmap to 2.0, it's finally possible again to make new releases. This would allow the changes you talk about to be retro-fitted indeed, and given all the subtle problems GitPython has, it would certainly be worth doing that. |
poll/selectbuffer-assembly code with pump-threads (Win TCs faling 90-->20!) and rework unicode handling in many places.Popen()procs it withsubprocess.CREATE_NEW_PROCESS_GROUPso that they can be killed.git-daemon(instead ofgit daemon); otherwise it detaches (unix-ism here) from parent git cmd, and then CANNOT DIE!Popen().proc.stdout/stderrfrom the launching-thread, it freezes due to GIL/buffering.+Rework GitCommandError.str() and add TCs on unicode handling.
with GitConfigarser()more systematically in TCs..gitfile prior overwrite; Windows denied otherwise!git add <file>case, PY2 fails when args are unicode.Must encode them with
locale.getpreferredencoding()AND use SHELL.shellintoexecute()kwds, for overriding USE_SHELL percommand.
communicate()in_clone()with thread-pumps (UNNECESSARY, see this later discussion).with...construct (not complete).Popen()calls, to collect cmd usage.Apveyor results