vlion: cut of the flammarion woodcut, colored (Default)
common lisp hacking tonight, yey.

Prodding and poking on my semantic analysis system. Interestingly, at this point this is largely a graph analysis problem. As I work over using the graph library I've created and trial test cases, I'll be able to develop a useful integration with it.
vlion: cut of the flammarion woodcut, colored (Default)
My personal project & open source journey has been longish and somewhat varied. I'm going to be trying to bring it to a point and either tie off or continue development with one major project.


- Rust log-piper to postgres for my rpis
- Finish Rust WAV parser - maybe?


- Card Catalog in Haskell - I need to understand how to make a CRUD app in Haskell.

Common Lisp

- a config file parser, rev to to the latest edition of the config file
- finish up some more generic support packages that will help the CL community.
- continue working on my BI database system (it's a fun & hard algorithmic challenge)

Of all those, I want to only be developing the Common Lisp BI system by July. My prior open-source (Quicklisp) Lisp work will be maintained with bugfixes, but I don't plan to do future feature on them. The BI work is interesting and encompasses a large segment of computer science, from compilers to algorithms.

Looking forward, I've roughly picked Scala as my "future" language, for future for-pay work, along with trying to learn it & the Play Framework in such a fashion that I can quickly gin up side projects/bootstrap income with Scala/Play. I've basically had it with dynamic languages: the system in Common Lisp is a disaster if there aren't lots of automated tests. Same for Python, Perl, etc. This isn't a big deal if you're doing it every day, but for the long-running projects, it's murder to pick something up after 3 months and understand what's going on.

Scala seems okay, I guess. It's statically typed and has a big commercial end of things. Which is cool. I'd rather use Haskell, but Scala clearly has the better financing and industrial tooling around it. Same for Rust, but I'm also not 100% sure Rust jobs will exist when I next look for work (hopefully quite a ways off!).
vlion: source: lisperati (lisp)
One thing I regularly want is a search tool for *my* needs. The OSX one (spotlight) is a bit slow and often doesn't do what I want. I haven't found one I'm happy with for Linux.

So I sat down this evening and hacked together some Common Lisp/SQLite to start this. At present it's a bit mindless but I can query for particular phrases. I need to add in stemming rules.

It's a good hack project. Not too complicated, but interesting enough I don't feel that I'm wasting my time. It's also extremely well-defined IMO.

My goal is to provide a separate system that'll be like `locate`, but will be "search 'token'". Depending on the SQLite syntax is, I might be able to swing regexes or LIKE queries as well. Otherwise I'll just have to implement some peculiar stemming rules in order to handle tokens of interest.


- Add in directory walking and insertnig

- Factor search code out into the client tool.


Feb. 27th, 2013 12:58 am
vlion: cut of the flammarion woodcut, colored (Default)
Working on a virtual pet game. My hope is to sell it on firefox OS as a web app. After all, if Cow Clickers made it onto Facebook as a game... then anything can.

My virtual cat now will go through a hungry->feeding->fed->hungry cycle now.

As a note, this is pretty easy with CLOS and method combiners. I have very little idea how I would do this in Python or C++ without piles of globals and fussing around.

... it's 1 am. I'm done
vlion: source: lisperati (lisp)
Spending some time working with CLOS in an implementation of my thesis system on my laptop. /Wow/, CLOS is really cool. Kind of weird and super-flexible, but amazingly... right.
vlion: cut of the flammarion woodcut, colored (Default)
My code has run real slow for my thesis.

But, I noticed something odd last night. My code was running faster the more I ran it. Obviously something was being cached...
With a little digging

* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  6.003 seconds of real time
  2.025841 seconds of total run time (1.815692 user, 0.210149 system)
  [ Run times consist of 0.153 seconds GC time, and 1.873 seconds non-GC time. ]
  33.75% CPU
  13,178,489,438 processor cycles
  4,899 page faults
  120,938,224 bytes consed
* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  3.147 seconds of real time
  1.871226 seconds of total run time (1.728549 user, 0.142677 system)
  [ Run times consist of 0.245 seconds GC time, and 1.627 seconds non-GC time. ]
  59.45% CPU
  6,906,955,110 processor cycles
  1,481 page faults
  120,910,704 bytes consed
* (time (render-trace "../../programs_of_interest/one-transfer"))

Evaluation took:
  1.888 seconds of real time
  1.807235 seconds of total run time (1.773451 user, 0.033784 system)
  [ Run times consist of 0.048 seconds GC time, and 1.760 seconds non-GC time. ]
  95.71% CPU
  4,143,453,818 processor cycles
  5 page faults
  120,905,696 bytes consed

Notice the page faults! They really sucked up the time.
vlion: source: lisperati (lisp)
I've been using Common Lisp fairly seriously for about a year or so, and recently I've rewritten part of my Master's thesis project in Common Lisp (from Ruby).

How is it?

The parens rapidly become not an issue. Maybe it's a personal thing, but the very regular syntax frees me to think about my semantics. Some people seem to favor irregular syntax. I don't personally understand that; forgetting semicolons, commas, or other elements is a common screwup in other languages for me. Lisp takes that away. Regular syntax (instead of wondering what the right Thungus is to put There) makes things better. Maybe this would be less of an issue if I didn't have so many languages floating in my head; I have used Perl, Python, Ruby, Bash, Lisp, and Make in serious fashion in the past year; I'm going to be learning Objective C and Haskell in the next year.

The library situation is pretty much as good as Perl or Python. Xach's Quicklisp serves quite well in this regard, and I expect it to be the comprehensive Lisp archive for the next decade. Lisp's fully dynamic nature allows redefinition of functions and reloading of modules, which is totally awesome. I'm not sure what other languages support that. Perhaps Erlang?

Macros have made my code shorter and better maintainable. I have almost no repetitive blobs of code. What I do have, I *could* rewrite, but would sacrifice clarity. I have had bugs with my macros, which have not been wholly obvious at first. You definitely need to open up your cleverness to debug them. What is fully evident is that a master Lisper can do portable things with macros that in other languages, require the compiler writers to implement.

The lack of a mainstream-sized community is something I feel. I participate in Stackoverflow and Reddit's Lisp areas, as well as read comp.lang.lisp, and there are generally only may be 5-10 regulars, which are shared between all 3 elements. The IRC channel is pretty good though, although it's infested with "Do it Right The First Time" people, like a parody of the "Worse is Worse" essay at times.

Sequences are put together in a 'so-so' fashion. There are vectors, and there are lists, and functions are not clear which type they take (and they might take both). I expect there's a library that manages this, but I haven't searched for it, preferring to learn the language from the ground up.

The FORMAT (Lisp's printf) function is crufty and weird.

LOOP works, after a fashion, and is unquestionably one of the weakest parts of the standard; I expect I shall investigate other iteration macros after the thesis is finished. Possibly the ITERATE library...

I haven't used any database connectors yet, so I can't comment on them.

Lisp shares the Image model with Smalltalk; this is a model where the REPL persists over a long time. Python and Ruby have their interactive mode, which (as they implement it) is a weaker version. So a common deployment strategy is to deploy a Lisp executable together with an image to be loaded into Lisp at run-time. That's pretty off-the wall compared to the Algol-derived world which has a hard line between compilation & application.

In terms of speed, Common Lisp is a bit slower than C++ for heavy computation - in the hands of an expert. This is in stark contrast with other dynamic languages, which usually are a joke for heavy in-language computation and require a C extension.

Typing is weird - I think it's close to Perl 5's typing - and I don't have 100% of a handle on how to write explicitly-typed code. Usually it's done in an optimization context.

Integration with the shell is "okay", and really requires external libraries to fully handle cleanly. I have put together a few functions which are pretty sweet for that.

In general, Common Lisp usually works like a language that's been designed, instead of organically grown with weird and annoying gaps in it. In this, it works like the C++ STL or the C stdio.
vlion: cut of the flammarion woodcut, colored (Default)
Jotting down for later polishing.

Given a list that denotes a computation.
(setq myawesomelist '(+ X (- (1+ X) X)))

Then, this macro will take that list and generate an 'anonymous' function that can be bound and saved.

;;Turns a tree into a lambda
(defmacro tree-to-lambda(tree)
  "Takes a tree and turns it into the lambda of its function"
  (eval ``(lambda (X) 

 (funcall (tree-to-lambda myawesomelist) 4)
will compute the function denoted by myawesome list on parameter=4.

Gnu common lisp was used.

That macro took some 5 hours to work out.

I spent a previous evening diddling with it in April or so, I think. Prior to that, I built the list-generating framework in... 2005? 2006? It was hideously crufty.

I do remember staring at it this spring and thinking I was smarter then. It depressed me enough I start poking at it again.

I have a small library of fuzzy comparisons and tree adjustment routines I had built to try to mutate/combine lists. The goal here is to evolve a program that will - after some work - compute a specified input function.

Note to self - figure out multi-parameter functions... later.
vlion: cut of the flammarion woodcut, colored (Default)
Just found out it that timestamps on the files I've been grading are in UTC instead of PST.

Hoo boy. Time to regrade.

I also have 40 pages of denotational semantics to read and understand.

Looks like it's going to be a hard-workin' weekend.

I've picked up some old lisp code I had; I have the kernel of a genetic programming program half-written. I think I'll try and make progress on it, then work on my taginator project.

Ah well. May have to retreat into WoW for a bit if things get too stressful.


vlion: cut of the flammarion woodcut, colored (Default)

August 2017

6789 101112

Style Credit


RSS Atom
Page generated Oct. 19th, 2017 07:22 am
Powered by Dreamwidth Studios

Expand Cut Tags

No cut tags

Most Popular Tags