with
addTransform that is not needed IIRC
so often you don't need to specify the types manually, like in the example
implicit val datePickler = transformPickler((t: Long) => new java.util.Date(t))(_.getTime)
One more thing...
Can I serialize partially applied functions?
Can I serialize partially applied functions?
case class FooModel(number: Int, text: String)
def setNumber(to: Int)(state: FooModel): FooModel =
state.copy(number = to)
val foo = setNumber(5) // is it possible to serialize this ?
but in reality, probably not
because your pickler has no way of figuring out what arguments have already been supplied
you would have to describe the arguments some other way, like with a case class
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.