--- Day changed Fri Apr 25 2008 00:00 < 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:01 < fenn> apparently the practice of "RFC" originated in his group 00:06 < kanzure> http://heybryan.org/art/ scifi 00:06 < kanzure> old stuff - http://heybryan.org/art/starwars/ 00:13 < fenn> i never really "got" star-wars 00:14 < kanzure> when did you see it first? 00:15 < fenn> oh, probably 1995 or so 00:16 < 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:17 < 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:18 < 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:19 < kanzure> Hm, Kevin Kelly rejected my comment submission to his blog entry re: Weizenbaum. 00:20 < fenn> new legos: http://www.notcot.com/images/dragoncom.jpg 00:20 < kanzure> you're shitting me. 00:21 < 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:23 -!- Aulere [n=dragon_d@131.229.176.252] has quit [] 00:24 < 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:25 < fenn> ah i havent been following my mail too diligently 00:26 < 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:27 < fenn> heh i think that's a pun 00:27 < kanzure> or they're being jerks. 00:29 < kanzure> is it okay if we demand agx-get to do linear downloading of files? 00:30 < 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:31 < kanzure> which manages the agx-get sessions and make sure they are not doing anything ridiculously redundant 00:33 < 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:36 < kanzure> nono, just think about downloading strategies 00:36 < kanzure> ah, screw it 00:36 < kanzure> linear is fine 00:39 < 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:40 < 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:41 < 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:42 < 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:43 < 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:44 < 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:45 < 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:46 < 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < fenn> maybe we just need to hack something together and see how it flies 00:52 < kanzure> why aren't we just using apt/deb/dpkg/etc. straight up? 00:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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 01:00 < 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:01 < 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:02 < 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:03 < kanzure> that's the next step, wasn't it? 01:03 < fenn> let me consult my roadmap.. 01:04 < fenn> yes 01:04 < fenn> it would be nice to have some realistic metadata files too 01:04 < fenn> as fodder for autospec 01:05 < 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:06 < 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:07 < 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < 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:19 < 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:20 < 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:21 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 < 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:32 < 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:33 < 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:34 < 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:35 < fenn> or is it the same sort of relationship? 01:35 < fenn> hmmm.. 01:35 * fenn gets some chocolate 01:36 < 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:37 < 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:38 < 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:41 < 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:42 < 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:43 < 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:44 < 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:45 < kanzure> remember the example from genetic reg-nets? cellerator or something? 01:45 < kanzure> http://cellerator.org/ generated ODEs from some input data 01:46 < 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < 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:56 < 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 02:19 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] 07:06 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap 07:38 < 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:39 < kanzure> *seems. 07:47 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] 16:37 -!- Splicer [n=p@h100n2c1o261.bredband.skanova.com] has joined #hplusroadmap 16:48 -!- marainein [n=marainei@220-253-10-191.VIC.netspace.net.au] has quit ["Ex-Chat"] 17:57 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap 17:59 < kanzure> http://video.google.com/videoplay?docid= 18:00 < 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:04 < fenn> mmm sending your own plans seems like a really stupid idea from a military perspective 18:05 < fenn> what if the aliens respond with plans for a mind-control virus or something 18:06 < fenn> also, they could just as easily determine that we aren't intelligent (since by and large we arent) 18:08 < fenn> videos of conference talks are so low knowledge-bandwidth 18:18 < 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:19 < fenn> i always thought patch clamping was like a mems array of needles 18:19 < fenn> otherwise what's the word "patch" from? 18:23 < 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:24 < kanzure> I'm pretty sure. 18:24 < kanzure> so Markram automated it. 18:32 < fenn> markram explains things well 18:35 < 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:38 < kanzure> I don't know what's better, Google Talks or TED. 18:41 < fenn> ted is more "popular" 18:41 < fenn> like popular science 18:42 < fenn> but the theme is very attractive (to me) 18:43 < 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:45 < 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:46 < fenn> the nice thing about simulating a parallel computer is you can use a parallel computer to simulate it 18:47 < fenn> brain simulation visualization seems like a good app for ted nelson's zigzag 18:51 < fenn> i guess it's all just graph visualization in the end 18:52 < 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:54 < 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:55 < kanzure> nope 18:55 < fenn> hum. maybe the server's cranky 18:56 < fenn> mine's stopped too 18:57 < fenn> going back/fwd in the web browser started it up again 19:02 < kanzure> yes 19:03 < 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:04 < kanzure> please feel free to add notes in realtime 19:15 < 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:22 < kanzure> I'm wondering how he has the funding for this 19:22 < kanzure> he's bruteforcing it. 19:24 < 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:25 < 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:26 < 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:27 < kanzure> sure 19:27 < fenn> btw after you watch this, watch the geoff hinton google talk 19:28 < fenn> if you have time 19:30 < fenn> oh good, he's talking about making ASIC's that simulate neurons 19:39 < 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:40 < fenn> you can get the same level of logical interconnection even if they arent physically connected 19:56 < kanzure> yes 19:57 < 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:58 < 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:59 < 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 :-( 20:00 < 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:01 < 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:02 < 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:03 < 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:04 < 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:05 < 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:06 < 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:07 < 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < 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:19 < kanzure> I once made a freudian-slip with 'deceptors' instead of 'receptors' ... but it was an insightful slip :-) 20:20 < 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:21 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:52 < kanzure> I would much rather watch the engelbart vid next 20:52 < fenn> it is more immediately relevant in the short-term 20:53 < 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:54 < 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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. 21:00 < 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:01 < 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:02 < 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:03 < 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:04 < 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:05 < 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:06 < 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:07 < fenn> rm ~/cache/* -rf 21:07 < kanzure> noooo 21:07 < kanzure> I just deleted OpenFOAM. :( 21:08 < 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:09 < 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:10 < kanzure> removing elmer - another 500 MB 21:10 < kanzure> removing freefem (which has a good website, btw) - another 200 MB 21:11 < 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:12 < fenn> bleh. "pyrex vs elmer" doesnt return what i want at all.. 21:13 < 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:18 < 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:19 < 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:20 < 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:21 < 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:22 < 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:24 < 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:25 < 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:27 < fenn> http://fennetic.net/pub/irc/autogenix.git.tgz 21:28 < fenn> that's just the .git directory so you'd have to clone it to make a working directory (checkout in cvs-speak) 21:33 < 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:34 < 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:35 < 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:38 < fenn> ugh one thing universities could do to massively improve the dissemination of knowledge is NOT DELETE STUDENTS WEBSITES 21:43 < kanzure> why do they do this 21:43 < kanzure> how much space is it costing them 21:45 < fenn> "policy" 21:45 < fenn> no free lunch! 21:46 < fenn> its like worrying about september 11th while millions of people die every day from preventable causes 21:47 < fenn> oop.. hundred thousand 21:48 < fenn> http://www.theonion.com/content/node/39236 21:57 < 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' 22:02 < kanzure> http://sifter.org/ but I suspect fenn already knows these guys 23:02 < fenn> i definitely have no expectation to find just one 'truth' 23:04 < 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:05 < 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:06 < kanzure> ah 23:07 < 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:08 < fenn> ah. what do logic nerds do for fun? :) 23:09 < 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:11 < 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:12 < fenn> well, it doesnt look like much on the surface 23:12 < fenn> compare to, say, myspace 23:52 -!- marainein [n=marainei@220-253-10-191.VIC.netspace.net.au] has joined #hplusroadmap