Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 20:29
    jbayardo edited #2018
  • Jan 31 2019 20:21
    jbayardo opened #2018
  • Jan 31 2019 20:16
    jbayardo commented #1352
  • Jan 31 2019 20:07
    SunderB synchronize #2017
  • Jan 31 2019 19:58
    SunderB synchronize #2017
  • Jan 31 2019 15:32
    JackUnthank starred samaaron/sonic-pi
  • Jan 31 2019 09:17
    oyd11 starred samaaron/sonic-pi
  • Jan 31 2019 06:27
    hidaris starred samaaron/sonic-pi
  • Jan 31 2019 05:23
  • Jan 30 2019 22:05
    lexmortis commented #1956
  • Jan 30 2019 21:54
    lexmortis commented #2012
  • Jan 30 2019 19:23
    lexmortis commented #2013
  • Jan 30 2019 19:00
    SunderB commented #1506
  • Jan 30 2019 18:10

    weblate on master

    Translated using Weblate (Russiā€¦ (compare)

  • Jan 30 2019 17:52
    SunderB commented #218
  • Jan 30 2019 17:46
    rdwebdesign commented #1506
  • Jan 30 2019 16:22
    JackEvans24 starred samaaron/sonic-pi
  • Jan 30 2019 06:25
    bob-the-dyer starred samaaron/sonic-pi
  • Jan 30 2019 03:21
    soasme starred samaaron/sonic-pi
  • Jan 30 2019 03:07
    luikore starred samaaron/sonic-pi
Sam Aaron
@samaaron
Ok
bawNg
@bawNg
It is a very minimal implementation of Ruby, so a huge amount of the lang code base would need to change, and a lot of MRI compatible functionality would need to be reimplemented
Sam Aaron
@samaaron
Sure
In which case it might make more sense to switch to something like Erlang
bawNg
@bawNg
You mean write a ruby interpreter for the DSL in Erlang?
ethancrawford
@ethancrawford
Cheers for the @ @samaaron... some interesting thoughts here! :smile:
bawNg
@bawNg
I think Ruby is fast enough for most things needed, especially when it comes to the DSL. If anything is still too slow after refactoring and reducing overhead, things in the hot path can always be implemented in a C extension
You can get considerable speed improvements by moving Ruby methods into C, it's always faster to call a native method from ruby than a ruby method no matter what, unlike a JIT language like C# where it's slower to call across the native boundary than to stay in managed land
Then again Ruby is getting it's own JIT in the future, so that may eventually change
ethancrawford
@ethancrawford
Hey @bawNg :)
I've been helping Sam on and off for the last few years with a few bug fixes and proof reading the docs etc (nothing as involved as profiling/optimisation though!)
bawNg
@bawNg
Nice to see how active the project is :)
Sam Aaron
@samaaron
:)
ethancrawford
@ethancrawford
It is! personally I'm always keen to do anything that's within my skill level if it helps lighten the load...
Sam Aaron
@samaaron
The issue with stop might be because I keep the thread relationship tree and traverse that to kill all dsl threads
@ethancrawford just thought you might be interested:)
ethancrawford
@ethancrawford
:+1:
bawNg
@bawNg
I found where it's going wrong, it's flaw in my "kill" implementation which I need to think about, pretty sure something in an ensure block somewhere is putting the fiber to sleep after it was meant to be killed, so it doesn't end
That's something that wouldn't happen with native threads since they get killed dead and skip clean up completely
ethancrawford
@ethancrawford
btw @samaaron using Sonic Pi just now I see log messages such as this in the log window - I take it they are expected?
=> removing subthread #<Thread:0x4da67c8>

=> completed removing subthread #<Thread:0x4da67c8>
bawNg
@bawNg
Turns out there was nothing wrong with the implementation, I just forgot to change one last place that used Fiber.yield to Job.yield after I refactored it to Job
Stopping works fine now
bawNg
@bawNg
Next issue that came up was redefining live loops, as a thread was suicidal, so fibered jobs are now able to commit suicide
Sam Aaron
@samaaron
@ethancrawford - which version are you using?
ethancrawford
@ethancrawford
that was the Windows beta 5
Sam Aaron
@samaaron
oh ok
that's not intended :-)
thanks for pointing it out
ethancrawford
@ethancrawford
no worries
Sam Aaron
@samaaron
@bawNg you should also be able to stop live_loops by inserting a call to stop inside them and redefining them
@ethancrawford what code you run to see those messages?
bawNg
@bawNg
There are a lot of things that need to be fixed, I'm surprised it worked so well with the initial changes, but I'll do further testing and continue working on it in between other things
Sam Aaron
@samaaron
:-)
bawNg
@bawNg
55.32 [Job 123] SonicPi::Stop while running job: SonicPi::Stop
That's another thing that needs to be handled
Better to use throw/catch instead of exceptions for anything that isn't an actual error, since the backtrace of exceptions have a lot of overhead and make them very slow
ethancrawford
@ethancrawford
@samaaron it appears to be when running code where a live loop has stop written inside it
Sam Aaron
@samaaron
ah yes, I see it now - thanks!
@ethancrawford fixed - thanks for pointing it out :-)
ethancrawford
@ethancrawford
:+1:
Sam Aaron
@samaaron
what did you think of the new windows installer?
btw, are you a windows user?
or are you just testing in a vm?
ethancrawford
@ethancrawford
I have a computer running windows 10 natively and also a macbook pro.
Sam Aaron
@samaaron
righto
a foot in both camps :-)
ethancrawford
@ethancrawford
indeed!
Sam Aaron
@samaaron
did you notice the installer had changed?
ethancrawford
@ethancrawford
the windows installer is great, though to be honest I hadn't updated the packaged version of Sonic Pi on windows for a while, so I can't quite remember what it was like last time :)
Sam Aaron
@samaaron
there were pictures of generic CD-ROMs in the installer ;-)
it also took ages for the installer to appear in some cases