pro

pro@common-lisp.net

345 discussions

[pro] Common Lisp Library for MS Word files (.doc or .docx)?
by Mark H. David 01 Mar '11

01 Mar '11

Does anyone know of any CL libraries for dealing with Microsoft Word files? Tools for creating them, reading from them, parsing them, converting them to plain text or other formats, things like that? Thanks, -Mark

7 6

[pro] Is cl-yacc going to cut it?
by Matthew D. Swank 15 Feb '11

15 Feb '11

I suppose this is only marginally related to common lisp, but everything I'm talking about is written in common lisp. I use cl-yacc for a lot of parsing, but one thing that has always seemed harder than it needs to be is writing lexers to feed it. One thing that I've found helpful is the creation of a custom lexer for each parser state by making the action table entry for that state available to the lexer. This provides the terminals the parser is looking for, and narrows the tokens the lexer has to look for at each step. However, this means I am also maintaining my own fork of cl-yacc. It seems (from my admittedly limited search) that this is not a common modification of yacc. Before I start bugging the maintainer about my changes, I want to know: am I abusing yacc? I do like the separation between low level tokenization the higher level symbol parse, but is there another general parsing technique, available as a lisp library of course, that either works at a lower level than yacc usually does or allows the lexer to access more context about the parse? Matt

12 20

[pro] Final empty parameters to format directives
by Didier Verna 11 Feb '11

11 Feb '11

Hello, I just fell upon a case where implementations seem to differ on what to do. The question is how to interpret a format directive in which the last parameter is followed by a comma. Consider this test case: (defun fmt (stream argument colonp atsignp &rest params) (declare (ignore stream argument colonp atsignp)) (format t "~S~%" params)) (format t "~1,2/fmt/~%" t) (format t "~1,2,/fmt/~%" t) (format t "~1,2:/fmt/~%" t) (format t "~1,2,:/fmt/~%" t) Here's what you get from various implementations: SBCL / ECL / ABCL: (1 2) (1 2 NIL) (1 2) (1 2) CMU-CL / CCL / CLISP / Allegro / LispWorks: (1 2) (1 2) (1 2) (1 2) Funnily, my instinct tells me that nobody's right, as I would have expected to get this: (1 2) (1 2 NIL) (1 2) (1 2 NIL) Indeed, the parameters list is implicitely terminated by the directive character OR a colon / at-sign. So using a final comma seems to me like adding another, empty, parameter at the end. I'm willing to report those divergences to the respective implementations, but the problem is that I don't really know what to report :-) Who's right? No matter how I read the spec, I cannot make a decision and it seems to me that this is an unspecified corner case. I reckon it's probably not a big deal, but this could be a problem for user-defined functions relying on the actual number of parameters that they get. Comments? -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

3 4

[pro] Are you an Imager or a Filer?
by Ala'a Mohammad 10 Feb '11

10 Feb '11

Hi, I'm continually learning Common-lisp and trying to find the best style that suites me better. I've tried 'an imager' style (cooking a an image with all required libraries loaded when required), and 'a filer' style (loading files or systems each time I fire-up a CL implementation). I'm interested to hear what others use CL. How do they manage day to day work? how do their preferred style mesh into their production pipeline (coding, debugging, deployment and maintenance)? and what makes them prefer one way over another or the mix if applicable? Regards, Ala'a Mohammad.

18 23

[pro] awk
by Daniel Weinreb 04 Feb '11

04 Feb '11

Has anybody written a domain-specific-language set of macros (or functions) to provide "awk" functionality from Common Lisp, with roughly the kind of brevity that awk users like? -- Dan

2 1

[pro] 404 animals
by Daniel Weinreb 03 Feb '11

03 Feb '11

There appears to be a new trend of putting cute animals on your HTTP 404 page. Twitter has a "Fail Whale", and now Tumblr has "TumblBeasts": http://www.observer.com/2011/tech/tumblr-adds-oatmeals-suggested-tumbeasts-… Perhaps we can have an easy way to make Lisp-based web sites use the "powered by alien technology" cute green creature? :) -- Dan

13 14

Re: [pro] simple-style-warning
by Vladimir Sedach 27 Jan '11

27 Jan '11

So from what I understand now, the way to accomplish a "simple-style-warning" without having compile-file return failure-p is to define a subclass of style-warning with the format-control/arg slots and a :report function myself. Is this correct? Vladimir

2 2

