1. 06 May, 2020 1 commit
    • Mark's avatar
      build: can now use Maven to build · 319e5c5f
      Mark authored
      The basic assembly of <file:dist/abcl.jar> now works, although these
      aren't completely hooked up to Maven's notion of output artifacts.
      We aren't really intercepting maven-jar-plugin default-jar goal
      correctly, so the resulting <file:build/abcl-1.6.x-SNAPSHOT.jar>
      artifact doesn't contain all artifacts.  We probably need to correctly
      define our resources to Maven, but they are currently expressed as
      various Ant properties, so we need to slave the Maven goals to
      appropiate Ant tasks?
      Maven really wants to create all output under a single directory,
      while the Ant recipe puts intermediate artifacts under <file:build/>
      and final results in <file:dist/>.
      Need to somehow encapsulate the existence of
      <file:dist/abcl-contrib.jar> within the <file:contrib/pom.xml> Maven
      description, even though its build is part of the Ant `abcl.jar` task.
  2. 28 Jan, 2022 1 commit
  3. 12 Mar, 2022 1 commit
  4. 16 Mar, 2022 1 commit
  5. 11 Apr, 2022 1 commit
    • Alan Ruttenberg's avatar
      This commit makes interrupt-thread react quickly. · 9dfc5ad5
      Alan Ruttenberg authored
      What happens on interrupt
      I'm assuming there's both a worker thread(w) and a control thread(c) running.
      Running in thread(c)
      Call (interrupt-thread thread(w) function args)
      thread(c).interruptThread unpacks the arguments into a list
      It then calls thread(w).interrupt(function, args)
      thread(w).interrupt pushes args and fun on thread(w) thread local variable pending
      it then call java's interrupt() method.
      If things are left alone, the java interrupt mechanism will at some
      point throw an InterruptedException when running inside thread(w) various
      lispThread functions catch the InterruptedException and call
      processThreadInterrupts() then runs the functions in the thread local
      variable pending.
      There's also one check that uses the java interrupt mechanism, a call to
      thread.isInterrupted(). So if thread(w) notices that it's been
      interrupted in this way it will also call processThreadInterrupts().
      Java will only throw the exception when running functions like sleep or
      wait, so the exception won't be handled until one of those methods is
      called within thread(w). The call to isInterrupted() only happens once
      per function call. So if a function is in a loop, it could be a long
      time until the interrupt is handled.
      Thread(w) is running. The compiler has thoughtfully inserted a check on
      a static variable Lisp.interrupted inside each iteration of a loop. If a
      global Lisp.interrupted get sets to true the compiler inserted code
      calls Lisp.handleInterupts().
      Lisp.interrupted is never set in the normal course of events. There's a
      function to set it, interruptLisp() but no one calls it. interruptLisp
      calls Lisp.setInterrupted() which sets Lisp.interrupted to true.
      The change:
      We add another static Lisp.threadToInterrupt.
      We change setInterrupted() take the boolean but also a thread that you
      want interrupted.  We change handleInterrupts(), which used to call
      break() to check whether the current thread is equal to threadTointerrupt.
      When the current thread is thread(w), it call thread(w).processThreadInterrupts().
      Then, we change interruptLisp() to call Lisp.setInterrupted() with the
      thread to be interrupted.
      We don't want to have to call interruptLisp separately. So we
      call setInterrupted() directly in thread(c).interruptLisp().
      And we win.
      In slime, when you hit Control-c, it calls interrupt-thread with the
      function invoking the debugger.  With the change, interrupt-thread gets
      handled promptly and the debugger is called, even if we are in an
      infinite loop.
  6. 17 May, 2022 3 commits
  7. 01 May, 2022 1 commit
  8. 10 Mar, 2022 2 commits
  9. 11 Apr, 2022 1 commit
  10. 07 Apr, 2022 1 commit
  11. 06 Apr, 2022 1 commit
  12. 28 Mar, 2022 1 commit
    • Kasper Gałkowski's avatar
      Start out with the actual Class in print-object on java:java-object · 0380ba7d
      Kasper Gałkowski authored
      This prevents jclass-superclass from failing on names (keywords) of
      classes generated by jnew-runtime-class (it fails because they are
      created in a different ClassLoader and it can't find them). By passing
      an actual Class it doesn't have to do a lookup by name. The fail
      occured on the first iteration of the loop in
      NB: Yes, jcall works on keywords. So this is working code:
        (jcall "getName" :|java.util.List|)
        (jclass-superclass :|java.util.HashMap|)
      The inheritance mechanism of print-java-object-by-class is unchanged,
      because it internally converts the classes found by jclass-superclass
      into a keyword in order to find-method. Before this change, it also
      worked because of the above fact that jcall getName works on keywords.
      For jnew-runtime-class hierarchies this is fine as well, since the
      programmers specialize print-object-by-class themselves on any keywords
      they want, so they are responsible for any bugs in that. I.E ABCL's
      catch-all print-java-object-by-class doesn't ever call
      jclass-superclass on a keyword because the `super` loop variable there
      is always java.lang.Class or nil (that's what jclass-superclass
      returns). Before this patch, it was a keyword on the first iteration,
      then a java.lang.Class in the rest of the iterations.
      Passing a Class is better than passing in a keyword and making it look
      up the Class by name (an information loss at the start of the function
      - it goes back to looping on actual Classes after the first iteration
      anyway) because it fixes the case of printing instances of
      jnew-runtime-class generated classes without having to play around with
  13. 10 Mar, 2022 4 commits
    • Mark Evenson's avatar
      Untabify en masse · 294c86e4
      Mark Evenson authored
      Results of running style.org source blocks on tree
    • Mark Evenson's avatar
      tools: start working towards a documentation of code style · 7022d6ef
      Mark Evenson authored
      We wish commits in general to be "non-noisy" with respect to
      whitespace changes, but the codebase is not quite at a common baseline
      due in part to the lack of a good AST manipulation tool for Java, but
      also that somehow the tabs vs. newline convention has gotten mixed in
      at some point.
      We can start by removing all hard tabs in favor of whitespace by
      running Emacs from an org file over the source units.
    • Mark Evenson's avatar
      Untabify · ebebf4c5
      Mark Evenson authored
    • Mark Evenson's avatar
      Whitespace justification · f32bd3d5
      Mark Evenson authored
  14. 21 Feb, 2022 1 commit
  15. 09 Mar, 2022 1 commit
  16. 21 Feb, 2022 2 commits
  17. 26 Feb, 2022 2 commits
  18. 25 Feb, 2022 2 commits
    • Mark Evenson's avatar
      abcl-introspect: home symbols in ABCL-INTROSPECT/SYSTEM · 0fb0bcff
      Mark Evenson authored
      Name exported symbols explictly as such.
      Add packages.lisp unit to assist the eventual move all of
      abcl-introspect.lisp as homed in ABCL-INTROSPECT/SYSTEM so we can
      distinguish between the ABCL core functionality and that provided for
      by ABCL-INTROSPECT.  For now, we just define the dictionary necessary
      for inspecting interpreted forms in this manner.
      Use a local function for the one-off STACK-TO-LIST.
    • Mark Evenson's avatar
      abcl-introspect: fix and move test into contrib · 97f7a1df
      Mark Evenson authored
      Failing test was actually returning additional information that was
      causing the test to fail, namely a block marker from Primitives.java:
          (:BLOCK BAR #<org.armedbear.lisp.Primitives$BlockMarker@ca46a46>))
      The "extra" stuff which ABCL-INTROSPECT adds to the SYSTEM package may
      not always be available if say JSS fails to load.  Make this explicit
      by moving the test.
  19. 23 Feb, 2022 1 commit
  20. 22 Feb, 2022 1 commit
  21. 21 Feb, 2022 1 commit
  22. 17 Feb, 2022 2 commits
  23. 10 Feb, 2022 2 commits
  24. 28 Dec, 2021 1 commit
  25. 05 Feb, 2022 1 commit
  26. 10 Feb, 2022 2 commits
  27. 13 Dec, 2021 1 commit
  28. 05 Dec, 2021 1 commit