ran up against the fact that, IMHO, any version of code which would pass review would require Java default methods in traits. Those are implemented in Scala 2.12 JVM but not in SN. Scalatest was pending, but not released, for SN then. Scalatest might be
It looked to me like some SN code would be needed to access the Olson time files directly, where available (in libmumble.so). From
a "not having done a trial implementation" view from afar, it looked like a Small Matter of Programming.
As I noted in the Issue, these days the issue is on the back burner for me.
@ekrich I had also put a considerable amount of sandbox work into providing some of the chunks understandably missing from
scala-js: Clock.scala and, especially, clocks than can be set for testing.
Folks of good will can read the same evidence and come up with differing conclusions. When I stepped back to see how I could
avoid duplicating and triplicating work, it looked to me that the least effort solution was to port cquiroz's scala-java-time. Clock.scala, etc. were a factor but the large body of well exercised testing code was the deciding factor.
Not to encourage fragmentation, but I think a third party (or cousin) solution is necessary/wise to deal with the thin/comprehensive
or light/heavy code weight discussion. Time handling has lots of corner case. The difference between minimal-acceptable and
comprehensive is huge, and most people only need/want minimally acceptable. IMHO, time support should be designed
with a first consideration to its own needs with a strong second consideration of how locale is handles. Agreed that locale
is over-the-horizon, but it is huge enough we can hear it slouching towards us, even on the far side of the hill.
I do not remember running into any Java 6 or Java 7 issues in any of my scala-java-time sandbox work. Perhaps I did not get to the point of triggering them. What did block me was the need for default methods in traits, which is a scala version issue.
To try to advance the Native time discussion beyond putting one's dollar/euro on red or black:
1) @ekrich Do you know if scala-js handles java default method implementations in traits? We may not need them but it is nice
to know where the edge of the world is.
2) If, for various reasons, a comprehensive solution is in the out years, what do you see, at a first cut, that we need for a
near term (over the next year or so) solution. I offer that we need/could_use Clock.scala support. A second want, for
SN at least, would be some minimal 24 hour timezone support, even if only UTC+N (or UTC-N). An SN addon might
be able to tie into existing Olson timezone file, if present (yeah, the location of those file on various operating systems
is a mess.
3) What are your thoughts about a possible light/heavy plan, where the heavy is a hypothetical comprehensive third
party solution? Do other people have thoughts or need a better explication of the problem? Basically, I am suggesting
that a well defined set of simple things should be "batteries included" and complicated things be in code which can be
added in by devos who need them. Relatively easy to describe at that level, hard to define a minimal-set. Discussion
has to start somewhere.
I'm able to reproduce the failure in #1653 . First question
stream.mark(Int.MaxValue) The implementation has this logic:
if (buf.size < readLimit) buf = new Array[Byte](readLimit)
Correct me if I'm wrong: That would attempt to allocate an
stream.mark(32768)Which is an arbitrary size less than max heap. Then the test passes for all GCs.
BufferedInputStream's handling of mark. The difference in GCs would then be differences in overcommit behavior?
BufferedInputStreamin scala-js. this looks to be equivalent code to scala-js's BufferedReader: https://github.com/scala-js/scala-js/blob/master/javalib/src/main/scala/java/io/BufferedReader.scala#L38
newlengthis only increased by 2x the current buffer length. Not immediately set to marklimit.
BufferedInputStreamto have similar logic. Adding some tests first, of course.