[pro] User defined format functions
by Didier Verna 26 Jan '11

26 Jan '11

Hello, there are situations in which I find myself frequently using the same format "pattern", which I'd like to abstract away. A concrete example is from my Declt package[1] which prints a lot in Texinfo format. Since Texinfo has a couple of special characters (e.g. @), I have an ESCAPE function which takes a string and returns another one with all special characters escaped. In the Declt code, I hence have very frequent calls which look like this: (format stream "... ~A ..." #|...|# (escape str) #|...|#) This is frustrating because I would like to abstract away the relation "~A <-> #'escape". Of course there are solutions (I could provide my own wrapper around FORMAT in some way) but none of them seem satisfactory. I'm aware of the ~// construct, which I find extremely cumbersome. Does anybody actually use it? It seems to me that the package handling part, specifically, makes it totally unusable. Just imagine that I would need to do something like that if I were to use it: (format stream "... ~/com.dvlsoft.declt:escape/ ..." #|...|# str #|...|#) and you get the idea! :-) No, in fact, the problem is that FORMAT control sequences are not extensible. This reminds me of something that we have in the Gnus mail/newsreader. It's called "user format functions". Gnus Group and Summary buffer lines, for example, are define by a format string with a set of predefined %<char> constructs. One of them, %u<char> lets you define and use your own function, called gnus-user-format-function-<char>. So what I would like to do is more or less define a function FORMAT-FUNCTION-E, just like a standard formatter, and then be able to write something like that: (format stream "... ~\e\ ..." #|...|# str #|...|#) Of course, there are package issues. Maybe we would need a centralized mapping between function names (what goes in ~\\) and actual symbols denoting the actual function? Possibly with the possibility to override the mapping by providing a package prefix in the ~\\ construct? In fact, the more I think about it, the more it sounds like having a format-table facility, much like what a readtable is, with a similar API. You could do (in-format-table :my-table-name) at the beginning of a file and have a totally customized set of format control sequences, possibly inheriting the standard ones. WDYT? Does something like that already exists[2]? Footnotes: [1] http://www.lrde.epita.fr/~didier/software/lisp/misc.php#declt [2] I've heard of something called fmt for scheme, but don't know much about it. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

6 11

[pro] User defined format functions
by Didier Verna 25 Jan '11

25 Jan '11

3 3

[pro] A little success story...
by Pascal Costanza 24 Jan '11

24 Jan '11

Hi, I just wanted to report on a little success story. In the recent few months, I have been working on a new project that concerns itself with parallel programming. For that purpose, I experimented with variations of a home-grown work-stealing scheduler. (See http://en.wikipedia.org/wiki/Cilk#Work-stealing for a description of what work stealing is.) The development platform is LispWorks 6.0, which comes with an excellent library for SMP. (I would say it's the best of any dynamic language I am currently aware of, not just those of Lisp dialects.) Performance matters in parallel programming. The benchmark application was a structured grid computation, like is for example used for computing heat equations, for running game of life, or for similar applications. This is easy to parallelize, because each processor can perform part of the computation on a sub-grid independently of all the other processors. The hardware that I ran the experiments on is a 4x 6-core Intel Xeon "Dunnington" 2.67 GHz running Ubuntu. For 200 iterations on a 4096x4096 matrix of single float values, I got the following runtimes: - with 8 cores ca. 19-20 secs. - with 16 cores ca. 9-10 secs. - with 24 cores ca. 8 secs. The same experiment was also implemented by others in our group in the following languages: Unified Parallel C, Cilk++, C with MPI, OpenMP, and C++ with Threading Building Blocks. They all have slight variations in runtime, but all roughly in the same ballpark. The runtimes were: - with 8 cores ca. 10-11 secs. - with 16 cores ca. 8-10 secs. - with 24 cores ca. 8-10 secs. The advantage of using Common Lisp is that I could still use higher-order constructs (closures) and have a pretty decent separation of concerns in the software architecture, while still getting very good efficiency. Of course, this required some pretty low-level tricks with type and optimization declarations in several places, but the nice thing about Common Lisp is that you don't have to be low-level right from the start, and only at the places that you identify as bottlenecks. Unfortunately, I cannot present a lot more details at this stage, because most of this is covered by an NDA. I hope, though, that I can make the work-stealing scheduler available as an open source library at some later stage. Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

3 5

← Newer
1
...
27
28
29
30
31
32
33
34
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro