Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 25 19:53
    LeeTibbert commented #1972
  • Oct 25 19:46
    LeeTibbert commented #1974
  • Oct 25 17:32
    Sciss commented #1571
  • Oct 25 17:30
    shadaj commented #1571
  • Oct 25 15:26
    Sciss commented #1571
  • Oct 25 15:25
    Sciss commented #1571
  • Oct 24 17:22
    ekrich commented #1974
  • Oct 24 13:40
    LeeTibbert edited #1974
  • Oct 24 13:39
    LeeTibbert commented #1974
  • Oct 24 04:25
    sjrd commented #1972
  • Oct 24 04:21
    ekrich commented #1974
  • Oct 24 03:13
    ekrich synchronize #1970
  • Oct 24 02:51
    ekrich commented #1970
  • Oct 24 01:20
    ekrich commented #1974
  • Oct 24 00:46
    LeeTibbert commented #1974
  • Oct 24 00:45
    LeeTibbert commented #1974
  • Oct 24 00:23
    ekrich commented #1974
  • Oct 24 00:22
    hepin1989 commented #1974
  • Oct 24 00:19
    LeeTibbert commented #1974
  • Oct 24 00:10
    LeeTibbert commented #1974
Eric K Richardson
@ekrich
Cool, glad you figured it out.
Eric K Richardson
@ekrich
Good news, NIO JUnit PR is in - scala-native/scala-native#1970 - yeah!
Last of the Java library.
kerr
@hepin1989
Cool
in scala-native, the javalib is not splited into javalanglib and javalib as it's in scala-js
Eric K Richardson
@ekrich
Not sure why Scala.js is like that. If someone decides to tackle Windows support then at least the IO and Net portions would have to be split off.
S├ębastien Doeraene
@sjrd
The javalanglib of Scala.js is subject to a very strict check that the .sjsir do not reference anything outside the java.* namespace (i.e., nothing from the Scala lib or the Scala.js lib). Eventually I'd like to get that check to apply to javalib as well, but we're not there yet.
Eric K Richardson
@ekrich
Thanks for explaining - that is a good goal. Dependencies are a big deal.
Eric K Richardson
@ekrich
Have we overrun our Travis CI quota so we are severely throttled back?
S├ębastien Doeraene
@sjrd
I don't know. It does feel extremely slow today.
Eric K Richardson
@ekrich
I looks like maybe one build finished since last night.
Eric K Richardson
@ekrich
Looks like we should do some CI on macOS - the changes to JUnit seem to have hidden the presumed GC bug - https://www.traviscistatus.com/
No Backlog for macOS.
Kirill A. Korinsky
@catap
JFI: I do have mac mini that is just running and that I'm using to some tests. I can run CI job for SN on this machine if it is possibly to do as simple as just run some jar
I can't promise that it will be unused forever, but it is just working for last couple of months and do nothing
Eric K Richardson
@ekrich
I just meant, we used to run half Linux and half macOS CI on Travis but we dropped it because it was flaky. I have been having the tests complete regularly now that the JUnit is in so maybe macOS would complete now. There is no backlog for macOS jobs.
Did you see my comment on your PR?
Eric K Richardson
@ekrich
@sjrd Are these suppose to be in version control? junit-test/outputs/scala/scalanative/junit/IgnoreAllTestAssertions_.txt
cc/ @WojciechMazur
Kirill A. Korinsky
@catap
@ekrich nope, thanks
I'll fix it right now
Kirill A. Korinsky
@catap

Ok, rebased corectly to last master. I also made trivial changes: scala-native/scala-native#1971

:)

