or by building a chain of classes with
apply functions returning the next class
@ochrons Thanks again :)
To give a bit of context, my environment is very similar to DIODE, but I have a hard requirement on being able to serialize actions. The idea is to have actions defined as
I guess that I could make this work with a macro, which generates a serialisation method and adds it to the
def (a: Int, b: String) = Action { state => state.copy(foo = a, bar = b) }.I guess that I could make this work with a macro, which generates a serialisation method and adds it to the
Action object.
since it's just a bunch of case classes
- Do we consider scala.js 1.0.0 stable enough to push a boopickle release for it?
Hi! Is there a clever way to find out which types are automatically derived the most times (ie duplications that would benefit from explicitly creating the pickler in a central place so that its macro is generated only once). Because I am using sloth for client-server communications I need to use auto-derivation as the sloth macros generate case classes that I could otherwise not serialize.
Unpickle does not take type parameters
How else do we use it ?
For example Vector(Point(1,2), Point(3,4), Point(5,6)) serializes into Array(3, 0, 1, 2, 0, 3, 4, 0, 5, 6)
but why is that ?
how can i fix it?
Struggled to find a way to pickle bytes running throuch a WebSocket in a Play Scala-js project and finally got it working. While I was at it I made my whole autowiring setup more generic so that I only have to configure the moving parts when adding a new api for instance.
Having a generic interface also allows to avoid messing around with websocket callbacks and instead use the exact same api as we do when using ajax:
// autowire websocket wire handle
object fooWireWS extends AutowireWebSocket[FooApi]("foo")
// Make type-safe api calls throuch websocket...
fooWireWS().incr(curNumber).call().foreach { n =>
println("got an incremented number from the server via WebSocket: " + n)
}Long story short - made a minimal sample project with all generic autowire plumbing separated out into a few generic util classes. Pretty neat me thinks. Hope this will be useful for others. Let me know if you have any comments or suggestions for improvements.
PS: You'll also find an ajax vs websocket performance test, yay...
@strelec I tried to do an update to 1.0.0, but ran into some issues with UintArray8 and IntArray8 tbje/boopickle@f9aaf12
like you can encode a
List[Int] and decode it as Vector[Int] no problem
or have a case class with differently named members, but of the same type
Have been working on updating Lihaoyi's autowire lib to version 0.3.2 with @mathieuleclaire (see PR). The suzaku-io/boopickle#126 would allow us to have the boopickle test working with both Scala 2.12 and 2.13. So, anytime you publish a 1.3.3, @ochrons, we'll publish autowire 0.3.3 with a working boopickle example...
guys, i am in a bit of a pickle here (no pun intended). i am getting java.nio.BufferOverflowException when i do Pickle.intoBytes() in scalajs. the weird thing is that for the first 4 calls, there were no trouble, it's not until the 5th call to intoBytes() would the exception get thrown. i know there are pooling stuff going on in the BufferProvider but from the outside, the intoBytes() call should be pure. so the BufferOverflowException really puzzles me.
I think
@cquiroz if you want to create a PR to use tag as version instead of manual override (like you did in Diode), that would be great :)
Hello, i'm sending serialized entities from backend as a stream one by one and not as Seq of entities, so on reception only the first one gets deserialized (unpickled), maybe there is a way to continue consuming next entity until there is nothing left in the ByteBuffer? Or maybe it is possible to inject separators on the fly and once all data is received deserialize it as a Seq of entities?
