Lazy sequences break cursors

[AshtonKem]

I know this has been mentioned in another issue, but this really tripped me up.

Any call to update! that returns a lazy sequence doesn't result in a sane cursor. This means that the first update works, but the second fails because you can't transact! a plain old fashioned list. The solution is to call vec inside of update!, which isn't a huge deal but it is confusing for new users.

[GetContented]

Seems like a good candidate for a FAQ, or the troubleshooting section at https://github.com/swannodette/om/wiki/Troubleshooting

[AshtonKem]

That would be a good secondary choice. Ideally it should handle them
just as well as it handles vectors, perhaps by forcing them to be
non-lazy somehow or by working the same magic on lazy sequences that
currently works on vectors.

On 09/29/2014 08:05 PM, JulianLeviston wrote:

Seems like a good candidate for a FAQ, or the troubleshooting section at https://github.com/swannodette/om/wiki/Troubleshooting

---

Reply to this email directly or view it on GitHub:
#246 (comment)

Ashton

[GetContented]

@AshtonKem is this the case for transact! too? Oh, of course not. Silly me ;-) The render-time access often confuses me.

[AshtonKem]

Apologies, I got my functions mixed up. I originally meant transact!,
but a quick test shows that update! has the exact same behavior.

On 09/29/2014 08:23 PM, JulianLeviston wrote:

@AshtonKem is this the case for transact! too?

---

Reply to this email directly or view it on GitHub:
#246 (comment)

Ashton

[GetContented]

I'm a little confused... why are you using the return value of transact! or update! ?

Shouldn't you use the original cursor?

[GetContented]

... or do you mean you shouldn't add a lazy sequence into an atom using transact or update?

[swannodette]

Not going to fix this, the documentation is very clear that everything in the app state must be an associative data structure.