- armedbear-devel - mailman3.common-lisp.net

[armedbear-devel] Some convenience functions
by Theam Yong Chew 08 Apr '15

08 Apr '15

Hi all, I've got a bunch of useful functions for general hacking with abcl. Hope they could be useful. Any suggestions on the best place for sending patches (if indeed they are useful enough). abcl contribs, slime contribs, or core abcl? Yong ;; javap seems to be bundled/more widely available compared to the defaults (defun disassemble-class-cmd (path) (with-accessors ((d pathname-directory) (n pathname-name)) (merge-pathnames path) (format nil "cd ~{/~a~}; javap -c ~a" (cdr d) n))) (defun disassemble-class (path) (ext:run-shell-command (disassemble-class-cmd path))) (setf system::*disassembler* #'disassemble-class-cmd) (in-package :swank) (defmethod menu-choices-for-presentation ((throwable java:java-exception)) "Java exception stack traces (different from Lisp stack traces) are also available." (list (list "printStackTrace" (lambda (choice object id) (declare (ignore choice id)) ;; TODO, print to an Emacs buffer instead (java:jcall "printStackTrace" *standard-output* (java:java-exception-cause object)))))) (in-package :swank-backend) ;; Not real frame local variables, but it at least exposes function ;; arguments for possible inspection (defimplementation frame-locals (index) (loop for id upfrom 0 for item in (java:jcall "toLispList" (nth-frame index)) collect (let () ;; ((id id) (item item)) (list :name "??" :id id :value item)))) (defimplementation frame-var-value (index id) (elt (java:jcall "toLispList" (nth-frame index)) id))

2 1

[armedbear-devel] ABCL 1.2.1 Release
by Mark Evenson 08 Apr '15

08 Apr '15

We think that [abcl-1.2.1][] represents the final release engineering work for the version available at ECLM 2013. A description of the [CHANGES] is included with the source. Upcoming in abcl-1.3.0: o per function call stack and memory exception handler in CL:COMPILE o further fixes in Quicklisp, q.v. [abcl-1.2.1]: http://abcl.org/releases/1.2.1 [CHANGES]: http://abcl.org/svn/tags/1.2.1/abcl/CHANGES

1 0

Re: [armedbear-devel] 20130823a Diffs for chemicalamba (Akka bridge in ABCL)
by Mark Evenson 08 Apr '15

08 Apr '15

On Aug 22, 2013, at 9:37 PM, ubikation _ <ubikation(a)gmail.com> wrote: > Hey Mark, > > I really appreciate your help but I am having trouble understand the diffs that you are sending me. I understand that HG is generating them but I am having trouble recreating your state. What tools do you recommend? I understand that creating a huge class isn't a good Java practice and I'm happy to break it up but it was hard for me to figure out exactly what goes where according to your diffs. […] For any software development, open or not, coming to terms with "diffs" is a basic skill that has no "right answer" for the tools one uses. A "diff" is a standardized format, used by a variety of tools including most IDEs these days. But in the beginning there was the command line, so the first tools you should come to terms with are diff(1) and patch(1): cmd$ [[[clone repo into "./chemicalambda"]]] cmd$ cd chemicalambda cmd$ patch -p 1 < file-that-contains-the-diff.diff The "-p 1" strips the top-level of the hierarchy, and then patch reads the contents of stdin for changes to make. One will see either success or error messages in applying the diff. Re-do until you get the results you want, then deal with the changes in your own version control ecology. What I like about hg is that one can just directly import a diff into the repo: cmd$ hg import file-that-contains-the-diff.diff but git certainly has similar functionality, somewhere. I avoided a comprehensive understanding diffs for many years, much to my own detriment.

1 0

[armedbear-devel] Unsubscribe
by Wayne Rogers 08 Apr '15

08 Apr '15

1 0

[armedbear-devel] bug: example java-to-lisp1 does not compile (ABCL 1.2.1)
by David Catteeuw 08 Apr '15

08 Apr '15

