Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jamal CHAQOURI
    @redarqas_twitter
    Thank you @lihaoyi that will do the job :)
    Antoine Doeraene
    @sherpal

    When I spawn a subprocess which is a python script containing this:

    import time
    
    for j in range(5):
      time.sleep(1)
      print(f"completion: {j * 20}")

    how can I make a "callback" run when the print actually occurs? All my attempts currently sum up to either see things printed in real time (when I use os.Inherit as stdout), but without being able to access it, or only receiving all the prints at once at the end (using stdout = Pipe)

    Li Haoyi
    @lihaoyi
    stdout = os.ProcessOutput.ReadLines
    or something like that
    Antoine Doeraene
    @sherpal
    Hum I tried that, but it's the sampe. Like os.ProcessOutput.Readlines(s => println("hello " ++ s)) but everything gets printed at once at the end. Quite weird
    Antoine Doeraene
    @sherpal
    I'll try to come up with a minimal example
    Li Haoyi
    @lihaoyi
    @sherpal you may need to start your python script with the -u flag
    Antoine Doeraene
    @sherpal
    ah indeed
    I was just about to come copy paste an example
    and indeed adding -u fixed it. Thank you very much!
    (I'm heading to read docs about this -u flag :p )
    Rohan Sircar
    @rohan-sircar
    Is it safe to use os.Path as the key of a hashmap?
    Li Haoyi
    @lihaoyi
    yes
    Rohan Sircar
    @rohan-sircar
    Nice, thanks!
    Tobias Roeser
    @lefou
    Can you please push the latest release tags to github
    Tobias Roeser
    @lefou
    I created a GitHub Actions setup for CI, as Travis always comes to late to the pary. But some tests fail on ubuntu. They also fail on my machine.
    3 targets failed
    os.jvm[2.12.13].test.test test.os.SpawningSubprocessesTests test.os.SpawningSubprocessesTests.proc.call.0 and 1 more
    os.jvm[2.13.4].test.test test.os.SpawningSubprocessesTests test.os.SpawningSubprocessesTests.proc.call.0 and 1 more
    os.jvm[3.0.0-M3].test.test test.os.SpawningSubprocessesTests test.os.SpawningSubprocessesTests.proc.call.0 and 1 more
    Any idea?
    Li Haoyi
    @lihaoyi
    not sure, passes on my macbook (2015 macbook with OS-X 10.14.3)
    Tobias Roeser
    @lefou
    Ah, it could be related to the env locale
    Tobias Roeser
    @lefou
    val sub = os.proc("python", "-u", "-c", "while True: print(eval(raw_input()))")
    This fails on my machine
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    NameError: name 'raw_input' is not defined
    python --version
    Python 3.9.0
    Looks like it only works for python 2
    python2.7 -u -c "while True: print(eval(raw_input()))"
    1+2
    3
    raw_input was renamed to input in Python 3
    Li Haoyi
    @lihaoyi
    ahhh python versions
    Tobias Roeser
    @lefou
    Your system is too old :-D
    Li Haoyi
    @lihaoyi
    hah
    I've been clicking "remind me tomorrow" on the update popup for the past three years now
    Tobias Roeser
    @lefou
    Python 3.0 migration isn't as smooth as Scala 3.0
    I tried to improve the test and CI situation. There is now a GitHub Actions setup, that should be as good as the Travis-CI and AppVeyor setups. IMHO, we can disable these latter two. Still some tests are failing, also on macos
    Li Haoyi
    @lihaoyi
    sounds good
    Tobias Roeser
    @lefou
    With lihaoyi/os-lib#57 we could also derive the publishVersion from the git tag
    Same as mill does
    Li Haoyi
    @lihaoyi
    let me know if you want me to go into the UI to clicky clicky anything
    Tobias Roeser
    @lefou
    If you, @lihaoyi, would enable publishing from Github Actions, we could automate that.
    Would also fix the missing git tags issue in the future
    Disabling travis looks easy, just deleting the file, but AppVeyor is more resistant.
    Anton Sviridov
    @keynmol

    Is there a known issue with things like os.write on Scala Native? I get segmentation fault on something as simple as

    object Main {
      def main(args: Array[String]): Unit = {
        val folder = os.temp.dir()
        val file = folder / "test"
    
        println(s"writing file $file")
        os.write(file, "hello") // works
    
       // never actually gets to those due to segfault
        println(s"overwriting file $file")
        os.write.over(file, "howdy")
    
        println(s"removing file $file")
        os.remove.all(file)
      }
    }

    Reading seems to work. If this doesn't look familiar, I can try and create a reproducible on github actions (example above I put in scala-native g8 template)

    Li Haoyi
    @lihaoyi
    I'm not aware of any issues, but then again nobody has really started exercising the library heavily on scala-native yet
    other than OS-Lib's own test suite
    sjsonnet uses it quite heavily but only for reading
    Tobias Roeser
    @lefou
    According to lihaoyi/os-lib#36 GraalVM native compilation seems to evaluate vals too early (at compile time). feels like GraalVMs fault. Do you know if scala native is more sane in that regard?
    In that case, the val pwd was always incorrect
    Anton Sviridov
    @keynmol

    @lihaoyi yep, reading works great (along with upickle, CLI zero startup time is awesome).

    I'have a repro, will add GA config to demonstrate failure

    Anton Sviridov
    @keynmol

    yep, seems like I can reproduce it on CI: https://github.com/keynmol/test-os-lib-scala-native/runs/1801082808#step:6:8

    Unless there's something stupid I'm doing, I'm going to create an issue

    Anton Sviridov
    @keynmol

    here it is: lihaoyi/os-lib#59

    Need to figure out how to read gdb's output again, after many years :D

    Li Haoyi
    @lihaoyi
    @lefou yeah, though that's Graal's fault not ours. They're meant to be able to distinguish pure computations and side effects, and are meant to keep behavior unchanged apart from the speedup
    @keynmol can you open a corresponding ticket in the scala-native repo? The OS-Lib code is unchanged from the JVM, and Scala-Native's job is to run it the same way as Scala-JVM, so if it fails on Native and passes on JVM it's Scala-Native's fault here
    Anton Sviridov
    @keynmol
    :+1: makes sense
    Tobias Roeser
    @lefou
    @lihaoyi Sorry about nagging on that git tag issue again. But commit history isn't really clear which commit resulted in binary releases. lihaoyi/os-lib#56
    Rohan Sircar
    @rohan-sircar
    The scaladex page isn't working, or is it just me? https://index.scala-lang.org/com-lihaoyi/os-lib