Skip to content
Snippets Groups Projects
  1. Jun 04, 2023
  2. Jun 03, 2023
    • Deucе's avatar
      Fix some pipes. · cd5efde2
      Deucе authored
      cd5efde2
    • Deucе's avatar
      Fix typo in line 666 · ce469261
      Deucе authored
      ce469261
    • Deucе's avatar
      Quick pass through the manpage · 64c944c1
      Deucе authored
      64c944c1
    • Deucе's avatar
      Fix SF tickets 113 and maybe 111 · d38bdc71
      Deucе authored
      Fix infinite loop in bitmap_drv_init_mode() if scaling results in
      larger than max size.
      
      This uncovered an issue in resize_window() which would cause the
      screen to be corrupted due to vstat not agreeing to the actual window.
      d38bdc71
    • Deucе's avatar
      Mention -b and -n. · 2541a858
      Deucе authored
      2541a858
    • Deucе's avatar
      Hardware scaling too! · 18b0571c
      Deucе authored
      18b0571c
    • Deucе's avatar
      Some more changes for the changelog. · da94ab63
      Deucе authored
      da94ab63
    • Deucе's avatar
      Fix up source/last for external scaling · 13143b0f
      Deucе authored
      This was ending up using an uninitialized value
      13143b0f
    • Deucе's avatar
      Fix use of uninitialized value · 8d437089
      Deucе authored
      8d437089
    • Deucе's avatar
      Use a single pipeline for Linux SyncTERM and dpkg · 5a597ccd
      Deucе authored
      No need to build twice just to create the bundle.
      5a597ccd
    • Deucе's avatar
      Format the .deb filename "correctly" and add a pipeline for it. · 91168725
      Deucе authored
      In theory, a crazy person could grab it every day and upgrade it.
      91168725
    • Deucе's avatar
      Meh, fix up the dpkg target to use PREFIX · d3377486
      Deucе authored
      You still need to specify it, but you can create a /usr/local dpkg
      now if you don't.
      d3377486
    • Deucе's avatar
      Fix warnings. · b92eeee1
      Deucе authored
      b92eeee1
    • Deucе's avatar
      Document how to build a dpkg. · be613be9
      Deucе authored
      It's pretty important to specift PREFIX here right now since it's
      not actually used in the paths, which means there would be a mismatch
      between where the files are installed and where the data lives.
      
      This is fairly easy to fix, but I likely never will.
      be613be9
    • Deucе's avatar
      Finally got ChromeOS icon/toltip working! · fd0370d5
      Deucе authored
      It appears its matching based on the class, not the application.
      Since this was hard-coded to CIOLIB based on the idea of using
      resources to customize all CIOLIB windows, this didn't match the
      SyncTERM .desktop file, so ChromeOS assumed it was "something else"
      
      Add yet another ciolib_initial_* variable to set this, and she's
      finally good!
      fd0370d5
    • Deucе's avatar
      Add dpkg target · 1a9930f0
      Deucе authored
      Part of my apparently never-ending quest to get the icon to show up
      for the SyncTERM window on ChromeOS.
      1a9930f0
    • Rob Swindell's avatar
      Fix channel.js line 372: TypeError: c.list[i] is undefined · b343e36f
      Rob Swindell authored
      Cyan may have a better fix. <shrug>
      b343e36f
    • Deucе's avatar
      Implement the _NET_WM_PING protcol · fb8189ce
      Deucе authored
      Implied by _NET_WM_PID being set, so may as well do it.
      fb8189ce
    • Deucе's avatar
      Set _NET_WM_PID · bf9cfc12
      Deucе authored
      Seems like a good idea, should allow WMs to kill hung processes and
      stuff like that.
      bf9cfc12
    • Rob Swindell's avatar
      Use "Message Editors" instead of the (vague) "External Editors" · 81548689
      Rob Swindell authored
      It was redudnant having "External Editors" under "External Programs" (they're
      all external, yeah?) and of course, "Editors of what?"
      
      So yeah, existing docs are now all wrong. :-)
      81548689
    • Deucе's avatar
      Disable X Synchronize and some minr optimizations in set_icon() · bbeb07bc
      Deucе authored
      The XSynchronize disablement is the most important here... didn't
      realize it defaulted to enabled, which has been slowing down a *lot*
      of stuff for a long time... not that there's much left that benefits
      from disabling Synchronized XLib except this new terrible icon thing.
      bbeb07bc
    • Rob Swindell's avatar
      Add a 60-second timeout to sbbs_t::passthru_socket_activate() · 0766f913
      Rob Swindell authored
      Keyop reported an issue via irc whereby a user that failed to download a file
      would leave the node "hung" in "downloading via telnet" node status even
      though the user had long since disconnected and the log reflected that the
      terminal server was aware of this:
      
      term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
      term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
      term Node 4 <user> external Timeout waiting for output buffer to empty
      <minutes later>
      term Node 4 connection reset by peer on send
      term Node 4 !ERROR 32 sending on socket 102
      term Node 4 !ERROR 32 sending on socket 102
      term Node 4 !ERROR 32 sending on socket 102
      term Node 4 !ERROR 32 sending on socket 102
      term Node 4 !ERROR 32 sending on socket 102
      term Node 4 disconnected
      term Node 4 !ERROR 32 sending on socket 102
      
      and
      
      term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
      term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !Receive timeout (1 seconds)
      term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
      term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
      term Node 3 <user> external Timeout waiting for output buffer to empty
      <minutes later>
      term Node 3 connection reset by peer on receive
      term Node 3 !ERROR 32 sending on socket 96
      
      These nodes were then locked up in call to passthru_socket_activate(false)
      as reported by gdb, e.g.
      
      Looking at passthru_socket_activate(), the deactivation path (called at the
      end of external() in this case), it was clear that this could be an infinite
      loop in the case the user had disconnected:
      
          do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
              SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
          } while(RingBufFull(&outbuf));
      
      These flush/purge loops aren't strictly needed if the user has disconnected,
      but as can be seen by the above logs, the terminal server may not know that
      (the socket may not indicate disconnect) before passthru_socket_activate()
      is called by external().
      
      So... worst case, just do the activation and deactivation buffer flushes
      and purges for 60 seconds.
      0766f913
  3. Jun 02, 2023
  4. Jun 01, 2023
Loading