Hello, While experimenting with ABCL, i noticed that the example "java-to-lisp1" cannot be compiled using ABCL 1.2.1. It does compile using ABCL 1.1.1. The method "findPackage(String)" seems to have disappeared from "Packages" in the new release. java-to-lisp1$ javac -cp /Applications/Dev/abcl-1.1.1/abcl.jar:. *.java java-to-lisp1$ javac -cp /Applications/Dev/abcl-1.2.1/abcl.jar:. *.java MainAlternative.java:39: cannot find symbol symbol : method findPackage(java.lang.String) location: class org.armedbear.lisp.Packages Packages.findPackage("CL-USER"); ^ 1 error java-to-lisp1$ java version "1.6.0_51" Java(TM) SE Runtime Environment (build 1.6.0_51-b11-457-10M4509) Java HotSpot(TM) 64-Bit Server VM (build 20.51-b01-457, mixed mode) java-to-lisp1$ javac -version javac 1.6.0_51 java-to-lisp1$ Kind regards, david.

2 2

Re: [armedbear-devel] threads:interrupt-thread
by Carlos Ungil 08 Apr '15

08 Apr '15

Hello Erik, I don't know how to debug java processes but I have an intuition about why those threads are not interrupted: they're never waiting. See the example below: an interruption scheduled for the interpreter thread is only executed when I put the thread to sleep (and if the garbage collector runs in the meantime it's lost). The reason why I cared about being able to interrupt the main thread was to run finalizers from there, to avoid concurrency issues in a foreign library. In the end I implemented an alternative solution using locks so I'm not really concerned about this problem anymore. Regards, Carlos CL-USER(1): (let ((main (threads:current-thread))) (threads:make-thread (lambda () (threads:interrupt-thread main (lambda () (print "Hi there!")))))) #<THREAD {3AF6EA95}> CL-USER(2): (* 2 2) 4 CL-USER(3): (sleep 1) "Hi there!" NIL CL-USER(4): (let ((main (threads:current-thread))) (threads:make-thread (lambda () (threads:interrupt-thread main (lambda () (print "Hi there!")))))) #<THREAD {CE5A31A}> CL-USER(5): (gc) 462843184 CL-USER(6): (sleep 1) NIL On 06/09/2013, at 21:49, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi Carlos, > > > is there a reason why interrupt-thread doesn't seem to run the requested function in some cases? The following code tries to run a function in each existing thread (the variable *output* logs the calls that we try to run and the ones that are actually run). > > Looking at your code, there may be multiple causes for the strings not showing up in the output. Frst of all, there's a problem with concurrency in your code: pushing into the *output* variable across threads isn't thread safe. The other reason for the code not being executed could be a bug: the code "checks manually" whether the thread interrupt has been invoked and executes the function(s) handed over. Maybe these threads land in loops that do not check this condition. > > (defvar *output*) > > > > (defun test-run () > > (setf *output* nil) > > (threads:mapcar-threads > > (lambda (thread) > > (push (format nil "~A : calling" thread) *output*) > > (threads:interrupt-thread thread > > (lambda () > > (push (format nil "~A : running" thread) *output*)))))) > > > > (defun test-report () > > (format t "~{~A~%~}" (reverse *output*))) > > > > Running in the command line: > > [snip] > > > > > I can understand that the thread "TEST-RUN" that I create to run the function might disappear before it gets to run the function as requested, or maybe the reason is that a thread can't interrupt itself by design... But why doesn't the thread "interpreter" run the function? > > > > Running in slime there are many threads present, and most of them will respond as expected. But "TEST-RUN", "interpreter" and "reader-thread" won't. > > Can you interrupt the reader-thread and interpreter thread in a java debugging environment and tell me what the stack trace is when you send the signal that isn't being processed? Maybe the answer turns out to be really obvious. > Thanks! > > Bye, > > > Erik. >

1 0

[armedbear-devel] [CfP] International Lisp Conference, Aug. 14-17 2014, Montréal, Canada
by Didier Verna 08 Apr '15

08 Apr '15

ILC 2014 - International Lisp Conference "Lisp on the Move" August 14-17 2014, Université de Montréal, Montréal, Canada Sponsored by the Association of Lisp Users http://www.international-lisp-conference.org Scope: Lisp is one of the greatest ideas from computer science and a major influence for almost all programming languages and for all sufficiently complex software applications. The International Lisp Conference is a forum for the discussion of Lisp and, in particular, the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. We invite high quality submissions in all areas involving Lisp dialects and any other languages in the Lisp family, including, but not limited to, ACL2, AutoLisp, Clojure, Common Lisp, ECMAScript, Dylan, Emacs Lisp, ISLISP, Racket, Scheme, SKILL, HOP etc. This year's focus will be directed towards integrated solutions, including mobile computing. We especially invite submissions in the following areas: * Pervasive computing * Interoperability * Portability * Implementation challenges/tradeoffs for embedded/mobile platforms * Language support for mobile toolkits and frameworks * Language support for distribution * Language support for reliability, availability, and serviceability * Mobile IDEs * Mobile applications Contributions are also welcome in other areas, including but not limited to: * Language design and implementation * Language integration, inter-operation and deployment * Applications (especially commercial) * Reflection, meta-object protocols, meta-programming * Domain-specific languages * Programming paradigms and environments * Efficient parallel and concurrent computation * Language support for managing both manual and automatic GC * Theorem proving * Scientific computing * Data mining * Semantic web Technical Programme: Original submissions in all areas related to the conference themes are invited for the following categories: Papers: Technical papers of up to 10 pages that describe original results. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries and applications. Workshops: Abstracts of up to 2 pages for groups of people who intend to work on a focused topic for half a day. Tutorials: Abstracts of up to 2 pages for in-depth presentations about topics of special interest for 1 to 2 hours. Panel discussions: Abstracts of up to 2 pages for discussions about current themes. Panel discussion proposals must mention panel member who are willing to partake in a discussion. The conference will also provide slots for lightning talks, to be registered on-site every day. For inquiries about any other kind of participation (commercial exhibits, advertising, prizes, book signing etc.), please see the contacts below. Important Dates: - May 18, 2014: Submission deadline - June 09, 2014: Notification of acceptance - June 29, 2014: Final Papers due - August 14, 2014: Conference All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=ilc14 Organizing Committee: General Chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Chair: Didier Verna (EPITA Research lab, Paris, France) Local chair: Marc Feeley (Université de Montréal, Montréal, Canada) Programme Committee: to be announced Contacts: * General Questions: ilc14-organizing-committee at alu.org * Programme Committee: ilc14 at easychair.org For more information, see http://www.international-lisp-conference.org -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[armedbear-devel] EXT:URL-PATHNAME vs http: as a logical pathname
by Karsten Poeck 08 Apr '15

08 Apr '15

Hello all, I am trying to compile cl-http on abcl. Mostly got it loading, but have some problems with abcls url-pathnames. Example: CL-USER> (lisp-implementation-version) "1.2.1" "Java_HotSpot(TM)_64-Bit_Server_VM-Apple_Inc.-1.6.0_51-b11-456-11M4508" "x86_64-Mac_OS_X-10.8.4" CL-USER> (lisp-implementation-type) "Armed Bear Common Lisp" CL-USER> (setf (logical-pathname-translations "http") '( ("port;**;*.*" "/Users/karstenpoeck/Documents/workspace/trunk/contrib/kpoeck/port-templa te/**/*.*") ("**;*.*" "/Users/karstenpoeck/Documents/workspace/trunk/**/*.*") ) ) ((#P"HTTP:PORT;**;*.*" #P"/Users/karstenpoeck/Documents/workspace/trunk/contrib/kpoeck/port-temp late/**/*.*") (#P"HTTP:**;*.*" #P"/Users/karstenpoeck/Documents/workspace/trunk/**/*.*")) ;;;; the problem is here CL-USER> (translate-logical-pathname "http:declaration.lisp") #P"http:" If I do the same with httpx: instead of http:, the code loads fine. The reason is probably the following. CL-USER> (type-of (pathname "http:declaration.lisp")) URL-PATHNAME Later starting up cl-hhtp i get: http:www;foo.html has a null authority. http:www;foo.html has a null authority. http:proxy-cache; has a null authority. http:pw;random-seed.lisp has a null authority. java.lang.NullPointerException at sun.net.www.ParseUtil.toURI(ParseUtil.java:261) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnectio n.java:905) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.jav a:836) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnect ion.java:1172) at java.net.URL.openStream(URL.java:1010) at org.armedbear.lisp.Pathname.getInputStream(Pathname.java:2369) .... I completely understand that it is desirable to have (load "http://beta.quicklisp.org/quicklisp.lisp") working, but can't you check for "http://" or "https://" before converting a pathname to an url-pathname? Karsten

2 2

[armedbear-devel] Unsubscribe
by Wayne Rogers 08 Apr '15

08 Apr '15

2 1

[armedbear-devel] Status of 1.2.0
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Mark, all, My own testing didn't reveal any notable problems, nor did the ANSI test suite. There are a few regressions in cl-test-grid which indicate our changes to symbol interning. My proposal is to go forward with the 1.2 release and release a bugfix as soon as we identify and fix the problem which the cl-colors tests indicate. What's your position? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 12