- pro - mailman3.common-lisp.net

Re: [pro] lisp on mobile platforms these days
by Bruce O'Neel 09 May '14

09 May '14

Hello, When you say "targeting mobile devices" do you mean 1. You get a lisp REPL on your Android/iPhone? 2. You can write Apps in Lisp such that the end user does not know whether lisp is there or not. I could be interested in either, though to be honest I am slightly more interested in the first. Thanks. bruce >>>>> On Sun, 27 Apr 2014 10:18:17 +0600, Attila Lendvai said: > > dear lispers, > > what is the state of the art in running lisp (not just CL) on mobile > platforms, preferably in a portable way? > > is mkcl viable to run as a native app both on iOS and android? > > if iOS has too many legal constraints and whatnot, then let's forget > it for now. We are working on targeting mobile devices and are currently seeking alpha testers. Please contact us directly if you would like to build a Common Lisp runtime for iOS or Android. We're not going to publish further details yet, so please don't ask here. -- Martin Simmons LispWorks Ltd http://www.lispworks.com/ _______________________________________________ pro mailing list pro(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

2 1

[pro] CDRs on arXiv
by Antoniotti Marco 08 May '14

08 May '14

Dear all, I thought that a good idea to generate some interest in the community would be to publish all the finalized CDRs on arXiv. To this end it would be useful if all the past CDR contributors would take the time to prepare an ‘arXiv’ acceptable submission and let the editors know that they have done so. All the best -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first.

1 0

[pro] [CfP] International Lisp Conference 2014, Aug. 14-17, Montreal
by Didier Verna 07 May '14

07 May '14

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 In cooperation with: ACM SIGPLAN 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. The conference proceedings will be published in the ACM Digital Library. 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: Charlotte Herzeel, IMEC, ExaScience Life Lab, Belgium Damir Cavar, Eastern Michigan University, USA Dave Herman, Mozilla Research, USA Greg Pfeil, Clozure Associates, USA Irène Anne Durand, LaBRI University of Bordeaux, France Jim Newton, Cadence Design Systems, France Kuroda Hisao, Mathematical Systems Inc., Japan Matthew Might, University of Utah, USA Nicolas Neuss, Friedrich Alexander Universitat, Germany Ralf Möller, TUHH, Germany Sam Tobin-Hochstadt, Northeastern University, USA William Byrd, University of Utah, USA 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

[pro] lisp on mobile platforms these days
by Attila Lendvai 01 May '14

01 May '14

dear lispers, what is the state of the art in running lisp (not just CL) on mobile platforms, preferably in a portable way? is mkcl viable to run as a native app both on iOS and android? if iOS has too many legal constraints and whatnot, then let's forget it for now. what are the downsides of connecting to the NDK (android C API)? how much of android is not available through the NDK? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- Paralysis through analysis.

8 12

[pro] Heartbleed?
by David McClain 29 Apr '14

29 Apr '14

Just curious for other opinions... but wouldn't this (Heartbleed) sort of buffer excess read-back failure have been prevented by utilizing a "safe" language like Lisp or SML? I used to be an "unsafe" language bigot -- having mastered C/C++ for many years, and actually producing C compilers for a living at one time. I felt there should be no barriers to me as master of my machine, and not the other way around. But today's software systems are so complex that it boggles the mind to keep track of everything needed. I found during my transition years that I could maintain code bases no larger than an absolute max of 500 KLOC, and that I actually started losing track of details around 100 KLOC. Making the transition to a higher level language like SML or Lisp enabled greater productivity within those limits for me. Dr. David McClain dbm(a)refined-audiometrics.com

12 42

[pro] write-char vs. 8-bit bytes
by Paul Tarvydas 14 Apr '14

14 Apr '14

I'm using sbcl to write-char a 16-bit unsigned integer to a socket as two separate unsigned 8-bit bytes, for example 141 should appear as #x00 #x8d. SBCL appears to convert the #x8d into a two-byte utf-8 char, resulting in 3 bytes written to the stream \#x00 #xcd #x8d. What is the proper incantation to achieve this? (SBCL on Windows, if that matters). thanks pt

12 21

Re: [pro] Heartbleed?
by Bob Cassels 12 Apr '14

12 Apr '14

