ghc-utils issueshttps://gitlab.haskell.org/bgamari/ghc-utils/-/issues2023-11-01T09:00:22Zhttps://gitlab.haskell.org/bgamari/ghc-utils/-/issues/19gdb extension calls Bdescr function2023-11-01T09:00:22ZTeo Camarasugdb extension calls Bdescr functionThis function isn't accessible if you are loading a core dump from a file.
GDB will complain that it can't run functions.
We should just inline this function into the extension by doing the bit twiddling ourselvesThis function isn't accessible if you are loading a core dump from a file.
GDB will complain that it can't run functions.
We should just inline this function into the extension by doing the bit twiddling ourselveshttps://gitlab.haskell.org/bgamari/ghc-utils/-/issues/18Update library versions wiki page2023-08-31T15:34:42ZAndreas AbelUpdate library versions wiki pageWould be great if this page could be updated: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
It misses recent GHC versions and the HEAD column seems to be esp. outdated.Would be great if this page could be updated: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
It misses recent GHC versions and the HEAD column seems to be esp. outdated.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/17Branch for 9.2 release2022-05-31T09:35:42ZZubinBranch for 9.2 releaseI've created a branch for doing releases in the 9.2 series at https://gitlab.haskell.org/bgamari/ghc-utils/-/tree/9.2-releaseI've created a branch for doing releases in the 9.2 series at https://gitlab.haskell.org/bgamari/ghc-utils/-/tree/9.2-releasehttps://gitlab.haskell.org/bgamari/ghc-utils/-/issues/16Contributions are being ignored2021-08-16T11:14:20ZSimon JakobiContributions are being ignoredI've noticed that several straight-forward MRs have been ignored for a long time, for example:
* https://gitlab.haskell.org/bgamari/ghc-utils/-/merge_requests/28
* https://gitlab.haskell.org/bgamari/ghc-utils/-/merge_requests/26
* https...I've noticed that several straight-forward MRs have been ignored for a long time, for example:
* https://gitlab.haskell.org/bgamari/ghc-utils/-/merge_requests/28
* https://gitlab.haskell.org/bgamari/ghc-utils/-/merge_requests/26
* https://gitlab.haskell.org/bgamari/ghc-utils/-/merge_requests/27
I was wondering whether the situation could be improved simply by allowing some contributors to merge their changes themselves. So I'd like to apply for commit bits, and I'd suggest that @takenobu-hs gets them too.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/15compare-ticks fails for high alloc counts.2021-03-15T22:44:46ZAndreas Klebingercompare-ticks fails for high alloc counts.I tried comparing ticks between 8.10 and 9.0 and got this error:
```
compare-ticks.exe: (interactive):1:40: error: expected: natural
1 | <3447200013130432000 0 3 +SI perceptual-hash-0>
| ...I tried comparing ticks between 8.10 and 9.0 and got this error:
```
compare-ticks.exe: (interactive):1:40: error: expected: natural
1 | <3447200013130432000 0 3 +SI perceptual-hash-0>
| ^
CallStack (from HasCallStack):
error, called at TickyReport.hs:115:27 in main:TickyReport
```
The line it chokes on is this:
` 23447200013130432000 0 3 +SI perceptual-hash-0.1.4.0-inplace:PerceptualHash.$s$fArrayVScse_$s$fVectorVectora_$cbasicUnsafeIndexM{v r3PH} (fun)
`
It seems we allocate so much in a single function that there is no whitespace between the columns anymore, breaking the parser.
Not sure if that's worth fixing, with recent efforts to output ticky results via the eventlog.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/14compare-ticks could look at the amount of allocation and order in the ticky f...2021-01-29T23:13:25ZSebastian Grafcompare-ticks could look at the amount of allocation and order in the ticky file to find better pairingsI strangely find that the .ticky files already are quite good for diffing, although it's a bit tedious to find the hard hitters. Why is that?
- The order in which the bindings appear is deterministic across different compiler versions, ...I strangely find that the .ticky files already are quite good for diffing, although it's a bit tedious to find the hard hitters. Why is that?
- The order in which the bindings appear is deterministic across different compiler versions, at least for the examples I checked
- That means the order in which the bindings appear line up pretty well across .ticky files. They get out of sync as soon as one variant introduces a binding that wasn't there in the other variant, but if you add an empty line in the other variant accordingly, it lines up well again.
I think those observations suggest some kind of edit distance approach for lining them up to find pairings for the presented 3 tables. Characters in the edit distance jargon correspond to lines/metrics in the ticky file. Equal characters/line have cost zero, a substitution has cost based on the similarity between lines, e.g., same (significant, e.g. > 10000 bytes) no of allocations but different name has a minor substitution cost 0.05. Then an insert/delete could have cost 1.
Just to be clear: whenever the algorithm chooses "substitute" or "equal", you'd put them in the first comparison table, "insert" would put them in the "alloc A" table and "delete" would put them in the "alloc B" table.
Since it's a dynamic program, we can be sure to always find "the optimum" effecienctly, without any inspection of STG code like I suggested in #13, which is pretty nice. "The optimum" surely depends on the similarity function we choose, but I strongly believe that we can fine-tune it to great effect.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/13compare-ticks should feed on a list of name pairings2021-01-26T12:26:17ZSebastian Grafcompare-ticks should feed on a list of name pairings`compare-ticks` is really helpful in pinning down unique allocations of variant B vs. variant A. But it's not so good at matching up the names of bindings: Because it's (necessarily) purely syntactically matching up e.g. `A.$wgo2` with `...`compare-ticks` is really helpful in pinning down unique allocations of variant B vs. variant A. But it's not so good at matching up the names of bindings: Because it's (necessarily) purely syntactically matching up e.g. `A.$wgo2` with `B.$wgo2`, it doesn't realise that `A.$wgo2` acutally corresponds to `B.$wgo3`.
It's not the job of `compare-ticks` to figure that our either. Here's [`corediff`](https://github.com/pbrinkmeier/corediff/), the corresponding [thesis](https://pp.ipd.kit.edu/uploads/publikationen/brinkmeier20bachelorarbeit.pdf) I supervised, that could figure out more semantically accurate pairings for us. A few issues:
- It's a bit POCy, so probably has a few bugs
- It operates on Core. But that should be moderately easy to fix. UNfortunately, I believe we need to extend `ghc-dump-core` for that, resp. write a `ghc-dump-stg`.
- It probably needs to be adjusted a bit to emit a file of pairings, e.g.
```
...
(M.$wgo2,M.$wgo3)
...
```
Then I imagine that `compare-ticks` could just take a `--pairings pairings.txt` flag and respect those pairings.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/12File ChangeLog.md is missing from compare-ticks2020-11-19T23:38:51ZRichard Eisenbergrae@richarde.devFile ChangeLog.md is missing from compare-ticksThe title says it all. Removing `ChangeLog.md` from `extra-source-files` in the cabal file fixes the build, but perhaps you have a change-log you wished to add.The title says it all. Removing `ChangeLog.md` from `extra-source-files` in the cabal file fixes the build, but perhaps you have a change-log you wished to add.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/11Build is quite badly broken2020-04-30T08:48:55ZMatthew PickeringBuild is quite badly brokenOn a recent commit I get the following build failure
```
ghc_gdb/ghc_heap.py:208: error:(B (B"Ptr"(B has no attribute (B"cast"(B(B
ghc_gdb/ghc_heap.py:213: error:(B (B"Ptr"(B has no attribute (B"cast"(B(B
ghc_gdb/ghc_heap.py:214: error:...On a recent commit I get the following build failure
```
ghc_gdb/ghc_heap.py:208: error:(B (B"Ptr"(B has no attribute (B"cast"(B(B
ghc_gdb/ghc_heap.py:213: error:(B (B"Ptr"(B has no attribute (B"cast"(B(B
ghc_gdb/ghc_heap.py:214: error:(B (B"Ptr"(B has no attribute (B"cast"(B(B
Found 3 errors in 1 file (checked 12 source files)(B
```
Also using the nix files in the gdb subdirectory directly fails because of the `{nixpkgs ? nixpkgs}` argument causing infinite recursion.
ecd0a23e93ad4d270c81fdcd08fdd4a0b6ab8322 seems to build ok.https://gitlab.haskell.org/bgamari/ghc-utils/-/issues/10Library versions ordering incorrect2021-02-04T18:13:01ZBen GamariLibrary versions ordering incorrectIt looks like my last refactoring changed the order of table rows. Specifically 7.10 appears between 7.0 and 7.2.It looks like my last refactoring changed the order of table rows. Specifically 7.10 appears between 7.0 and 7.2.Ben GamariBen Gamarihttps://gitlab.haskell.org/bgamari/ghc-utils/-/issues/8gdb extension doesn't work with Python 2.72019-02-08T23:21:51ZÖmer Sinan Ağacangdb extension doesn't work with Python 2.7```
(gdb) python import ghc_gdb
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/omer/.local/lib/python2.7/site-packages/ghc_gdb/__init__.py", line 5, in <module>
from . import ghc_heap
...```
(gdb) python import ghc_gdb
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/omer/.local/lib/python2.7/site-packages/ghc_gdb/__init__.py", line 5, in <module>
from . import ghc_heap
File "/home/omer/.local/lib/python2.7/site-packages/ghc_gdb/ghc_heap.py", line 577, in <module>
PrintGhcClosureCmd()
File "/home/omer/.local/lib/python2.7/site-packages/ghc_gdb/ghc_heap.py", line 372, in __init__
self.__class__.__doc__ += '\n' + self._parser.format_help()
AttributeError: attribute '__doc__' of 'type' objects is not writable
Error while executing Python code.
```
Deleting this line makes it work.