Back to Questions
1.1k
views5
comments
ListModel.DocSeqCached
websharperui.nextfeature request

Here is a (low priority) feature request:

Add

1
2

    [Extension; Inline>]
    static member DocSeqCached(lm:ListModel<_,_>, conv) = lm.View |> Doc.BindSeqCachedBy lm.Key conv

to DocExtensions.

So that I can use

1

let doc = listModel.DocSeqCached conv

instead of

1

let doc = listModel.View |> Doc.BindSeqCachedBy listModel.Key  conv

(Just so that others may not run into the same trap: Given the intention of ListModel, I did not think about the need of keying, used Doc.BindSeqCached, and ended up with a stack overflow in the ListModel state Dictionary hashing of my complex objects.)

(Maybe you have reasons to limit DocExtensions to extensions of Doc, Elt and View. Then please discard this request.)

.

I have pretty much exactly this sitting on a branch somewhere, as well as a version that passes an IRef<'T> to the function. I'll look into resurrecting that.

By on 10/7/2017 3:30 PM ()

(Hi Martin! Feel free to submit PRs to https://github.com/intellifactory/websharper.ui.next)

Can you elaborate on the stack overflow issue, would you have a small repro for it by any chance?

By on 10/7/2017 7:33 AM ()

I have created a pull request for DocExtensions.

Here is some more information regarding the stack overflow: The stack call depth is 291 when Chrome runs out of space. The last 200 calls are recurring triples of

1
2
3

Unchecked.hashObject @ Unchecked.fs:169
Unchecked.Hash @ Unchecked.fs:182
(anonymous) @ Unchecked.fs:168

I cannot trace this back to my own code, the problem starts with

1
2
3
4
5
6
7
8

Unchecked.Hash @ Unchecked.fs:182
(anonymous) @ Unchecked.fs:168
Unchecked.hashObject @ Unchecked.fs:169
setTimeout (async)
tick @ Concurrency.fs:90
(anonymous) @ Concurrency.fs:98
setTimeout (async)
Fork @ Concurrency.fs:97

I suspect the following happens: I have a ListModel<int,(ComplexType*int)>. When I forgot the key function, ListModel searched the list of the previous state by taking the whole (ComplexType*int) as key. The underlying Dictionary hashes the complex object recursively. It seems the tail calls are not optimized away in the above methods. So especially with Lists in the ComplexType you generate many calls.

To be honest, ComplexType is not that complex, and the longest list has length 9. So the above does not completely explain the case. I don't understand the asynchronous workflow well enough to debug it efficiently, so I have not found the point where my ListModel is actually accessed.

Let me know if the above is helpful, else I will try to create a repro.

By on 10/8/2017 6:34 AM ()

Yes this is definitely caused by ListModel recursively hashing the values. Recursive hashing can also potentially lead to a stack overflow on .NET (just try hash [1..100000] in fsi), but it should only happen with very deep structures. Maybe your ComplexType contains recursive self-references? If it does, then I would recommend overriding this.GetHashCode() on ComplexType.

By on 10/9/2017 5:56 AM ()

Thanks. My problem is solved anyway by using the key.

By on 10/9/2017 11:45 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper