[cl-markdown-devel] #. compile problem

[Gary King]

Hi Ties,

I've looked into this a little more and here is what I think is  
happening: CL-Markdown uses my containers library (CL-Containers)  
and, in particular, the iterator constructs. These let me create an  
iterator and use it without caring about where the data originates  
because the iterator is supposed to abstract all of that out. So the  
call in chunk-source can look like:

> (with-iterator (i source :treat-contents-as :lines :skip-empty- 
> chunks? nil)
>         (iterate-elements
>          i
>          (lambda (line)
>            (chunk-line line))))

where source can be a string or a pathname. The with-iterator macro  
eventually turns into a call to make-iterator and make-iterator uses  
the arguments it is supplied to construct the appropriate class and  
instantiate it. in particular, if source is a pathname, the iterator  
will be of type 'file-line-iterator; if source is a string, you'll  
get  a 'line-iterator. The line-iterator is a subclass of delimited  
iterator and uses #\linefeed, #\newline (and now #\return) to find  
lines. On OS X, this code

> (list (char-code #\linefeed) (char-code #\newline) (char-code # 
> \return))

return various things in various Lisps:

> (MCL)               ==> 10 13 13
> (SBCL 0.9.11) ==> 10 10 13
> (OpenMCL)     ==> 10 10 13

So if one of your strings had switched to #\return's instead of # 
\linefeed or #\newlines, then this is probably what caused the  
problem. I'm adding #\return to the list of delimiters for the line- 
iterator so that should correct this problem.

Note that the file-line-iterator uses read-line to suck in each line.  
This means that the changing the delimiter won't have any effect on  
files. It also means that the line ending in files will be  
significant to CL-Markdown (i.e., CL-Markdown won't work correctly if  
read-line doesn't read lines <smile>).

HTH, please keep me informed as to any more trials and tribulations  
you encounter (and successes too!)


On Jun 9, 2006, at 3:59 PM, Ties Stuij wrote:

> Eureka!
> i got it.
>
>> So are you saying that
>>
>> ? (markdown "..." :stream t)
>>
>> works but
>>
>> ? (markdown "..." :stream "/my/file/name/here")
>>
>> fails?
>
> No i store two strings in elephant class slots: the markdown text and
> the output of the markdown. Since elephant only references slots you
> ask for, this seemed to me to be the most efficient way to use it. If
> you want to update the text you can edit it in place through a form
> (we're talking browsers here).
>
> Anyway, it turns out that get?/post?/the browser?/ucw? saves
> line-jumps as returns in stead of newlines. Something a newbie like me
> doesn't think about so fast. I solved it in my app by regexp-replacing
> through the string. I was gonna supply a patch but i noticed your code
> decides on a low (container) level if the text you want to process is
> a string or whatever, so i don't really know what is the preferred
> route.
>
> Btw, while on my bughunt i installed through asdf-install and noticed
> it installed a couple of dependencies that were not needed with the
> darcs markdown, eg trivial shell, lml2, lift, cl-html-diff and
> cl-difflib. You probably knew this and it is no biggie but you never
> know.
>
> Anyway, thanks for the help,
>
> Greets,
> Ties


-- 
Gary Warren King
metabang.com
http://www.metabang.com/
(413) 210 7511
gwking on #lisp (occasionally)