That was always part of the Lisp dogma. It's probably even true. On Apr 12, 2014 5:52 PM, David McClain <dbm(a)refined-audiometrics.com> wrote: > > Just curious for other opinions... but wouldn't this (Heartbleed) sort of buffer excess read-back failure have been prevented by utilizing a "safe" language like Lisp or SML? > > I used to be an "unsafe" language bigot -- having mastered C/C++ for many years, and actually producing C compilers for a living at one time. I felt there should be no barriers to me as master of my machine, and not the other way around. > > But today's software systems are so complex that it boggles the mind to keep track of everything needed. I found during my transition years that I could maintain code bases no larger than an absolute max of 500 KLOC, and that I actually started losing track of details around 100 KLOC. Making the transition to a higher level language like SML or Lisp enabled greater productivity within those limits for me. > > Dr. David McClain > dbm(a)refined-audiometrics.com > > >

1 0

Formal Presentation and initial doubts.
by Alejandro Zamora Fonseca 11 Apr '14

11 Apr '14

Hello for everybody!!. My name is alejandro and I'm a new Common Lisp fan. I've been use it almost 1 year and I think is an awesome language. But I have some troubles with topics, like GUI for desktop apps, and Unicode characters. I use Clisp mainly, ECL, and Clozure CL too. Would you help me with some hints for these problems? Greetings, Alejandro -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/

8 9

Re: [pro] write-char vs. 8-bit bytes
by Bob Cassels 11 Apr '14

11 Apr '14

Yes. From the original description, this is a binary operation, not a character operation. On Apr 10, 2014 10:45 PM, raito(a)raito.com wrote: > > I end up doing something like: > > (defmacro with-open-binary-file (args &rest rest) > `(with-open-file (,@args :element-type '(unsigned-byte 8)) ,@rest)) > > (defun write-word (word out) > (write-byte (ldb (byte 8 8) word) out) > (write-byte (ldb (byte 8 0) word) out)) > > only because I'm exclusively writing binary stuff to the files this code > serves, and because it parallels the C code that does the same thing > fairly well. I'm not writing to a socket stream, but this may help anyway. > It might need to account for endianness, but I'm not sure. It's been a > while since I've looked at it closely. > > Neil Gilmore > raito(a)raito.com > > > I can't easily verify right now, but check the :external-format on your > > stream: it may be defaulting to UTF-8 and you will need to specify > > something else. > > > > -tree > > > > Sent from my iPhone > > > >> On Apr 10, 2014, at 10:31, Paul Tarvydas <paultarvydas(a)gmail.com> wrote: > >> > >> I'm using sbcl to write-char a 16-bit unsigned integer to a socket as > >> two separate unsigned 8-bit bytes, for example 141 should appear as > >> > >> #x00 #x8d. > >> > >> SBCL appears to convert the #x8d into a two-byte utf-8 char, resulting > >> in 3 bytes written to the stream > >> > >> \#x00 #xcd #x8d. > >> > >> What is the proper incantation to achieve this? (SBCL on Windows, if > >> that matters). > >> > >> thanks > >> pt > >> > >> > >> _______________________________________________ > >> pro mailing list > >> pro(a)common-lisp.net > >> http://common-lisp.net/cgi-bin/mailman/listinfo/pro > > > > _______________________________________________ > > pro mailing list > > pro(a)common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/pro > > > > > > _______________________________________________ > pro mailing list > pro(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/pro

1 0

Re: macro returning more than one form
by Paul Tarvydas 19 Mar '14

19 Mar '14

@All, thanks for the interesting discussion. Certainly gives me something to chew on. Re-reading the responses, I see that, while I did sort-of say it, I didn't emphasize the point of this: I have a PEG-syntax parser written in esrap. I am binding at least two such parsers as reader-macros (not the normal kind of macro). The first parser parses PEG syntax and creates an esrap program. That esrap program, bound as a reader-macro, reads Prolog syntax and returns a bunch of lisp forms to the reader. I have a file of code that contains both, lisp and Prolog syntax (cl-heredoc to switch between the syntaxes), e.g. https://github.com/guitarvydas/paraphrase/blob/master/prolog.lisp The parsers read characters, not forms. (lisp) #{ prolog(A,B,c) :- p1(A), p2(B,c). } (morelisp) I am making at least 2 assumptions: 1. That using different name spaces for the various parsers will help me preserve my sanity, (regression testing the PEG parser using itself brings me to the limits of my comprehension :-), 2. That a reader macro must return a single form. I actually want to return a separate 'defun' for every prolog rule in the file. (Writing this, just now, makes me ask myself why I don't just put #{ ... } around every separate rule...) (I even started fooling around with a Python syntax). This line of thinking was inspired by the Gambit Scheme talk at ILC2010, where they showed inline infix mathematical expressions. Thanks for your suggestions. pt

4 3