--- Day changed Thu Apr 24 2008 | ||
kanzure | so that agx-get specifies the exact gui/cli library, but provides functions that the scripts call | 00:00 |
---|---|---|
kanzure | to do #2 I want to do a review of common gui/cli libraries and the input parameters that they need | 00:00 |
kanzure | this way I don't screw us over | 00:00 |
kanzure | so once I do that, I'll write up a python interface layer for that purpose and publish the specs etc. | 00:09 |
kanzure | then, uh, we'll start to write some interpreters for parts of the (skdb package file)'s metadata file. | 00:09 |
kanzure | we'll also release the first agx-get code | 00:09 |
kanzure | i think. | 00:09 |
kanzure | another idea I had was to use yaml to serialize io objects .. but then you start getting into weird territory that might be fun to try out with, I dunno, GNU Hurd or something about the time Duke Nukem Forever comes out ... | 00:10 |
fenn | you mean use yaml as a communication protocol? | 00:11 |
kanzure | not so much | 00:11 |
kanzure | uh, it's a stupid idea, I'm kinda embarrased to explain | 00:11 |
kanzure | but | 00:11 |
kanzure | what if we could assume a java vm or something | 00:11 |
kanzure | and then we could have yaml serialized objects that encode the interfaces themselves for user input and so on | 00:12 |
kanzure | it's not too implementable. | 00:12 |
kanzure | I'm going with the other method. | 00:12 |
kanzure | some good places to review: the HTML form specs - what are all of the types of form elements? You have text, big fields, select, radios, buttons, character input, line input, file input (stdin), ... | 00:13 |
kanzure | heck, scripted input | 00:13 |
fenn | wow there's a lot of traffic on hplusroadmap | 00:13 |
kanzure | are you being sarcastic? | 00:13 |
fenn | no | 00:13 |
kanzure | because it's mostly me :) | 00:13 |
fenn | right | 00:14 |
kanzure | other gui libraries worth reviewing? | 00:15 |
kanzure | ncurses, I suppose | 00:15 |
kanzure | gtk, maybe | 00:15 |
fenn | w3c is the place to read about html form specs | 00:15 |
fenn | dunno why you want that though | 00:15 |
kanzure | http://www.gtk.org/documentation.html | 00:16 |
kanzure | http://www.cs.utk.edu/~vose/c-stuff/ncurses.html | 00:16 |
fenn | i like gtk | 00:16 |
kanzure | doesn't matter if it's HTML or GTK or Java Swing really | 00:16 |
kanzure | the point is that there is a set of parameters that they all use | 00:16 |
kanzure | so I want a broad list of them | 00:16 |
kanzure | http://www.w3.org/TR/html401/interact/forms.html | 00:16 |
kanzure | http://www.jformdesigner.com/ heh | 00:16 |
kanzure | http://www.jgoodies.com/ aha | 00:16 |
fenn | you want a ui abstraction layer | 00:17 |
kanzure | yes | 00:17 |
fenn | i dont think it's going to happen any time soon | 00:18 |
kanzure | no reason to demand that all yaml-interpreters use just GTK or some bullshit like that | 00:18 |
kanzure | (I happen to like gtk too) | 00:18 |
kanzure | because remember | 00:18 |
kanzure | I want cli too | 00:18 |
fenn | what you can do instead is provide an api, and link various ui's to that | 00:18 |
kanzure | I think there's a gtk-cli version | 00:18 |
kanzure | wait, what? | 00:18 |
kanzure | how is that different | 00:18 |
kanzure | we'd have to write a binding for GTK to the API, right? | 00:19 |
kanzure | and then the scripts would use api calls of course | 00:19 |
fenn | a ui abstraction layer would be to design the ui and then export it to various formats, like desktop application (gtk or wxwindows) and html | 00:19 |
fenn | i guess | 00:19 |
fenn | i might be making this all up | 00:19 |
kanzure | I see | 00:19 |
fenn | anyway, publishing an API is the standard way to do it | 00:19 |
kanzure | yep | 00:19 |
kanzure | so that's what I want to do | 00:19 |
kanzure | so that we don't have to commit to one gui/cli lib | 00:19 |
kanzure | this way that's left up to the end user | 00:20 |
kanzure | but at the same time, it's stupid to restrict it | 00:20 |
fenn | to restrict what? | 00:20 |
kanzure | so we can at least look at the current standards across the gui/cli libraries | 00:20 |
kanzure | restrict parameters that the api accepts | 00:20 |
kanzure | for example, you don't just say | 00:20 |
kanzure | 'ask for user input' | 00:20 |
kanzure | you might say 'getchar' | 00:20 |
kanzure | or 'get a line' | 00:20 |
fenn | of course | 00:20 |
kanzure | and if you are in a GUI mode, it's even more complicated | 00:20 |
fenn | that doesnt have anything to do with the API though | 00:20 |
kanzure | sure it does | 00:20 |
kanzure | getaline() versus getaline(max length = 5) | 00:21 |
fenn | API is like, a list of functions and the type of variables they accept | 00:21 |
kanzure | so what if you don't have max length as a pararameter | 00:21 |
kanzure | so the idea is to make sure we accept common parameters | 00:21 |
kanzure | where 'common' is defined by the other specs I've been linking to | 00:21 |
kanzure | does it make sense | 00:23 |
kanzure | if not, shoot me down now, I have to log off (but not before saving those other specs to the hdd for in school viewing and maybe finally getting some work done) | 00:23 |
fenn | it just sounds like you're fuzzy on what an API is | 00:23 |
kanzure | we'll provide a set of functions | 00:24 |
kanzure | getchar, getline, gettext, getfile, stdin, whatever | 00:24 |
fenn | those aren't the sort of functions though | 00:24 |
kanzure | but the method of implementation (gui, cli) will be up to agx-get | 00:24 |
kanzure | hm | 00:24 |
kanzure | what functions are you considering? | 00:24 |
fenn | its more like, updatedb(); check-keys(); parse-file() | 00:24 |
kanzure | that's agx-get | 00:25 |
kanzure | sigh | 00:25 |
kanzure | okay, so it tries to parse the file | 00:25 |
kanzure | catches the exception | 00:25 |
kanzure | goes looking for the plugin to fix it, which would provide the class (the yaml is the serialized object that fits that class) | 00:25 |
fenn | wait, what is "it"? | 00:25 |
kanzure | it = agx-get | 00:25 |
kanzure | you're describing agx-get | 00:25 |
fenn | ~[6~[6~[6~[6~[6~[6~[6~[6~[6~what's the gui for? | 00:25 |
kanzure | not for me, | 00:26 |
kanzure | I like cli | 00:26 |
kanzure | but that's my preference | 00:26 |
fenn | i mean, its an interface to what | 00:26 |
kanzure | to agx-get | 00:26 |
kanzure | agx-get will read skdb metadata files | 00:26 |
kanzure | right? | 00:26 |
fenn | yeah, and agx-get presents the basic usage functions as its API | 00:26 |
kanzure | maybe - let me type out what I was thinking first, then I'll consider that | 00:27 |
kanzure | once agx-get installs a plugin to read the yaml file, the plugin gains control and gets to ask the user questions or whatever (this can be bypassed by parameters of course) | 00:27 |
fenn | getline is part of the client code, which then gets parsed and turned into function calls to the API | 00:27 |
kanzure | so it would have a way of saying "well, there's this list here, which one(s) would you like? or all of them?" | 00:27 |
kanzure | so the plugin would call getChar() or whatever to get the information that the user types in | 00:28 |
kanzure | hm | 00:28 |
kanzure | now, in your switch-aroo, | 00:28 |
fenn | ew | 00:28 |
kanzure | why would getline "then get[s] parsed and turned into function calls to the API" | 00:29 |
kanzure | where getline is a part of the client code | 00:29 |
fenn | that's not very flexible, what if you switch to a radio button instead? then you have to go and change getChar() in every plugin | 00:29 |
kanzure | and the API is supposed to be the ui stuff | 00:29 |
kanzure | huh? | 00:29 |
kanzure | I don't understand that | 00:29 |
kanzure | the plugins are individually responsible for their interface | 00:29 |
fenn | no, API is not the UI it's the interface between UI and library code | 00:29 |
kanzure | how is it that you think that | 00:30 |
kanzure | erm | 00:30 |
kanzure | switching to a radio button? | 00:30 |
kanzure | why would you do that | 00:30 |
kanzure | ohh | 00:30 |
kanzure | you mean | 00:30 |
fenn | because you're writing a GUI | 00:30 |
kanzure | switching a plugin's representation | 00:30 |
kanzure | would mean it changes for all of them that rely on that plugin | 00:30 |
kanzure | for example | 00:31 |
kanzure | package chair has (conveniently?) a dependency on a plugin to parse chair-type metadata files | 00:31 |
kanzure | and another package entirely, ed302941 also has that !! yaml statement for the chair-type | 00:31 |
fenn | i never really expected a plugin to directly ask the user for input (because dpkg always pissed me off when it got stuck halfway through a big install waiting for me to press enter) | 00:31 |
kanzure | then, changing the plugin's code to ask the user for stuff and so on - well - then it would change it for anybody using either chair *or* ed302941 | 00:32 |
kanzure | fenn: that's fixed with passing parameters to dpkg ... | 00:32 |
fenn | not if you dont know you have to pass any parameters | 00:32 |
kanzure | unless it's a genuine 'uh oh and halt' dpkg error | 00:32 |
fenn | its stuff like 'this version of libpam does blahdyblah and is a possible security risk if you are running foobar v123' and i generally have no idea what they're talking about | 00:32 |
kanzure | I still think you are wrong --> "that's not very flexible, what if you switch to a radio button instead? then you have to go and change getChar() in every plugin" | 00:33 |
kanzure | getChar() in every plugin? | 00:33 |
fenn | the point is getChar shouldnt be in the plugin at all | 00:33 |
kanzure | that's not true at all | 00:33 |
kanzure | right | 00:33 |
kanzure | so | 00:33 |
kanzure | let's say it's gtkGetChar() | 00:33 |
kanzure | some object for a gui or something | 00:33 |
kanzure | that's not a plugin | 00:33 |
fenn | neither should that | 00:33 |
kanzure | that's in the interface to the API layer or whatever | 00:34 |
kanzure | and then the plugins call to the APIs | 00:34 |
fenn | in the gtk GUI? | 00:34 |
kanzure | gtkGetChar() would call an object in the GTK gui | 00:34 |
kanzure | or whatever | 00:34 |
kanzure | I don't know how that works | 00:34 |
kanzure | gtk bindings for the ui-abstraction-layer | 00:34 |
kanzure | so ui.getChar() would then be mapped to gtkGetChar() | 00:34 |
kanzure | then the python plugins that would do user io or just output or whatever would call ui.someFunction() | 00:35 |
kanzure | where someFunction is of course dependent on what the user's setup is | 00:35 |
kanzure | so gtk, or cli, or whatever | 00:35 |
fenn | i want to believe that your ui.someFunction is what i'm calling an API | 00:35 |
fenn | see, getChar isn't appropriate to a radiobutton, but it performs the same function on a ncurses interface | 00:36 |
kanzure | wait, what? | 00:36 |
fenn | say you're at an interactive session | 00:37 |
kanzure | getChar would do get-character in ncurses just the same as get-character from a prompt, but the trick is that ncurses gets to choose a weird way to implement it | 00:37 |
kanzure | okay | 00:37 |
fenn | would you like: a, b, or c? | 00:37 |
kanzure | and this could be either graphical or just text-based | 00:37 |
kanzure | right? | 00:37 |
kanzure | the script is fundamentally asking me for those options, but my API knows that I want in gui form for example | 00:37 |
kanzure | because that's what I've configured/told it to do | 00:37 |
fenn | in the text-based version you're type 'a' but in the gui version you'd click the box next to a | 00:37 |
kanzure | (where I am the user) | 00:37 |
kanzure | well | 00:37 |
kanzure | I'm not so sure about that, that's more of a question for configuration I think, right? | 00:38 |
kanzure | I mean, that might be a popular configuration for end-users | 00:38 |
kanzure | but personally, intuitively, I'd think that even in cli you should still be able to do a key press | 00:38 |
kanzure | but I dunno. | 00:38 |
kanzure | oops | 00:38 |
kanzure | *even in gui | 00:38 |
kanzure | I think that is something reasonably configurable, right? | 00:38 |
fenn | yeah, sure, most gui options have key shortcuts | 00:38 |
kanzure | but I mean whether or not to make it a radio button | 00:39 |
kanzure | whether or not to make it a radio button should be up to *something* on the end-user end | 00:39 |
fenn | instead of what, a box you type in? gimme a break | 00:39 |
kanzure | not the python script itself | 00:39 |
kanzure | dunno | 00:39 |
kanzure | whatever | 00:39 |
kanzure | I don't care about it, that's up to the end-user | 00:40 |
kanzure | or the gui/cli library | 00:40 |
kanzure | okay, so I think that part sounds solid | 00:40 |
fenn | hrmm | 00:40 |
fenn | what do you think would be the API for agx-get? | 00:40 |
kanzure | I mentioned that I'd like to do a review of html form specs, gtk, and ncurses to see common parameters so that I don't screw us over with a bad API-layer/thingy first off. | 00:41 |
kanzure | it would be in python obviously | 00:41 |
-!- Aulere [n=dragon_d@131.229.176.252] has quit [Read error: 110 (Connection timed out)] | 00:41 | |
kanzure | and I'm hoping there's python-gtk bindings or python-ncurses bindings out there to make things easier to test out and debug or show mockups etc | 00:41 |
fenn | sure | 00:42 |
kanzure | I'll dump a few notes on to the wiki re: this stuff, then download some docs/specs, and get to work tomorrow | 00:43 |
fenn | i will sit on my bum and feel sorry for myself | 00:43 |
kanzure | http://library.gnome.org/devel/references which reference manual do I want? | 00:44 |
kanzure | why's that? | 00:44 |
fenn | no idea | 00:44 |
kanzure | http://library.gnome.org/devel/gtk/2.6/ ? | 00:44 |
fenn | use pygtk.org | 00:44 |
kanzure | convenient | 00:45 |
kanzure | the python guys always seem to keep simple websites | 00:45 |
kanzure | I suspect this is just due to the python syntax style | 00:45 |
fenn | the python code is much easier to read than c with funky type declarations everywhere | 00:45 |
kanzure | my typed text kinda have those funky type declarations everywhere like in c :( | 00:46 |
kanzure | *has those funky | 00:46 |
kanzure | hm, glade | 00:46 |
kanzure | I remember trying to use glade once or twice | 00:46 |
fenn | i have mixed feelings about glade | 00:46 |
fenn | i think it just makes things more complicated in the end | 00:47 |
fenn | auto-generated code is a big nono in my book | 00:47 |
kanzure | I remember being it barely usable | 00:47 |
kanzure | wait, what about gcc and its automated code generators? | 00:48 |
kanzure | and compiler compilers in general? | 00:48 |
fenn | but even with libglade, then you have to sort through a big mess of buttons and windows to figure out where to put your code | 00:48 |
fenn | kanzure: as long as i dont have to see it | 00:48 |
kanzure | more than fair :) | 00:48 |
fenn | as long as someone cant possibly mistake it for source code | 00:48 |
fenn | the core communication API of emc was written with a code generator.. been suffering ever since | 00:49 |
fenn | you cant just rip it out | 00:49 |
fenn | oh well | 00:49 |
fenn | modularity, abstraction layers.. the more the merrier | 00:50 |
kanzure | hm, a code generator to communicate with what? | 00:52 |
kanzure | with the machines? | 00:52 |
kanzure | oh, right | 00:52 |
kanzure | g-code is like a language | 00:52 |
kanzure | so I maybe see what they were thinking? | 00:53 |
fenn | no, nothing to do with g-code | 00:53 |
kanzure | wtf? | 00:53 |
fenn | stuff like, turnSpindleOn(), popupStupidErrorMessage() | 00:54 |
fenn | thousands and thousands of these, all with their own c++ types | 00:54 |
kanzure | so was a code generator a lazy man's answer to a problem ? | 00:54 |
kanzure | eek | 00:54 |
fenn | it was because they couldnt figure out a way to send messages between machines with different architectures (besides c++ types) | 00:55 |
fenn | surely there's a better way (and it wouldnt even have been an issue with an interpreted language) | 00:55 |
fenn | plain RPC is what I would have done | 00:55 |
fenn | oh well | 00:55 |
fenn | see, back in the day, computers werent fast enough to handle controlling the table and the i/o at the same time (?) so they split up the different parts of the system between computers | 00:56 |
fenn | but it was a govt project so of course they had to support a bunch of incompatible computer types | 00:57 |
fenn | now, it's been scaled back to just x86 machines running rtai-linux, but the inter-process messaging layer is the same | 00:57 |
kanzure | hey, uh, how hard would it be to convert between git, svn, cvs, monotone, etc.? | 00:58 |
fenn | not too hard, but then you have to interconvert all the time | 00:59 |
fenn | (i've never done it) | 00:59 |
fenn | you dont want to use cvs | 00:59 |
kanzure | well | 01:00 |
kanzure | my main woe at this time is that | 01:00 |
kanzure | apt-get is supposedly our cover-story, I mean, what we use as an example | 01:00 |
kanzure | "See how well it works?" or at least the concept | 01:00 |
fenn | heh | 01:00 |
kanzure | and if they can't apt-get install git-core | 01:00 |
kanzure | then WTF are they going to be thinking? | 01:00 |
kanzure | but otherwise git looks like an awesome choice | 01:00 |
fenn | um.. by the time we have anything useful released, nobody will be using debian-etch | 01:00 |
kanzure | I guess we can say "go get unstable" | 01:00 |
kanzure | eh | 01:00 |
fenn | sorry | 01:01 |
kanzure | it took me four years to get around to upgrading my last knoppix box | 01:01 |
kanzure | it was this terribly transformed knoppix->debian->ubuntu?->debian box from random sources.list additions/deletions | 01:01 |
kanzure | (newbish ;)) | 01:01 |
fenn | i think git-core is supposed to work on etch, but somehow you borked it by installing GNU git | 01:02 |
fenn | so, apt-get is not perfect, but you have to admit it works pretty well most of the time | 01:04 |
fenn | git can be a deb-dependency of our package if we use it, but i cant realistically see most end-users learning how to use a command-line version control system | 01:06 |
fenn | packages can be downloaded a zillion other ways | 01:06 |
kanzure | sure | 01:06 |
kanzure | agx-get would probably automatically clone some git repos ;) | 01:06 |
kanzure | that's what I'm thinking. | 01:06 |
kanzure | but on the other hand, I'm not so sure | 01:07 |
kanzure | that'd be more like a parameter feature or something | 01:07 |
kanzure | since the user doesn't necessarily want to download all 10 MB associated with a project, just certain data files or just the human readable stuff at the moment | 01:07 |
kanzure | whatever. | 01:07 |
fenn | i may be confusing this project with my theoretical cad software which uses a git repo to save files | 01:08 |
fenn | based loosely on this idea: http://www.bruno.postle.net/neatstuff/draft/ | 01:08 |
fenn | i like files :) | 01:09 |
kanzure | fenn: I don't see how the two are different. CAD software is the same thing methinks. But ultimately you still need to have that 'social knowledge' somehow | 01:10 |
kanzure | or something | 01:10 |
kanzure | too tired | 01:10 |
kanzure | don't make much fo that | 01:10 |
kanzure | *of that | 01:11 |
fenn | git-rebase in a parametric cad .. mmmmm | 01:13 |
kanzure | guys in #python suggesting a "cli markup language that can then be converted to glade" | 01:16 |
kanzure | eek, glade references. | 01:16 |
kanzure | (2008-04-24 00:20:23) xif: you just need something that says <this is a form that lets the user input a string>, and then translate to the same thing in Gnome. | 01:16 |
fenn | no, workflow is different in a command line program | 01:17 |
kanzure | http://ubuntuforums.org/showthread.php?t=630693&page=8 cli markup language | 01:18 |
kanzure | oh | 01:18 |
kanzure | http://linux.pte.hu/~pipas/CUI/index.html | 01:18 |
kanzure | composite ui | 01:19 |
fenn | oh wow, its like a terminal except it's not! | 01:20 |
kanzure | hrm | 01:20 |
kanzure | terrible idea | 01:20 |
fenn | i think switching from cli to gui means a total rewrite and re-think is in order | 01:21 |
kanzure | (2008-04-24 00:24:51) xif: kanzure: what I'd probably do, is define a small set of widgets that I actually need, then write an adapter that reliably represents each widget in a CLI markup and glade. | 01:21 |
kanzure | hm | 01:21 |
kanzure | but then how does debian do it | 01:21 |
kanzure | they have graphical frontends | 01:21 |
kanzure | ooh | 01:21 |
fenn | the dialog thingy? blue background and red buttons | 01:21 |
kanzure | they put them in "shut the fuck up" mode | 01:22 |
kanzure | nope | 01:22 |
kanzure | that's not it | 01:22 |
kanzure | they have gtk versions | 01:22 |
kanzure | of aptitude and so on | 01:22 |
kanzure | but I think they are in STFU mode | 01:22 |
kanzure | maybe. | 01:22 |
fenn | synaptic? | 01:22 |
kanzure | yes | 01:22 |
fenn | its a frontend to apt, but it uses apt's API | 01:22 |
fenn | the stuff defined in libapt or whatever its called | 01:23 |
kanzure | so | 01:23 |
kanzure | in some cases the configuration scripts require user input | 01:23 |
kanzure | does this translate up to gtk window popups ? | 01:23 |
kanzure | and if so, how? are they doing the api layer thing that I have been suggesting? | 01:23 |
fenn | i dont know | 01:24 |
fenn | i cant think of any cases where we would need user input halfway through an operation | 01:24 |
fenn | ideally they'd just press 'go' and it would spit out the result | 01:25 |
fenn | dem compyootah's better not gimme any back-talk | 01:26 |
kanzure | what if they didn't know about the parameters for that project | 01:27 |
kanzure | they need to be told or something | 01:27 |
kanzure | like "Hello, this is your first time using this data type, so here's a quick walkthrough" or something? (yuck?) | 01:28 |
fenn | hmm that ubuntu thread. "training wheels for the CLI" sounds like a good idea | 01:28 |
kanzure | yeah, hold on | 01:28 |
kanzure | screw gui | 01:28 |
kanzure | why do I care this much | 01:28 |
kanzure | http://surfraw.alioth.debian.org/ Surfraw - Shell Users' Revolutionary Front Rage Against the Web | 01:29 |
kanzure | Surfraw abstracts the browser away from input. Doing so lets it get on with what it's good at. Browsing. Interpretation of linguistic forms is handed back to the shell, which is what it, and human beings are good at. Combined with netscape-remote or incremental text browsers, such as lynx, links or w3m, along with screen a Surfraw liberateur is capable of navigating speeds that leave GUI tainted idolaters agape with fear and wonde | 01:30 |
fenn | yeah its a great vision but the software is useless' | 01:30 |
fenn | at least google provides a decent set of "command-line" style search queries (instead of making you click boxes in some advanced search page) | 01:31 |
kanzure | hurray for box clicking | 01:32 |
kanzure | :( | 01:32 |
kanzure | wasted hours | 01:32 |
kanzure | probably ten million man hours by now | 01:32 |
fenn | but 99% of the website designers out there could care less | 01:32 |
kanzure | it's not that they don't care, I think they just don't understand | 01:32 |
fenn | ah, no, its that they dont care, and it wasnt part of the assignment | 01:32 |
fenn | the person giving the assignment doesnt understand | 01:33 |
-!- Aulere [n=dragon_d@131.229.176.252] has joined #hplusroadmap | 01:33 | |
fenn | if you're writing dynamic web code you are probably using a command line at multiple points in the process | 01:33 |
kanzure | back when I was doing 1k~ of dynamic web code a night, the only command line I knew about was MSDOS | 01:34 |
kanzure | and it was *useless* | 01:34 |
kanzure | although I guess I could have used EDIT and then FTP | 01:34 |
kanzure | but really. | 01:34 |
fenn | hrm. i suppose it could be possible that one could write code without using a command line... (are my GNU horns showing?) | 01:35 |
kanzure | not sure | 01:36 |
kanzure | back in my day, we programmed by smoke signals | 01:37 |
fenn | fwiw i learned to program on macintosh quickbasic and then ms-somethingorother C++ IDE | 01:37 |
kanzure | none of these damned 'electrons' and 'fields force'. | 01:37 |
kanzure | my intro to programming was, sadly, html + js | 01:37 |
kanzure | but I was young enough for it to not scar me | 01:37 |
fenn | well, javascript is sorta useful | 01:38 |
kanzure | sure | 01:38 |
kanzure | but not when you think anybody who "knows" HTML to be a demigod | 01:38 |
fenn | in 1996 it was pretty much a requirement for participating on the (http) web | 01:38 |
kanzure | 'night | 01:39 |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 01:39 | |
-!- AulereV [n=dragon_d@131.229.176.252] has joined #hplusroadmap | 03:46 | |
-!- Aulere [n=dragon_d@131.229.176.252] has quit [Read error: 110 (Connection timed out)] | 03:55 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has joined #hplusroadmap | 03:57 | |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 07:24 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has quit [Remote closed the connection] | 07:27 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has joined #hplusroadmap | 07:32 | |
-!- AulereV [n=dragon_d@131.229.176.252] has quit [] | 07:40 | |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 08:05 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has quit ["Ex-Chat"] | 08:41 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has joined #hplusroadmap | 10:31 | |
-!- marainein [n=marainei@220-253-110-236.VIC.netspace.net.au] has quit [Read error: 110 (Connection timed out)] | 12:20 | |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 17:48 | |
-!- marainein [n=marainei@220-253-113-232.VIC.netspace.net.au] has joined #hplusroadmap | 17:49 | |
kanzure | conclusion: | 17:49 |
kanzure | fenn: no reason for these scripts to need input | 17:49 |
kanzure | I was wrong. | 17:49 |
kanzure | So I was talking with Greg Egan this morning. | 17:49 |
-!- Splicer [n=p@h35n1c1o261.bredband.skanova.com] has joined #hplusroadmap | 18:56 | |
kanzure | Hey Splicer. | 18:58 |
Splicer | hello | 19:02 |
Splicer | I was listening to a berkley genetics podcast earlier today, about the Recombinant DNA Debate... | 19:11 |
kanzure | Debate?? | 19:12 |
Splicer | it started among scientists, some of which were very notable.. spread to the public.. | 19:12 |
kanzure | what debate. | 19:12 |
kanzure | " Ready are you? What know you of ready? For eight hundred years have I trained Jedi. My own counsel will I keep on who is to be trained. A Jedi must have the deepest commitment, the most serious mind. | 19:12 |
kanzure | This one a long time have I watched. All his life has he looked away... to the future, to the horizon. Never his mind on where he was. Hmm? What he was doing. Hmph. Adventure. Heh. Excitement. Heh. A Jedi craves not these things. You are reckless. " | 19:12 |
Splicer | heh | 19:13 |
Splicer | The recombinant DNA debate, there is a thread about it on DIYbio.. sonething about berkley laws, the debate started there. | 19:14 |
Splicer | not berkley... the other place | 19:14 |
Splicer | 'Cambridge DNA laws' is the name of the thread | 19:15 |
kanzure | There were only three or four emails on the diybio mailing list abotu that. | 19:15 |
Splicer | yes | 19:15 |
kanzure | So how is it a debate. | 19:15 |
kanzure | There's nothing *to* debate. We *know* how biology does it and we know it occurs, randomly, billions of times each day, perhaps billions of times each moment. | 19:16 |
Splicer | mmm... the berkley professor describes it better than I can: | 19:16 |
kanzure | if you can link me to the transcripts to the genetics podcast, that'd be great | 19:16 |
Splicer | don´t have transcrips, sorry: http://webcast.berkeley.edu/media/f2007/mcb140/mcb140_2007-09-24.mp3 | 19:17 |
kanzure | wtf | 19:17 |
Splicer | ? | 19:17 |
Splicer | hehe.. no trascript sorry | 19:18 |
Splicer | It starts 33.10 in | 19:18 |
Splicer | It ends with the mayor of Cambridge banning the research and the mayor of berkley banning it for 2 years and setting up an advisory board consisting of firemen and nurses. | 19:20 |
kanzure | Hm. | 19:23 |
kanzure | Listening. | 19:23 |
kanzure | Erwin Chargaff | 19:24 |
Splicer | yup.. he got carried away.. the good stuff is to come | 19:24 |
kanzure | "... whether we have the right to put a fearful load on the future people. You can recall a bomb, you can recall a war; you can't recall a new organism." | 19:24 |
kanzure | Ah, so it's just the grey goo argument. | 19:24 |
Splicer | and he wasn´t just anyone | 19:25 |
marainein | bah...just try recalling a war | 19:25 |
kanzure | marainein: Your men. | 19:26 |
marainein | I meant in practical terms | 19:27 |
kanzure | "And so they banned recombinant DNA research." Hahah. Try banning natural biology. Yes, that's a great idea. Sure. Just try. | 19:27 |
kanzure | "We will create the perfect race, citing Adolf Hitler" - yawn, eugenitical approach to transhumanism | 19:27 |
kanzure | http://heybryan.org/transhumanism_def.html | 19:27 |
marainein | need to ban sex too...don't forget about homologous recombination during meiosis | 19:28 |
* Splicer sings "We will not be cloooooned" | 19:28 | |
kanzure | marainein: A few days ago fenn was mentioning how Texas banned 'sex toys' up til, what was it, 2007? | 19:28 |
* kanzure lives in Texas and didn't know :-( | 19:28 | |
kanzure | "You don't need to understand things to argue about them." erm... | 19:29 |
marainein | well, technically that's true | 19:29 |
kanzure | if you want to be grounded. | 19:30 |
Splicer | public debate follow the laws of memetics not reason | 19:30 |
kanzure | doesn't matter, they are wrong | 19:30 |
Splicer | of course, and technology beats politics, but they can make things miserable for a while | 19:31 |
Splicer | i like his conclusion, that noone cares about that particular debate now... every student is doing it first thing | 19:32 |
-!- marainein [n=marainei@220-253-113-232.VIC.netspace.net.au] has quit ["Ex-Chat"] | 19:48 | |
Splicer | hmm.. the biology channel seems quiet | 19:55 |
Splicer | time to sleep | 19:56 |
Splicer | cu | 19:56 |
-!- Splicer [n=p@h35n1c1o261.bredband.skanova.com] has left #hplusroadmap [] | 19:56 | |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit [Connection timed out] | 20:26 | |
-!- Aulere [n=dragon_d@131.229.176.252] has joined #hplusroadmap | 20:48 | |
-!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 21:00 | |
kanzure | http://www.davidzindell.com/id16.html | 21:50 |
Aulere | is he a favorite author of yours? | 21:53 |
Aulere | looks interesting | 21:53 |
kanzure | Yes, I have a copy of his book on http://heybryan.org/docs/ | 22:01 |
kanzure | I am also wikifying a copy of the book. | 22:29 |
kanzure | http://heybryan.org/mediawiki/index.php/Neverness/1 | 22:30 |
Aulere | nice | 22:40 |
Aulere | he has a certain poetry to his prose | 22:41 |
kanzure | Sure. | 22:42 |
kanzure | Alright fenn, so I realized that all of that configuration talk was just bullshit. The only thing we have to do is download the plugins that provide the classes. These classes can be configured, yes, but ultimately it's only two ways. (1) Through the parameters. (2) Default config as provided by the package. | 22:44 |
kanzure | Here's why. Let's say that you type in agx-get install --recursive chair to get anything and everything related to a chair | 22:45 |
kanzure | It will pick up the yaml plugin for the chair datatype. So it might need to do some configuration, right? Not really. What's there to configure? All that you really care about is installing it, so it'll just do default stuff for you. If you don't give it anything *specific* to 'chair'-type then it will not really do much. | 22:46 |
kanzure | so you'd have to wait | 22:46 |
kanzure | if you're going to be waiting there, you might as well quit the program and just type in some parameters | 22:46 |
kanzure | this way, even better, you can *repeat* the configuration steps and show other people | 22:46 |
kanzure | but it's wrong to call it configuration | 22:46 |
kanzure | this is more like: agx-get install chair | 22:46 |
kanzure | > Hello, you're downloading a chair. Did you know you can specify --specific <id> to get a specific model? If you don't know the ID, it's okay, just run chairFinder to help you out. | 22:47 |
kanzure | that sort of thing | 22:47 |
kanzure | http://www.cosmographica.com/gallery/index_main.html | 22:58 |
-!- marainein [n=marainei@220-253-10-191.VIC.netspace.net.au] has joined #hplusroadmap | 23:01 | |
fenn | marainein: is your nick based on the iain banks language? | 23:49 |
[Users #hplusroadmap] | 23:49 | |
[ Aulere] [ drazak] [ fenn] [ kanzure] [ krebs_] [ marainein] | 23:49 | |
-!- Irssi: #hplusroadmap: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal] | 23:49 | |
marainein | no...what makes you ask? | 23:50 |
fenn | because then i'd know you'd read some banks novels :) | 23:51 |
* marainein has read some of banks's books, but doesn't recognise the reference | 23:51 | |
fenn | marain is the language of Culture | 23:51 |
marainein | ah...didn't know that | 23:51 |
marainein | although I've read some culture books | 23:51 |
fenn | did anyone watch the 1968 engelbart demo? | 23:53 |
fenn | i've been geeking out on engelbart since i did. he's all about bootstrapping | 23:54 |
fenn | its really amazing all the different things they had to invent, and how spot-on they got the whole system and interface the very first time | 23:56 |
fenn | like, there was no such thing as a monitor that showed words electronically | 23:56 |
kanzure | not yet | 23:59 |
kanzure | ah | 23:59 |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!