Merged
Merge Request #12 · created by Harshad RJ


Use the fast-dev build of doppio for testing

Types of doppio builds:

  • release: no assertions, no tracing (logging)
  • fast-dev: has assertions, but no tracing
  • dev: has assertions and tracing

I played with the tracing level (logging level). It is very detailed and mostly useful for debugging doppio itself, not for users of doppio.

Hence, I think fast-dev is ideal for us during testing.

@jimsproch I don't know whether it affects your deployment needs. So please review.


From hrjet9:useFastDev into jimsproch:master

Merged by Jim Sproch

2 participants
  • No avatar
    Jim Sproch @jimsproch

    Would a user of JavaPoly ever hit a doppio assertion? Presumably a valid Java program would not hit a doppio assertion (unless there was a bug in doppio, right?). Presumably a user of JavaPoly wouldn't be able to do anything to trigger a doppio assertion?

    My intuition is that the build:browser would want to use 'release', but maybe 'fast-dev' if we think a user would ever hit an assertion while using JavaPoly.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Jim Sproch @jimsproch

    Status changed to merged

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar Jim Sproch @jimsproch
    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • 1419208586 beethoven 512
    Harshad RJ @hrjet9

    Would a user of JavaPoly ever hit a doppio assertion?

    There are two parts to it:

    If JavaPoly exposes doppio officially, then it also exposes JNI functionality, which when used can lead to a doppio assertion to fail.

    If the user only uses JavaPoly (without accessing doppio directly), then as long as there are no bugs in JavaPoly, it shouldn't cause a doppio assertion to fail.

    My intuition is that the build:browser would want to use 'release', but maybe 'fast-dev' if we think a user would ever hit an assertion while using JavaPoly.

    Right now, the build folder doesn't get a copy of doppio. The copy of doppio is only going into test folder, presumably only for testing (and not for deployment).

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    I wonder if the build folder should get a copy of doppio, since it is a necessary artifact that is required in order to deploy JavaPoly. Also browserfs. It is a little annoying to be forced to track down dependencies, rather than just copy-paste the build output onto a webserver. I honestly don't know what is considered best-practice in this situation.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
  • No avatar
    Jim Sproch @jimsproch

    I don't think we will ever expose doppio directly. We want JavaPoly to be a polyfill for native browser support, and exposing the underlying JVM implementation would cause people to rely on that implementation, which would make it more difficult for browser implementors.

    Edit in fullscreen
    Comments are parsed with GitLab Flavored Markdown
    Attach images (JPG, PNG, GIF) by dragging & dropping or selecting them.
jimsproch/JavaPoly!12

Assignee: Jim Sproch

Milestone: none


Votes
0 up
0 down

17 Dec, 2015

1 commit