search

firephil / lotrepls

Automatically exported from code.google.com/p/lotrepls
Other
0 stars 0 forks source link

Scala's state is not serializable #4

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Scala's state is not serializable.  Need to investigate further.

Original issue reported on code.google.com by jamesr+legacy@google.com on 7 Apr 2009 at 12:41

GoogleCodeExporter commented 9 years ago 
Hi!

Do not understand why do you need to serialize Scala's state.

You have history so you can just apply all chunk from begining for every 
request + 
add something like "/clear_state" to allow to start new sequence of commands.

Regards, Alexander Pavlov

Original comment by alexande...@gmail.com on 23 Apr 2009 at 9:08

GoogleCodeExporter commented 9 years ago 
@alexander

Wouldn't that reprint everything on the screen again?

> println("hello")
hello

> println("world")

hello
world

Original comment by harshad...@gmail.com on 23 Apr 2009 at 6:34

GoogleCodeExporter commented 9 years ago 
The other issue with replay, besides the user-visible side effects, is that a 
previous statement may take a really 
long time to run and there's a limit to how long a request can run.  The ideal 
solution is to replay the minimal 
amount of statements to bring all state back up to where it was when the last 
statement finishes, which boils 
down to exactly the same thing as serializing the runtime's state.

On the flip side, implementing replay would be very easy since the per-language 
history is already stored on the 
client - I'd encourage interested parties to try it out and see how it works.  
Start by looking at: 
http://code.google.com/p/lotrepls/source/browse/trunk/src/com/google/lotrepls/cl
ient/CommandHistory.java

Original comment by jamesr+legacy@google.com on 23 Apr 2009 at 7:49

GoogleCodeExporter commented 9 years ago 
@harshad.rj
> Wouldn't that reprint everything on the screen again?

@jamesr@google.com
> The ideal solution is to replay the minimal 
amount of statements to bring all state back up to where it was

Sure. But suggested behaviour is better than nothing :)))

Also, in most cases big size scripts are just about declaring various classes/
objects/functions so I do not expect a lot of side effects.

If you doubt about performance/side effect you can just made these controllable 
by 
user, e.g. introduce commands /begin_file "script-name" and /end_file. Later, 
user 
can refer to these via /use_file "script-name".

For example:

Scala >>>/begin_file "permutations" [CTRL+ENTER]

Scala:permutations>>>def permutations[T](list:List[T]):List[List[T]] = list 
match {
    case List() => List()
    case List(a) => List(List(a))
    case _ => list.flatMap(item => permutations(list.filter(_ != item)).map
(permutation => item :: permutation))
}[CTRL+ENTER]

Scala:permutations>>>/end_file[CTRL+ENTER]

Scala:>>>/use_file "permutations"
println(permutations(List(1,2,3,4)).mkString("\n"))
[CTRL+ENTER]

Original comment by alexande...@gmail.com on 24 Apr 2009 at 7:00

GoogleCodeExporter commented 9 years ago 
Just to clarify - in "file mode" server should not execute code, just collect 
(and 
may be compile???), so execution will be really performed just one time, when 
you 
refer to file via /use_file

Original comment by alexande...@gmail.com on 24 Apr 2009 at 7:06