1. 23 Feb, 2022 1 commit
  2. 22 May, 2021 1 commit
  3. 13 Apr, 2021 1 commit
  4. 08 Apr, 2021 2 commits
  5. 05 Apr, 2021 5 commits
  6. 04 Apr, 2021 3 commits
  7. 03 Apr, 2021 1 commit
  8. 02 Apr, 2021 1 commit
    • Deucе's avatar
      Initial work on setTimeout() · ad635a64
      Deucе authored
      This appears to work and the event handler *should* work on other
      event types already.
      
      Note, this is *nix-only due to the use of poll().  select() will
      need to be used for Windows to keep XP compatability.
      ad635a64
  9. 06 Mar, 2021 1 commit
  10. 28 Feb, 2021 1 commit
  11. 15 Feb, 2021 2 commits
    • Rob Swindell's avatar
      Address more Coverity issues · 5e7baf93
      Rob Swindell authored
      Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.
      5e7baf93
    • Rob Swindell's avatar
      Address more Coverity issues · 9344a7d8
      Rob Swindell authored
      Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.
      9344a7d8
  12. 17 Jan, 2021 1 commit
  13. 16 Jan, 2021 1 commit
    • Rob Swindell's avatar
      Fix js.exec() returned nul" unless exit() was called explicitly · da7c67c9
      Rob Swindell authored
      Don't use the "exit_code" property value as the return value of js.exec() unless it's a number. As reported by mlong (thanks).
      
      Also, "exit_code" was being set to null (instead of void/undefined) in js_PrepareToExecute(). I think this was just an oversight or typo by Deuce from his commit of 5 years ago (f3256d81). Since we're comparing exit_code with JSVAL_VOID in other places to determine if it was actually set, this appears to be a long standing bug.
      da7c67c9
  14. 23 Nov, 2020 1 commit
    • Deucе's avatar
      Add generic on_exit support. · f09622cd
      Deucе authored
      Store all on_exit() strings in the global scope, execute them
      one scope at a time with scopes ordered in reverse order of
      first call to js.on_exit().  Within a scope, they are ordered
      last string first.
      f09622cd
  15. 18 Nov, 2020 3 commits
  16. 26 Sep, 2020 1 commit
  17. 16 Aug, 2020 1 commit
  18. 29 Mar, 2020 4 commits
  19. 29 Aug, 2019 1 commit
  20. 28 Aug, 2019 1 commit
  21. 27 Aug, 2019 2 commits
  22. 26 Aug, 2019 1 commit
  23. 25 Aug, 2019 2 commits
    • rswindell's avatar
      Fix typo in previous commit. Thanks, NotBert. · d114d05b
      rswindell authored
      d114d05b
    • deuce's avatar
      Add js.exec(). · d53cddaf
      deuce authored
      This allows executing a new script in a specified scope, much like load().
      There are important differences however...
      1) js.exec() *must* specify a scope.
      2) js.exec()d scripts can call exit() and their handlers are ran then,
         rather than when the parent script exists as in js.load().
      3) The js object is installed in the scope with the real JS object as the
         prototype.  This generally shouldn't be an issue, but if you're doing
         strange things, stranger things may happen.
      4) As part of #3, the exec_path/exec_dir/exec_file/startup_dir/scope
         properties of the JS object represent the new script, not the calling
         one.
      5) js.exec() only searches in the passed startup dir (if specified) and the
         current js.exec_dir path.  It does not search the load paths or the mods
         directory at all.
      
      This API is also subject to change.
      d53cddaf
  24. 28 Dec, 2018 1 commit
  25. 20 Feb, 2018 1 commit