-
Notifications
You must be signed in to change notification settings - Fork 0
MBcode/kmb
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
base-utils for http://www.cs.utexas.edu/~mfkb/km/ http://www.advogato.org/person/crhodes/diary.html?start=158 I'll throw in some old code I was going to rewrite 2open-up. use http://www.quicklisp.org/ it even has KM now use with ../LispUtils/util_mb.lisp https://docs.google.com/present/view?id=dfppzgjw_33fttsj6dm has old work and some potential new directions =late 2012: potential offshoots: just after: http://bit.ly/TP8gfz Instead of getting KM to be the reasoner for a system like BBN's shard (batch), why not get Lisp to make a Clojure/Storm like (streaming ~RT) but with scalable shard like reasoning/qry ability. If it is to mirror some of storm's ability, the first order would be to get one of the MQ libs going. Even if it stayed batch though, we will want something like the shard query planner. So when the cascading like workflow is made, you know what the new emit key is to order/group for the next pass. If I just do that, I would do it in: kms Each of these would depend on: kmb (km base), that has some km api sugar, and my regular utils. Once that is asdf loadable, then just reference it. If kmq is built on kms, then just ref it's asd file as well. kmq -needs-> kms -needs-> kmb -needs-> km (which is now loadable via quicklisp) =instead of just streaming consider: http://storm-project.net/about/multi-language.html but not just Thrift, consider Avro, &other formats as are useful, incl HPC ones (eg.hdf5).
About
Knowledge-Machine base-utils
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published