| --- Day changed Fri Apr 25 2008 | ||
| kanzure | he bootstrapped monitors? | 00:00 |
|---|---|---|
| kanzure | first time too? | 00:00 |
| kanzure | that is impressive | 00:00 |
| fenn | he was a radar engineer so he knew about what CRT's could do | 00:00 |
| fenn | er, radar operator | 00:00 |
| fenn | apparently the practice of "RFC" originated in his group | 00:01 |
| kanzure | http://heybryan.org/art/ scifi | 00:06 |
| kanzure | old stuff - http://heybryan.org/art/starwars/ | 00:06 |
| fenn | i never really "got" star-wars | 00:13 |
| kanzure | when did you see it first? | 00:14 |
| fenn | oh, probably 1995 or so | 00:15 |
| kanzure | I guess the lego+star-wars thing doesn't make sense to you either, then? | 00:16 |
| kanzure | because that's a pretty good way to explain star-wars | 00:16 |
| fenn | the new lego stuff doesnt make much sense either. it's all just big dolls | 00:17 |
| fenn | like, the pieces don't even snap together anymore | 00:17 |
| kanzure | wtf | 00:17 |
| kanzure | we need a way for the python plugins [which are allowed/encouraged to be in skdb files if not bootstrapped in the agx-get primary download] that provide the ability to read yaml files (the metadata of skdb files) to .. specify what to download and whether or not it should be linear or parallel. I think that's the only thing that matters now for agx-get. + standards for these plugins, for standardized functions to call.. | 00:18 |
| Aulere | http://www.wired.com/science/space/multimedia/2008/04/gallery_hubble | 00:18 |
| kanzure | Sure. | 00:18 |
| kanzure | Hm, Kevin Kelly rejected my comment submission to his blog entry re: Weizenbaum. | 00:19 |
| fenn | new legos: http://www.notcot.com/images/dragoncom.jpg | 00:20 |
| kanzure | you're shitting me. | 00:20 |
| fenn | i've got one like that but it's orange, and indeed it says 'lego' on the bumps | 00:21 |
| kanzure | not some cheap Chinese rip-off? | 00:21 |
| kanzure | how hard is it to rip a brick? | 00:21 |
| -!- Aulere [n=dragon_d@131.229.176.252] has quit [] | 00:23 | |
| kanzure | http://heybryan.org/mediawiki/index.php/2008-04-24 added an email from Eric Hunting | 00:24 |
| kanzure | he sounds like he knows what skdb/oscomak is about | 00:24 |
| fenn | ah i havent been following my mail too diligently | 00:25 |
| kanzure | was interesting to see the debconf tutorial was written by Joey Hess, the guy behind ikiwiki too | 00:26 |
| kanzure | but his work on debconf significantly predates ikiwiki | 00:26 |
| kanzure | not http://debconf.org/ the debian conference, but debconf the configuration program for dot-deb files and so on. | 00:26 |
| fenn | heh i think that's a pun | 00:27 |
| kanzure | or they're being jerks. | 00:27 |
| kanzure | is it okay if we demand agx-get to do linear downloading of files? | 00:29 |
| kanzure | no multiple downloads at once sort of thing | 00:30 |
| kanzure | otherwise we might run into dependency errors | 00:30 |
| kanzure | hrm, is that really much of a problem | 00:30 |
| kanzure | because a user could have multiple instances of agx-get open at a time | 00:30 |
| kanzure | as long as there's some centralized way of checking files into a database | 00:30 |
| kanzure | ah, well, the solution would be to have only one daemon proc running at a time | 00:30 |
| kanzure | which manages the agx-get sessions and make sure they are not doing anything ridiculously redundant | 00:31 |
| fenn | i honestly dont know anything about live downloading of code plugins except that it appears to be hard to do (from experience as an end-user) | 00:33 |
| kanzure | nono, just think about downloading strategies | 00:36 |
| kanzure | ah, screw it | 00:36 |
| kanzure | linear is fine | 00:36 |
| kanzure | so, the basic agx-get application is then simply something that reads the metadata files stored locally, sees if it's already there (which can be overwritten), and then fetches new files from the web as needed to 'interpret' all of the files. All plugins provide a default configuration, all plugins have configs that can be overwritten via parameters, no ambiguous parameter-names are allowed. | 00:39 |
| kanzure | so agx-get install --comfiness=5 chair | 00:40 |
| kanzure | would limit the chair download to those chairs with comfiness=5 | 00:40 |
| fenn | yep and download package data | 00:40 |
| kanzure | if comfiness is in fact a chair parameter | 00:40 |
| kanzure | so then, the trick seems to be just pairing up the db scanning + wget to go fetch a base url | 00:40 |
| fenn | now, configuration is the interesting bit :) | 00:40 |
| kanzure | I guess we can call this 'url construction' | 00:40 |
| kanzure | not really, this is not about configuration, | 00:41 |
| kanzure | dpkg/apt does config only because it's installing software that is important to the system | 00:41 |
| kanzure | whereas here we're doing programs that are all in a giant interpreted environment | 00:41 |
| kanzure | hrm | 00:41 |
| kanzure | don't know how to explain this | 00:41 |
| kanzure | I don't think that we need to implement a 'debconf' equivalent really | 00:41 |
| fenn | so you're saying it's more interactive and desktop-application oriented? | 00:41 |
| kanzure | huh? | 00:42 |
| kanzure | no? | 00:42 |
| fenn | rather than setting up config files and acting like a server environment | 00:42 |
| kanzure | definitely not for agx-get plugins; but if you mean debconf equivalent for configuring the software in each of the skdb packages ... hm. | 00:42 |
| fenn | i'm just asking where the bulk of the user input will come from | 00:42 |
| kanzure | I'm trying to figure it out | 00:42 |
| kanzure | give me a case where user input is needed | 00:42 |
| kanzure | :( | 00:42 |
| fenn | well, i think --comfiness=5 is a bare minimum specifcation | 00:43 |
| fenn | a real user will have all sorts of other limits and preferences | 00:43 |
| kanzure | that's different | 00:43 |
| kanzure | that's a limit on the downloading of content of the skdb package | 00:43 |
| fenn | how much space they have, how much mass they can load on the spaceship, etc | 00:44 |
| kanzure | that's more like an SQL query: SELECT * FROM chair WHERE comfiness=5 | 00:44 |
| kanzure | and then it gets everything related to that. | 00:44 |
| fenn | hmm | 00:44 |
| fenn | i'm seeing a problem here where you really want to download all the .skdb files in the world in order to find the optimal solution | 00:44 |
| kanzure | really, comfiness is not a good example | 00:44 |
| fenn | the idea behind metadata files with blackbox specifications is so you only have to download all the metadata files in the world | 00:45 |
| kanzure | it'd be more like ... agx-get install chair --woodType=mahogony .. this isn't good either. hrm. | 00:45 |
| kanzure | sure | 00:45 |
| kanzure | but these metadata files just specify what's in the skdb file | 00:45 |
| kanzure | think of skdb == deb == zip file, basically (except not necessarily zipped, so that it can be easy to fetch stuff over http) | 00:46 |
| fenn | you could construct a query file (in say yaml) and submit that query to skdb (online) | 00:46 |
| fenn | then our servers crunch on the query | 00:46 |
| kanzure | sure | 00:46 |
| fenn | or it could be more distributed like freenet or kazaa supernodes | 00:46 |
| fenn | i'm not really up to that | 00:47 |
| kanzure | the parameters to agx-get are more for dealing with the metadata file, i.e. there are lots of things it specifies or does, and so you want to automate your usage of those types of metadata files | 00:47 |
| kanzure | but on the other hand | 00:47 |
| kanzure | yes, there is a need for further configuration | 00:47 |
| kanzure | autospec would investigate a specific portion of a metadata file | 00:47 |
| kanzure | and then agx-make or whatever would even further ... | 00:47 |
| kanzure | so I think you're thinking more about configuration to agx-make | 00:47 |
| fenn | isnt agx-make what actually calls agx-get? (eventually) | 00:48 |
| fenn | unless you're hacking around | 00:48 |
| kanzure | sure, there might be a certain amount of recursion involved | 00:48 |
| kanzure | but you said that agx-make would do GAs or whatever for optimization based off of local skdb packages chosen for the project v. availability and so on | 00:49 |
| kanzure | and that's where you do limits and preferences | 00:49 |
| kanzure | yes? | 00:49 |
| kanzure | well, other preferences could be dropped into the local copies of the skdb files, so that the software in there (anything extra - like 'html2wiki' might be a program in there) can be based off of those prefs/config | 00:50 |
| kanzure | either way. | 00:50 |
| fenn | maybe we just need to hack something together and see how it flies | 00:51 |
| kanzure | why aren't we just using apt/deb/dpkg/etc. straight up? | 00:52 |
| fenn | that's what i suggested originally | 00:53 |
| kanzure | I suspect the main reason is because in truth we want this to be agx-get but it'll fetch packages/repos ;) | 00:53 |
| fenn | oh, the problem with apt/dpkg is it requires root access and modifies the running OS | 00:53 |
| fenn | whereas i'd like everything nice and neat and sandboxed | 00:54 |
| kanzure | root access = bootstrapping access | 00:54 |
| kanzure | but anyway, yes | 00:54 |
| kanzure | I'd like that too | 00:54 |
| fenn | uhh.. root access == fucked up system | 00:54 |
| kanzure | sure | 00:54 |
| kanzure | another reason might be because the apt architecture isn't using a scripted language (or is it?) | 00:54 |
| fenn | i think it's perl | 00:55 |
| kanzure | it seems to be very hacky because it's used to bootstrap many debian installations | 00:55 |
| kanzure | well | 00:55 |
| kanzure | perhaps that's true. nevermind. | 00:55 |
| kanzure | apt, the frontend, is C | 00:55 |
| fenn | aptitude is also Y2K-compliant, non-fattening, naturally cleansing, | 00:55 |
| fenn | and housebroken. | 00:56 |
| fenn | it's all true! | 00:56 |
| fenn | heres what i was looking for: implemented-in::c++ | 00:56 |
| kanzure | I wonder if we care about configuration | 00:56 |
| kanzure | does it need to be automated? | 00:56 |
| kanzure | if it can be automated then why is it called configuration | 00:56 |
| kanzure | it's just accessing environmental variables and then ... doing what? | 00:57 |
| kanzure | won't we have a specific place to drop the Stuff? | 00:57 |
| kanzure | /some/place/on/system/skdb/packages/package-name/README | 00:57 |
| kanzure | etc. | 00:57 |
| fenn | ya | 00:57 |
| kanzure | so what other configuration. | 00:58 |
| fenn | ok, until further notice, it doesnt matter how you get the package data | 00:58 |
| fenn | just throw the files in a directory | 00:58 |
| kanzure | agreed | 00:58 |
| kanzure | so these files are everything, it's all there, by default, no way in hell we want them to change that | 00:58 |
| kanzure | it's all userspace anyway, they shouldn't be pushing files around much, unless generating stuff - that's a different matter of course :) | 00:58 |
| kanzure | I was thinking earlier today of a few possible implementations of the user's local cache of skdb | 00:59 |
| kanzure | I was thinking it would be helpful if we could have a flatfile database manager | 00:59 |
| kanzure | sqlite would be great, but it's a single file | 00:59 |
| kanzure | I suspect that git might be the solution, but it doesn't really handle queries over the projects | 01:00 |
| kanzure | do we just do flatfile searching or something? load up each file one by one and do the search? | 01:00 |
| kanzure | (load up each metadata file, of course, not the entire skdb filedump) | 01:00 |
| fenn | this is a structured query? like comfiness >= 5 | 01:00 |
| kanzure | don't think so | 01:00 |
| fenn | for just searching text, hard to beat grep | 01:01 |
| kanzure | individual packages would have to provide specific search functions - like for 'comfiness' - since those are serializations, which means they need their classes in order to work with that data | 01:01 |
| kanzure | so it's their job. not ours. | 01:01 |
| fenn | comfiness is an attribute inherited from 'chair' | 01:02 |
| fenn | or, 'furniture' really | 01:02 |
| kanzure | chair.yaml | 01:02 |
| kanzure | !!yaml/chair or whatever | 01:02 |
| kanzure | chair: | 01:02 |
| kanzure | - comfiness: 5 | 01:02 |
| kanzure | - datafile: 10241.CAD | 01:02 |
| fenn | um, so, what's searching what again? | 01:02 |
| kanzure | dunno, what are we doing | 01:02 |
| kanzure | we have this big giant collection of skdb files | 01:02 |
| kanzure | perhaps fully downloaded | 01:02 |
| kanzure | autospec, right? | 01:02 |
| kanzure | that's the next step, wasn't it? | 01:03 |
| fenn | let me consult my roadmap.. | 01:03 |
| fenn | yes | 01:04 |
| fenn | it would be nice to have some realistic metadata files too | 01:04 |
| fenn | as fodder for autospec | 01:04 |
| kanzure | assume we have realistic metadata files, they specify their unit-types and so on, all is well | 01:05 |
| kanzure | then what? | 01:05 |
| kanzure | how would the user say "put two and two together, does it make four?" | 01:05 |
| kanzure | I think we discussed this at one point, we definitely talked about simplifying units expressions to see if they held true or something | 01:05 |
| fenn | that's the next level down in the diagram, with the two hexagons? | 01:05 |
| kanzure | just passing to gnu units directly | 01:05 |
| kanzure | nah, I thought that's simulation? | 01:06 |
| kanzure | then what's autospec? | 01:06 |
| kanzure | it just validates the units? | 01:06 |
| kanzure | what does that mean? | 01:06 |
| fenn | autospec just makes sure you can understand the units, yes | 01:06 |
| fenn | it instantiates the code, cleanly | 01:06 |
| kanzure | 'autospec - validates the units for the packages, validates the yaml, gets additional python plugins if necessary when the yaml specifies some weird class that is not yet installed.' from the notes down below | 01:06 |
| kanzure | that's wrong | 01:06 |
| kanzure | hm | 01:06 |
| kanzure | instantiates what code? | 01:06 |
| fenn | objects that each represent an skdb package | 01:07 |
| kanzure | then what. | 01:07 |
| kanzure | simulations? | 01:07 |
| fenn | then the objects interact, perhaps with simulations | 01:07 |
| kanzure | uh | 01:08 |
| kanzure | that's not well defined at all | 01:08 |
| fenn | but it can be more logic like 'tab a fits in slot b' | 01:08 |
| fenn | ok, its poorly defined | 01:08 |
| fenn | you verify that package A's functionality is sufficient for package B's requirements | 01:09 |
| kanzure | 'Autospec evaluation of the metadata would just be for units and making sure that the final product is technically feasible. ' | 01:09 |
| fenn | uh technically feasible meaning just a sanity check | 01:09 |
| kanzure | yep | 01:10 |
| fenn | like, no infinite masses, etc | 01:10 |
| fenn | of course i wouldnt want to stifle innovation :) | 01:10 |
| kanzure | or weird connections between different parts - like going in random loops from mechanical -> chemical -> mechanical energy (optimization-checkers can be added later) | 01:10 |
| kanzure | of course | 01:10 |
| kanzure | there'd be levels of checking or something, like barebones "physically impossible - fatal flaw" stuff but then also "possibly detrimental energy loop at this portion, please make sure you are accounting this." | 01:11 |
| fenn | like a style checker? | 01:11 |
| kanzure | ? | 01:12 |
| fenn | bad style i'm mostly concerned with is over-specification and under-specification | 01:12 |
| kanzure | hm | 01:12 |
| kanzure | sure | 01:12 |
| fenn | example of a 'detrimental energy loop'? | 01:13 |
| kanzure | mechanical -> chemical -> mechanical -> chemical, without anything really detailing what's going on - you might not even know this is occuring or something. | 01:13 |
| kanzure | how would you specify that you want the projects together in the same project | 01:14 |
| fenn | see, that sounds like a diesel engine to me | 01:14 |
| kanzure | and how would you specify the connectedness | 01:14 |
| kanzure | in programming you just write up some messaging protocols to make sure it's all glued together or something | 01:14 |
| kanzure | but in this case, we need to be able to do very detailed stuff | 01:14 |
| kanzure | not only do we know about certain units (liters of hydrogen per sec through the pipe) but also positioning and other data | 01:15 |
| kanzure | this is starting to sound like the job-maker, not just a feasability tester ... if you can check feasability, then surely you broke it up in some way | 01:15 |
| fenn | we dont know positioning data from the metadata | 01:15 |
| kanzure | ah, I guess feasability checking in autospec can be 'experience-based' - based off of bug reports? | 01:15 |
| kanzure | that's true. | 01:15 |
| kanzure | so are we sure we really need this sort of vague validity checker? | 01:15 |
| kanzure | is it really that important? | 01:15 |
| fenn | yes, because anyone could write a totally fubared yaml file | 01:16 |
| kanzure | ok | 01:16 |
| kanzure | yes, true | 01:16 |
| kanzure | you could just upload a new skdb file that just has a metadata file really | 01:16 |
| fenn | and it will happen, and you and i will be doing it a lot | 01:16 |
| kanzure | and it would be a combo of other projects | 01:16 |
| kanzure | and be completely backwards / stupid | 01:16 |
| kanzure | so that's why I think it could be 'bug report driven' or something - "THIS IS NOT A GOOD IDEA". But also unit-evaluation. Anyway. | 01:17 |
| fenn | no, a validation error would kill that process | 01:17 |
| kanzure | k | 01:17 |
| fenn | you dont go ahead with garbage data | 01:17 |
| kanzure | is it garbage, unknown, or 'suggested against' ? | 01:18 |
| fenn | its like a segfault | 01:18 |
| kanzure | we still haven't come up with a way to specify the connectedness of the packages | 01:18 |
| kanzure | oh | 01:18 |
| kanzure | nevermind | 01:18 |
| kanzure | yaml object | 01:18 |
| kanzure | yes we did :-) | 01:18 |
| fenn | ya you put some yaml tags corresponding to (python) code objects | 01:18 |
| kanzure | sort of, I was thinking that you could have a list or 'Graph object' that could graph out the relations or something | 01:19 |
| kanzure | and these would be just simple energetic relationships, not necessarily the actual physical structure and shape | 01:19 |
| fenn | the yaml file is the graph | 01:19 |
| kanzure | however, if that was important to you, that could be done too | 01:19 |
| kanzure | sure | 01:19 |
| kanzure | yes | 01:19 |
| fenn | there is no 'actual physical structure' | 01:19 |
| kanzure | yaml also has a graph-theoretic basis IIRC from the yaml.org specs | 01:19 |
| kanzure | fenn: what if you wanted to make a duck? | 01:19 |
| kanzure | a wooden duck? | 01:19 |
| fenn | sure, a graph is the most general linked data structure | 01:20 |
| fenn | a wooden duck? | 01:20 |
| kanzure | yes, don't you have to specify the actual physical structure? | 01:20 |
| kanzure | a 3D object file of some sort? | 01:20 |
| fenn | not in the metadata | 01:20 |
| kanzure | I suppose that would be a single vertice | 01:20 |
| kanzure | ah, right | 01:20 |
| kanzure | okay, you're right | 01:20 |
| kanzure | this is *META* | 01:20 |
| fenn | you say cadfile: duck.3ds | 01:20 |
| fenn | (or something) | 01:20 |
| kanzure | quack quack | 01:20 |
| fenn | 3-dimension-topological-manifold: | 01:20 |
| fenn | hard to figure out what's data and what's metadata | 01:21 |
| kanzure | metadata talks about what the package is | 01:21 |
| kanzure | in formal terms. | 01:21 |
| kanzure | or what the package provides, etc. | 01:21 |
| kanzure | it provides these files, here's a description, here are your general options, ... | 01:21 |
| kanzure | whereas the actual content is probably to be considered the more 'low level' stuff - even if it's really important. 'meta' is the butter to make everything go down smoothly. | 01:22 |
| kanzure | although I tend to choke on heavily buttered breads. | 01:22 |
| kanzure | okay, so to make autospec work out for evaluating units in the metadata, you provide a main yaml file that represents your entire supposed project | 01:23 |
| kanzure | or an skdb file reference, either way, dunno | 01:23 |
| kanzure | then autospec goes through the graph layout and explores the relationships | 01:23 |
| kanzure | the relationships are referenced there, so it can have plugins to work with those classes of objects and so on - so this way new types of relationships can be formulated/suggested, so that a directed cyclical graph is not the extent of its abilities | 01:24 |
| kanzure | (but I would be interested in hearing an argument that you don't need much more than that ..) | 01:24 |
| kanzure | so once it has a picture of the relationships, it then does some binary search or binary comparison routine to chug through them and use the 'gnu units' program | 01:24 |
| kanzure | and generates some type of output report | 01:24 |
| kanzure | the chugging method is what worries me | 01:25 |
| fenn | it would be a directed acyclic graph (otherwise you have a dependency error - compiler stuff) | 01:25 |
| kanzure | the output report can be tiddied up a lot | 01:25 |
| kanzure | how would you chug through the graph - would you follow the links directly? | 01:25 |
| kanzure | and do it in order? | 01:25 |
| kanzure | that's basically a linearization of a graph | 01:25 |
| kanzure | uh, I remember reading about this | 01:25 |
| kanzure | it's not a Hamiltonian path | 01:25 |
| kanzure | but a http://en.wikipedia.org/wiki/Euler_path I think | 01:25 |
| kanzure | hm, no. | 01:26 |
| fenn | that's graph traversal heuristics | 01:26 |
| fenn | breadth first or depth first seem to be the main options | 01:26 |
| kanzure | ah, wait, that's the right one | 01:26 |
| kanzure | the idea is that you can reduce a 'parallel, highly connected graph' down to a 'linear equivalent' | 01:26 |
| kanzure | so in our case we want to unravel the graph down to some linear form | 01:26 |
| kanzure | and then chug through it step by step to check it all out | 01:26 |
| fenn | uh, that doesnt make sense | 01:26 |
| kanzure | now, if there's two things that need to work at the same time ... then you have to run simulations or something, or leave it up in the air | 01:27 |
| fenn | we want to find the shortest path from a to b | 01:27 |
| kanzure | okay, example time | 01:27 |
| kanzure | no | 01:27 |
| kanzure | example: | 01:27 |
| fenn | shortes path between two vertices | 01:27 |
| kanzure | a, b, c, d, e, f | 01:27 |
| kanzure | let's say they all point to the next | 01:27 |
| kanzure | but then c -> a and , uh, e -> b | 01:27 |
| kanzure | (additional links, I mean) | 01:27 |
| fenn | ok | 01:27 |
| kanzure | so in this case what we want to do is get it flat | 01:27 |
| kanzure | then we can go 'in order' | 01:28 |
| kanzure | we have to pick a way to traverse the graph and do the gnu units prog call, right? | 01:28 |
| fenn | ok so it assumes a sort of figure-8 with a tail | 01:28 |
| kanzure | but what are you going to do at the loops | 01:28 |
| kanzure | you have to section it off, go through it linearly still | 01:28 |
| kanzure | ultimately same result | 01:28 |
| fenn | where do you start? | 01:29 |
| kanzure | energy input into the system? | 01:29 |
| fenn | a b c are states, right? | 01:29 |
| fenn | so you have to start at one of them | 01:29 |
| kanzure | they are nodes representing metadata files | 01:29 |
| kanzure | but you seem to be thinking of a state machine of some sort ? | 01:30 |
| kanzure | that might be interesting? | 01:30 |
| fenn | we could have a state for 'nothing' meaning you are floating in vacuum between galaxies | 01:30 |
| kanzure | what do you mean by state | 01:30 |
| kanzure | state of what | 01:30 |
| kanzure | state of autospec, or state of the metadata files? | 01:30 |
| fenn | configuration state? i dunno, this graph theory stuff sucks | 01:30 |
| kanzure | you have to present autospec your design somehow | 01:31 |
| kanzure | and it's going to have to be connected to other various packages somehow, like chair + table | 01:31 |
| fenn | if there's a graph vertex for each permutation you have this combinatorial explosion | 01:31 |
| kanzure | yes | 01:31 |
| kanzure | that's a permutation of all possible states of the final machine | 01:31 |
| kanzure | and that's not what we're talking about, is it? | 01:31 |
| fenn | so, obviously we can't do that | 01:32 |
| kanzure | we're talking about "this package provides 20 volts" | 01:32 |
| fenn | although analytically it might work | 01:32 |
| fenn | with massively huge computer power | 01:32 |
| kanzure | and then we have another one saying "feed me 19 volts" | 01:32 |
| fenn | yes | 01:32 |
| kanzure | and the user already has plugged those two together | 01:32 |
| kanzure | and autospec just checks and says "hey, cool" | 01:32 |
| fenn | the relationship between those two vertices is 'satisfactory' so there is an edge between them | 01:33 |
| kanzure | we must emphasize to our users that autospec is a *recommended* tool, but it doesn't do the impossible | 01:33 |
| kanzure | because it's easy to misportray this as doing the impossible - of going through trillions of possible states | 01:33 |
| kanzure | not even Intel does that for their chips ... they just do design and unit testing at individual modules that they do extensive reuse on | 01:33 |
| fenn | the validator program (we've been calling it autospec) shouldnt also have to evaluate whether the two packages are compatible | 01:34 |
| fenn | that's something else | 01:34 |
| fenn | or is it the same sort of relationship? | 01:35 |
| fenn | hmmm.. | 01:35 |
| * fenn gets some chocolate | 01:35 | |
| kanzure | compatability would be obvious by whether or not there is a shared ancestor in the class hierarchy?? but I wasn't expecting there to necessarily be class-hierarchies (this could get bad, bloated, huge.) | 01:36 |
| kanzure | I think C++ has something called 'neighbor' or 'friend' classes which are ways of saying two things are similar but don't go calling it a child or something | 01:36 |
| kanzure | don't remember what that is. | 01:37 |
| kanzure | package compatability should be a factor within autospec | 01:37 |
| kanzure | whether or not it is the same sort of relationship - | 01:37 |
| kanzure | ah, we're talking about units here mainly | 01:37 |
| kanzure | so as long as some component can provide the units, who cares | 01:37 |
| kanzure | screw class hierarchies | 01:37 |
| kanzure | as long as the units can be provided | 01:37 |
| kanzure | as for physical connections and parts, that comes later | 01:38 |
| kanzure | that could be done in agx-make or something, or rely on user knowledge about using interfaces between parts and how beneficial it would be to minimize the number of jumps from one package to another in terms of input chaining (energy -> converter -> converter -> converter -> input for next part ... yikes.) | 01:38 |
| fenn | you need class hierarchies, funfortunately | 01:41 |
| fenn | otherwise its just a pile of numbers | 01:41 |
| kanzure | not in this case | 01:41 |
| kanzure | nope, it's just units | 01:41 |
| kanzure | GNU units recognizes these units | 01:41 |
| kanzure | so that's the end of that | 01:41 |
| fenn | just units works for simple things | 01:41 |
| kanzure | as opposed to what. | 01:42 |
| fenn | but a complex object like a car or a rocket has lots of different things going on | 01:42 |
| kanzure | it's unit evaluation, remember? feasability? | 01:42 |
| kanzure | that's true, but so what? | 01:42 |
| fenn | you have to say what 'power means' | 01:42 |
| kanzure | evaluate the cycles and loops of the graph in there as separate parts individually | 01:42 |
| kanzure | that's just the "separation of the subsystems" | 01:42 |
| kanzure | and then they are interacting in some way as a differential equation | 01:42 |
| fenn | is it engine power? transmission output? power to the road? thermal dissipation? | 01:42 |
| kanzure | and that's another level. | 01:42 |
| kanzure | think of it as a differentiable equation | 01:42 |
| kanzure | the zeroth derivative level is bare units | 01:42 |
| kanzure | the first derivative is where you have different systems interacting | 01:43 |
| kanzure | and evaluation would occur at each of these levels | 01:43 |
| kanzure | good idea? | 01:43 |
| kanzure | this makes it about modeling | 01:43 |
| kanzure | which I think makes sense. :) | 01:43 |
| fenn | yes, the whole point is to model possibilities | 01:43 |
| kanzure | so now we need ODE solvers and other fun things | 01:43 |
| fenn | to do that you must model things that can interact | 01:43 |
| kanzure | but luckily there's tons of code on the net for that | 01:43 |
| kanzure | sure | 01:44 |
| kanzure | that's where the graphs showing relationships comes in etc. | 01:44 |
| kanzure | MathML is a good example, I think it can represent differentiable equations of a system | 01:44 |
| fenn | we can do detailed numerical simulations but i dont think it's necessary | 01:44 |
| kanzure | nah, not detailed | 01:44 |
| kanzure | I just mean simple algebraic solvers of ODEs | 01:44 |
| kanzure | and then if the algebra checks out ok, all is well | 01:44 |
| fenn | oops ODE is an overloaded acronym | 01:44 |
| fenn | (open dynamics engine) | 01:44 |
| kanzure | ordinary differential equation | 01:44 |
| kanzure | ah | 01:44 |
| kanzure | remember the example from genetic reg-nets? cellerator or something? | 01:45 |
| kanzure | http://cellerator.org/ generated ODEs from some input data | 01:45 |
| kanzure | and then we do autospec on the first derivative 'graph' (MathML can be translated into a graph or something, I'm sure) | 01:46 |
| kanzure | ah, wasn't I reading a paper on algebraic field representations of ODEs | 01:46 |
| kanzure | anyway, it's definitely possible | 01:46 |
| fenn | i'd still call that numerical analysis since it's more than just a binary yes/no compatibility relationship? | 01:46 |
| kanzure | actually, I think it would be binary yes/no compatability because at each of the different levels it's doing something different | 01:46 |
| kanzure | erm | 01:46 |
| kanzure | wait, doing the same thing | 01:46 |
| kanzure | so on the zeroth level - that's basic units, yes? constants, stuff, making sure you don't drop a unit randomly or something | 01:47 |
| fenn | yes, unit checking | 01:47 |
| kanzure | first derivative - same thing | 01:47 |
| kanzure | except you're using the graph that makes up that dynamic system instead | 01:47 |
| kanzure | so you have rates | 01:47 |
| fenn | rates? | 01:47 |
| kanzure | and you're checking the rates against each other | 01:47 |
| kanzure | yes, rate of energy supplied or whatever | 01:47 |
| fenn | that's a unit | 01:47 |
| fenn | J/s | 01:47 |
| fenn | kW | 01:47 |
| kanzure | if you think it can be simplified all on to one layer, sure. | 01:48 |
| fenn | i do | 01:48 |
| kanzure | now what | 01:48 |
| fenn | i thought you were going somewhere like, then the second level you'd specify what the units represent | 01:49 |
| kanzure | no, I was thinking of doing differential equations for modeling of the system | 01:49 |
| fenn | where does that information come from? | 01:49 |
| kanzure | the yaml file representing this project of the user | 01:50 |
| kanzure | the user would have to come up with a good guess for a representative equation | 01:50 |
| fenn | so the user just types in a bunch of equations? | 01:50 |
| kanzure | and if he's wrong, autospec will error | 01:50 |
| fenn | yikes | 01:50 |
| kanzure | not really | 01:50 |
| kanzure | the user would connect the components together | 01:50 |
| kanzure | could be a gui for all I care | 01:50 |
| kanzure | they have relationships to each other, etc., but the user can't be bothered with going into them individually and debugging it all? just needs it to all tweak to some desired specs, so this is where your GA idea can be doubly used (not just for agx-make and materials selection) | 01:51 |
| kanzure | but yes, yikes | 01:51 |
| kanzure | dunno how to aviod this. | 01:51 |
| kanzure | let's just stick with that unit evaluation | 01:51 |
| kanzure | and that's it. | 01:51 |
| fenn | ok i'll try to come up with some unit validation code | 01:56 |
| kanzure | ok, so you get to define a python 'unit' class | 01:56 |
| kanzure | should be pretty simple ... it's just a text field really? | 01:56 |
| kanzure | but then there's certain things like provides/needs, etc. | 01:56 |
| kanzure | so have fun with that | 01:56 |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 02:19 | |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 07:06 | |
| kanzure | "Is this whole discussion a waste of time, fretting over rhetoric when we should just roll up our sleeves and build something? Well, I think a certain amount of attention to rhetoric is necessary if you don't want people turning up with pitchforks, or legislating whole technologies out of existence (or banishing them to more accommodating jurisdictions) ... not to mention the fact that large amounts of research are funded either b | 07:38 |
| kanzure | Bah, Greg isn't an open source advocate, it seesm. | 07:38 |
| kanzure | *seems. | 07:39 |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 07:47 | |
| -!- Splicer [n=p@h100n2c1o261.bredband.skanova.com] has joined #hplusroadmap | 16:37 | |
| -!- marainein [n=marainei@220-253-10-191.VIC.netspace.net.au] has quit ["Ex-Chat"] | 16:48 | |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 17:57 | |
| kanzure | http://video.google.com/videoplay?docid= | 17:59 |
| kanzure | -2874207418572601262&q= | 18:00 |
| kanzure | almaden+cognitive+computing | 18:00 |
| kanzure | The Emergence of Intelligence in the Neocortical Microcircuit, Henry Markram (1hr 10min.) | 18:00 |
| kanzure | He begins by speculating about how to convince an alien culture that we are intelligent: Send a blueprint of how to build us! I think most would agree that this is a very Transhumanist theme in the guise of an IBM Cognitive Computing Conference. It is very plausible. | 18:00 |
| kanzure | http://video.google.com/videoplay?docid=-2874207418572601262&q=almaden+cognitive+computing | 18:00 |
| fenn | mmm sending your own plans seems like a really stupid idea from a military perspective | 18:04 |
| fenn | what if the aliens respond with plans for a mind-control virus or something | 18:05 |
| fenn | also, they could just as easily determine that we aren't intelligent (since by and large we arent) | 18:06 |
| fenn | videos of conference talks are so low knowledge-bandwidth | 18:08 |
| kanzure | hm? | 18:18 |
| kanzure | low knowledge-bandwidth? | 18:18 |
| kanzure | re: communicating with aliens, dunno how much I care. if it turns to that, whatever, we'll cope | 18:18 |
| kanzure | but otherwise, don't worry too much about it | 18:18 |
| fenn | i always thought patch clamping was like a mems array of needles | 18:19 |
| fenn | otherwise what's the word "patch" from? | 18:19 |
| kanzure | oh, | 18:23 |
| kanzure | crap, I need to be watching this | 18:23 |
| kanzure | this is Markram | 18:23 |
| kanzure | well, basically the patch clamp technique is pretty easy | 18:23 |
| kanzure | you remember the ivf vids? | 18:23 |
| kanzure | where you have a micropipette close up to a cell? | 18:23 |
| kanzure | it's the same thing, where you suck in the membrane | 18:23 |
| kanzure | and then use some micropipette volumetric analysis or whatever | 18:23 |
| kanzure | I'm pretty sure. | 18:24 |
| kanzure | so Markram automated it. | 18:24 |
| fenn | markram explains things well | 18:32 |
| kanzure | Center/LFE jack. Crap. | 18:35 |
| kanzure | Yes, I suspect Markram is autistic. ;-) | 18:35 |
| kanzure | Okay, only now starting to watch it. | 18:35 |
| kanzure | I don't know what's better, Google Talks or TED. | 18:38 |
| fenn | ted is more "popular" | 18:41 |
| fenn | like popular science | 18:41 |
| fenn | but the theme is very attractive (to me) | 18:42 |
| kanzure | yes | 18:43 |
| kanzure | even my local art teacher is addicted to TED | 18:43 |
| kanzure | although she kind of sticks out around these parts | 18:43 |
| kanzure | He definitely knows the issue. | 18:45 |
| kanzure | He says stepping out of the paradigm. | 18:45 |
| kanzure | erm, cat is eating my pizza | 18:45 |
| kanzure | hm | 18:45 |
| fenn | your art teacher sticks out in austin or in waldorf-steiner-land | 18:45 |
| fenn | the nice thing about simulating a parallel computer is you can use a parallel computer to simulate it | 18:46 |
| fenn | brain simulation visualization seems like a good app for ted nelson's zigzag | 18:47 |
| fenn | i guess it's all just graph visualization in the end | 18:51 |
| kanzure | btw, I am in the public high school | 18:52 |
| kanzure | and it's not Austin, but rather 'Buda' | 18:52 |
| kanzure | but yes, she'd fit in at Waldorf, I guess | 18:52 |
| kanzure | artsy, or something | 18:52 |
| fenn | imagine that | 18:52 |
| kanzure | I want to be able to order Google Talks on dvd. | 18:54 |
| kanzure | hm, it froze at 17:19 | 18:54 |
| fenn | pause and drag the arrow around a bit | 18:54 |
| kanzure | aha | 18:54 |
| kanzure | thank you | 18:54 |
| kanzure | nope | 18:55 |
| fenn | hum. maybe the server's cranky | 18:55 |
| fenn | mine's stopped too | 18:56 |
| fenn | going back/fwd in the web browser started it up again | 18:57 |
| kanzure | yes | 19:02 |
| kanzure | 200 ion channels, hm | 19:03 |
| kanzure | I'm trying to decypher his research, if you haven't noticed | 19:03 |
| kanzure | in particular the Markram imitation project | 19:03 |
| kanzure | http://heybryan.org/mediawiki/index.php/Henry_Markram_computational_neurosci_imitation_project | 19:03 |
| kanzure | http://heybryan.org/mediawiki/index.php/Henry_Markram | 19:03 |
| kanzure | please feel free to add notes in realtime | 19:04 |
| fenn | there's enough of these conference video websites that they should have two video streams, one for the slideshow and another for the speaker | 19:15 |
| kanzure | I'm wondering how he has the funding for this | 19:22 |
| kanzure | he's bruteforcing it. | 19:22 |
| fenn | that's the whole idea | 19:24 |
| fenn | you can generate functional "neural" circuits using abstract models like ANN's which are much easier to run on computers (since you're not simulating a million messy blobs) | 19:24 |
| fenn | but he's just visualizing it and doing experiments in simulation | 19:25 |
| kanzure | no, he's doing repetitive automated experiments to collect data | 19:25 |
| kanzure | and then setting up models like any good programmer | 19:25 |
| fenn | the automated experiments are to make his simulation more complete | 19:26 |
| kanzure | no, he addressed completeness theorems earlier in the speech | 19:26 |
| kanzure | sigh | 19:26 |
| fenn | i dont think it's anything like programming. in programming you want to generalize and abstract things down to the simplest and most reusable form | 19:26 |
| fenn | he's simulating all these details that may not even matter | 19:26 |
| kanzure | sure | 19:27 |
| fenn | btw after you watch this, watch the geoff hinton google talk | 19:27 |
| fenn | if you have time | 19:28 |
| fenn | oh good, he's talking about making ASIC's that simulate neurons | 19:30 |
| fenn | an all-to-all network model wouldnt work very well with analog voltages.. you'd have to have some kind of bus and packet switching else you have a huge explosion in the amount of wiring (and then it starts looking like a big messy brain and very hard to etch on a chip) | 19:39 |
| fenn | you can get the same level of logical interconnection even if they arent physically connected | 19:40 |
| kanzure | yes | 19:56 |
| kanzure | my interpretation is that he wants to do hardlevel circuits from the ground up to model the neurons | 19:57 |
| kanzure | as in, instead of a general ALU in some cases, do the full program implemented on gates | 19:57 |
| fenn | it would be fun to do a sort of 'internet zero' that models a brain over UDP/IP | 19:57 |
| kanzure | but the problem with this is what if you want to do debugging? what if you want to add in new programs? you'd have to remanufacture everything | 19:57 |
| kanzure | http://heybryan.org/mediawiki/index.php/Henry_Markram_computational_neurosci_imitation_project my notes | 19:57 |
| fenn | that's why you use fpga's instead of ASIC's | 19:58 |
| fenn | also, you can put a lot of 'neurons' on a single fpga, like a miniature cortical column | 19:58 |
| fenn | the confusion comes about because the principles of an FPGA are much like the principles in neural wiring | 19:59 |
| * kanzure wants to agx-get install blue-brain :-( | 19:59 | |
| fenn | a highly interconnected "regular" network that has connections disabled in order to impose functional circuits | 20:00 |
| fenn | i'm really not that excited about brain simulation | 20:00 |
| fenn | where's it going? without abstraction you'll never get anywhere without just building a brain, and we have enough of those already | 20:01 |
| fenn | its like letting a bacterium multiply and claiming you've created a new life form | 20:02 |
| kanzure | sigh | 20:02 |
| kanzure | "where's it going?" | 20:02 |
| kanzure | uh | 20:02 |
| kanzure | you've become epitron | 20:02 |
| fenn | yes | 20:02 |
| kanzure | http://heybryan.org/recursion.html explains it | 20:02 |
| kanzure | recursive self-improvement, no? | 20:02 |
| kanzure | we use simulations of biological expeirments (since we can't grow exponential brains as easily as we can harvest electrons) | 20:03 |
| kanzure | so that we can figure out what possible changes might be useful or not | 20:03 |
| fenn | it just seems very far off | 20:03 |
| kanzure | particularly Markram talked about learning strategies to transform the input into some optimized form to convert it for the dendritic-map that the hu brain has | 20:03 |
| kanzure | you can see the dendritic-map via fMRI *for certain active portions* (an important condition) | 20:04 |
| fenn | like direct uploading? | 20:04 |
| kanzure | no | 20:04 |
| kanzure | well | 20:04 |
| kanzure | I thought you meant mind uploading shit | 20:04 |
| fenn | no, i mean like 'i know kung fu' | 20:04 |
| fenn | sry | 20:04 |
| kanzure | yes, he talked about a 'scene' in a microcircuit | 20:04 |
| kanzure | and this isn't really a scene | 20:04 |
| kanzure | but he was doing some very good generalizing IMHO | 20:04 |
| kanzure | it's not really a scene, but rather actors and different functions making up some 'subject' that the microcircuit is devoted to | 20:05 |
| kanzure | granted, the functional specifity might not be that exact - take a way a certain microcircuit and I doubt you'll suddenly forget how to do addition | 20:05 |
| fenn | uh... hasnt that been demonstrated? | 20:05 |
| kanzure | has it? for selectively removing a *single* circuit? | 20:06 |
| kanzure | a single minicolumn, I mean | 20:06 |
| kanzure | oh | 20:06 |
| kanzure | I guess we can use fMRI to locate the column | 20:06 |
| kanzure | then use surgery to get to it | 20:06 |
| fenn | not a single circuit (whatever that means) but a small 'lesion' from a mini-stroke or whatever | 20:06 |
| fenn | physically localized damage | 20:06 |
| fenn | resulting in loss of a specific abstract functionality | 20:07 |
| kanzure | another organizing principle that Markram mentioned, but didn't touch upon was how the voltage-leaking between synapses was important; the brain is there to 'guide' and 'select' the perceptions more or less -- I can't elaborate on this since I need to go back to that time in the vid, but it's basically his intense world hypothesis down to the molecular level | 20:07 |
| kanzure | hm, well, | 20:07 |
| kanzure | that's not very localized IMHO because that spans over tens of thousands of microcircuits | 20:07 |
| kanzure | but it's a good start | 20:07 |
| kanzure | anyway, within a microcircuit you're processing some sort of data ... he proposes that *targetting specifity* is what's important in intelligence differences between animals, not that they have more microcolumns or less since the microcolumnar structure is mostly conserved overall | 20:08 |
| kanzure | this molecular targetting specifity is the general rules by which you manage the Electromagnetic Dendritic Object/Map (it's really more of a map than an object, IMHO) | 20:08 |
| fenn | i didnt understand that part | 20:08 |
| kanzure | okay, so do you understand the comparison he made ? | 20:09 |
| kanzure | he was talking about the action potential / spike centric view | 20:09 |
| fenn | specificity for what? and how does it relate to humans being 99% identical genetically | 20:09 |
| kanzure | wherein the body of the neuron is what propogates the spikes, and the spikes encode the perception | 20:09 |
| kanzure | the 'brain wave theory' basically | 20:09 |
| kanzure | specifity for targetting the synapses | 20:09 |
| kanzure | for targetting dendrites and axons and whatever. | 20:09 |
| kanzure | this is how neurons grow and connect to each other - plasticity, see Gary Lynch et al. | 20:09 |
| kanzure | (LTP) | 20:09 |
| kanzure | anyway, Markram is very obviously opposed to the 'brain wave theory' | 20:10 |
| kanzure | because the wave theorists are all talking about action potentials and spiking | 20:10 |
| fenn | sure, he's connectionist | 20:10 |
| kanzure | but he's proposing that it's more about the dendrites and the connections | 20:10 |
| kanzure | yep | 20:10 |
| kanzure | the 'synaptic paradigm' | 20:10 |
| kanzure | so in this case, all of the perceptions are really encoded more in terms of the ion channels on the neurons | 20:10 |
| kanzure | this is *not* the same thing as Penrose and his quantum thinking bullshit | 20:10 |
| fenn | spikes are not digital signals, they're more like pwm or pcm (as in RC airplanes) | 20:11 |
| kanzure | the data is represented in analog form on dendrites, and the perceptions are animated by the spatiotemporal spikes. The thoughts occur on the dendrites themselves. We can get dendrite maps (MEG, fMRI), they go across dendrites. | 20:11 |
| kanzure | the 'animation' he showed in one of the slides as an example of his 'voxel' concept | 20:12 |
| kanzure | where the 'voxel' is just an abstracted microcircuit/column | 20:12 |
| kanzure | and he showed a person as the dendritic map or something, and then the action potential was 'the animating force' - the perception was 'animated' by the spatiotemporal spikes | 20:12 |
| kanzure | which kind of jumbled it up it seemed - but I don't know if that was the message he was intending to send heh | 20:12 |
| kanzure | (jumbled up the image that he showed, an animated gif I'm guessing) | 20:12 |
| fenn | lets see if our perceptions of markram's talk match up: dendrite connections are like the arrangement of gears and levers, and spikes are the movement that turns all the gears, right? (more or less) | 20:13 |
| kanzure | yes, the spikes/voltages are what carry *minimal* information about what's going on, I made an analogy to rss feed aggregation :-) | 20:13 |
| kanzure | and then there's synaptic voltage leakage because synapses are 200 nm apart or whatever, meaning they influence each other -- the microcircuit is guided by a "rule set" for plasticity so that it can control this voltage and aggregation | 20:14 |
| kanzure | he doesn't use the word aggregation, but connectionism -> aggregationism (see the current state of the web and rss ... ;-)) | 20:14 |
| fenn | ok, go watch geoff hinton: http://www.youtube.com/watch?v=AyzOUbkUf3M | 20:14 |
| kanzure | now, in the 'intense world syndrome' paper - he talks about how in autism these circuits are wild, rogue, working on their own, but they are so very close together with very precise targetting that they spill over and amplify signals (and lots of pain etc.) | 20:15 |
| kanzure | but not pain in the sense of ouch my hand, | 20:15 |
| kanzure | but pain in the sense of .. hm. In the sense of Zindell. | 20:15 |
| kanzure | I'll watch it in a few secs, there's a few other things I want to go over | 20:15 |
| fenn | that's contrary to the other guy you mentioned last week, who says the connection strength is less (but stronger inside a particular minicolumn) | 20:15 |
| fenn | less between minicolumns | 20:16 |
| kanzure | no, long-distance connections are less | 20:16 |
| kanzure | right, | 20:16 |
| kanzure | there's a specific model where inhibitory neurons don't work as well at the edges of the minicolumns | 20:16 |
| kanzure | lemme go see | 20:16 |
| kanzure | hypersensitivity results from reductions in the peripheral zone of inhibitory and disinhibitory activity allowing spill-over (stimuli spill) from one minicolumn to the next and allowing an amplification effect, " ... so a reduction in GABAergic inhibitory activity could also result in a loss of inhibition and greater amplification." | 20:16 |
| kanzure | inhibitory/disinhibitory activity @ the edge of the minicolumn | 20:17 |
| kanzure | 'narrow vertical stream of inhibition through the cortex, as well as a vertically directed disinhibition of those pyramidal cells' | 20:17 |
| kanzure | this was the 'dendritic ecology' and 'perception ecology' that he mentioned | 20:17 |
| kanzure | http://heybryan.org/intense_world_syndrome.html#minicolumnar_ecology | 20:18 |
| fenn | thanks | 20:18 |
| kanzure | ' A simplified representation of a minicolumn is thus of a processing core surrounded by a GABAergic interneuron circumferential zone of inhibitory and disinhibitory activity.' | 20:18 |
| kanzure | I once made a freudian-slip with 'deceptors' instead of 'receptors' ... but it was an insightful slip :-) | 20:19 |
| kanzure | '... how excessive neuronal processing may render the world painfully intense when the neocortex is affected and even aversive when the amygdala is affected, leading to social and environmental withdrawal. Excessive neuronal learning is also hypothesized to rapidly lock down the individual into a small repertoire of secure behavioral routines that are obsessively repeated.' | 20:20 |
| fenn | idionomics: the names of idiotic concepts.. | 20:20 |
| kanzure | http://ideonomy.mit.edu/ | 20:21 |
| fenn | its too dead-tree for me | 20:21 |
| kanzure | ? | 20:21 |
| fenn | i've been spoiled by outline views | 20:21 |
| kanzure | ah, yes | 20:22 |
| kanzure | but do *not* 'animate it' with semantics and RDF and other nonsense | 20:22 |
| kanzure | that will not work, you'll fall into the curse of Xanadu. | 20:22 |
| fenn | 13MB pdf is lame | 20:22 |
| kanzure | yes, me too - http://heybryan.org/todo.html etc | 20:22 |
| fenn | especially when it downloads at 15kB/s | 20:23 |
| kanzure | oh, re: "it is very plausible" up at the top ---> That was *not* my commentary. | 20:23 |
| kanzure | re: alien intelligence stuff | 20:23 |
| kanzure | when I was linking to the Markram vid | 20:23 |
| fenn | hnb is a poor imitation of the 1968 "oN-Line-System" | 20:23 |
| kanzure | I'll have to check that out | 20:24 |
| kanzure | hnb sucks in general - it loads up the entire file no matter how many tens of thousands of nodes you have | 20:24 |
| kanzure | and even though it's only a few megabytes of RAM, these programs *suck* at managing multimegabyte ram variables | 20:24 |
| fenn | hmm.. the data isnt stored in the file in order of levels of hierarchy? | 20:25 |
| fenn | that's basic database stuff | 20:25 |
| fenn | key sorting | 20:25 |
| fenn | sql calls it "indexing" i think | 20:25 |
| kanzure | the data is stored in one single flatfile | 20:25 |
| kanzure | sql sucks - just use a flatfile system all around ... why have all 20,000 entries in a single table file? Sometimes that extra metadata provided by the file system can be useful, but yes it uses lots of overhead | 20:26 |
| kanzure | trade offs :( | 20:26 |
| kanzure | sqlite should have a flatfile extension so that it doesn't use all only one file | 20:26 |
| kanzure | I also hear it used to have logging problems with pidgin/gaim - it would lock up, take forever to write, etc. | 20:26 |
| kanzure | yuck. | 20:26 |
| fenn | the really bad thing about sql is no revision control | 20:26 |
| fenn | if you modify something *poof* | 20:27 |
| kanzure | have you checked out the mediawiki table structure for their revision control? | 20:27 |
| kanzure | it's nice that they tried of course but ... | 20:27 |
| fenn | so you have to make huge binary-blob backups of the entire DB | 20:27 |
| kanzure | why the hell would you implement RCS on top of an sql-db on top of a file system | 20:27 |
| fenn | no, i generally shun anything SQL (part of why i dont use mediawiki) | 20:27 |
| kanzure | if anything mysql should be doing revision control | 20:27 |
| kanzure | but that's even *more* overhead | 20:28 |
| kanzure | (nightly backups of databases is a recommended practice, but how many people are doing that) | 20:28 |
| fenn | hmm.. overhead is not bad if it changes the way you work | 20:28 |
| fenn | qualitatively | 20:28 |
| fenn | i'll trade quantitative performance hit for qualitative improvement any day | 20:28 |
| kanzure | I would much rather watch the engelbart vid next | 20:52 |
| fenn | it is more immediately relevant in the short-term | 20:52 |
| kanzure | ugh, another hour | 20:53 |
| kanzure | hrm | 20:53 |
| kanzure | I really need to get a coding | 20:53 |
| kanzure | hey, quick question | 20:53 |
| kanzure | can a git repo have a git file within it | 20:53 |
| fenn | yes but that would be rather silly, since you cant do much with binary diffs | 20:53 |
| kanzure | and if I download the subgit, and update it, and the maingit branch totally changes while I'm editing my copy of the subgit, what happens when I want to push the subgit | 20:54 |
| fenn | you mean a recursive git repo? | 20:54 |
| kanzure | yes | 20:54 |
| fenn | no, that wouldnt work | 20:54 |
| kanzure | sucks | 20:54 |
| kanzure | it would all have to be within git? | 20:54 |
| kanzure | I mean, one main git? | 20:54 |
| fenn | eh? | 20:54 |
| kanzure | or lots of smaller gits, obviously | 20:54 |
| kanzure | see, I was thinking that it would be useful if skdb could contain 'git files' for each of the skdb projects | 20:55 |
| fenn | git is like a filesystem | 20:55 |
| kanzure | not that we host them necessarily, but rather that we do in fact have cloned copies of them | 20:55 |
| kanzure | and that we get periodic updates from where-ever on the internet they are working | 20:55 |
| kanzure | so our users can get the updates too, it's all based on git | 20:55 |
| kanzure | rather than just a plain, stinky little skdb file (a zip, basically) | 20:55 |
| kanzure | tar may be a more ... pun intended - apt comparison? | 20:55 |
| fenn | yes that's why i chose git | 20:56 |
| fenn | we can pull the developments from other people and make them part of the autogenix distro | 20:56 |
| kanzure | so ... we can't have git within git | 20:56 |
| kanzure | ah | 20:56 |
| kanzure | okay | 20:57 |
| kanzure | but users want to be able to git-clone, yes? | 20:57 |
| fenn | but all the work is going on somewhere else (on that project) | 20:57 |
| kanzure | that's how they download the skdb stuffs | 20:57 |
| kanzure | actually | 20:57 |
| kanzure | that depends on whether or not git can partially clone a project | 20:57 |
| fenn | you can partially clone something, i think its called 'tracking' | 20:57 |
| kanzure | excellent | 20:57 |
| kanzure | so if the users want to do development, they just go get the latest stable one | 20:58 |
| kanzure | hrm | 20:58 |
| kanzure | is that reasonable? | 20:58 |
| kanzure | I'd much rather have a direct link to the repos out there | 20:58 |
| fenn | if users want to do development, they get the devel branch | 20:58 |
| fenn | otherwise they're working in parallel (bad) | 20:58 |
| kanzure | right, but the devel branch is not local | 20:58 |
| kanzure | ah, well, this is a nonproblem really | 20:58 |
| kanzure | if the devel branch is nonlocal then it's being worked on | 20:58 |
| kanzure | if it's not being worked on and has no hosting, then it doesn't really exist | 20:59 |
| kanzure | and thus the user should just be happy with git-clone for the skdb file | 20:59 |
| kanzure | which is 'pretty close' - or, really, as close as you can get in that scenario | 20:59 |
| fenn | we could pull devel branches into autogenix too perhaps, like debian unstable | 20:59 |
| kanzure | (unless there's social data in the yaml file so that you can go contact the old developers) | 20:59 |
| kanzure | wait | 20:59 |
| kanzure | does deb unstable proactively, automatically go out and download from rcs repos? | 20:59 |
| kanzure | I mean, not the unstable distro | 20:59 |
| kanzure | but the repo for unstable. | 20:59 |
| kanzure | that'd be awesome :-) | 21:00 |
| kanzure | I bet they are doing human filtering though | 21:00 |
| fenn | i think it's manual | 21:00 |
| fenn | its not hyper-unstable :) | 21:00 |
| kanzure | hehe | 21:00 |
| kanzure | btw, the fact that debian works on human work alone is impressive | 21:00 |
| kanzure | with manual updates to the repos | 21:00 |
| fenn | it is quite structured and automated (not automatic, but automated) | 21:00 |
| kanzure | although dependency hell is still an issue | 21:00 |
| kanzure | anyway. | 21:01 |
| kanzure | knowing all of this, I'll go figure out agx-get now, I was jotting down some pseudocode earlier today | 21:01 |
| fenn | there could be pointers in a package metadata to the current development repo | 21:01 |
| kanzure | in particular, it seems to be a layer on top of git calls, but users should be able to do the same git calls on their own if they want | 21:01 |
| kanzure | yes | 21:01 |
| kanzure | or various other branches too if it's in dispute | 21:02 |
| kanzure | "this branch is disputed ... please see this list:" | 21:02 |
| kanzure | or whatever | 21:02 |
| fenn | usually programmers maintain a stable branch that people actually use, while working on the unstable, so they can merge links to the new repo back into the stable package | 21:02 |
| fenn | sure that's the package maintainer's job | 21:02 |
| fenn | i think it will be hard to find people to act as package maintainers | 21:03 |
| kanzure | that's true | 21:03 |
| kanzure | how much maintenance is required for a 1962 convertible | 21:03 |
| fenn | many original developers just want to work on their thing, and care less about this little complicated project they cant quite undersand | 21:03 |
| kanzure | well, in truth it's more than a 1962 convertible | 21:03 |
| kanzure | it's about finding new developments and making it more specific | 21:04 |
| kanzure | so you have to have broad interests | 21:04 |
| kanzure | right | 21:04 |
| fenn | hmm.. pull out that dirty piston engine and swap in an electric one with a speaker to play engine-noises | 21:04 |
| fenn | zero maintenance :) | 21:04 |
| kanzure | perhaps, if the electric one has been sufficiently characterized | 21:05 |
| fenn | right | 21:05 |
| kanzure | what I mean is that with a chair, if we were in the 1600s, we don't know about cells | 21:05 |
| kanzure | erm | 21:05 |
| kanzure | well, that's a wood chair | 21:05 |
| kanzure | suppose another type of chair, polyether, and we don't know about the material sci | 21:05 |
| kanzure | anyway, you get it. | 21:05 |
| fenn | cells, like where monks sit | 21:05 |
| kanzure | heh | 21:05 |
| fenn | (origin of the term, btw) | 21:05 |
| kanzure | who was it that made that observation | 21:05 |
| kanzure | John Brown? | 21:05 |
| kanzure | van Leuwenhook? | 21:05 |
| fenn | leewenhoek? | 21:05 |
| kanzure | hehe | 21:06 |
| kanzure | oh shit | 21:06 |
| kanzure | disk space | 21:06 |
| fenn | well at least i'm not dutch | 21:06 |
| kanzure | 3.1 M available | 21:06 |
| kanzure | SHIT | 21:06 |
| fenn | apt-cache clean! | 21:06 |
| fenn | rm ~/cache/* -rf | 21:07 |
| kanzure | noooo | 21:07 |
| kanzure | I just deleted OpenFOAM. :( | 21:07 |
| kanzure | this is weird, I had 500 meg available just the other day | 21:08 |
| fenn | oh it's apt-get clean | 21:08 |
| fenn | surely you can delete something not software? | 21:08 |
| kanzure | these CFD packages are 500 meg each | 21:08 |
| fenn | ugh why | 21:08 |
| kanzure | that's a great question | 21:08 |
| fenn | its like 5 equations | 21:08 |
| fenn | stupid opencascade, what a clusterfuck | 21:09 |
| kanzure | http://www.opencfd.co.uk/openfoam/ | 21:09 |
| kanzure | 'The OpenFOAM (Open Field Operation and Manipulation) CFD Toolbox can simulate anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics, electromagnetics and the pricing of financial options.' | 21:09 |
| kanzure | salome was 1.5 GB | 21:09 |
| fenn | salome uses opencascade | 21:09 |
| fenn | i bet they all have their own little copy of parts of opencascade (subtly modified to be incompatible) | 21:09 |
| kanzure | removing elmer - another 500 MB | 21:10 |
| kanzure | removing freefem (which has a good website, btw) - another 200 MB | 21:10 |
| kanzure | I never never want to see that again | 21:11 |
| kanzure | :-( | 21:11 |
| fenn | how big is your disk? | 21:11 |
| kanzure | 40 GB | 21:11 |
| kanzure | but I have a 500 GB external disk/'server' thing (it's not really a server, it's a POS) | 21:11 |
| fenn | bleh. "pyrex vs elmer" doesnt return what i want at all.. | 21:12 |
| kanzure | ah, removed a 300 MB vid from the mol-neuropsychopharm lectures I emailed about to hplusroadmap yesterday.. | 21:13 |
| fenn | elmer looks really dumb | 21:13 |
| kanzure | I do *not* like deleting | 21:13 |
| kanzure | yes, but I was recursing through as much CFD software as I possibly could | 21:13 |
| fenn | i like the adaptive meshing of FEM models, i wish they had cad software that did that with shapes to provide an optimal structure for constraining points/interfaces | 21:18 |
| kanzure | fenn: my todo list is now basically reading up on git commands ... the design for agx-get was done from the start when I showed that yes, it's possible to parse a yaml exception error string for the package that needs to be fetched; but now it needs to be able to call git commands to get skdb packages in part or in whole, as specified by the default configuration (or overwritten by user commandline params to agx-get). | 21:18 |
| kanzure | http://heybryan.org/mediawiki/index.php/2008-04-25 has a lot of collected links on git tutorials, can you quickly click through and tell me if anything looks like bullshit / particularly good worthwhile ? | 21:19 |
| fenn | git tutorials are hard to understand because the people using it are primarily doing very complex things with merging branches | 21:20 |
| fenn | all you really need to know to start is pull, push, add, commit, mv | 21:20 |
| kanzure | how do I do those commands | 21:21 |
| kanzure | git pull | 21:21 |
| kanzure | git push | 21:21 |
| kanzure | git add | 21:21 |
| kanzure | etc.? | 21:21 |
| fenn | right | 21:21 |
| fenn | see man git-pull for example | 21:21 |
| fenn | also i think this would be a good model to follow for command line usage | 21:22 |
| kanzure | dash? | 21:22 |
| fenn | so there's unique man-pages for the functions | 21:22 |
| fenn | instead of one huge page like 'man bash' | 21:22 |
| fenn | i hate the bash man page | 21:22 |
| fenn | the best way to learn is really to play around with it | 21:24 |
| fenn | and then just refer to the git cheat sheet | 21:24 |
| fenn | you can clone my autogenix ikiwiki to have some material to play with (i can make a tarball if your git is still lacking http support) | 21:25 |
| fenn | http://fennetic.net/pub/irc/autogenix.git.tgz | 21:27 |
| fenn | that's just the .git directory so you'd have to clone it to make a working directory (checkout in cvs-speak) | 21:28 |
| kanzure | hrm, that's not a bad idea | 21:33 |
| kanzure | IIRC, ikiwiki was working ok | 21:33 |
| kanzure | but not the editing feature | 21:33 |
| kanzure | hrm, I'll play around with it soon | 21:34 |
| kanzure | let me get to git :) | 21:34 |
| fenn | i mean, its just a simple repo with stuff in it that you may already be familiar with the revision history | 21:34 |
| fenn | uh there isnt a whole lot there though, so whatever | 21:35 |
| kanzure | the problem was that I couldn't make a git repo apparently | 21:35 |
| kanzure | weird stuff. | 21:35 |
| fenn | ugh one thing universities could do to massively improve the dissemination of knowledge is NOT DELETE STUDENTS WEBSITES | 21:38 |
| kanzure | why do they do this | 21:43 |
| kanzure | how much space is it costing them | 21:43 |
| fenn | "policy" | 21:45 |
| fenn | no free lunch! | 21:45 |
| fenn | its like worrying about september 11th while millions of people die every day from preventable causes | 21:46 |
| fenn | oop.. hundred thousand | 21:47 |
| fenn | http://www.theonion.com/content/node/39236 | 21:48 |
| kanzure | I guess it's the same reason why they kill small articles on Wikipedia, despite their obsessive compulsive tendency to gather articles on nonsense topics | 21:57 |
| kanzure | pop culture stuff that isn't really too 'pop' | 21:57 |
| kanzure | http://sifter.org/ but I suspect fenn already knows these guys | 22:02 |
| fenn | i definitely have no expectation to find just one 'truth' | 23:02 |
| kanzure | dunno about desires to find 'truth' - maybe personal truths, but anyway, there's some interesting people aggregated here | 23:04 |
| fenn | to talk precisely about objective reality is very difficult.. look at the fiasco with godel/principia mathematica | 23:04 |
| fenn | we cant even agree on subatomic particles | 23:04 |
| fenn | now expect people to agree about emergent phenomena? no way | 23:05 |
| kanzure | hm? | 23:05 |
| kanzure | agree, where? | 23:05 |
| kanzure | from the sifter.org site? | 23:05 |
| fenn | so, that's why i am highly suspect when people talk about 'truth' because i feel they have an agenda, to get me to believe their interpretation | 23:05 |
| kanzure | ah | 23:06 |
| kanzure | 'the desire to know the truth above all other considerations' | 23:07 |
| kanzure | yikes, that does sound wrong | 23:07 |
| kanzure | from what I have seen of the group, that statement is not representative | 23:07 |
| kanzure | and it's not so much a group as it is an activity meetup gang, or occassional philosophy gang, | 23:07 |
| kanzure | but really there's folks like A. Garret Lisi on there, Tony, Jef, Eliezer, ... | 23:07 |
| fenn | ah. what do logic nerds do for fun? :) | 23:08 |
| fenn | "dinner, BBQ, movie, concert" | 23:09 |
| kanzure | where does that answer come from? | 23:09 |
| fenn | What do you "meet" about? | 23:09 |
| kanzure | oh | 23:09 |
| kanzure | the list | 23:09 |
| kanzure | the faq. | 23:09 |
| fenn | well, i'm not going to go pouring lots of energy into some random web form just so i can join an elitist secretive group | 23:11 |
| kanzure | you're not missing much specifically | 23:11 |
| kanzure | not like they're doing any projects, it's more community stuff, I don't know what to call it | 23:11 |
| kanzure | just thought you'd have known :) | 23:11 |
| fenn | well, it doesnt look like much on the surface | 23:12 |
| fenn | compare to, say, myspace | 23:12 |
| -!- marainein [n=marainei@220-253-10-191.VIC.netspace.net.au] has joined #hplusroadmap | 23:52 | |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
