I suppose as the organization owner, yes, you are indeed allowed to :P but yeah I have no issues with it, and I kept it like that in the new version
when I first saw the commit I thought you added yourself in and I was like "yes that's fair and you are allowed to do that" and then I realized it was actually you removing it and that made a lot more sense :P
So about the l flag here, if it's not going to modify the Settings object, it should either not be passed in at all, or it should modify the Settings object and the interpreter should use that to decide whether to sbcsify
And for vyPrint, I would prefer us to use printFn so that vyPrintln doesn't have to be aware of what's going on and so we can customize printing for tests (although printFn really should be inside Globals, not Settings, that's my bad). If you do want to go ahead with the current way, then onlineOutput should be inside Globals, so that you don't have to get the top context
Also, over here, when popping off an empty stack in online mode, why turn the default value into a string? Why not just use a normal 0 as a number?
if settings.online then settings.defaultValue
else
val temp = StdIn.readLine()
if temp.nonEmpty then Parser.parseInput(temp)
else settings.defaultValue
We could do ^
Because if the default value is a string, then doing toString and parseInput again would ruin it
@lyxal The JS code passes in a function that does the outputting, the Scala.js code doesn't need to know about the DOM
So I have a webworker:
package pWorker
import scala.scalajs.js._
import org.scalajs.dom._
object WorkScript extends scala.scalajs.js.JSApp
{
def main(): Unit =
{
val x = 4
val y = 8
val z = x + y
println("Worker x + y =" -- z.toString)
}
}
When launched from...
@hyper-neutrino Yes. We'll have to modify the context thingy to keep track of frames or whatever, and the Interpreter.execute method and anything that involves executing function objects will need a bit of special handling, but it's definitely doable
@lyxal Nice work!
That was really quick
@emanresuA They just work differently. You have to convert a js.FunctionX to a FunctionX
This page shows corresponding Scala types for JS types
Oh, i see what you mean
@lyxal Why can't printFunc be taken as a js.Function1[String, Unit] directly?
@lyxal So that's why you've been promoting PLDI so hard :P
@lyxal Thanks, I'll try to do it as soon as possible but if I can't get around to it by Saturday you can just go ahead and merge it
PR looks good to me overall, I just feel like printFunc would be better as a js.Function1 instead of a string
Man, I wish I could try GitHub pages on branches other than version-3 so that I could try out the program stopping
So I have a webworker:
package pWorker
import scala.scalajs.js._
import org.scalajs.dom._
object WorkScript extends scala.scalajs.js.JSApp
{
def main(): Unit =
{
val x = 4
val y = 8
val z = x + y
println("Worker x + y =" -- z.toString)
}
}
When launched from...