Eric K Richardson
@ekrich
There was already this one approved - scala-native/scala-native#1967
Ok, the other PR seems correct now. Do you mind if I kill the latest job? @catap
Kirill A. Korinsky
@catap
kill?
ah
you mean at CI
not at all!
Eric K Richardson
@ekrich
Yes, that is what I mean.
Thanks, CI is taking forever so we don't want any extra.
Also, thanks for holding off on that fix so I could get the bulk changes in for JUnit.
Wojciech Mazur
@WojciechMazur
@ekrich I think it should, however this file was created before I've discovered JUnit outputs recording. If this file content is empty it can be removed I guess
Eric K Richardson
@ekrich
It all got checked in to master.
Eric K Richardson
@ekrich
@WojciechMazur Look at this commit - scala-native/scala-native@c375b43
Eric K Richardson
@ekrich
@WojciechMazur Would it be okay to remove the scala.junit.JUnitExampleTest in my next PR? We have quite a few examples now :smile:
LeeTibbert
@LeeTibbert
RIP JUnitExampleTest. @WojciechMazur just so that you know that the effort was appreciated, I used that file as a basis for my PR #1947 Convert unsafe.CStringSuite.scala to JUnit unsafe.CStringTest.scala. Thank you, it saved me days.
@ekrich No problem is your work obviates that PR. I do not want to slow down or complicate your work. I can review the changes I intended after your work settles down.
Eric K Richardson
@ekrich
No worries, I'll keep that one in mind to do that area last. Also, I don't know if you saw the conversation but I was planning to go through the Scala.js code base maybe Java lib first and toggle case the methods. This way if they are ported to Scala Native they will have the same style.
The TreeMap is holding you back?
LeeTibbert
@LeeTibbert

re: The TreeMap is holding you back? The TreeMap work was in support of scala-java-time, particularly their ScalaTest code. I believe that @catap found a way to get those working without TreeMap. TreeMap was used in the sjt Java code. The sjs platform used other code, marked as inefficient. So, my javalib TreeMap work fell to the back of the pack. Not forgotten, not deleted, but distant. I know of no javalib TreeMap in public Scala.js or Scala Native repositories. SN does have the Scala TreeMap, but that has different methods, etc.

Short story, thank you for checking but you are not blocking me.

Yes, I think regularizing the names, in one or two swoops, is worth the effort. Let me know where you want me to stay out of or to rebase existing work. You have the baton (in the relay sense, not in the paramilitary sense).
Eric K Richardson
@ekrich
Just try and get the test you have in because the rest of tests is pretty big. I will get the Scala.js going so when we share tests the style will be the same.
Kirill A. Korinsky
@catap
@LeeTibbert I'm oveloaded this days and if you can put a bit context I probably can remember :)
LeeTibbert
@LeeTibbert
@ekrich Sorry if I did not describe things well. No need for a TreeMapTest because there is, to the best of my knowledge , not javalib TreeMap.scala in the wild with which to test. Not Scala Native, not Scala.js. There is a TreeSet, I believe in both.
I was working to provide TreeMap.scala, which is harder than it looks, what with mutable views. Perhaps someone else got to the finish line before me? I could find nothing like that in my searches.
@catap: I understand overloaded... I believe it was you who got the ScalaTests for scala-java-time up and running. I have
Does that sound familiar or am I conflating/confusing things?
Kirill A. Korinsky
@catap
yes, I remmeber :) it was soo long ago. From emotional point of view but by calendar I see that in this month
LeeTibbert
@LeeTibbert
OK, stress & overwork have not totally destroyed my memory. I was telling @ekrich that I thought that you had been
LeeTibbert
@LeeTibbert

able to accomplish the scala-java-time tests without having to implement TreeMap.scala. Good for you!

On my first reconnaissance run at sjt testing, I copied over the sjt code for scala.js, but that code had warnings in it about its
inefficiency. I believe that the sjt JVM branch used TreeMap.scala. So, I took a run at implementing TreeMap.scala,
with the idea of ScalaNative then Scala.js. Dreams! I got pretty far before I fell into my current pit of recursive interruptions. I see why scala-java-time js went with a partial simple implementation, suitable to need.

So all of this is to say that TreeMap.scala does not, to the best of my knowledge, exist yet. (Add to say "Well done!" )

"Does not exist yet" meaning both "javalib" and "outside of my machine".