| --- Log opened Tue Nov 10 00:00:45 2009 |
| 00:01 | | You're now known as TheWatcher[T-2] |
| 00:06 | < ToxicFrog> | LaTeX indicts all existing word processors in guilt that even death cannot repay. |
| 00:07 | < McMartin> | LaTeX is not a word processor. |
| 00:07 | < ToxicFrog> | Precisely. |
| 00:10 | | You're now known as TheWatcher[zZzZ] |
| 00:14 | < McMartin> | No, I mean, that's like saying "Photoshop indicts all existing web browsers in guilt that even death cannot repay." |
| 00:17 | < ToxicFrog> | They both exist to the solve the same problem, though. |
| 00:17 | < ToxicFrog> | They just have totally different approaches. |
| 00:17 | < ToxicFrog> | I have spent years creating papers of various kinds in several different word processors, and it's always been a pain in the ass and I've never really been happy with the results. |
| 00:18 | < ToxicFrog> | Over the past few days I put together a requirements specification document in LaTeX way more painlessly and it also looks far better than anything I've created with a word processor. |
| 00:19 | < gnolam> | Not really, no. Word processors exist to replace typewriters. To be able to easily edit text on the fly. |
| 00:20 | < gnolam> | LaTeX exists to replace regular type/setting/. |
| 00:29 | < ToxicFrog> | gnolam: text editors replace typewriters. |
| 00:29 | < ToxicFrog> | word processors are 90% typesetting tools. |
| 00:31 | < McMartin> | Typewriters perform layout, and if you don't believe this you've never tried to lay out a page with diagrams using one. |
| 00:32 | | * simon` can never position figures right in LaTeX. they always end up in a pile at the bottom. |
| 00:33 | < McMartin> | It can get a bit... willful, yes. |
| 00:33 | < McMartin> | I ran into that with my dissertation, where one figure was a quarter-inch too wide and as a result every figure in the entire 250-page document was relocated to an appendix in the back. |
| 00:34 | < simon`> | heh :) |
| 00:35 | < simon`> | I guess your level of latex-fu grows with the size of the documents you write since your need to have it actually work grows in proportion to the size. |
| 00:35 | < simon`> | I first bothered proper bibliography during my last written exam. |
| 00:36 | < McMartin> | BibTeX has no credible competition anywhere |
| 00:37 | < simon`> | really. |
| 00:38 | < simon`> | \cite{yourtag} and have everything nicely formatted is all I can expect. |
| 00:38 | < McMartin> | Yeah, and I know of no other system that actually does that and maintains it properly across later edits |
| 01:09 | | AnnoDomini [farkoff@Nightstar-602e92ab.adsl.tpnet.pl] has quit [[NS] Quit: Tradition may be defined as an extension of the franchise. Tradition means giving votes to the most obscure of all classes, our ancestors. It is the democracy of the dead. Tradition refuses to submit to the small and arrogant oligarchy of those ] |
| 01:32 | | Attilla [The.Attilla@FBC920.65CFFF.B7E2D0.EBD89A] has quit [Ping timeout: 121 seconds] |
| 01:47 | | Derakon[AFK] is now known as Derakon |
| 02:03 | <@Derakon> | I haven't used LaTeX in years... |
| 02:03 | <@Derakon> | Mostly I used to use it for my Algorithms homework (lots of equations) and for writing lab reports. |
| 02:05 | <@Derakon> | Hrm. I should do something with the book on chainmaille weaves that I mostly-wrote and then abandoned. |
| 02:06 | <@Derakon> | (Which is typeset using LaTeX) |
| 02:23 | < ToxicFrog> | McMartin: typewriters perform _layout_, but so do text editors. I consider _typesetting_ a large superset of this. |
| 02:24 | < ToxicFrog> | My main line of thinking here is that when I'm using a word processor, my end goal is the same as it is when I'm using LaTeX; however, LaTeX produces better results in less time and with less effort. |
| 02:24 | < ToxicFrog> | Whereas when I'm using a text editor my end goal is not the same. |
| 02:35 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 03:50 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 04:50 | | Vornicus is now known as Vornicus-Latens |
| 06:31 | | Derakon is now known as Derakon[AFK] |
| 08:16 | | AnnoDomini [farkoff@Nightstar-602e92ab.adsl.tpnet.pl] has joined #code |
| 08:23 | | Tarinaky [Tarinaky@Nightstar-38f414ef.adsl.virginmedia.net] has joined #code |
| 08:59 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Client exited] |
| 09:09 | | You're now known as TheWatcher |
| 09:43 | | Attilla [The.Attilla@FBC920.65CFFF.9EEB6C.048A40] has joined #code |
| 09:43 | | mode/#code [+o Attilla] by ChanServ |
| 10:06 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 10:07 | | SmithKurosaki [Smith@Nightstar-683a7925.dsl.teksavvy.com] has quit [Operation timed out] |
| 10:20 | | SmithKurosaki [Smith@Nightstar-5efa8f67.dsl.teksavvy.com] has joined #code |
| 10:20 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 10:31 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 10:31 | | SmithKurosaki [Smith@Nightstar-5efa8f67.dsl.teksavvy.com] has quit [Operation timed out] |
| 10:51 | | SmithKurosaki [Smith@Nightstar-270a1069.dsl.teksavvy.com] has joined #code |
| 10:51 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 11:12 | | AnnoDomini [farkoff@Nightstar-602e92ab.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 11:15 | < simon`> | wow |
| 11:15 | < simon`> | I was just in my metaheuristics study group |
| 11:15 | < simon`> | I can now say that both the field of study and this way of meeting and discussing are interesting. |
| 11:17 | | AnnoDomini [farkoff@Nightstar-9a0feb34.adsl.tpnet.pl] has joined #code |
| 11:18 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 11:48 | | You're now known as TheWatcher[afk] |
| 12:50 | | Attilla [The.Attilla@FBC920.65CFFF.9EEB6C.048A40] has quit [Ping timeout: 121 seconds] |
| 12:51 | | Attilla [The.Attilla@FBC920.480E8C.3E679A.E258A8] has joined #code |
| 12:51 | | mode/#code [+o Attilla] by ChanServ |
| 13:10 | | Tarinaky [Tarinaky@Nightstar-38f414ef.adsl.virginmedia.net] has quit [Ping timeout: 121 seconds] |
| 13:21 | | You're now known as TheWatcher |
| 13:24 | | Tarinaky [Tarinaky@Nightstar-056b4d13.adsl.virginmedia.net] has joined #code |
| 14:07 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 14:08 | | SmithKurosaki [Smith@Nightstar-270a1069.dsl.teksavvy.com] has quit [Operation timed out] |
| 14:47 | | ilf_atuni [santros_vexan@971820.E3523E.8A17F0.C4EDCD] has joined #code |
| 14:49 | | * ilf_atuni has a java applet that makes a red ball bounce around the applet's area. He needs to make a blue ball that follows the red ball, which should be easy if he uses the same formula for movement, since the red ball takes the sam epath every time, but I'm trying to figure out how to get it to work. And failing. |
| 14:49 | | * ilf_atuni is using Java. |
| 15:01 | < jerith> | Have them both use the same algorithm, but have them offset in time? |
| 15:02 | < jerith> | What's the algorithm you're using? |
| 15:21 | < gnolam> | Arrrrrrrrrrgh |
| 15:21 | | * gnolam stabs OpenGL again and again and again and again and again. |
| 15:21 | < ilf_atuni> | I'd tell you if I could find where I left the .java file... bleh, damnit, today's just going bad. |
| 15:21 | < gnolam> | DIE MOTHERFUCKER, DIE! |
| 15:24 | < ilf_atuni> | bleh, great. I've lost my code. Time to start over from scratch. |
| 15:33 | < ilf_atuni> | Bleh. And the code in the book dosen't work, and I can't remember what I changed ot make it work. |
| 15:34 | < ilf_atuni> | http://pastebin.starforge.co.uk/27 but here it is, so far. |
| 15:35 | | * gnolam slaps ilf_atuni. |
| 15:36 | < gnolam> | Never use the phrase "doesn't work" to describe a problem. :P |
| 15:37 | < ilf_atuni> | gnolam: Let it be said that I use the phrase dosen't work to describe everything, evne things that aren't problems. :P Specifically, it says it cannot be cast to java.applet.Applet |
| 15:38 | | SmithKurosaki [Smith@Nightstar-2f700130.cable.rogers.com] has joined #code |
| 15:50 | | * ilf_atuni blehs. Friggin thing.\ |
| 15:56 | < ilf_atuni> | all I want to do is get my friggin' homework doen. >< |
| 15:57 | < SmithKurosaki> | Yea |
| 15:57 | < SmithKurosaki> | Same here |
| 15:58 | | * jerith has given up on day-job work to play with his dicebot for the last hour or so. |
| 15:58 | < SmithKurosaki> | Heh |
| 15:59 | | * TheWatcher did likewise about 20 minutes ago - blasted database migration scripts messing with his head, is now dromeding |
| 16:02 | < jerith> | Database migration was pretty much the reason I threw in the towel as well. :-) |
| 16:03 | < gnolam> | And all I want to do is get this project completed, but goddamned OpenGL is preventing me from it. |
| 16:04 | < jerith> | About half the effort I've put into this bot is getting text formatted sanely. |
| 16:10 | | SmithKurosaki [Smith@Nightstar-2f700130.cable.rogers.com] has quit [Operation timed out] |
| 16:12 | < ilf_atuni> | Hmm... hah, got it! |
| 16:12 | | * ilf_atuni just moved the starting location of the blue ball to 'behind' the red one relative to movement, and it worked. Sure, it's probably not what the professor intended, but it works and it fits the parameters of the exercise. |
| 16:13 | < ilf_atuni> | well, once I figured out how to get it all the work. |
| 16:25 | | ilf_atuni [santros_vexan@971820.E3523E.8A17F0.C4EDCD] has left #code [] |
| 16:44 | < MyCatVerbs> | By far the best time to find out that you happen to really, really need a set of unit tests for a particular feature is after have already written some. <3 |
| 16:44 | < MyCatVerbs> | s/some/plenty enough/ |
| 16:45 | < Alek> | of course. XD |
| 16:52 | | SmithKurosaki [Smith@Nightstar-6450f657.dsl.teksavvy.com] has joined #code |
| 16:57 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 17:00 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 17:15 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 18:38 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Client closed the connection] |
| 18:45 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 19:43 | | * Derakon[work] compiles a list of variables that are shoved into a completely unrelated module during the course of running an experiment. |
| 19:44 | < Derakon[work]> | I'm up to 11 so far, including such names as f_mrc_hdr, weAreDoingPalm, _dontSend, and f. |
| 19:58 | < simon`> | Derakon[work], do you study, or do you write games all day? :D |
| 19:59 | < Derakon[work]> | Um, neither. |
| 20:00 | < Derakon[work]> | These days I'm working for a UCSF lab on their microscope software. |
| 20:37 | | crem_ [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 20:38 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Ping timeout: 121 seconds] |
| 20:39 | | * TheWatcher eyes dera |
| 20:39 | <@TheWatcher> | 'f' |
| 20:39 | < Derakon[work]> | Yep. |
| 20:39 | <@TheWatcher> | Please tell me you are joking |
| 20:39 | < Derakon[work]> | Imagine finding that in the codebase. |
| 20:40 | < Derakon[work]> | I'm pretty certain it's short for "file", as in, the file the program writes that holds the images taken by the microscope cameras. |
| 20:41 | <@TheWatcher> | I'm trying not to. It's bad enough seeing single character names for loop variables, but outside that? |
| 20:41 | | crem_ [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Client closed the connection] |
| 20:44 | < jerith> | 'f' is a reasonable name for a local variable in a short function where 'file' is a reserved word. |
| 20:45 | < jerith> | I usually use 'ff' or something in those cases, though, just because I dislike single character identifiers. |
| 20:46 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 20:50 | < ToxicFrog> | I use 'fd', or 'fin/fout' |
| 20:51 | < Namegduf> | I use "f" because "ff" implies it's short for something beginning with or possessing two 'f's and seems confusing |
| 20:51 | < Namegduf> | If "file" is reserved, that is. |
| 20:52 | < Namegduf> | But, yeah, in non-short functions... |
| 20:53 | < jerith> | People who write Python code using two-space indents and TitleCaseFunctionNames need a serious beating about the head and shoulders with PEP 8. |
| 20:53 | < Namegduf> | And worse, used the way it's using them, as externally accessible |
| 20:53 | < Namegduf> | Ew. |
| 20:53 | | * jerith is looking at Google for that. |
| 20:53 | < jerith> | "Short" functions are fewer than five lines. |
| 20:54 | < jerith> | "Long" functions are more than ten. |
| 20:54 | < Namegduf> | I would consider it fine up to about 20. |
| 20:55 | < Namegduf> | Maybe beyond, really, it just isn't right to be used in a large amount of code and definitely not used intermodule. |
| 20:55 | < jerith> | Depends on the language. |
| 20:55 | < jerith> | Approximately double those numbers for Java. |
| 20:55 | < McMartin> | fin/fout is what I usually ues. |
| 20:55 | < McMartin> | use |
| 20:56 | < Derakon[work]> | I generally use "filehandle". ?.? |
| 20:56 | < Derakon[work]> | Admittedly that doesn't indicate if it's open for reading or writing. |
| 20:57 | < jerith> | I use infile or outfile (or something more descriptive like config_file) or whatever more often than not. |
| 20:58 | < Namegduf> | Descriptive is good, yeah. |
| 21:07 | < McMartin> | Actually, I tend to use "f" for a formal of type FILE *. |
| 21:07 | < McMartin> | And "fname" if it's const char* or boost::path or what have you. |
| 21:07 | < Derakon[work]> | Oh, hey, random style question! |
| 21:07 | < Derakon[work]> | Which do you prefer: "int* foo" or "int *foo"? |
| 21:08 | < McMartin> | The latter |
| 21:08 | < Derakon[work]> | (And why?) |
| 21:08 | < jerith> | The latter. |
| 21:08 | < McMartin> | Because the former looks like "int* foo, bar, baz" means they're all pointers, and they aren't. |
| 21:08 | < jerith> | int *foo, *bar; |
| 21:08 | < Derakon[work]> | Mm. |
| 21:09 | < jerith> | Also, * is an indirection operator and is right-associative. |
| 21:09 | < Derakon[work]> | My personal stance on it is that the ability to mix pointer and non-pointer types in the same declaration is a mistake, and that "pointerness" is an inherent property of the type, and so should be aligned with the type instead of the name. |
| 21:09 | < Derakon[work]> | So I'd do "int* foo; int bar; int baz;" instead. |
| 21:09 | < jerith> | While it doesn't have that meaning in the declaration, the context is similar. |
| 21:09 | < McMartin> | In actual practice, I am almost always dealing with pointers as typedefs. |
| 21:10 | < McMartin> | Which sort of makes it moot. |
| 21:10 | < McMartin> | Actually, in argument lists I will generally do that. |
| 21:10 | < jerith> | The only pointer types I deal with regularly (on the rare occasions that I'm writing C) are char*. |
| 21:10 | < McMartin> | So, in the definition, it'll be f(int *a, int *b) { ... } |
| 21:11 | < McMartin> | But the declaration will be "f(int*, int*);" |
| 21:17 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Client closed the connection] |
| 21:17 | < McMartin> | Due to the requirements on their initialization, I do tend to do int&, but int *. |
| 21:21 | < Namegduf> | I usually do int*; hate that language feature. |
| 21:21 | < Namegduf> | I don't normally create multiple variables on a line, though. |
| 21:22 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 21:25 | < Rhamphoryncus> | Derakon[work]: if I were designing C I would make * in declarations left-associative, so "int* foo;" would be right. However, that's not the case, and using that coding style just leads to confusion about what the language is really doing |
| 21:26 | < Derakon[work]> | Mm, fair. |
| 21:29 | < Namegduf> | The latter is logically more sound. |
| 21:30 | < Namegduf> | I find it looks "odd" because I *do* consider the * part of the type |
| 21:30 | < Namegduf> | So putting it on the name makes it look like it's being deferenced or something strange. |
| 21:35 | < Namegduf> | But aside "it looks funny to me", it does make more sense, I guess. |
| 21:36 | < ToxicFrog> | I avoid this by using 'int * foo' or typedefs~ |
| 21:37 | < Derakon[work]> | I generally avoid it through using Python~ |
| 22:00 | < Rhamphoryncus> | Being a pointer *is* part of the type. It's the syntax that's fucked up |
| 22:01 | < McMartin> | Quite. |
| 22:14 | | * gnolam cues the Händel. |
| 22:14 | < gnolam> | HAAAAAALLELUJA, HALLELUJA, HALLELUJA |
| 22:19 | < gnolam> | I'm finally getting the project to compile over on the System of Doom. :P |
| 22:19 | < gnolam> | I don't know if it will actually /work/, but... |
| 22:19 | < Derakon[work]> | Compilation, I find, is generally less than half the battle. But it's still a major accomplishment, so congrats. |
| 22:22 | < gnolam> | Yeah. I'm a bit skeptical, especially since the computers there managed to be buggy on a simple bump map shader that used, IIRC, 6 uniform words. |
| 22:22 | < gnolam> | I'm using 173. :P |
| 22:31 | | * Derakon[work] devises a design that takes advantage of Python's arbitrary parameter lists system to let him make a class that encapsulates arbitrary other classes and includes the encapsulated class's constructor parameters in the encapsulating class's constructor parameters. |
| 22:31 | < Vornicus-Latens> | Der: :( |
| 22:31 | < Derakon[work]> | Hm. Well, let me describe the problem space. |
| 22:32 | < Derakon[work]> | See if you have a better idea. |
| 22:32 | < Derakon[work]> | Basically, we have a set of different experiment types. |
| 22:32 | < Derakon[work]> | An "experiment" is a way of collecting images of the slide. |
| 22:32 | < Derakon[work]> | For example, you might take an image at each of several different Z heights, or you might keep the camera shutter open as you sweep through Z. |
| 22:33 | < Derakon[work]> | So each of those different types subclasses the Experiment class, which is basically a Python-style virtual class. |
| 22:33 | < Vornicus-Latens> | ok |
| 22:33 | < Derakon[work]> | We also have the concept of a multi-site experiment, where you want to run a given experiment type on several different locations on the slide (i.e. you have 20 different areas that you've identified as interesting, and you want to image them all). |
| 22:34 | < Derakon[work]> | Enter the Multisite Experiment, which encapsulates an Experiment and also includes parameters on the set of sites to visit, how often to visit them, etc. |
| 22:34 | < Derakon[work]> | ...hm, I guess I could just pass the already-instantiated Experiment subclass to the MultisiteExperiment constructor, instead of having it make it itself. |
| 22:35 | < Derakon[work]> | Biggest problem there is having to do things like tweak the output filename for each site. |
| 22:36 | < Derakon[work]> | Since filename is a parameter to the Experiment subclasses' constructor. |
| 22:36 | < Derakon[work]> | ...I should pastebin this. |
| 22:37 | < Vornicus-Latens> | You coul give Experiment a globbable string or something... |
| 22:39 | | Vornicus-Latens is now known as Vornicus |
| 22:40 | < Derakon[work]> | Something like this: http://paste.ubuntu.com/315444/ |
| 22:40 | < Derakon[work]> | This glosses over a lot of stuff, of course, and my syntax may be off in the *args stuff, but it should give you an idea of what I'm dealing with here. |
| 22:42 | < Derakon[work]> | I either need to code a reset() function for a single Experiment instance that gets reused over the lifetime of the MultisiteExperiment, or I need to instantiate a new one for each site in siteList. |
| 22:50 | < ToxicFrog> | "main: local function definitions are illegal" |
| 22:50 | < ToxicFrog> | C :argh: |
| 22:50 | < McMartin> | Derakon: How is that not just a "hey, I get arbitrary parameter lists and duck typing, let's write a generic proxy" |
| 22:54 | < Derakon[work]> | Define "generic proxy"? |
| 22:55 | < McMartin> | A proxy is an object that stands in for another object, generally doing something before delegating out to the real, original one (usually). |
| 22:55 | < McMartin> | Thanks to duck typing, you don't have to dick around with inheritance to throw proxies whereever you want, so why not write one that will eat anything? |
| 22:55 | < Derakon[work]> | Ah. |
| 22:55 | < Derakon[work]> | Well, for certain values of "everything" restricted to "subclasses of Experiment", that is in fact what I'm suggesting here. |
| 22:56 | < Derakon[work]> | The important thing is that these subclasses are guaranteed to implement certain functions so the MultisiteExperiment class can call them. |
| 22:56 | < Derakon[work]> | But the idea is that you should be able to have a MultisiteExperiment run any type of Experiment at each of the specified sites. |
| 22:57 | < McMartin> | You could override __call__ and have it work on any method whatsoever~ |
| 22:57 | < Derakon[work]> | If I only needed Experiment to export a single function, sure. |
| 22:57 | < Derakon[work]> | I suspect I'll need more; at the very least, some kind of status() function. |
| 22:58 | < McMartin> | Er, wait, what is that. not __call__ |
| 22:58 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 22:59 | < McMartin> | The thing that's called when you try to invoke a non-existent method |
| 23:00 | < Rhamphoryncus> | Derakon[work]: passing already completed objects to MultipleExperiment is a Good Thing(TM). |
| 23:00 | < Rhamphoryncus> | Derakon[work]: is MultipleExperiment used every time, or just when you want mutliples? |
| 23:00 | < Derakon[work]> | Rhamphoryncus: that does mean I need to make every experiment be cleanly resettable, though. |
| 23:00 | < Derakon[work]> | Just when you want multiples. |
| 23:00 | < Derakon[work]> | It's not uncommon for the biologist to say "Okay, I'm at a good spot, let's image this." |
| 23:01 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:01 | < Derakon[work]> | Multisite stuff tends to be for when the biologist wants to observe a particular process which any of a large number of sites might be about to undergo. |
| 23:01 | < Rhamphoryncus> | You should consider using it even when there's just one. Then you can pull common functionality into it. For instance, it could manage output files |
| 23:02 | < Derakon[work]> | That doesn't work for side reasons. |
| 23:02 | < Rhamphoryncus> | bah :) |
| 23:02 | < Derakon[work]> | Mostly, MultisiteExperiment incurs significant overhead that drops our imaging rate by a factor of 5 or so. |
| 23:03 | < Derakon[work]> | I might eventually be able to work around that, but I'm not going to base the design I'm working on now on that, since I don't know if it's actually possible. |
| 23:03 | < ToxicFrog> | "unresolved external symbol __cdecl double round(double)" |
| 23:03 | < ToxicFrog> | Windows :argh: |
| 23:04 | < Rhamphoryncus> | Ahh, so MultisiteExperiment isn't just a container. It's a different physical process |
| 23:05 | < Derakon[work]> | Yeah. |
| 23:05 | < Rhamphoryncus> | So the next obvious answer: SinglesiteExperiment |
| 23:05 | < Derakon[work]> | The process of moving from one site to another entails, on the side, blowing away some external state (stored on a different machine) that was used by the previous Experiment run. |
| 23:06 | < Derakon[work]> | Experiment is implicitly a SinglesiteExperiment. |
| 23:06 | < Derakon[work]> | Each Experiment is a different way to image a slide. |
| 23:06 | < Derakon[work]> | So there's ZStackExperiment, ProjectionExperiment, TIRFExperiment, etc. |
| 23:06 | < Derakon[work]> | I don't want to have to do MultisiteZStackExperiment, MultisiteProjectionExperiment, MultisiteTIRFExperiment, etc. |
| 23:07 | < Rhamphoryncus> | not what I meant |
| 23:08 | < Rhamphoryncus> | Always using MultisiteExperiment would let you merge common functionality, but it has too much other consequences too. For the cases you don't want those, use a dummy SinglesiteExperiment container instead of MultisiteExperiment |
| 23:08 | < Derakon[work]> | What does that buy me over just using an Experiment subclass directly? |
| 23:10 | | * McMartin successfully runs his first C# module. |
| 23:10 | < Rhamphoryncus> | cleaner.. just tell them to ask the container about file handling. Don't need different behaviours for single vs multiple |
| 23:12 | < Derakon[work]> | So the user's interaction with either case will basically look like "Set up Experiment class, hand it off to a container, and tell the container to run". |
| 23:12 | < Derakon[work]> | But that's just busywork when you're only doing one site; your interaction should instead be "Set up Experiment class, tell it to run." |
| 23:15 | < Rhamphoryncus> | It really depends on your setup |
| 23:15 | < Rhamphoryncus> | It may be significantly cleaner to have a container |
| 23:16 | < Derakon[work]> | Well, I'll give it serious thought as I continue to refine the design. Thanks. :) |
| 23:16 | < Rhamphoryncus> | :) |
| 23:17 | < McMartin> | Do bear in mind, though, that an awful lot of Enterprisey things are the way they are to get around C++ and friends's lack of introspection or dynamic typing. |
| 23:19 | | * McMartin cracks open his copy of Stroustrup |
| 23:19 | < McMartin> | Oh hey, there round isn't. |
| 23:20 | < McMartin> | What the Hell, Bjarne |
| 23:20 | < McMartin> | This is even more awesome because numeric_limits<float>::round_error is totally there. |
| 23:21 | < McMartin> | But nothing that you can do that could yield that error. |
| 23:21 | < Derakon[work]> | Hee. |
| 23:21 | < Rhamphoryncus> | round isn't? |
| 23:21 | < McMartin> | round() is not part of the C standard until the C99 library which only GCC supports by default. |
| 23:22 | < McMartin> | MSVS shifted over to C++ almost exclusively a long time ago and never bothered picking up the C99 library as a result. |
| 23:22 | < McMartin> | This results in some weird gaps, like round() and random(). |
| 23:22 | < McMartin> | floor() and ceil(), on the other hand, A-OK. |
| 23:22 | < Rhamphoryncus> | heh |
| 23:23 | < Derakon[work]> | round(foo) == floor(foo + .5) for positive numbers. |
| 23:23 | < Rhamphoryncus> | 'course it's easy to implement round using ceil |
| 23:23 | < Rhamphoryncus> | err wait, misread it |
| 23:23 | < Rhamphoryncus> | Derakon[work]: not guaranteed though, afaik\ |
| 23:31 | < Derakon[work]> | ...heh, one of the biologists has mentioned the desire to be able to change multisite experiments' behaviors partway through, possibly on some image-analysis-based trigger. |
| 23:32 | < Derakon[work]> | So I could have a MetaMultisiteExperiment~ |
| 23:32 | < Rhamphoryncus> | heh |
| 23:32 | < Derakon[work]> | (e.g. if the camera sees a blob of at least this much total brightness, that means that a chromosome has started to coalesce, so focus on that site and take images more rapidly) |
| 23:33 | < Derakon[work]> | Wrappers around wrappers around wrappers! Enterprise, here I come~ |
| 23:36 | < McMartin> | Next, make a framework that automatically generates wrappers based on an XML specification~ |
| 23:37 | < Rhamphoryncus> | Derakon[work]: all the more reason to use a SingleSiteExperiment |
| 23:39 | < Derakon[work]> | Mmm, or just make MultisiteExperiment the only thing users interact with, with the default value of siteList being "the current site only". |
| 23:53 | | * gnolam hugs modern multicore CPUs. |
| 23:56 | < gnolam> | It's just awesome being able to encode video and watch a decompressed preview of the output while at the same time compiling and listening to music. :) |
| 23:57 | < Derakon[work]> | Heh. |
| 23:57 | < Derakon[work]> | Time was when I couldn't listen to music on my computer without Angband's performance getting severely degraded. |
| 23:58 | < Namegduf> | gnolam: But you're affecting your optimum compiling performance! |
| 23:58 | < Namegduf> | gnolam: You need to have it spawn TWICE the number of processes as your CPU cores! |
| 23:58 | < gnolam> | Just compiling something reasonably large made my previous computer /overheat and crash/. |
| --- Log closed Wed Nov 11 00:00:00 2009 |