Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - bairui

#61
newLISP in the real world / Re: cleaning strings
May 14, 2012, 02:00:04 AM
Cool. I was thinking of something along the same lines:



(setf input "a bb ccc dddd eeeee ffffff")

(filter (fn (s) (>= (length s) 4)) (parse input))
#62
Thanks for the quick reply, acknowledgement of the bug and having it fixed in dev already, Lutz.

This is not an emergency, so I can wait for the update to trickle down. I'm on Arch Linux.



Love newLISP, btw, Lutz - such a clean and pretty little lisp. Thanks for all the good work.
#63
I found a workaround for my immediate needs by setting the file pointer to the position after the search:



(search file (append {<a name="} search-term {">s*</a>}) true 1)


I'm still not yet skipping the lines after the search, but I imagine I could do that with another regex.



Knowing the more idiomatic way to skin this rat would be awesomer.
#64

(setq file (open {foo} {read}))
(println (seek file))
(read-line file)
(println (seek file))


The first seek prints 0 as expected, however the second one prints the EOF byte position. I couldn't find this behaviour documented in the read-line section of the manual. So... is this a bug in newLISP or me?



If this is normal expected behaviour, how do you suggest I:
[list=1]
  • [*]search to a place within a file (search file {something})

  • [*]skip a few lines (read-line file)(read-line file) <-- currently fails here

  • [*]read a chunk of text (read file buf 1000)
  • [/list]


    Thanks in advance. :-)