Nondeterministic errors when instantiating class with Char constructor parameter

93 views
Skip to first unread message

Jakub Liska

unread,
Oct 7, 2014, 12:45:01 PM10/7/14
to scal...@googlegroups.com
Hey, 

when I was running uTests, there was like 50/50 chance that this code failed on runtime error and I had to do sbt clean to make it work again :

TypeError: undefined is not an object (evaluating 'ScalaJS.c.Lcom_whatever_CharOp.prototype.init___I.call')

which is the moment of CharOp case class new instantiation with Character parameter. If I use Integers instead of Characters, it's OK

trait PressEvent {
 
def char: Char
}
case class CharOp(char: Char) extends PressEvent


object OpImplicits {
 
implicit def ToInputOp(char: Char): Op = {
   
char match {
     
case 'a'  => CharOp(char)
     
case 'b'  => CharOp(char)
     
case 'c'  => CharOp(char)
     
case x => throw new IllegalArgumentException("Please do not use : " + x)
   
}
 
}
 
implicit def ToInputOps(str: String): Iterable[Op] = str.toCharArray.filterNot(_ == '|').map(ToInputOp)
}

Unfortunately I didn't manage to make a test case that would catch this error, it was just working no matter what I tried when I tried to reproduce it. So I used integers instead. 

Now I tried to use Chars again in another case class via fastOptJS the first time the class is instantiated it throws TypeError: undefined is not a function without any further information in Chrome and weird thing is that the second time the class is instantiated it works without any errors... Any idea what it might be ? Sorry that I can't retrieve any more stackTrace, it's just not there.

using scalaJS 0.5.5

Sébastien Doeraene

unread,
Oct 7, 2014, 3:33:00 PM10/7/14
to Jakub Liska, scal...@googlegroups.com
Hi,

Can you report that as an issue on GitHub, please?

Cheers,
Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/821e0da4-6a74-4e10-b32a-b925ebba640e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jakub Liska

unread,
Oct 7, 2014, 7:41:42 PM10/7/14
to scal...@googlegroups.com, liska...@gmail.com
It was caused by initialization of another field of that class, it was just a bit "invisible" in the stacktrace. Sorry for a futile message.

Btw, regarding those Chars, I've noticed a strange javascript thing :

On keypress events, KeyboardEvent::keyCode is deprecated and always 0 value in firefox v.26.0 as well as KeyboardEvent::key is empty in firefox, leaving you with charCode that has no binding in scala-js-dom. charCode seems to be the only way to get an ascii code (unicode value) for a printable keypress character in all browsers... But it has been deprecated too.

From what I read one should use html5 input but that gives you only the entire value of the input field, not just a newly added character, which is ridiculously useless for tons of use cases.

It's like a joke, do you see into this Sébastien?

Jakub Liska

unread,
Oct 8, 2014, 2:53:48 AM10/8/14
to scal...@googlegroups.com, liska...@gmail.com
Got it, keypress is to be deprecated entirely and one should be using beforeinput. Everything is described here in the w3.org keypress documentation.

Jakub Liska

unread,
Oct 8, 2014, 3:45:25 AM10/8/14
to scal...@googlegroups.com, liska...@gmail.com
I suggest adding KeyboardEvent::charCode to scala-js-dom, otherwise keypress is useless for getting char unicode value if you want to support Firefox.

beforeinput event is a sound of future, see :

Sébastien Doeraene

unread,
Oct 8, 2014, 3:47:51 AM10/8/14
to Jakub Liska, scal...@googlegroups.com
Feel free to send a PR to scalajs-dom :-)
Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.

Jakub Liska

unread,
Oct 8, 2014, 4:34:01 AM10/8/14
to scal...@googlegroups.com, liska...@gmail.com
Done, it's quite horrifying to see what if-else crap you should do to keep KeyboardEvents cross-browser compatible...

Jakub Liska

unread,
Oct 8, 2014, 11:15:37 AM10/8/14
to scal...@googlegroups.com, liska...@gmail.com
Sébastien I'd like to add some KeyCodes to scala-js-dom what do you think would be better, the actual val names or the names commented  out :

  val numpad_* = 106 // multiply
  val numpad_
+ = 107 // add
  val numpad_
- = 109 // subtract
  val numpad_
/ = 111 // divide


  val
`;` = 186 // semicolon
  val
`=` = 187 // equals
  val
`,` = 188 // comma
  val
`-` = 189 // dash
  val
`.` = 190 // period
  val
`/` = 191 // slash
  val tilde
= 192
  val
`[` = 219  // open square bracket
  val backslash
= 220
  val
`]` = 221 // close square bracket
  val
`'` = 222 // single quote


tilde and backslash cannot be tilded out.  

Sébastien Doeraene

unread,
Oct 8, 2014, 11:28:26 AM10/8/14
to Jakub Liska, scal...@googlegroups.com
Hi,

I personally prefer the alphabetic names. Since they're constants, they should have uppercases at the beginning of words. For example Multiply and OpenSquareBracket.

Also, either use ??? for the actual codes (js.native in 0.6) or make them 'final val's if they are truly constant (spec'd, i.e., the same on all browsers). final vals can be constant-folded by scalac.

Sébastien

--
You received this message because you are subscribed to the Google Groups "Scala.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-js+u...@googlegroups.com.

Jakub Liska

unread,
Oct 8, 2014, 12:07:32 PM10/8/14
to scal...@googlegroups.com, liska...@gmail.com
I personally prefer the alphabetic names

Me too

Since they're constants, they should have uppercases at the beginning of words

The current scala-js-dom convention is just a value starting with lowercase. I'd keep it that way since everybody depends on it. 

either use ??? for the actual codes (js.native in 0.6)

Afaik there are actually no bindings for native constants in scala-js-dom defined except for the non-native KeyCode object constants, do you think that scala-js-dom would need KeyEvent object binding with all those constants available natively? I don't know what support do browsers have for KeyEvent (i.e. stackoverflow answer). If the native KeyEvent object is not available, there'd still have to be a fallback object with all those constants declared in scala-js-dom.

For instance closure and dart have their own constants and do not rely on the native ones.

final vals can be constant-folded by scalac.

Yes, I can make them all final in the KeyCode object 

Jakub Liska

unread,
Oct 9, 2014, 3:25:51 PM10/9/14
to scal...@googlegroups.com, liska...@gmail.com
I made a polyfill scala-js-dom extension based on the Dart lang implementation. I'm gonna have to test it and improve it for some time cause it turned out to be quite a challenge. Anyway, it seems to be a right step to make scala-js possible to use for something that requires extensive usage of Keyboard events and it wants to be cross browser compatible. Unfortunately it won't go under 500 LOC, we'll see.

The rough version. I was trying to preserve the Dart stuff regarding polyfilling cause they certainly got it well tested...
Reply all
Reply to author
Forward
0 new messages