No, I did the same thing, and only the first hundred tests work normally,
the other 100 hand for several minutes. Maybe my computer is too weak, it's
an early 2009 iMac with a 2.66GHz Core2Duo and 8GB of RAM. I also ran `raco
setup msgpack` after making the change to the source file to make sure
I'm not able to replicate that (see transcript below). Is there
something else I should be doing?
[samth@huor:~/tmp/MsgPack.rkt (master) plt] git diff
diff --git a/unpack.rkt b/unpack.rkt
index 30c87a9..3806548 100644
--- a/unpack.rkt
+++ b/unpack.rkt
@@ -81,7 +81,7 @@
[else (error "Unkn
When I change the return type of `unpack` to `Packable` instead of an
explicit union of types the map packing test (`test/pack/map.rkt`) hangs.
https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/unpack.rkt#L83
https://gitlab.com/HiPhish/MsgPack.rkt/blob/master/test/pack/map.rkt
--
You received t
Ok, looking more at the commit, I think this is not actually a bug
anywhere, but really an unfortunate combination of things that I don't
have an idea for improving at the moment. Sorry for not realizing that
earlier.
First, I think you should just go back to using `Any` in the type for
`pack` and
Anything more I can do?
On Sunday, December 3, 2017 at 6:11:42 PM UTC+1, Sam Tobin-Hochstadt wrote:
>
> Thanks, that's very helpful. It's clear that the contract optimization is
> working in the old code but not the new code, and we need to fix that.
>
--
You received this message because you ar
Thanks, that's very helpful. It's clear that the contract optimization is
working in the old code but not the new code, and we need to fix that.
Sam
On Dec 3, 2017 12:07 PM, "HiPhish" wrote:
> Here is what happens when I run one of the array tests with the more
> restrictive type specifications
Here is what happens when I run one of the array tests with the more
restrictive type specifications:
OK, passed 100 tests.
Running time is 70.75% contracts
75/106 ms
(-> (recursive-contract (or/c (and/c hash? (and/c hash-equal ... 75 ms
(lib msgpack/pack.rkt):24:9
Running the contract profiler [1] on your code would be quite helpful.
[1] https://docs.racket-lang.org/contract-profile/index.html
Sam
On Sun, Dec 3, 2017 at 9:29 AM, HiPhish wrote:
> Is there anything I can do to help investigate the issue? I have reverted my
> commit for the time being, and
Is there anything I can do to help investigate the issue? I have reverted
my commit for the time being, and it's a difference like day and night.
On Sunday, December 3, 2017 at 12:36:16 AM UTC+1, Sam Tobin-Hochstadt wrote:
>
> I don't think the mutable/immutable issue should be as significant as
I don't think the mutable/immutable issue should be as significant as it
seems here. Using the Any type shouldn't perform better the way you
describe, so we need to look more at what the actual contracts are doing.
Sam
On Dec 2, 2017 6:24 PM, "HiPhish" wrote:
> Now that I think about it, changi
Now that I think about it, changing the types to be immutable is not really
correct either. There is no reason users should not be able to serialise a
mutable list, vector or hash table, just as they can serialise any mutable
scalar as well.
The result of unpacking bytes could be immutable, but wo
11 matches
Mail list logo