SaswatPadhi
Support for Bit Vectors
Oh I see the issue with of_string for BitVec type. PR #11 is introducing a of_sexp function that would solve this.
In order to run benchmarks I have to remove line 9 of Simulator.ml. Also, I think the way I tried to parameterize the bit vector type is probably not that good since I use TVAR to store information for a string instead of another type. Maybe I should create another type which just parameterizes the length of a bit vector.
Thanks, let me take a look at your current set of changes and then I can provide better feedback.
Hi Adam,
Thanks for all these changes. Please let me know when you want me to take another look at your changes.
Hi Saswat, I'm ready for you to take another look at the changes. Thank you
I ran into the same problem that you had here with core_extended. Did you ever find a solution to it? It seems like the issue is that the dune file for the bitarray module does not have the (public_name ...) field so the library is not actually being installed by dune. I checked with the Docker container and all the other submodules defined in core_extended are installed by dune except for core_extended.bitarray, and the base core_extended library does not exist. It seems like this could be a bug with the way core_extended is built. I got it to work by adding (public_name core_extended.bitarray) to the bitarray dune file and rebuilding core_extended.
@adaminsky You're right. I just tried it again and there doesn't seem to be an easy way of using bitarray even though it's packaged within core_extended. I noticed that it was included in core_extended again, but hadn't tried using it.
I would raise another bug report, but for now I think you should move all your additions to some other files (BitArrayExt.ml?) and restore the original BitArray.ml so that when the bug is finally resolved, we can simply remove our copy of BitArray.ml and use the library copy of it.