| lifeless | we're pretty good on disconnected, if I may say so myself | 00:00 |
|---|---|---|
| gmpff | I saw the story about the renames as first class citizens. And usability seems to be a big driver. | 00:00 |
| gmpff | Cool - thanks for the info! Think I'll give it a try. | 00:00 |
| lifeless | excellent. Just ask here and I'm sure someone will give you a hand, though often weekends are a little quieter than the week | 00:02 |
| gmpff | Thanks. | 00:05 |
| jelmer | lifeless: Do you know what triggers display or hiding of progress bars? | 00:10 |
| lifeless | jelmer: yes | 00:12 |
| jelmer | lifeless: bzr-svn's progress bars are sometimes not shown by bzr, even though I know they'r ebeing created | 00:12 |
| lifeless | do they appear eventuall? | 00:13 |
| lifeless | s/ll/lly/ | 00:13 |
| jelmer | yeah | 00:14 |
| lifeless | ok | 00:14 |
| lifeless | there is debounce protection for small operation | 00:14 |
| lifeless | *operations* | 00:14 |
| lifeless | what can happy is that your first operation takes more than 0.1 seconds | 00:18 |
| lifeless | e.g, many seconds | 00:18 |
| lifeless | without doing a nested child bar or other output | 00:18 |
| lifeless | and this results to the user in no visible output until the first operation finishes | 00:19 |
| lifeless | its possible this is what you are triggering | 00:19 |
| jelmer | hmm, I don't think that's the case. afaik there are progress bars for everything now | 00:20 |
| jelmer | *anything significant | 00:20 |
| lifeless | jelmer: can you trigger this behaviour? | 00:22 |
| jelmer | it appears to be somewhat random to me but I've never spent time looking into it once I hit it | 00:23 |
| lifeless | next time it hits, ctrl-\ and you'll be in pdb | 00:23 |
| lifeless | its the only thing that occurs to me | 00:23 |
| lifeless | I suppose its possible that there is a bug in the bar nesting resulting a nested bar not triggering a show after the MIN_PAUSE | 00:24 |
| lifeless | or many extremely small bars never getting past MIN_PAUSE each | 00:24 |
| jelmer | hmm | 00:28 |
| lifeless | wow | 01:25 |
| lifeless | inventory extraction really blows | 01:25 |
| lifeless | .37 seconds each | 01:31 |
| lifeless | makes indexing...slow | 01:31 |
| mwhudson | this is the main bzrlib performance pain point in loggerhead too | 01:42 |
| mwhudson | make log -v fast and everyone will be happy | 01:43 |
| === lamont` is now known as lamont | ||
| lifeless | mwhudson: well | 01:55 |
| lifeless | I need paths_for(revs_to_fileids) to be fast | 01:55 |
| lifeless | which is in principle log -v FILENAME | 01:55 |
| lifeless | to get the xml's only: | 02:07 |
| lifeless | 0.014 | 02:07 |
| jelmer | lifeless, so it's the xml parsing that's slow basically? | 02:29 |
| lifeless | its a significant factor | 02:29 |
| lifeless | anyhow, new feature time in a sec | 02:29 |
| lifeless | I'm on make it work | 02:29 |
| lifeless | thats better: | 02:38 |
| lifeless | :!bzr search COPYING | 02:38 |
| lifeless | COPYING in revision 'robertc@robertcollins.net-20080608052044-s7ktacyyyiib8zi4'. Summary: 'No summaries yet.' | 02:38 |
| lifeless | nice and fast: | 02:39 |
| lifeless | Misc/HISTORY in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:17190'. Summary: 'No summaries yet.' | 02:39 |
| mwhudson | lifeless: yes, the inventory object creation seems like it might be a bit too all or nothing atm | 02:40 |
| lifeless | so, 1) make it work completed | 02:41 |
| Peng | "No summaries yet."? | 02:41 |
| lifeless | right | 02:41 |
| lifeless | if you do a search that hits a commit message you see | 02:41 |
| lifeless | Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:15502'. Summary: 'Fix a problem reported by Oleg Broytmann, who complains that very' | 02:42 |
| lifeless | file hits used to show the fileid, revision id pair | 02:42 |
| lifeless | my most recent push makes it show the PATH and revision id | 02:42 |
| lifeless | but adds 0.3 of a second for every revision indexed | 03:07 |
| === mark1 is now known as markh | ||
| beuno | lifeless, around? | 04:58 |
| lifeless | yes | 05:00 |
| lifeless | (must diet sometime) | 05:00 |
| beuno | I'm finally trying to get Loggerhead to use bzr-search | 05:01 |
| lifeless | cool | 05:01 |
| beuno | and, btw, it's always very nice to go through your code :) | 05:01 |
| beuno | anyway, I just want revids for loggerhead, and, well, each type of hit seems to handle that differently | 05:02 |
| lifeless | so | 05:03 |
| lifeless | what do you mean 'just want revids' ? | 05:03 |
| beuno | the results | 05:03 |
| beuno | as to what revisions ids match that query | 05:03 |
| lifeless | rather than say specific paths ?:) | 05:03 |
| lifeless | btw, did you see: | 05:04 |
| lifeless | 11:39 < lifeless> Misc/HISTORY in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:17190'. Summary: 'No summaries yet.' | 05:04 |
| lifeless | current tip, its extremely slow to index in this manner, I'm fixing that now. | 05:04 |
| beuno | yes, I say, and I pulled, and I jumped right into getting this working :) | 05:04 |
| beuno | you're even giving the UI some lovin' :p | 05:05 |
| lifeless | yah, sexy is a feature :) | 05:05 |
| lifeless | anyhoo | 05:05 |
| lifeless | I guess I'm saying 'why do you want to limit yourself to just the revision_id' | 05:05 |
| beuno | well, I guess it's because I already have the rest of the information | 05:06 |
| lifeless | do you ? | 05:06 |
| lifeless | so you have file_id, revision_id -> path mappings already available? | 05:07 |
| beuno | and, the current interface for loggerhead accepts a list of revids | 05:07 |
| beuno | yeap | 05:07 |
| lifeless | so | 05:08 |
| lifeless | I think there are a couple of ways to tackle this | 05:08 |
| lifeless | one is to make the Hit interface more pluggable | 05:08 |
| lifeless | so loggerehead can have its own hit types | 05:08 |
| lifeless | this would involving making the constructor interface homogeneous | 05:09 |
| beuno | yes, although from a glance, it seems to be that if all types had revids and fileids (if applicable) available in the same way, well, that would also cover all the use cases similar to LH | 05:10 |
| beuno | but I may be over-simplifying things | 05:10 |
| lifeless | another is to make a revision key always be available which lh could interrogate | 05:11 |
| lifeless | but I think that that is possibly/likely overconstraining the interface | 05:11 |
| lifeless | anyhow | 05:13 |
| lifeless | what would you prefer | 05:13 |
| lifeless | do a patch to make it be like that, with enough tests that I can't accidentally change it on you | 05:13 |
| lifeless | and I'm cool | 05:13 |
| beuno | I'd prefer to "do the right thing", although lazyness is pushing towards the easy fix | 05:14 |
| beuno | I'm looking at how I can make the contructor interface pluggable | 05:14 |
| beuno | in a non-hackish kind of way | 05:14 |
| lifeless | I don't think the right thing is entirely clear yet | 05:14 |
| lifeless | so I'd rather do the thing-that-is-easiest-for-you | 05:14 |
| beuno | I wonder if there are many more use cases for different types | 05:16 |
| lifeless | well | 05:18 |
| lifeless | tags | 05:18 |
| lifeless | threads | 05:18 |
| lifeless | phrases | 05:19 |
| lifeless | I'm considering the logics of working tree indexing | 05:19 |
| lifeless | and taking the very core and making it fully generic | 05:19 |
| beuno | working tree indexing? | 05:20 |
| lifeless | yeah | 05:20 |
| lifeless | wonder where a line of code is in your working tree | 05:20 |
| lifeless | TAGS is kindof primitive | 05:21 |
| lifeless | can't lookup phrases | 05:21 |
| lifeless | (for instance) | 05:21 |
| beuno | as in the last revision? | 05:21 |
| beuno | or uncommitted changes too? | 05:21 |
| lifeless | uncommitted | 05:22 |
| beuno | I've been also thinking that something *really* cool to add on top of this is something like "who worked on this class/method" | 05:22 |
| beuno | I suppose it would be language-specific | 05:22 |
| lifeless | last revision in already available, just need an interface to search for revision ids directly (and stash them as terms( | 05:22 |
| beuno | but that would of been very useful for me many times | 05:23 |
| lifeless | it would be interesting indeed | 05:23 |
| lifeless | the way I would approach is is to add a term for the method to a result which is an author | 05:23 |
| beuno | and that should a fairly straightforward UI in LH | 05:23 |
| beuno | "click on the class/method in annotate, or search for it" | 05:23 |
| lifeless | possibly author,fileid,revision_id or something | 05:24 |
| beuno | hm, yes | 05:24 |
| lifeless | but this is an example where revision_id starts to become less relevant as a mandatory piece of info | 05:24 |
| beuno | right, I can see that | 05:24 |
| lifeless | anyhow, tell me what works best for you and either do it, or I will for you | 05:25 |
| beuno | but I'd have to whip a new UI in LH, so I can tailor that around what bzr-search gives me | 05:25 |
| beuno | I'll take a stab at a patch now | 05:25 |
| lifeless | the shortest-possible-path for you is an isinstance check in LH | 05:26 |
| lifeless | 1) make it work | 05:26 |
| lifeless | :) | 05:26 |
| beuno | actually, yeah, but being able to get revids in a nicer way will probably tend to break less with newer versions | 05:29 |
| beuno | anyway, yes, I'll make it work in a hackish-sort-of-way, and then go back :) | 05:30 |
| === _W_ is now known as W_ | ||
| beuno | aaaaaaaaaand, it works :) | 05:47 |
| lifeless | oh yay | 05:48 |
| lifeless | I think I have a corrupt test data set | 05:48 |
| lifeless | jelmer: ping | 05:48 |
| lifeless | ah no, rich root breaks my optimised code | 05:49 |
| === mwhudson__ is now known as mwhudson | ||
| lifeless | much better | 06:04 |
| lifeless | did 100 in 0.0627507519722 each | 06:04 |
| lifeless | thats down from 0.37 | 06:04 |
| lifeless | its also chopped 150M of memory usage :) | 06:05 |
| beuno | what did you do? | 06:06 |
| lifeless | patience kemosabe | 06:06 |
| beuno | hahah | 06:06 |
| * beuno stis back down | 06:06 | |
| beuno | *sits | 06:06 |
| beuno | well, LH uses bzr-search | 06:07 |
| beuno | it and rocks | 06:07 |
| lifeless | revno 34 | 06:07 |
| beuno | mwhudson, ^ | 06:07 |
| lifeless | and you can peek | 06:07 |
| lifeless | beuno: fantastic | 06:07 |
| lifeless | beuno: screen shot! or demo site! | 06:07 |
| lifeless | I would love to show bkor it running :) | 06:07 |
| mwhudson | beuno: nice! | 06:07 |
| beuno | let's see if the router will let me redirect 8080 | 06:08 |
| lifeless | 34 is pushed FWIW | 06:08 |
| mwhudson | loggerhead could probably steal that paths_from_ids code | 06:09 |
| lifeless | I don't know if it is faster when looking at a full revision | 06:09 |
| lifeless | but generally we aren't looking at a full revision in the search code | 06:10 |
| lifeless | (even though we need full xml to process things) | 06:10 |
| beuno | lifeless, http://200.127.6.219:8080/bazaar/bzr_garbage/changes | 06:12 |
| beuno | search away | 06:12 |
| lifeless | cool | 06:14 |
| lifeless | so, you're not showing FileTextHits any different to revision hits? | 06:14 |
| beuno | not yet :) | 06:15 |
| lifeless | no worries | 06:15 |
| beuno | the sql cache got in the way and I lost a bunch of time on that | 06:15 |
| beuno | (it turns out it doesn't like duplicate hits) | 06:15 |
| beuno | I also want to show hwo many results there are, highlight it (text if in commit message, file if in file) | 06:16 |
| beuno | s/hwo/how | 06:17 |
| lifeless | excellent | 06:17 |
| lifeless | well, feel free to send me patches to make bzr-search nicer for you | 06:17 |
| beuno | but I should probably have some way to index the repos from LH first :p | 06:17 |
| lifeless | I *like* patches | 06:17 |
| * lifeless goes hunting a gnome sysadmin | 06:18 | |
| beuno | heh, will do | 06:18 |
| lifeless | I think a limit is the next thing | 06:19 |
| lifeless | to be able to say 'no more than 1000 revs' or whatever | 06:19 |
| beuno | yes, that's probably sensible | 06:20 |
| beuno | and, an "order by relevance" | 06:20 |
| lifeless | I'm thinking for LH actually | 06:20 |
| lifeless | well, relevance is actually the hard thing about searching :P | 06:20 |
| lifeless | relevance talks about precision, if you want to read up on IR theory | 06:21 |
| beuno | yeah, start with something basic, like most amount of hits, prioritize commit messages maybe | 06:21 |
| lifeless | mwhudson: actually, I think ids_to_paths should be on Repository | 06:22 |
| lifeless | mwhudson: but, backward compatibility etc | 06:22 |
| beuno | something basic will be much better than seemingly random order | 06:22 |
| lifeless | lol small deltas: | 06:22 |
| lifeless | did 100 in 0.00272021055222 each | 06:22 |
| lifeless | beuno: there is no weighting in the core at the moment though | 06:23 |
| lifeless | beuno: so any order is equivalent as far as the system is concerned | 06:23 |
| lifeless | who beuno | 06:24 |
| beuno | ehm, Martin? :p | 06:24 |
| lifeless | getting your last name right | 06:24 |
| lifeless | to do a demo to Lynne of the web search | 06:25 |
| lifeless | she was asking how the code was going :) | 06:25 |
| beuno | who Lynne? :p | 06:25 |
| lifeless | erm, my Fiance! :) | 06:26 |
| beuno | ah! you're enganged. I somehow don't know that | 06:27 |
| lifeless | hehe, enganged :) | 06:27 |
| lifeless | it would be nice to show more details, I get back 1594.2.17 when searching on your name | 06:28 |
| lifeless | but can't figure out why :) | 06:28 |
| beuno | NEWS? | 06:28 |
| beuno | oh, no | 06:28 |
| lifeless | could you run 'bzr search Albisetti' on that tree? | 06:29 |
| beuno | yes, one sec | 06:29 |
| lifeless | no progress bar is shitting me | 06:32 |
| lifeless | time to fix that | 06:32 |
| beuno | lifeless, bzr search doesn't return that revid | 06:32 |
| beuno | LH's cache must be screwing with me again | 06:32 |
| lifeless | beuno: so, first bug found :) | 06:32 |
| beuno | yes, thank you :) | 06:33 |
| beuno | I'm going to rip out most of the cache next week, so if it is a cache bug, it should be squashed with that | 06:34 |
| lifeless | mmm | 06:36 |
| lifeless | would be nice to be sure of it/be able to show people this :) | 06:36 |
| beuno | oh, yes, I won't defer it, just that I won't fix the cache if it is | 06:36 |
| beuno | I'll do some cleanups, like, not hardcode '/home/beuno/bzr_devel/bzr.garbage' into the code, and push it | 06:37 |
| lifeless | sweet | 06:38 |
| lifeless | mwhudson_: welcome back | 06:40 |
| lifeless | python-packs$ time (bzr search socket inet_pton | head -n1) | 06:40 |
| lifeless | Mac/Include/pyconfig.h in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:22230'. Summary: 'No summaries yet.' | 06:40 |
| lifeless | bzr: broken pipe | 06:40 |
| lifeless | real 0m0.726s | 06:40 |
| lifeless | user 0m0.592s | 06:40 |
| lifeless | sys 0m0.084s | 06:40 |
| beuno | that's with the inventory tweaks? | 06:41 |
| lifeless | they only affect index time | 06:41 |
| lifeless | search is orthogonal | 06:41 |
| beuno | ah, diffs didn't tell me *where* that change was :p | 06:42 |
| lifeless | I thought the commit log would :P | 06:43 |
| beuno | well, if we had a bzr pull --show-log... | 06:43 |
| beuno | (yes, I did ignore the commit message, it's just a good time to plug in a feature I want) | 06:44 |
| beuno | ugh, I'm stuck and sleepy. I'm off to bed | 07:48 |
| beuno | g'night | 07:48 |
| lifeless | gnight | 07:49 |
| lifeless | abentley: abentley@panoramicfeedback.com-20070410141425-86yh4m1cb6wwnwwm seems to have a corrupt inventory | 08:21 |
| lifeless | abentley: oh, nvm, it's a format behaviour I have not accomodated | 08:21 |
| abentley | You mean the fact that it has a unique root? | 08:22 |
| lifeless | I didn't remember what format 5 looked like | 08:23 |
| lifeless | I've written a custom path-from-xml extractor thats 5 times faster than deserialising to an Inventory | 08:23 |
| abentley | lifeless: But we're still on format 5... | 08:24 |
| lifeless | on average that is, for processing deltas when you don't need all-paths | 08:24 |
| lifeless | abentley: right, format-5 rich roots were not in my test suite | 08:24 |
| lifeless | I tried format-5 plain, and rich-root-pack in my test suite | 08:24 |
| abentley | lifeless: that's quite nice. | 08:25 |
| lifeless | It seems to have worked out well. I'd like to fit it into Repository or some such | 08:26 |
| lifeless | its not optimised yet either | 08:26 |
| lifeless | but 5 times faster was sufficient to stop at for now | 08:26 |
| lifeless | I'm hoping that some of what I develop may go into the core packs as faster lookups for common things | 08:38 |
| lifeless | this just came together as an interesting project :) | 08:38 |
| johnf | with bzr-svn is it possible to work out which svn revision number I've just merged? | 08:55 |
| lifeless | I don't know | 08:58 |
| Peng | If you find a way, I'd like to know. | 09:16 |
| Peng | Could tags be used? Does bzr scale well with thousands of tags? | 09:17 |
| AfC | Peng: I don't think you'd want one tag per Subversion revision. | 09:22 |
| AfC | johnf: if you have a branch which is just a straight pull of a svn+ssh:// URL, then I think the Bazaar revno == Subversion's. I could be wrong, but that was the impression I got. Let me test that hypothesis some. | 09:22 |
| Peng | AfC: Why not? | 09:23 |
| AfC | Peng: signal to noise ratio, of one thing: it would make other uses of tagging a little less palatable to use. | 09:25 |
| Peng | Yeah.. | 09:25 |
| Peng | I'm really curious if it would still perform well though. (But not curious enough to test it myself.) | 09:26 |
| AfC | Hm. bzr[-svn] revno = 219 ; subversion revno = 249 | 09:28 |
| AfC | Guess not. | 09:28 |
| lifeless | Peng: they don't | 09:28 |
| lifeless | I would check the svn revision for a property | 09:28 |
| lifeless | jelmer may have stashed it there | 09:28 |
| Peng | AfC: svn revisions are repo-wide; bzr revisions are branch-wide. | 09:29 |
| gour | svn should be thrown away...they still have problems after 11 RCs with 1.5.0 | 09:38 |
| lifeless | hmm, I should add text hit summaries before blogging | 09:44 |
| * lifeless goes to do that | 09:44 | |
| johnf | aha bzr version-info has it | 10:06 |
| johnf | revision-id: svn-v3-trunk0:90e61fa5-4541-0410-a685-e5b9dba3c764:trunk:74 | 10:06 |
| johnf | svn revision 74 | 10:06 |
| === pbor|out is now known as pbor | ||
| lifeless | man | 10:20 |
| lifeless | crying tiger is _hot_ tonight | 10:21 |
| thekorn | hi, is there a way to only show the commit messages from the 'main-line' with 'bzr log' | 10:26 |
| thekorn | not the messages of the merged changes | 10:26 |
| lifeless | log --line | 10:29 |
| lifeless | or --short I think too | 10:29 |
| === VK5FOSS is now known as Kamping_Kaiser | ||
| thekorn | thanks lifeless, --short looks good | 10:50 |
| === Mez|DPC is now known as mez | ||
| === mez is now known as Mez|DPC | ||
| === Mez|DPC is now known as mez | ||
| === mez is now known as Mez|DPC | ||
| jelmer | james_w: ping | 13:27 |
| rexium | Does anyone know how to commit to an sf.net svn repo with bzr-svn? (or have a link to the relevant documentation?) | 13:27 |
| jelmer | johnf, ping | 13:27 |
| james_w | hi jelmer | 13:27 |
| jelmer | james_w: debian bug 472543 - does that patch look sensible to you? | 13:27 |
| ubottu | Debian bug 472543 in bzr-builddeb "bzr-builddeb: FTBFS: Unknown command "test-builddeb"" [Serious,Open] http://bugs.debian.org/472543 | 13:27 |
| johnf | jelmer: pong | 13:27 |
| jelmer | johnf: The subversion revision number is sometimes part of the bazaar revision id | 13:28 |
| johnf | jelmer: yep eveuntually worked that out and even blogged about it :) | 13:28 |
| james_w | jelmer: That should have been included in the last upload, maybe I messed up the changelog, let me look. | 13:28 |
| jelmer | james_w: The BTS doesn't contain any claims it's been fixed | 13:29 |
| jelmer | johnf: It's not something that's guaranteed though - if the commit was pushed from bzr, it could be a completely different revno | 13:29 |
| jelmer | rexium: Simply use it like any svn repo with bzr-svn | 13:30 |
| rexium | jelmer, I am getting authentication issues | 13:30 |
| jelmer | rexium, see the FAQ entry about authentication and http | 13:30 |
| james_w | jelmer: ah, my mistake, let me close it. | 13:31 |
| james_w | jelmer: thanks for catching it. | 13:31 |
| jelmer | james_w: Thanks | 13:32 |
| * jelmer is chasing down RC bugs at a BSP atm | 13:32 | |
| === Mez|DPC is now known as mez | ||
| === mez is now known as Mez|DPC | ||
| james_w | anyone want to review my first attempt at a bzr screencast? | 16:24 |
| james_w | http://jameswestby.net/scratch/introducing_yourself.ogg | 16:24 |
| Leonidas | james_w: you speak a little bit too fast, I think. | 16:27 |
| * Leonidas watches it to the end now | 16:27 | |
| gour | james_w: i think the same - too fast and too long sentences. otherwise it's very nice | 16:28 |
| * gour watched till the end | 16:28 | |
| * Leonidas too | 16:29 | |
| Leonidas | Yeah, the text in the console is even pretty much readable. | 16:30 |
| james_w | thanks, I'll try and slow down for my next one. | 16:30 |
| matkor | james_w: great, but I agree previous comments about speed of talking | 16:30 |
| gour | james_w: what do you use for casting? | 16:31 |
| james_w | heh, recordmydesktop to capture | 16:31 |
| gour | james_w: use 'comma' in your speech ;) | 16:31 |
| james_w | but it gets pretty messy from then to get to the finished product. | 16:31 |
| james_w | gour: heh, what are they? | 16:32 |
| gour | heh, atm i'm doing some video-editing in cinelerra | 16:32 |
| james_w | I tried that, but I couldn't work it out at all. | 16:32 |
| gour | james_w: look for this ',' sign on your keyboard :-) | 16:32 |
| * gour thinks video-editing on linux still sucks. hopefully lumiera will fix it, but the project needs help | 16:33 | |
| jelmer | james_w: btw, did you see the announcement of the extremadura vcs-pkg meeting? | 16:34 |
| james_w | jelmer: yeah, I never registered my interest. | 16:34 |
| Pilky | james_w: the podcast is good, the audio could do with some work though | 16:40 |
| Pilky | the music needs to fade in/out before/after you finish talking | 16:40 |
| Pilky | plus your voice could probably do with being a bit loud | 16:41 |
| Pilky | *louder | 16:41 |
| james_w | I like having a bit of overlap, but I could cut the music a bit further. | 16:41 |
| Pilky | oh, a bit of overlap is fine, it just seems a bit too much overlap, and seems to drown out your voice a bit | 16:42 |
| james_w | My mic picks up a lot of noise on my laptop, so I can't have it too much louder, but I'll put my new soundcard in my other machine and see if it is any better there. | 16:42 |
| james_w | thanks for the feedback though. | 16:42 |
| jelmer | james_w: Ah, ok | 16:47 |
| jelmer | james_w: Thanks for merging that patch btw | 16:47 |
| === bigdo2 is now known as bigdog | ||
| rockstar | Is there a bzr plugin that will help me create debs from a bzr repository? | 18:20 |
| Jc2k | bzr-builddeb? | 18:26 |
| Jc2k | rockstar: https://launchpad.net/bzr-builddeb | 18:27 |
| rockstar | Awesome, thanks. I knew there was something, but bzr-deb doesn't google well... | 18:27 |
| Jc2k | :) | 18:28 |
| rockstar | That should belong to the bazaar project group, methinks | 18:28 |
| james_w | hi rockstar | 18:55 |
| james_w | give me a shout if you have any trouble with it. | 18:55 |
| rockstar | james_w, well, I'm not a great packager. Ideally what I would like is a tool that just creates a dummy debian/ folder with default files in it... | 18:56 |
| james_w | rockstar: dh-make will do that for you | 18:57 |
| james_w | rockstar: I've added it to the bazaar group, thanks. | 18:58 |
| rockstar | james_w, well, not without needing a .orig.tar.gz first | 18:58 |
| james_w | rockstar: ah true, though it probably has a "native" package mode that will avoid the need for that. | 18:59 |
| james_w | rockstar: yup, dh_make -n | 19:00 |
| * rockstar wipes egg off his face | 19:00 | |
| scorpioxy | hey guys, i am trying to push via ssh. Isn't the url syntax similar to that of sftp? sftp works, ssh i think is spitting a command not found. | 19:13 |
| james_w | scorpioxy: you need to have bzr installed on the server to use bzr+ssh:// | 19:14 |
| scorpioxy | james_w: i think i do. Issuing bzr does the right thing. | 19:14 |
| james_w | is it installed in the $PATH? | 19:15 |
| scorpioxy | james_w: yes | 19:16 |
| james_w | and "ssh server bzr" doesn't complain? | 19:17 |
| scorpioxy | james_w: umm...what is that? do you mean bzr serve? | 19:18 |
| scorpioxy | james_w: oh oh...never mind | 19:19 |
| scorpioxy | james_w: it says command not found...but bzr is in my $PATH...this is a shared host, does it have anything to do with that? | 19:20 |
| james_w | scorpioxy: is it in a part of the $PATH that is set in .bashrc or similar? | 19:22 |
| james_w | I've got to go, but I will point you to $BZR_REMOTE_PATH, and suggest that you hang around, because someone else might be able to help. | 19:22 |
| scorpioxy | james_w: alright, thanks | 19:22 |
| ddaa | jelmer: on the bug tracker, I saw you say something along the lines of: | 19:25 |
| ddaa | "branching schemes are unecessary. Kill, kill, ex-ter-mi-na-te" | 19:26 |
| ddaa | could you elaborate on how they are unecessary? | 19:26 |
| jelmer | ddaa: hi | 19:27 |
| jelmer | ddaa: Yes - they do not need to be part of the revision id | 19:28 |
| jelmer | ddaa: Since we can just follow the history of the path we're branching | 19:28 |
| ddaa | uh | 19:28 |
| ddaa | sorry, dvcs neurons a bit rusty | 19:29 |
| jelmer | the idea would be to replace branching schemes with a somewhat similar thing called 'repository layouts' that is less intrusive | 19:29 |
| ddaa | I'd love to hear about it. | 19:29 |
| jelmer | e.g. just used to determine what a branch is when converting the whole repository, but not when analysing history | 19:29 |
| ddaa | let me think aloud for a bit | 19:30 |
| ddaa | ATM, branching scheme are not used to "guess" merges right? | 19:31 |
| jelmer | no, merges are never guessed - only tracked explicitly using file properties | 19:31 |
| ddaa | The only way you get merge in bzr-svn history is (currently) through revisions created by bzr, svk and eventually svn>=1.5. | 19:32 |
| jelmer | correct | 19:32 |
| ddaa | the thing is, those merges involve other paths in the svn repo | 19:34 |
| ddaa | and that's where branching schemes get involved | 19:34 |
| jelmer | why would that involve branching schemes? We just allow all paths in the repo as branch paths | 19:35 |
| ddaa | sorry, I do not think I'll be able to make much sense, this stuff has just gone too hazy :( | 19:35 |
| ddaa | my concern comes from the fact I needed to create a new branching scheme to hack around a limitation in bzr-svn | 19:36 |
| ddaa | i.e. when pushing a commit, it tried to inspect some branches that I do not have access to, and failed 403 | 19:36 |
| ddaa | It really should not need to look at those branches (such as "/toolkit/trunk") when pushing to my branch (such as "/language/trunk") | 19:37 |
| jelmer | that's the bit that's going to be replaced by repository layouts | 19:38 |
| jelmer | it's calling Repository.has_revision() to figure out which of the revisions it will push are already present somewhere in the repository | 19:38 |
| ddaa | but it was easier for me we write a RestrictedTrunkBranchingScheme that just looks at /foo/trunk, /foo/branches/*, and /foo/tags/* | 19:38 |
| ddaa | jelmer: the current behaviour is meant to allow things like "commit on A, merge A into B and commit B, push B"? | 19:40 |
| ddaa | (where A and B are svn branches) | 19:40 |
| jelmer | the current behaviour is meant to support something like this: | 19:41 |
| jelmer | pushing large branch foo to /branches/foo | 19:42 |
| jelmer | then pushing large branch bar which descends from foo to branches/bar | 19:42 |
| jelmer | the latter would do a copy from /branches/foo to /branches/bar and then push the extra revisions not yet present in foo | 19:42 |
| ddaa | I see. | 19:42 |
| jelmer | anyway, that bit is not going away, it's jsut going to be more flexible | 19:43 |
| jelmer | so it would be possible for the user to specify how hard bzr-svn would have to look for revisions to reuse | 19:43 |
| ddaa | are you actually working on this (or planning to, at least), or is that a "someone would need to siphon out jelmer's brain and take over" kind of plan? | 19:44 |
| jelmer | I'm working on this bit by bit | 19:45 |
| jelmer | The initial work (now done) was adding support for having more than one mapping scheme present in the same version of bzr-svn | 19:45 |
| jelmer | so it's now possible to support revisions created with and without branching schemes without having to use a different version of bzr-svn | 19:45 |
| jelmer | most of the branching-scheme-less mapping also already works and I've done ad-hoc testing of it | 19:46 |
| ddaa | it knocked my socks off when I saw that if I pushed revisions from with my custom branching scheme, and then switched back to the standard trunk1 scheme, it preserved the shape of the ancestry graph. | 19:47 |
| ddaa | jelmer: which kind are you? Motivated by thank you or by complains? | 19:48 |
| jelmer | ddaa: yes | 19:50 |
| jelmer | ddaa: I mean, both | 19:50 |
| ddaa | I can do both :) | 19:50 |
| ddaa | So: Thanks, at work they use svn (thanks god!), now I have something which will allow me to make merges without having to reimplement gnu-arch-era star-merge in scripts... | 19:52 |
| ddaa | also, making bzr-svn to work gave me the motivation to install ubuntu on my office workstation (thanks WUBI) | 19:52 |
| ddaa | (between newline translation on windows native and issues recompiling the python bindings on cygwin, I could not make it work on windows) | 19:54 |
| jelmer | ddaa: (-: | 19:55 |
| jelmer | compiling the bindings on Windows should be a lot easier soon | 19:55 |
| jelmer | I've redone them using pyrex | 19:55 |
| ddaa | Now, if only it worked correctly without this ghastly hack of mine, I would be able to recommend it to the other IT folks. | 19:55 |
| ddaa | HOOOORAY | 19:55 |
| ddaa | about pyrex | 19:55 |
| jelmer | I really regret not having done that earlier, the patches I contributed to the current bindings took much more time than the pyrex bindings | 19:56 |
| ddaa | anyway, the recompiling issue will solve it itself when svn1.5 gets out, right? | 19:56 |
| ddaa | now, with a usable windows version, and better support for access restrictions, that would really take some pain out of the folks who try to do patch management on parallel branches using svn ATM. | 19:57 |
| ddaa | they seem to think it's a law of nature that integrating "deltas" (as they say) involves a mind-dulling amount of conflict resolution. | 19:58 |
| ddaa | well... it's probably is, considering how shit the code is probably organized wrt to version control, but bzr would certainly take some of the pain it out if only they could use it. | 19:59 |
| ddaa | jelmer: is that enough motivation for now? | 19:59 |
| jelmer | ddaa: :-) Certainly | 20:00 |
| jelmer | I'm still waiting for the complaints though :-P | 20:00 |
| ddaa | hu | 20:00 |
| ddaa | I complained that I could not make it work on windows and that I could not recommend it to my co-worker in its current state... | 20:01 |
| ddaa | the rest of the complaints would relate to the lack of a tortoisebzr, but that's not your dept... | 20:01 |
| ddaa | jelmer: I'm starting to miss free software hacking | 20:02 |
| ddaa | maybe I could give you a hand if you could give me some bite-sized task and a bit of mentoring. | 20:02 |
| ddaa | I know a bit about bzr and svn conversion kind of things :) | 20:02 |
| jelmer | ddaa: (-: | 20:03 |
| jelmer | ddaa: The launchpad bugs page probably has some interesting todo things | 20:05 |
| ddaa | jelmer: what's the benefit of using revision props instead of file props? | 20:11 |
| ddaa | it only provides a marginal performance improvement, as all revisions without revprops will still need to be inspected for fileprop changes for backwards compatibility, and it adds a major new code path. | 20:13 |
| ddaa | I can see how that's "more pure", but I do not see how that's a good technical choice. | 20:14 |
| ddaa | oh, right bug 128496 hit me too, and it's particularly nasty as on french localized windows installation the $HOME contains such non-ascii chars. | 20:15 |
| ubottu | ddaa: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/128496/+text) | 20:15 |
| * Peng pats ubottu. | 20:15 | |
| ddaa | bug 128496 "Unable to open native working tree with non-ascii filenames" https://bugs.launchpad.net/bzr-svn/+bug/128496 | 20:16 |
| ubottu | Launchpad bug 128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] | 20:16 |
| ubottu | Launchpad bug 128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] https://launchpad.net/bugs/128496 | 20:16 |
| * ddaa punches ubottu in the nose | 20:16 | |
| Peng | Haha. | 20:17 |
| jelmer | re | 20:18 |
| jelmer | ddaa: Revision properties don't show up in "svn diff" and they don't annoy users of commit notification emails or trac users | 20:18 |
| jelmer | ddaa: Also, they don't confuse "svn merge" (which tries to merge those preoprties as well) | 20:18 |
| ddaa | Ok, that seem like good reasons :) | 20:18 |
| jelmer | ddaa: s/pyrex bindings/C bindings/ | 20:54 |
| ddaa | meh? | 20:54 |
| ddaa | Why bother? Pyrex does all the tedium for you. And it's deliciously geeky too. | 20:54 |
| * ddaa thinks he saw something on cheeseshop not too long ago that claimed to be the successor of pyrex | 20:55 | |
| Peng | Cython. | 20:57 |
| Peng | I don't know its current status as Pyrex has come back from the dead. | 20:57 |
| jelmer | Pyrex and Cython were both too limited | 20:57 |
| jelmer | They couldn't handle the callbacks in the subversion API that need to return a Subversion error struct when an exception is raised | 20:58 |
| ddaa | That's funny, I do not remember having such a problem when I investigated pyrex bindings to libsvn for launchpad back then. | 21:01 |
| jelmer | I confirmed with the pyrex/cython developers that it was something that couldn't be handled with either at the moment | 21:01 |
| ddaa | IIRC, the technique I used was | 21:03 |
| ddaa | 1. as the svn callback, use a wrapper function that has a try/except catch all and return the appropriate error if it caught an exception | 21:04 |
| ddaa | that's a C function | 21:04 |
| ddaa | 2. as the baton of the svn callback, use a python callable | 21:04 |
| ddaa | or a combination of the callable and any desired arguments | 21:05 |
| ddaa | the key being that all svn callbacks are associated to "batons" | 21:05 |
| ddaa | jelmer: how is that insufficient? | 21:05 |
| ddaa | lifeless: just in case you missed that one, I know you'll love the look of it. http://pypi.python.org/pypi/multimethod/0.2 | 21:06 |
| jelmer | ddaa: If you catch the exception you can't reraise it again and change the returned struct | 21:08 |
| ddaa | oh... I see | 21:09 |
| ddaa | it's for the commit stuff, right? | 21:09 |
| jelmer | yeah, commit editor and ra reporter | 21:09 |
| ddaa | you want to let exceptions from the commit callbacks (I did not look at those) bubble all the way up _through_ the layer of libsvn involved. | 21:10 |
| jelmer | yep | 21:10 |
| jelmer | and if I return NULL it will call continue calling python callbacks | 21:11 |
| ddaa | sure, you need to give an error status to libsvn so it returns early. The thing is that you need to store the exception data and traceback in global storage to preserve it while control moves back to the python caller. | 21:12 |
| ddaa | Which means you need to play really ugly games with the GIL. | 21:13 |
| ddaa | otherwise you could have insanity in multithreaded context | 21:13 |
| ddaa | that's the issue you were trying to solve? | 21:13 |
| tro | vila: is there a revision of the webdav plugin that's compatible with bzr 1.5? | 21:16 |
| tro | right now i'm getting "not installing http[s]+webdav:// support (only supported for bzr 1.6 and above)" with the latest revision | 21:16 |
| jelmer | ddaa: other things were annoying as well - pyrex doesn't support the C preprocessor for example | 21:17 |
| jelmer | so there's no proper way to support both svn 1.4 and functions from svn 1.5 when they're available | 21:17 |
| ddaa | THAT bit sounds scary | 21:17 |
| jelmer | e.g. there's no way to do #ifdef SVN_MINOR_VERSION > 5 | 21:18 |
| ddaa | I see | 21:18 |
| ddaa | okay, you're clearly outside the kind of problems pyrex tried to solve. | 21:19 |
| ddaa | If I were you | 21:19 |
| jelmer | yeah, and the Python C API is quite sensible | 21:19 |
| ddaa | I would not have been this much of a perfectionist. | 21:19 |
| jelmer | it took me about a day to do the initial bits in Pyrex and then another day to rewrite all of it in C | 21:19 |
| jelmer | 18 hour days :-) | 21:20 |
| ddaa | You're going to make me look bad. When I was asked how much time it would take to move cscvs-launchpad to pyrex bindings, I said "weeks". | 21:20 |
| ddaa | You know, test suites, code reviews, etc. | 21:21 |
| ddaa | and also hundreds of users relying on daily code imports. | 21:21 |
| jelmer | well, this was about 36 hour in total so that's pretty much a full work week | 21:22 |
| jelmer | and I already had a lot of the test code | 21:22 |
| jelmer | and it's not finished yet - there's some segfaults remaining in the C code | 21:22 |
| jelmer | nor did I have to do the workarounds you'd have to do in Pyrex :-) | 21:23 |
| jelmer | so I don't think weeks is an unfair estimate | 21:23 |
| ddaa | Not that the work itself was particularly difficult. But getting stuff up to launchpad code-review quality takes fixing up a lot of details like naming, coding standards, docstrings, etc. | 21:23 |
| ddaa | Well, they'd have been happy with c bindings too. | 21:23 |
| ddaa | There's also the fact that you grok a lot more about libsvn than I do. | 21:24 |
| ddaa | That's funny when I think of it. | 21:25 |
| ddaa | At my current job, I'm hacking up a prototype, with better test coverage than mission-critical production code. | 21:25 |
| ddaa | It's funny enough that I got into a one-of-kind research-development mission where I got to pick Python as implementation language in a business where almost everything is short-cycle development in C++/VB/C# :) | 21:27 |
| ddaa | I need to get this mission over with as soon as possible, or I'll go crazy. | 21:27 |
| ddaa | Investment banking is definitely not my cup of tea. | 21:27 |
| jelmer | :-) So you're working mostly on Windows these days? | 21:28 |
| ddaa | Mostly, yes. | 21:28 |
| ddaa | Until I decided to install ubuntu on my workstation. | 21:28 |
| ddaa | I went out to learn what the workplace is really like. | 21:29 |
| ddaa | But somehow, my profile got me into one very special mission. | 21:30 |
| ddaa | Maybe I should have tried to look dumber ;) | 21:30 |
| jelmer | (-: | 21:31 |
| === Mez|DPC is now known as mez | ||
| === mez is now known as Mez | ||
| === abadger1999 is now known as Guest56436 | ||
| === abadger19991 is now known as abadger2000 | ||
| === abadger2000 is now known as abadger1999 | ||
| awilkins | No abentley? | 21:46 |
| jelmer | ddaa: well, at least you get to do python now rather than something horrible like C++ | 21:47 |
| ddaa | Well, I did C++ in a previous life. | 21:47 |
| * awilkins did VB6 in a previous life | 21:48 | |
| ddaa | If you can get over the "fighting with the compiler" bit, there's plenty of interesting puzzles there. | 21:48 |
| ddaa | The shame is that most of those puzzles involve working around shortcomings of the language :) | 21:48 |
| ddaa | I mean... most of those puzzles are about working around the language. | 21:49 |
| jelmer | heh | 21:49 |
| ddaa | right, the situation could be a whole lot worse. | 21:49 |
| ddaa | So I still expect to drive this project to completion. Which will probably take another six months or so. | 21:50 |
| vila | tro: the 1.6 restriction is mostly me being lazy to test against previous revisions. The tests may require a 1.4 or 1.5 but the code itself should be ok with any bzr version you can put your hands on. But out of curiosity, why do you need to stick with 1.5 ? | 21:54 |
| libwilliam | I was listening to a podcast where they talked about Bazaar doing something with XML files for integration into other apps. Is this in progress or implemented already? | 22:21 |
| beuno | libwilliam, yes, it's a plugin, bzr-xmloutput | 22:22 |
| beuno | a few projects are using it | 22:22 |
| beuno | https://launchpad.net/bzr-xmloutput | 22:23 |
| libwilliam | beuno, thanks ill check it out | 22:24 |
| beuno | libwilliam, was that the IDE Integration podcast? | 22:24 |
| Verterok | libwilliam: the xmlrpc bit isn't there yet, but we 're working on it | 22:25 |
| Verterok | hi beuno | 22:25 |
| beuno | hey Verterok :) | 22:26 |
| beuno | libwilliam, Verterok is the author, so you can blame him for anything that goes wrong ;) | 22:26 |
| libwilliam | bueno, i'm trying to find it again, it might have been from a post I read on This Week In Bazaar or the Launchpad Podcast | 22:27 |
| libwilliam | great news, now I know who to point the finger at =) | 22:27 |
| libwilliam | I am doing the integration with Anjuta, and was doing alright using the C/Python API, but I got hung up on trying to get a list of the log messages, so I remembered hearing about this XML thing so figured I would check it out | 22:28 |
| Verterok | sure :) | 22:29 |
| beuno | libwilliam, so you're William Fagan? | 22:30 |
| libwilliam | ya | 22:31 |
| beuno | I just added an "email" column to the IDEIntegration wiki: http://bazaar-vcs.org/IDEIntegration | 22:31 |
| beuno | to be able to keep in touch with everyone | 22:31 |
| beuno | libwilliam, so you're making progress with anjuta? | 22:31 |
| libwilliam | I just updated the page | 22:32 |
| beuno | libwilliam, cool, thanks. Have you got any code published yet? May help to get it out there as soon as possible, for drive-by contributions | 22:33 |
| beuno | brb | 22:33 |
| Verterok | libwilliam: I'm working in the xmlrpc service for it, my current prototype focus on keeping the same CLI/command oriented interface to minimize the python/bzr startup time for each call... | 22:34 |
| libwilliam | ya I am doing alright. I have a lot of the functionality in. Now I am stuck on some issues with doing some things in Bazaar because I am so lost with the Python API | 22:34 |
| Verterok | libwilliam: next step is to provide low level api (in comparsion to CLI commands) | 22:35 |
| libwilliam | For example, my log GUI needs to get the log message, commiter, timestamp etc to put into the treeview and I am having a hard time understand the API to get that data | 22:35 |
| beuno | libwilliam, well, with XML it will be trivial | 22:35 |
| beuno | but if you want to use the Python API, let me know and I'll be happy to help you whip up that code | 22:36 |
| Verterok | libwilliam: did you looked bzrlib/log.py? | 22:36 |
| libwilliam | Vertorok, ya I have been looking at the log.py, I have been trying to reproduct the _show_log essentially in C but it has been a pain, so thats when I decided to go look for the XML | 22:37 |
| Verterok | oh, I get it, I can't even imagine how to get that done in C :P | 22:38 |
| libwilliam | ya, its been a depressing afternoon trying to figure it out =) | 22:39 |
| libwilliam | so without me really looking into it yet, with the xml plugin would I like request a log, and it will output to xml, then I would parse the xml file? | 22:39 |
| libwilliam | excuse me for the ignorance, I am asking without looking into it yet | 22:40 |
| Verterok | libwilliam: yep, the default output is stdout, but you can redirect to a file | 22:40 |
| ddaa | probably, if you are looking to minimize the python spawning cost, you could use the "shell" command (in bzrtools I believe) | 22:41 |
| Verterok | libwilliam: just a note, xmloutput trunk overrides builtins commands, my current work is in the standalone_commnand branch to be completetly independent of the bzr builtins commands | 22:42 |
| ddaa | to spawn a slave bzr process, then run whatever command line you need and get its output across a pair of stdin/stdout pipes | 22:42 |
| Verterok | ddaa: sure, the main problem I have with CLI is the win32/*nix mismatch :( (it's a pain to make it work right in win32) | 22:44 |
| ddaa | really, bzr should offer line protocol to allow access to most of the API functionality without involving a C api, but nobody was really interested enough to make this happen | 22:44 |
| Verterok | actually, cmd.exe is...well ugly :) | 22:44 |
| ddaa | ugh | 22:44 |
| libwilliam | verterok, that sounds like it will solve a lot of the issues I have been to scared to dive into. I would like to get this into the next Anjuta build for the next gnome, will the standalone be done by then, if so I will start using that instead of the trunk version | 22:45 |
| Verterok | libwilliam: bzr branch lp:~guillo.gonzo/bzr-xmloutput/standalone_commands :D | 22:46 |
| Verterok | it's a work in progress, but all the commands implemented in trunk are already there ;) | 22:46 |
| Verterok | libwilliam: the xmlrpc service branch I'm working builds on top of the changes in standalone_commands, so it's safe start using it | 22:47 |
| Verterok | I'm using it in my current dev branch of bzr-eclipse | 22:47 |
| libwilliam | nice =), I have to go, but it sounds great. can I shoot you an email this week with any questions I have? | 22:48 |
| Verterok | sure | 22:49 |
| libwilliam | thanks a ton everyone, i will be dropping soon | 22:52 |
| libwilliam | dropping in soon* | 22:52 |
| lifeless | ddaa: hi | 23:04 |
| ddaa | hey lifeless | 23:07 |
| ddaa | how is it goin? | 23:08 |
| ddaa | getting stacked? | 23:08 |
| lifeless | :) | 23:08 |
| lifeless | closing in on stacked quite rapidly | 23:08 |
| lifeless | down to the last bits of implementation | 23:08 |
| lifeless | seen bzr-search? | 23:09 |
| ddaa | looks like mwhudson_ got around to eradicating buildbot | 23:09 |
| ddaa | that's the end of an epoch | 23:09 |
| lifeless | the dinosaurs have fallen | 23:09 |
| ddaa | I saw some bugmail that suggested that | 23:09 |
| ddaa | did not look at bzr-search, just saw your blog | 23:10 |
| ddaa | I do not have a use case for this at all at the moment | 23:10 |
| ddaa | I'm working on a project I'm writing from scratch. | 23:10 |
| lifeless | what is it? | 23:11 |
| ddaa | I mean work as in "for real money" | 23:11 |
| lifeless | cool | 23:11 |
| lifeless | is it open? | 23:11 |
| ddaa | hell no | 23:11 |
| ddaa | it's some stuff to model exotic equity derivatives | 23:12 |
| lifeless | ah, traders :P | 23:12 |
| lifeless | probably challenging and fun | 23:12 |
| ddaa | actually, not traders, more back-office kind of stuff | 23:12 |
| ddaa | it's probably highly challenging and fun compared to other projects in this line of work | 23:13 |
| ddaa | I feel a bit lonely though. My code is mostly covered by unit tests using niemeyer's mocker, and I have some second thoughts about it. | 23:14 |
| lifeless | you're working solo? | 23:14 |
| ddaa | pretty much, I have a binom who's handling some of the "figure out the financial meaning of the crap in the database" tedium, and some other people around trying to understand what they want me to do. | 23:16 |
| ddaa | But as far as object modelling, python coding and testing go, I'm a lone cowboy. | 23:16 |
| lifeless | that can be lonely indeed | 23:16 |
| lifeless | teddy bears are not as good as people | 23:16 |
| ddaa | There are some good IT folks around I can use as teddy bear when the need arise. | 23:17 |
| ddaa | My favourite is the guy who's running the 2000 cpu pricing farm. | 23:17 |
| ddaa | probably something thumper could relate to :) | 23:18 |
| ddaa | anyway, did you hear about this multimethod hack I pointed you at | 23:19 |
| lifeless | oh, backlog | 23:19 |
| lifeless | lets see | 23:19 |
| ddaa | Whenever I have to code a Visitor pattern to implement multiple dispatch, I can't help but think "python should know better" | 23:20 |
| lifeless | mmm | 23:20 |
| lifeless | multimethod fits in functional languages really nicely, its part of the idioms | 23:21 |
| lifeless | I don't know that it fits in python well - I mean guido did a multimethod implementation ages ago, but its not been merged | 23:21 |
| ddaa | I seems to me the whole zope adapter thing is a kind of multiple dispatch. | 23:22 |
| ddaa | (being zope, it's probably much more complicated than that, but I guess you see what I mean) | 23:22 |
| lifeless | mmmm, from a certain angle I guess, and if only one method is being called | 23:24 |
| lifeless | but in ocaml or erlang, multimethods are pervasive | 23:25 |
| lifeless | if-then constructs even use them | 23:25 |
| ddaa | sounds funny | 23:25 |
| lifeless | its really elegant, but this is why I am saying they don't feel pythonic to me | 23:26 |
| lifeless | its not that you can't, or that if you do its ugly | 23:26 |
| ddaa | from my perspective, dispatch and conditionals fit very distinct niches in the OO world. | 23:26 |
| lifeless | its that its not integrated in | 23:26 |
| ddaa | it's not part of the culture? | 23:26 |
| lifeless | no, its not part of the language | 23:27 |
| lifeless | making dispatch do lookup-on-parameters is a hack layered on the language | 23:27 |
| lifeless | its implemented as double-dispatch | 23:27 |
| lifeless | mmm, do you know ocal/erlang/that-other-common-functional-language-that-isn't-lisp? | 23:28 |
| ddaa | you mean haskell | 23:29 |
| lifeless | yes! | 23:30 |
| ddaa | and no. I have meant to look at those, but I never did. | 23:30 |
| lifeless | I think it also has pattern matching | 23:30 |
| ddaa | The closest to multimethods was guile's implementation of CLOOP | 23:30 |
| lifeless | so, it was very hard for me to really grok this until I learnt enough of one to think in it | 23:30 |
| ddaa | * the closest I got to multimethods | 23:30 |
| lifeless | and when I did, there was a very large penny that dropped | 23:30 |
| ddaa | pattern matching seems to be core in all ML derivatives | 23:31 |
| lifeless | coming back to python though, are multimethods really pythonic - are they the simplest way, clean, clear, easy to understand | 23:31 |
| lifeless | ddaa: yeah, I think ML derived guarantees pattern matching :) | 23:32 |
| ddaa | It certainly depends on the situation. | 23:32 |
| ddaa | I saw an occurence recently when I ended up doing manual type dispatching because I could not be bothered to code a Visitor. | 23:32 |
| ddaa | mh... | 23:33 |
| lifeless | I think as something that some-methods-might-do its inherently unclear (until its available for all methods as a standard language feature) | 23:33 |
| ddaa | I think I see your point. | 23:35 |
| lifeless | but that said, if it works for your code and looks nice | 23:35 |
| ddaa | For example, it looks like this implementation of multimethods would only work for module-level functions, not methods. | 23:35 |
| lifeless | use it, but document clearly that you are, and try to make it as obvious as possible when its being used etc | 23:36 |
| ddaa | I'll probably abstain. | 23:36 |
| ddaa | At some point, I'll have to design a micro-language to generate the object model I'm currently prototyping. | 23:37 |
| ddaa | Maybe we can construe some way for you to give me feedback on this. | 23:37 |
| lifeless | you can always drop me a mail | 23:38 |
| lifeless | man | 23:38 |
| lifeless | evolution | 23:39 |
| lifeless | man | 23:39 |
| lifeless | now that I've written a search engine | 23:39 |
| lifeless | my respect for evolution has shrunk substantially | 23:39 |
| ddaa | I understand how evolution gives you pain. | 23:39 |
| ddaa | for me it's been in the "stuff that sometimes has to use" box for some time... | 23:40 |
| ddaa | they to have this vastly overengineered internal service with its own micro-language to drive their search and vfolder system. | 23:41 |
| ddaa | * they seem to have | 23:41 |
| ddaa | I still cannot type though. | 23:41 |
| lifeless | :P | 23:41 |
| ddaa | I think it's called "camel-helper" or something like that. | 23:42 |
| ddaa | use sylpheed, it's least painful of the local mail readers I've used. | 23:42 |
| ddaa | But I think I told you that one year ago already :) | 23:42 |
| lifeless | yah | 23:43 |
| lifeless | I use evo because for all the things that shit me, other setups shit me more | 23:43 |
| ddaa | BTW I found something MS Outlook is very good at. | 23:44 |
| lifeless | ? | 23:44 |
| ddaa | Arranging pointless meetings. | 23:44 |
| lifeless | ahha | 23:44 |
| ddaa | This whole email-calendar integration thing. | 23:45 |
| mwhudson_ | ddaa: hello! | 23:48 |
| * mwhudson_ is not really here though | 23:49 | |
| ddaa | I'm going bedwards too. | 23:49 |
| lifeless | ddaa: good to catch up, do drop by more often :) | 23:52 |
| ddaa | I've busy with addictions. | 23:52 |
| ddaa | First stopping smoking. Then buying a Wii. | 23:52 |
| ddaa | I'm only just coming out of the Wii addiction. | 23:52 |
| lifeless | serial addictions :) | 23:54 |
| ddaa | seriously so | 23:54 |
| ddaa | beddy time | 23:55 |
| ddaa | cya around | 23:55 |
| lifeless | bye! | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!