Add tracing utilities; with cabal flags switching #39
Conversation
|
Question: Is it necessary to have a separate library |
|
Yes. So the thing about mixins is that you have to explicitly name every single module you want to import in plutarch (Plutarch.Trace) requires (Plutarch.TraceSig as Plutarch.Trace.Enable),It would only make I think this is why signature packages are generally tiny and don't export many modules. |
|
Makes sense. As for the tests, we this should be fine. We should be able to depend on plutarch-trace in the tests. |
|
I wonder if Also, I think you'll get a cyclic dependency error if you try adding |
Sorry, didn't get what you mean here. Remove what? |
|
We probably want to add a separate package for tests. |
This is entirely my mistake. I was thinking of the code you wrote outside of this repository for tracing and had forgotten that that wasn't in Plutarch yet. |
|
Relevant: IntersectMBO/plutus#4304 |
|
I'm honestly still not sure whether Backpack is the best choice, but since I have very little experience with it, I'm thinking it's worth trying. Worst case we rip it out and make a backward incompatible change. |
|
I'm not super sure about backpack either ¯\(ツ)/¯ But from what I've seen so far - I don't think we'll need to rip it out. I've learnt from Drazen that cabal flags aren't exactly the best for even slightly complex dev UX. I like the ability to have both versions at once. I like the easy switching. I like the painless propagation of "generic-ness". And for our simple usecase, this shouldn't cause any problems. We won't really be mending much with the tracing package anyway. |
|
By the way, it looks like |
|
@L-as @TotallyNotChase I would be surprised if backpack gets ongoing support in GHC. It's very unpopular, and the economics are terrible. It's not really a first module system for Haskell a la Standard ML, so much as a hacked on module system. I would avoid backpack if possible. I have some alternative approaches if you want. |
|
Would love to hear about alternative approaches! Not a fan of cabal flags + CPP either. |
|
I had some discussions on #haskell:libera.chat wrt. this. Seems like nobody is maintaining Backpack, not to mention it's still unsupported in Stack. The implementation in GHC is supposedly not even finished. I'm not sure what the correct decision to take here is. Considering it's a small part of Plutarch, we can always switch it out if needed. |
|
I've noticed Matthew Pickering has started to make an effort at improving backpack 2 months ago. That's pretty neat! I find it funny that the backpack unofficial documentation, through the examples, is extremely good. Getting up and running with backpack is super easy with Also, I'm totally fine with switching the backpack impl out for some other machinery. I had fun learning it anyway. Although I do personally like backpack, we don't have certainty of its future. |
|
I think we should go with the Backpack approach for now. Doesn't make sense timewise to rewrite it now in case support gets dropped in the future. We can always handle this then. |
|
@L-as Moved out the tests suite to a separate package and added tests for tracing/no-tracing. I'm not sure if the CI ran them though. |
Otherwise haskell.nix won't detect it
It is more efficient, albeit if you care about efficiency you'd just disable traces entirely, and `ptrace'` can't be elided completely, unlike `ptrace`.
|
There's a big problem here... haskell.nix doesn't support Backpack. |
|
It seems like we'll have to move off of Backpack... The only other clean solution I can think of is passing in The alternative is that we fix support for Backpack but from what I can tell, this is far from trivial. We'll probably have to use flags and CPP unfortunately. |
|
I suppose I'm missing something, but why do we need to elevate this to the level of Cabal? Why wouldn't something as simple as https://hackage.haskell.org/package/NoTrace work well enough? |
|
Is there a good programmatic way of switching automatically to that? I certainly don't think we need Backpack, but just adding add |
|
@L-as Ha, I expected something of this sort to happen. Let's just get this over with - switched to cabal flags + CPP. I think this also means the CI should re-run the "Tracing" testcase with a |
|
@TotallyNotChase We don't need to use CPP. We can use the flags in the cabal file to select between different source files. |
CPP reduces some code duplication compared to that approach. I don't think it really matters though. |
|
Is this missing anything? I looked at the code and it seemed fine to me. |
|
@L-as It should be ready to merge. |
TotallyNotChase
changed the title
It's added as a separate package -
plutarch-trace. Everything one needs to know to useplutarch-traceand switch between tracing/no-tracing is explained inplutarch-trace/README. Users can also have both tracing and no-tracing version at the same time.Cabal >= 3.0 will be required to add
plutarch-traceas a dependency.Some general notes-
Any testing of these new utilities should be done within
plutarch-tracingitself, after instantiating a signature. This is becauseplutarch-tracingdepends onplutarch.plutarch-tracingexposes a generic module. That is, a module that actually uses a signature under the hood. In fact, the module just re-exports the signature.Why not just have the signature? You cannot instantiate a signature directly and get to using it. You need to have a package with a module that uses said signature, then you need to instantiate that package using an implementation. You cannot do-
where
Plutarch.TraceSigis a signature.TL;DR - In our case, dev experience will be better with this structure. No one should ever have to import
Plutarch.TraceSig.Cabal will give off warnings about using experimental features and some things are clearly a bit finicky. But it's all good, this usecase is not too complex.