--- Log opened Wed Sep 17 00:00:33 2008 00:46 < SplinterOfChaos> I opened chrome.sln in VS2008 and now all the project files have been converted to 2008's format, so I can't open any. Is there any way to set them back? 01:07 -!- DannyB is now known as DannyB|away 01:08 < mal> svn revert ? 01:09 < SplinterOfChaos> ...calling gclient sync again? 01:09 < SplinterOfChaos> (I'm new to svn.) 01:09 < SplinterOfChaos> That didn't work. 01:09 < Catfish_Man> svn revert -R . 01:09 < Catfish_Man> to be more specific 01:09 < mal> not sync.. sync will ignore local changes. 01:10 < mal> Catfish_Man has the proper advice 01:12 < SplinterOfChaos> Catfish_Man: It says there aren't enough arguments. 01:12 < Catfish_Man> did you include the . ? 01:12 < SplinterOfChaos> Oh. I figured that was to end the sentence XP 01:13 -!- mode/#chromium-dev [+v aboodman] by ChanServ 01:14 < SplinterOfChaos> svn: '.' is not a working copy 01:14 < SplinterOfChaos> svn: Can't open file '.svn\entries': The system cannot find the path specified. 01:15 < Catfish_Man> make sure you're in the right directory 01:16 < SplinterOfChaos> The one right under src? (Or where, according to the build instructions, is my "trunk"?) 01:17 < Catfish_Man> probably, dunno 01:18 < SplinterOfChaos> Actually, it ALMOST works when I do it in the src file. 01:18 < SplinterOfChaos> Except: This client is too old to work with working copy '.'; please get a newer Su 01:19 < SplinterOfChaos> bversion client 01:19 < Catfish_Man> I'd follow its advice 01:19 < SplinterOfChaos> ...how? 01:19 < Catfish_Man> download the latest version of svn? 01:20 < SplinterOfChaos> The depot_tools? 01:20 < Catfish_Man> wherever your svn is from 01:20 < Catfish_Man> I'm using the one that came with my system, dunno how it's set up on windows 01:21 < SplinterOfChaos> -_-; Thanks anyway. 01:33 < SplinterOfChaos> Hah!, I think it's working now. Thanks. 01:33 < MathiasSvensson> what's working? 01:33 < SplinterOfChaos> I had to call gclient update. 01:34 < SplinterOfChaos> Before you'd joined, I'd explained that I messed up every project file by opening Chrome.sln in MSVS 2008. 01:34 < MathiasSvensson> ok 01:34 < SplinterOfChaos> It converted EVERYTHING to 2008. (It's Microsoft supposed to be smart?) 01:35 < MathiasSvensson> yup - microsoft are the best 01:35 < heavyhelmet> MS knows their IDEs 01:35 < heavyhelmet> visual studio ftw 01:35 < SplinterOfChaos> I wouldn't even be insulting their intelligence if they would have made it so you can revert the changes. 01:35 < heavyhelmet> ... 01:36 < SplinterOfChaos> That is, without being an expert on the subject. 01:36 < heavyhelmet> they save a backup 01:36 < heavyhelmet> like in a different folder 01:36 < heavyhelmet> so you can just go and get it 01:36 < heavyhelmet> it even says where it will save it in the upgrade process 01:36 < heavyhelmet> dont think you can make it easier than that 01:37 < SplinterOfChaos> lol, would have been nice to know. 01:37 < heavyhelmet> yeah... 01:37 < Catfish_Man> splinterofchaos: uh, anyone programming without version control (i.e. their own ability to revert anything) is doing it wrong 01:38 < heavyhelmet> that too 01:38 < heavyhelmet> just run a small SVN server on your own comp 01:38 < SplinterOfChaos> I've never needed it. I've never made anything complex enough to require it. 01:38 < Catfish_Man> heavyhelmet: eh, there are simpler ways than that 01:38 < Catfish_Man> bzr/hg/git are all more suited for local use 01:38 < heavyhelmet> although if you have vista, you already have it built in 01:38 < Catfish_Man> personally I like bzr 01:38 < heavyhelmet> I just have vista index my files directory 01:39 < heavyhelmet> so it saves shadow copies of everything 01:39 < heavyhelmet> although something MADE for version control is probably better if you want a lot more configurability 03:30 < _ph> Hi. What would be a good replacement for fopen_s on Linux? 03:31 -!- asac_ is now known as asac 04:37 -!- oiaohm_ is now known as oiaohm 04:45 -!- oiaohm_ is now known as oiaohm 05:32 <+maruel> _ph: fopen? :) 06:08 -!- stalled__ is now known as stalled 06:09 < SplinterOfChaos> My connection was closed by the server... Is the tree really open? 06:11 <+maruel> which connection? 06:12 < SplinterOfChaos> Dunno, but gclient sync was the command. 06:13 <+maruel> ah 06:13 <+maruel> it's just a network hickup 06:13 <+maruel> start again 06:13 <+maruel> it happens, sorry 06:14 < SplinterOfChaos> OK, seems to be working again. 06:18 < _ph> maruel: sure, but there are some issues with it. Could you take a look at http://codereview.chromium.org/3097 ? I thought about adding a wrapper to file_util. 06:19 <+maruel> ok, won't be long, temporarily overloaded 06:22 <+maruel> _ph: uh, I'm already reviewing this one 06:22 <+maruel> it's funny, you're doing sgk's work. ;) 06:28 < _ph> maruel: for reading file in json_value_serializer.cc I used ReadFileToString from file_util... I rhink writing WriteStringToFile would be a good idea. What do you think? 06:32 <+maruel> humm, WriteStringToFile() isn't a testing function? 06:33 -!- mode/#chromium-dev [+v pinkerton] by ChanServ 06:33 <+maruel> Ok I finally got to the file 06:34 <+maruel> Dean is right, you'll have to do a #ifdef until this is sorted out 06:34 <+maruel> sorry 06:34 <+maruel> _ph: uh, Mark is right, anyway. 06:34 < _ph> maruel: ok, so I will use ReadFileToString where possible and for writing case use #if defined. 06:35 <+maruel> humm, not sure either 06:35 <+maruel> just use #ifdef for now 06:36 <+maruel> ah 06:36 <+maruel> no 06:36 <+maruel> you're right! 06:36 <+maruel> there's file_util::WriteFile() 06:38 < _ph> maruel: I could use it to write WriteStringToFile in file_util. Would that be good? That would result in cleanest code IMHO. 06:40 <+maruel> _ph: I just finished the review. 06:41 < DrPizza> when I do an svn update, what does status "G" mean? 06:41 <+maruel> drpizza: it merged the difference in your files with the update that was applied 06:41 < DrPizza> ah ok 06:41 <+maruel> if svn is not able to do that automatically, it will display C 06:41 < DrPizza> with no conflict? 06:41 < DrPizza> I see 06:42 < DrPizza> historically I have only ever used tortoise. 06:42 <+maruel> svn help up 06:42 <+maruel> and you'll see 06:42 <+maruel> svn help status for even more states 06:42 <+maruel> I use tortoise too 06:42 <+maruel> I had to compile it for svn 1.5 for a while :( 06:43 <+maruel> that's history anymore. :) 06:43 < _ph> maruel: thanks for review, now everything is clear; I was mostly done with other things, just this fopen stuff delayed the whole thing 06:43 < DrPizza> I uninstalled tortoise as it does its context menu icon in a rather annoying way 06:44 <+maruel> it also chockes on multi-gigs repos 06:45 <+maruel> I tried to submit one or 2 patches to help but it didn't really help. :( 06:46 < DrPizza> (it makes the menus go owner-drawn which means they don't theme properly) 06:46 < DrPizza> bbl 07:31 <+maruel> _ph: sorry for being anal but you can't do that 07:32 <+maruel> you need to paste as I written in the review comment 07:32 <+maruel> otherwise, you need to align at +4 07:33 < _ph> maruel: do you mean // Order the members ... ? 07:33 <+maruel> no, the ALLOW_THIS_IN_INITIALIZER_LIST( 07:34 <+maruel> when you split a line, it needs to be at current alignement + 4 07:35 < _ph> maruel: ok, will upload in a minute; But, for the future, please elaborate about what takes precedence: this +4 rule or lining up with the parentheses (which I used to do in previous reviews). 07:40 <+maruel> it depends if you can fit the first argument on the original line 07:40 <+maruel> if so, use the parenthese line up 07:40 <+maruel> otherwise, use +4 07:47 < _ph> maruel: ok 08:03 -!- mode/#chromium-dev [+v erikkay] by ChanServ 08:24 -!- mode/#chromium-dev [+v ifette] by ChanServ 08:37 <+pinkerton> when i go to the public buildbot page, it's cut off at 7:54am PDT 08:37 <+pinkerton> there's nothing else below that 08:38 <+pinkerton> in the middle of the page-cycler 08:38 < _ph> How should I handle situation when unittest's setup fails? For example when I need a temp dir and GetTempDir returns false? 08:43 <+maruel> EXPECT_TRUE(false) at the point of failure 08:46 < _ph> maruel: ok, so I can probably do as well EXPECT_TRUE(preparation_function_that_could_fail); 08:47 < _ph> maruel: or maybe even ASSERT_TRUE, because at least in my case the rest of test just wouldn't make sense 08:49 <+maruel> sure 08:50 <+pinkerton> anyone else see what i'm seeing on the waterfall? 08:50 <+pinkerton> oh, now it's ffixed 08:51 <+pinkerton> pipes must have been full 08:52 -!- fishd_ is now known as fishd 08:54 < _manyoso> is there a commit list for chrome? 08:54 <+maruel> IPCSyncChannelTest.ChattyServer 08:54 <+maruel> IPCSyncChannelTest.ChattyServer 08:54 <+maruel> IPCSyncChannelTest.ChattyServer 08:54 <+maruel> IPCSyncChannelTest.ChattyServer 08:54 <+maruel> chromium-checkins@ 08:54 <+maruel> uh 08:55 <+maruel> _manyoso: it's chromium-checkins@ 08:55 < _manyoso> maruel: a recent check-in broke the linux build 08:56 < _manyoso> we now have: MSVC_PUSH_WARNING_LEVEL(0); in one of the only files in the webkit/glue directory that was enabled for linux build ;) 08:56 * _manyoso looks how to fix 08:56 < _ph> _manyoso: oh, could be a typo in one of my proposed changesets ;-) it should be MSVCC, look at base/compiler_specific.h 08:57 < _ph> I meant :-/ 08:57 <+pinkerton> linux looks green to me 08:57 < _manyoso> _ph: don't think *any* msvc specific will work under linux, no? 08:57 < _ph> _manyoso: this macro expands to nothing on anything except MSVCC 08:57 < _manyoso> oh 08:58 < _manyoso> MSVCC, i'll try that 08:58 < jamessan> no, it's just MSVC_PUSH_WARNING_LEVEL 08:59 < _manyoso> yah, looking at base/compiler_specific.h it looks fine... 09:04 < _ph> _manyoso: if you're not getting compile failure then fine; I recently made such typo at some point, and actually rely on Vim's completion to figure out MSVCC or MSVC... 09:04 < _manyoso> i am getting compiler failure 09:04 < _manyoso> something is wrong with the macro 09:04 < _manyoso> investigating... 09:07 < icefox> problem is the macro name in the header doesn't match the one in base/compiler_specific.h 09:08 < icefox> s/MSVC_PUSH_WARNING_LEVEL/MSVC_PUSH_DISABLE_WARNING/ 09:09 < _ph> #define MSVC_PUSH_WARNING_LEVEL(n) __pragma(warning(push, n)) - maybe you need to update? 09:11 < manyoso> shall i make a patch? 09:12 < jamessan> manyoso: it should be working fine. are you sure you're fully updated? 09:13 < manyoso> hmm, i must have only svn up'd in webkit 09:14 < manyoso> sorry 09:14 < manyoso> i see the new macro now 09:15 < _ph> manyoso: run gclient sync instead of svn up; gclient does few more things and they are important 09:16 * manyoso looks for gclient 09:16 < jamessan> depot_tools/gclient 09:16 < icefox> manyoso: http://dev.chromium.org/gclient 09:18 < manyoso> interesting 09:26 <+motownavi> Security types: I'm rewriting the X509 cert handling for the Mac, and have the option of writing to the CSSM. 09:26 <+motownavi> I'm downloading CDSA/CSSM docs now, but would that be useful to the linux folks? 09:26 <+motownavi> or are they using something else? 09:28 <+erikkay> motownavi, you may want to try that on the mailing list instead. I think dkegel is looking at SSL issues for Linux, but I'm sure wtc will have an opinion as well. 09:45 -!- mode/#chromium-dev [+v pamg] by ChanServ 09:55 < MathiasSvensson> What the hell is wrong with the world? I upgraded my system, and then the next time I rebooted (after I had replaced my motherboard, which happened to be broken) I had to delete a file, for the system to recognize my network card 09:56 <+pinkerton> no comment :) 10:03 -!- DannyB|away is now known as DannyB 10:06 < _ph> What is the correct way to convert wstring containing a path to char* (in POSIX/Linux) ? Is it WideToUTF8(path).c_str() or something else, possibly involving SysWideToNativeMB? 10:07 <+maruel> _ph: maybe SysWideToNativeMB is better 10:07 <+maruel> but I'm not sure 10:09 < _ph> maruel: ok, will ask in review 10:09 < jamessan> file_util_linux uses WideToUTF8 10:11 <+pinkerton> we'll have to resolve this somehow, on mac there are different calls to go from UTF16 in NSString to a file system representation vs. plain utf8 10:12 <+evmar> _ph: for now we've been assuming the sys encoding is UTF-8 10:12 <+evmar> mark@ is working on a FilePath abstraction so we can use native encodings everywhere 10:13 <+pinkerton> right. 10:13 < DrPizza> Really, we need to reset the entire world so that UTF32 is the only encoding. 10:13 < _ph> evmar: ok, deanm asked me to ask mark anyway - now it is even more clear 10:14 -!- mode/#chromium-dev [+v erikkay] by ChanServ 10:14 < Simetrical> s/UTF32/UTF-8/ 10:14 < DrPizza> no 10:14 < DrPizza> not UTF8 10:14 < DrPizza> UTF32. 10:14 < DrPizza> memory is cheap 10:14 < DrPizza> fixed-length encodings are superior. 10:15 <+maruel> drpizza: not on cell phones 10:15 < jamessan> tell that to my slug 10:15 < Simetrical> UTF-32 uses four times as much space in a lot of cases, plus you can't detect if the character stream is misaligned. 10:15 < DrPizza> maruel: please, my cellphone has hundreds of MB 10:15 < DrPizza> everyone should just buy new cellphones 10:15 < Simetrical> What's the percentage of a web browser's memory footprint that's just due to storing strings? 10:15 <+maruel> still, memory access is costly on a cell phone 10:15 < Simetrical> A remarkable amount, IIRC. 10:16 <+maruel> simetrical: indeed 10:16 < DrPizza> space optimization is short-term thinking. 10:16 < DrPizza> in a year or two we'll have even cellphones with multiple gigabytes. 10:16 < Simetrical> It also makes simple operations like strcpy() a lot slower. 10:16 <+evmar> there's been discussion on the team about switching to utf-8 internally, even on (utf-16-based) windows, to save memory 10:16 < DrPizza> but we'll still be stuck with awkward 8-bit encodings. 10:16 < Simetrical> DrPizza, it's not just an issue on cell phones, it's an issue on desktops, from what I've heard. It adds up to a large portion of used browser memory. 10:16 <+maruel> drpizza: you haven't understood the root problem on portable devices: energy consumption. 10:16 < jamessan> there will always be embedded devices with small space requirements 10:17 < DrPizza> maruel: energy consumption is solved by process shrinks 10:17 <+maruel> eh 10:17 < Simetrical> Do any of the browser devs here have a specific figure on how much memory is used for string storage? 10:17 <+maruel> simetrical: I don't have the values at hand, sorry 10:17 < Simetrical> roc had a blog post about how UTF-8 is the best. 10:18 < DrPizza> UTF-8 sacrifices easy indexing and iteration 10:18 < Simetrical> Wrong, it only does that if you need "get nth character". You don't. You just need iteration, "give me the next character", and it does that fine. 10:19 < DrPizza> it doesn't do taht fine. 10:19 < Simetrical> http://weblogs.mozillazine.org/roc/archives/2008/01/string_theory.html 10:19 < Simetrical> Yes it does. 10:19 < DrPizza> No it doesn't. 10:19 < DrPizza> It's not ptr++ 10:19 < DrPizza> or ++iter 10:19 < DrPizza> ==> not fine 10:19 < Simetrical> It's still fast enough for any sane purpose. Getting the next char is not going to be a bottleneck. 10:19 < Simetrical> "Measurements of large Java apps such as Eclipse and Websphere would often show 30% or more of the live heap being consumed by strings." 10:20 < Simetrical> That post is mostly against UTF-16, admittedly, not UTF-32. 10:20 < DrPizza> That's probably a rather dubious comparison 10:20 < DrPizza> Java interns strings. 10:20 < DrPizza> C++ doesn't. 10:21 < Simetrical> What does that have to do with anything? You're storing entire webpages in memory, possibly multiple copies, maybe tens or dozens of them. 10:21 < Simetrical> You have to cache them on disk and do all sorts of other things with them. 10:21 < DrPizza> What does it have to do with your citation of Eclipse? 10:21 < Simetrical> You're saying to quadruple the size of all of those. 10:21 < DrPizza> What do you think it does? 10:21 < Simetrical> . . . never mind, I have a class in 40 minutes and should have already left. 10:21 < DrPizza> @_@ 10:21 < DrPizza> I have to go 10:22 < Iron> hey 10:22 < Iron> anybody tgere? 10:22 < Iron> there 10:23 < jamessan> there are 135 people in the channel 10:23 <+pinkerton> so....no. 10:23 < Iron> i am making a fork based on chromium where i removed some problematic things like URL tracking 10:23 < Iron> so can i advertse this work with 10:24 < Iron> "use all full chrome-features without privacy problems" or do i have to write "use all full chromium-features without privacy problems" ? 10:24 < Iron> problem is: chromium nobody knows... 10:24 <+maruel> chromium 10:24 <+maruel> Google Chrome is trademarked 10:24 <+evmar> Iron: nobody here's a lawyer, so our advice is probably not useful 10:24 < Iron> hmm 10:24 <+evmar> maruel: no legal discussions. 10:26 < Iron> why must google be so evil :( 10:27 <+evmar> it's pretty rough here, what with the strangling kittens all day 10:27 <+evmar> some days i wake up and wonder why i come in each day! 10:27 <+pinkerton> i hate that i'm so evil. it makes me cry. 10:28 < kenneo> just admit it, you like it :p 10:28 * pinkerton goes to take candy from a baby 10:31 < RageOfThou> it's not as easy as you might think pinkerton, the always want to fight for the candy 10:31 < RageOfThou> *they 10:32 <+pinkerton> i'll find one that's asleep 10:47 < Iron> hm have an idea 10:47 < Iron> i write 10:47 < Iron> technic behind google chrome 10:47 < Iron> i think that is ok, or? 10:49 <+pkasting> I'm pretty sure that using a trademarked term to advertise a similar product requires agreement from the trademark holder 10:50 < kenneo> Iron: the problem is that the people in here are coders, and not legal experts in any way 10:50 < Iron> hm yes ok 10:51 < kenneo> so whatever they say, it cannot be really trusted 10:51 < kenneo> ( well to some extent that is ) 10:51 < Iron> ok... 10:52 < Iron> where can i change the ressource names of the exe in visual studio? 10:52 < Iron> like "original filename" 10:52 < Iron> or "Internal Name" 10:52 < Iron> the "version" info...when right click propterties in explorer on the chromium.exe 10:55 -!- mode/#chromium-dev [+v cpu] by ChanServ 10:57 < Iron> nobody an idea? :( 10:57 <+kuchhal> Iron: that is generated by a script in Chromium 10:57 <+kuchhal> look for files *rc.version 10:57 <+kuchhal> and a rules file that converts those to actualy strings and puts them in resources files of binaries 10:58 < Iron> ok 10:58 < osmosis> any closer? 11:02 < Iron> propably chrome_exe_version.rc.version 11:02 < Iron> could that be? 11:03 < Iron> i changed some things there 11:03 < Iron> but nothing changes when compiled... 11:03 <+kuchhal> Iron: what are you trying to change? 11:04 <+pamg> Iron: you may ened to do a clean build after changing string resources. 11:04 < Iron> ok.. 11:05 <+kuchhal> Actually not in this case. You changed rc.version but the values in that file get replaced from strings in VERSION file. 11:05 <+kuchhal> but my question still remains - what are you trying to change? 11:05 < Iron> ORIGINALFileName 11:05 < Iron> InternalName 11:06 <+kuchhal> I believe it is ok to release your own Chromium with file executable name as chrome.exe 11:06 < Iron> i already changed chrome.exe to my own 11:06 <+kuchhal> but it you still want to change it you need to modify VERSION file 11:06 < Iron> but now i want to change the version-info, too 11:07 < Iron> i make a clean recompile 11:07 < Iron> isn't chrome_exe_version.rc.version not the right file to change? 11:07 < brettw> kuchhal: I would not say what you're allowed to call anything since you're not a lawyer 11:08 <+kuchhal> yes chrome_exe_version.rc.version is the right file for your change 11:09 <+kuchhal> and like brettw said i am not a lawyer so ignore my statement about naming of executables 11:14 < Iron> ok...i already renamed it..the DLL also ;) 11:14 -!- eseidel_ is now known as eseidel 11:14 < Iron> can't be wrong :D 11:18 < Iron> ok have thanks 11:18 < Iron> changing the infos in the version file 11:18 < Iron> was successfull 11:18 < Iron> but clean build is needed 11:21 < manyoso> http://blog.chromium.org/2008/09/dns-prefetching-or-pre-resolving.html <-- awesome idea guys 11:22 < cartman> you guys need some bug wranglers 11:22 < cartman> there are too many untriaged bugs 11:22 < mgreenblatt> hi folks, would anyone like to review a teeny-tiny patch to webkit_glue ? 11:23 <+erikkay> cartman, agree. we're working on it. it turns out to be a limitation of the bug db. 11:23 < cartman> erikkay: ah ok :) 11:26 < manyoso> how about having generic names for the macros in base/compiler_specific.h 11:27 < manyoso> ie changing, MSVC_PUSH_WARNING_LEVEL to COMPILER_PUSH_WARNING_LEVEL 11:27 < manyoso> or so 11:27 < manyoso> as it is very disconcerting to see a macro with MSVC prepended inside cross-platform code without an #ifdef 11:28 <+evmar> manyoso: i'm not sure "warning level" is really a cross-platform concept anyway 11:28 <+evmar> perhaps it'd be better as COMPILER_DISABLE_WARNINGS(), since that's what i think we use it for 11:28 < mgreenblatt> many.. in that case you should actually use COMPILER_DISABLE_WARNING and COMPILER_ENABLE_WARNING or somesuch that also hides the parameter details 11:28 -!- DannyB is now known as DannyB|away 11:29 < manyoso> that sounds good to me 11:30 < jamessan> evmar: there's both MSVC_PUSH_WARNING_LEVEL and MSVC_PUSH_DISABLE_WARNING 11:30 < mgreenblatt> is someone planning to do a search/replace on the whole codebase for #program warning, or will it be something that people change as they make other changes to files? 11:30 < mgreenblatt> #progma 11:30 <+evmar> mgreenblatt, the latter, most likely. 11:31 -!- mode/#chromium-dev [+v pkasting] by ChanServ 11:31 < manyoso> evmar: any objection to a patch which does s/MSVC_PUSH_WARNING_LEVEL/COMPILER_DISABLE_WARNING/ ? 11:32 <+pkasting> can COMPILER_DISABLE_WARNING be popped? 11:32 < manyoso> well, also s/MSVC_POP_WARNING/COMPILER_ENABLE_WARNING/ 11:33 < mgreenblatt> manyoso: you should use a macro with no parameters 11:33 <+evmar> argh, gsearch is behind 11:33 * evmar is having some technical difficulties 11:33 < manyoso> mgreenblatt: that is what i'm proposing 11:34 <+evmar> MSVC_PUSH_DISABLE_WARNING also is compiler-specific (it takes a warning number) 11:34 < mgreenblatt> manyoso.. ok.. but keep in mind that the current macro is MSVC_PUSH_WARNING_LEVEL(0) .. something like COMPILER_DISABLE_WARNINGS() would be more appropriate 11:34 < jamessan> pkasting: yes 11:35 < manyoso> evmar: that can also be replaced with something like COMPILER_PUSH_DISABLE_WARNING(n) which will be noop on platforms that don't support warning levels from pragma 11:35 < manyoso> my point is that MSVC is not a good prefix for these macros 11:35 <+evmar> my point is that "n" here is platform-specific 11:35 <+evmar> so you gain nothing by not having MSVC there 11:36 <+evmar> i don't really understand thsi code though, so i'm happy to be proven wrong. :) 11:36 <+pkasting> I agree with evmar 11:36 < manyoso> you gain readability 11:36 <+evmar> can you point me at some code you're unhappy about? 11:36 < jamessan> what's not readable about the current form? 11:36 <+pkasting> Disabling particular warning numbers is inherently compiler-specific 11:36 < manyoso> again, having MSVC_ prepended to code that is supposedely cross platform 11:36 < jamessan> these macros only do something for MSVC, so it makes sense to call that out in the name 11:36 <+pkasting> Disabling warning #xxx is not cross-platform 11:36 < DrPizza> but it's not cross-platform 11:37 <+pkasting> Pretending it is is wrong 11:37 <+evmar> manyoso: i'm grepping the code for MSVC nad i don't see it used anywhere? 11:37 < manyoso> webkit/glue 11:37 <+evmar> ah, yes 11:37 <+evmar> we should have 11:37 <+evmar> COMPILER_DISABLE_WARNINGS() which expands tot he MSVC_ one int hat case 11:37 -!- DannyB|away is now known as DannyB 11:37 * evmar can't type 11:37 < manyoso> you see what i'm talking about? 11:37 < DrPizza> ??? 11:37 < DrPizza> but how? 11:38 < DrPizza> disable what warnings? 11:38 < mgreenblatt> evmar... recent commit to weburlrequest_impl.h, for instance 11:38 < manyoso> currently the majority of code is using this: #pragma warning(push, 0) 11:38 <+evmar> i'd be fine with #define COMPILER_DISABLE_WARNINGS() MSVC_... in compiler_specific.h 11:38 < DrPizza> manyoso: imo it shouldn't be doing that. 11:38 < manyoso> which gives this ironic comment under linux 11:38 < manyoso> warning: ignoring #pragma warning 11:38 < manyoso> :) 11:39 <+evmar> manyoso: yeah, i agree those should all be switched to a compiler-agnostic macro 11:39 < DrPizza> unless it's wrapping an #inclusion, it should be disabling specific warnings 11:39 < DrPizza> not all of them 11:39 < DrPizza> but, of course, there's no compiler-agnostic way of disabling specific warnings 11:39 <+evmar> the only point of contention is that warning levels and warning numbers shouldn't be exposed 11:40 < jamessan> DrPizza: it's ignoring warnings in third party code, aiui. i.e., code that's not under out control 11:40 <+evmar> -#pragma warning(push, 0) 11:40 <+evmar> +MSVC_PUSH_WARNING_LEVEL(0); #include "PlatformKeyboardEvent.h" #include "PlatformMouseEvent.h" #include "PlatformWheelEvent.h" 11:40 <+evmar> -#pragma warning(pop) 11:40 <+evmar> +MSVC_POP_WARNING(); 11:40 <+evmar> argh, my paste was eaten 11:40 <+evmar> hopefully you can get the gist of that patch 11:40 <+evmar> i would be fine with a macro wrapping the MSVC_ bits 11:40 < DrPizza> jamessan: yes, I see, although that's still rather irksome a lot of the time 11:41 < manyoso> the problem is we have this: http://codereview.chromium.org/2418 11:41 < manyoso> which turned all warnings into errors 11:42 < manyoso> but there is no good way in code to turn off warnings when compiling with gcc 11:42 < DrPizza> yes, I found that out a few weeks ago 11:42 < jamessan> you fix them or, if there's good reason, add the right flag to ignore the warning for that specific module 11:42 < DrPizza> although I thought they were thinking of putting a way into the compiler to disable them 11:43 < jamessan> as was done in skia/SConscript 11:48 <+evmar> manyoso: i'm going to lunch, but i'd be happy to look at any suggested patch 11:49 < manyoso> evmar: ok 11:50 < manyoso> do you have your own pastebin i should use or...? 11:51 < Iron> hmmm 11:51 < Iron> if its ok to say "chromium is the sourcecode of chrome?" 11:51 < Iron> i know you are now lawyer ^ 11:51 < Iron> but..hm ^ 11:51 < Iron> good question?!? 11:56 < mgreenblatt> Iron.. perhaps "The open source project behind the Chrome browser is called chromium" 11:56 < mgreenblatt> or "underlying" instead of "behind" 11:57 < Iron> so..look..so problem is...i want to advertise my fork 11:58 < Iron> and .. nobody knows chromium of the press, journalists and co 11:58 < Iron> so i wanted to write 11:59 < Iron> "use Iron Browser - which uses the genious technic behind chrome"....but thats perhaps not good because chrome is trademarked... 11:59 < Iron> so..anybody has an idea for an alternative sentence..? 12:00 < Kmos> Iron: why not contribute to it, instead of forking ? 12:00 < Iron> because i removed all privacy-related code 12:01 < Iron> e.g. RLZ 12:01 < Iron> and URL tracking every 5 seconds after start 12:01 < Iron> the original chrome is heavily communitating to google...i hate that 12:01 < jamessan> all of those are supposed to have options to disable them, iirc 12:01 < Iron> yes but they haven't options yet 12:01 < Iron> and nobody knows when the next beta is released 12:02 < jamessan> so work on getting the options added so they'll be there for the next release 12:02 < mgreenblatt> Iron.. why not propose a patch based on preprocessor defines that disables the sections you dislike without forking the code? 12:02 < mgreenblatt> (assuming such a thing doesn't already exist) 12:03 < Iron> because a fork will bring a lot of publicity to my person and my homepage 12:03 < Iron> that means: a lot of money too ;) 12:03 < Kmos> rotflol 12:04 < Iron> what means rotful? 12:04 < mgreenblatt> Iron.. you're a large corporation that can dedicate the time to support a fork of something as complicated as chromium? 12:04 < Kmos> Iron: google about it 12:05 < Iron> yes there is enough time to support it 12:05 < jamessan> heh, you're expecting to make lots of money from making a fork of chromium? that's quite amusing 12:05 < Iron> i dont take money for my fork 12:05 < Iron> but i have adsense on my page ;) 12:06 < Iron> a lot of visitor -> a lot of clicka > a lot of money ;) 12:06 < Kmos> and do you think google should support your fork 12:06 < Kmos> lol 12:06 < mgreenblatt> Iron.. it's always good to have dreams ;-) 12:06 < Iron> we are here in germany 12:06 < Iron> the press will love my fork 12:06 < Iron> i talked to much journalists already 12:07 < DrPizza> Why are you forking? 12:07 < DrPizza> to do what? 12:07 < Iron> to remove all things in source talking to google ;) 12:07 < jamessan> to get fame and fortune 12:07 < Iron> nobody here trusts google 12:07 < Iron> the german people say: google is very evil 12:07 < jamessan> yet you use google's adsense 12:07 < DrPizza> To appease the idiotic german government? 12:08 < Iron> so look at china 12:08 < Iron> yahoo cooperated with the government there 12:08 < Iron> to get bloggers into jail 12:08 < Iron> just because of free speech 12:08 < DrPizza> I'm pretty sure that German companies operating in China honour local law. 12:08 < jamessan> I agree with having the ability to disable all of the "phone home" functionality, but it's better to do that in chromium instead of forking it 12:09 < Iron> proapbly...but they don't say that they are not evil by thereself ;) 12:09 < DrPizza> ... 12:09 < DrPizza> Google is a corporation. 12:09 < mgreenblatt> :agrees w/jamessan 12:09 < DrPizza> A publicly traded one, no less. 12:09 < Iron> yes but then they should call them so 12:09 < DrPizza> What do you expect them to do? 12:09 < Iron> they should remove this slogan 12:09 < DrPizza> Why? 12:09 < Iron> and replace "dont be evil" with "maximum profit" 12:09 < Iron> ;) 12:09 < beng_> btw a better place for philosophical discussion is #chromium 12:10 < DrPizza> Do you think that the McDonald's person who says "I'm lovin' it" really does _love_ his McD's? 12:10 < DrPizza> I imagine he was just a session singer being paid to say it... I bet he doesn't love it at all. 12:10 < mgreenblatt> speaking of non-philosophical conversation.. anyone have time to play reviewer for a 6-line patch to webkit_glue ? 12:11 < beng_> mgreenblatt: lots of folk just went to lunch, I bet someone will have time in about 30 min when they get back ;-) 12:11 < DrPizza> Iron: which non-evil search engine should we use instead? 12:11 < Iron> cuil has good privacy..but bad search results 12:12 < Iron> i use google by myself - there is no alternative at the moment 12:12 < DrPizza> haha, yeah, you can use cuil. 12:12 < Iron> but...i don't like hem ;) 12:12 < DrPizza> I prefer to find stuff 12:12 < DannyB> so let me get this straight 12:12 <+maruel> drpizza: askkids.com 12:12 < mgreenblatt> beng... no doubt you're right... us mid-westerners are just naturally less patient then you westcoasters ;-) 12:12 < DrPizza> hah 12:12 < Iron> i don't use cuil... 12:12 < DannyB> rather than actuall y particiapate in the ocmmunity and work with people to add options to disable what you don't like 12:12 < Iron> i said that there is no alternative 12:12 < DannyB> (which btw, there already are for *all* of them) 12:12 < jamessan> Iron: what you call evil, other people call improving search results and the user experience. that's why there is (or will be) the ability to change the options 12:12 < DannyB> you think you will get fame and fortune by forking 12:12 < beng_> mgreenblatt: feel free to upload it into the system, i'll take a look and suggest a reviewer 12:13 < DrPizza> Iron: Then you're surely a part of the problem, by denying non-evil alternatives revenue? 12:13 < DannyB> and then you think *google* is evil 12:13 < mgreenblatt> beng... will do, thanks 12:13 < Iron> @jamessan: why does google log ip'adresses? 12:13 < Iron> there is no need to do that 12:13 < DannyB> sure there is 12:13 < DannyB> are you braindead? 12:13 < Iron> they could anonymize them instantly 12:13 < DannyB> no we couldn't 12:13 < DrPizza> yes yo ucould. 12:13 < Iron> into a geo ip code 12:13 < DannyB> how would we detect click fraud, for starters? 12:13 < Iron> so wy dont they to it? 12:13 < Iron> anonymized ip's ... 12:13 < DrPizza> DannyB: who cares? You already do a pretty poor job of it. 12:13 < beng_> once again: this is not the channel for this sort of discussion. 12:13 < DannyB> DrPizza: uh, no really, we don't 12:14 < beng_> this is a chromium development channel, please move it to #chromium. 12:14 < DannyB> beng_: more like #moronswhothinktheyknowwhattheyaretalkingabout 12:14 < mmoss> or better yet, some non-product-specific channel 12:15 < Iron> so just let's see 12:15 < Iron> my fork will be welcome in europe ;) 12:15 < Iron> people will love it ;) 12:15 < DannyB> Iron: you are both "evil" and an "asshole" 12:15 < Iron> lol 12:15 < Iron> why? 12:15 < DannyB> as far as i can tell 12:15 < DannyB> because rather than actually work with people 12:15 < DannyB> you want to fork for fame and fortune 12:16 < DannyB> ie you only care about yourself here 12:16 < Iron> i would fork to myself too.,.. 12:16 < Iron> fame is an additional thing... 12:16 < DannyB> onto the ignore list you go 12:17 < Iron> hm.... 12:17 < Iron> :( ... 12:18 -!- beng_ is now known as ben_g 12:18 -!- mode/#chromium-dev [+v ben_g] by ChanServ 12:19 -!- mode/#chromium-dev [+o ben_g] by ChanServ 12:20 < Iron> google made a lot of money ^ 12:20 < mgreenblatt> someone needs to figure out how to make gcl change run faster 12:20 < Iron> why shouldn't i try to do so, too ^ 12:21 <+maruel> mgreenblatt: disable the auto update 12:21 <@ben_g> Iron: if you don't quit it you're going to be removed from this channel in moment. 12:21 <+maruel> it's the major pain point 12:21 < DannyB> ramdisk 12:21 < DannyB> :) 12:21 < mgreenblatt> maruel... good idea 12:21 <+pinkerton> it's not that slow for me on mac, but it's really slow on my peecee 12:21 <+pinkerton> i think the disk is just super slow on that old box 12:21 < DannyB> HFS is much better at small file handling 12:22 < DannyB> We've analyzed it extensively in SVN land 12:22 < DannyB> :) 12:22 < mgreenblatt> pinkerton.. great.. when does google start buying everyone macs? ;-) 12:22 <+pinkerton> get a job here, they will ;) 12:22 < DrPizza> DannyB: vs. NTFS? 12:23 < DannyB> yes 12:23 < DannyB> Theoretically there is no good reason for this 12:23 < mgreenblatt> pinkerton.. eh, they want everyone to move out west... a 9 hour flight to europe is bad enough already 12:23 < DannyB> it is likely just not an area MS optimizes 12:23 < DrPizza> DannyB: any operations in particular? 12:24 <+maruel> mgreenblatt: that's not true 12:24 < DannyB> DrPizza: all of them :( 12:24 < mgreenblatt> maruel... really? then I guess I'm just being contacted by the wrong google headhunters 12:24 < DannyB> from statting files to opening them 12:24 <+pinkerton> mgreenblatt: there are a bunch of us on the east coast 12:24 < DannyB> i'm east coast 12:24 < DannyB> so is pink 12:25 < DannyB> DrPizza: if you hunt dev@subversion archives you can find graphs, etc 12:25 < DrPizza> DannyB: I know NTFS regularly takes a beating on things like open/create, which I always assumeed to be because ACL checks were relatively expensive 12:25 < DrPizza> but perhaps it's a broader problem than that 12:25 <+maruel> mgreenblatt: They even hire people living in Canada! :/ 12:25 < DannyB> it's slow on writes too 12:25 < DannyB> which there is no reason for 12:26 < mgreenblatt> maruel.. what is this world coming to? ;-) 12:26 <+maruel> eh 12:27 < mgreenblatt> maruel... afaik, all that google has in michigan is adwords in ann arbor... 12:27 < DannyB> ? 12:27 < DannyB> i know some engineers in ann arbor 12:27 < mgreenblatt> dannyb... what group do they work with? 12:28 < mgreenblatt> dannyb.. and do you mean hardware or software guys? 12:28 < DannyB> both 12:28 < DannyB> and i can't say what they work on 12:28 < mgreenblatt> dannyb... that's fine 12:30 < mgreenblatt> as I thought.. the only michigan jobs on the google website are adwords-related 12:30 < mgreenblatt> *shrugs* perhaps the jobs in michigan are all inter-company transfer 12:30 < DannyB> it's quite simple 12:30 < DannyB> apply for an engineering job 12:30 < DannyB> tell them you want to work in michigan or wherver 12:30 < DannyB> if you are a good enough engineer 12:30 < DannyB> they will hire you and let you work there 12:33 < mgreenblatt> dannyb... good to know 12:33 < jamessan> the important part is being a good enough engineer ;) I failed that part 12:34 < mgreenblatt> well, you have to remember google's perspective on "good"... they employ about 80% of the guys who invented modern computing 12:34 < jamessan> I console myself by thinking they only contacted me because I'm a Debian developer (which they seem to love) 12:35 < nemo> mgreenblatt: 80%? 12:35 < nemo> mgreenblatt: what share does MS get? 12:35 < mgreenblatt> nemo... many of google's 80% used to work for MS :-) 12:35 < DannyB> ? 12:35 < DannyB> Not really 12:35 < DannyB> the percentage of MS expatriates is lower than you think :) 12:35 < nemo> soo. 20% retired 12:35 < nemo> 80% google 12:35 < nemo> 0% MS? 12:35 < mgreenblatt> nemo.. no, I'm only referring to person set that still works 12:36 < nemo> ah. that was not specified :-p 12:36 < nemo> the canadian hires thing interests me. I'll have to consider that if I go back home 12:36 < mgreenblatt> nemo... yeah, even the dead ones are working for google now ;-) 12:36 < nemo> speaking of going back home. insane day on the markets today. 12:36 < nemo> mgreenblatt: fine. 80% hired. 10% dead 10% retired :-p 12:38 < mgreenblatt> nemo... ok, let's start will all of the "founders of modern computing"... probably 10% are dead, 20% are retired, 50% work for google and 30% work for other companies... so, ok, more like 62% instead of 80% :-P 12:38 < mgreenblatt> oops.. that doesn't add up 12:38 < nemo> heh 12:38 < nemo> giving 110% 12:39 < mgreenblatt> nemo.. well, some founders are worth more than others ;-) 12:39 < jamessan> well, they always say give 110%. guess that applies to modern computing founders ;) 12:39 < nemo> jamessan: man. way to ruin a joke :-p 12:40 < nemo> so. anyway. yeah. google hires in canada too? 12:40 < mgreenblatt> for instance, I'd trade Marc Andreessen and Guido van Rossum for Bjarne Stroustrup 12:40 <+maruel> nemo: yes 12:40 < nemo> I really wasn't interested in US, but if I go back... 12:40 < nemo> nifty. 12:40 < mgreenblatt> nemo.. I would imagine google has a presence in most countries.. the question being, where in that country (canada is rather large), and will you be working on anything interesting? 12:40 < nemo> would be even more fun to maintain those floating data centres. I could pretend I was a pirate 12:41 < nemo> mgreenblatt: heh. that's always the key parts 12:41 < nemo> mgreenblatt: canada *is* rather large, but the densities vary significantly 12:41 < nemo> mgreenblatt: I'm guessing the nunavut presence is low 12:41 < mgreenblatt> nemo... which means you'll likely end up in Quebec cursing the day you were born ;-) 12:41 < nemo> va te foutre 12:42 <+maruel> mgreenblatt: I work on Google Chrome, that is interresting. 12:42 < mgreenblatt> maruel... are all of the google chrome folks on the east coast? 12:42 < nemo> mgreenblatt: t'a un probleme avec le quebec, americain? 12:42 <+maruel> mgreenblatt: ah, no 12:42 <+maruel> I can only talk about me 12:43 <+pamg> mgreenblatt: Most Google Chroem folks are on the west coast, with a handful elsewhere. But most of the Mac people are on the east coast. 12:43 < mgreenblatt> maruel... approx. how many folks does google have working on chrome fulltime, if you don't mind me asking? 12:43 < nemo> pamg: nifty. any in Vancouver? 12:43 <+pamg> nemo: Don't think Google has an eng office in Vancouver, and no, nobody working from home there. 12:43 < mgreenblatt> pamg... it would be interesting to see the organizational chart 12:44 <+pamg> mgreenblatt: Sorry, we're not announcing the team size. 12:44 < mgreenblatt> pamg.. no problem 12:45 < mgreenblatt> pamg.. what about the ratio of non-google contributors to google contributors? 12:45 <+pamg> Not yet 1:1 afaik. :) 12:45 < mgreenblatt> pamg... ok, so all I have to do now is grep the unique user names from the commit logs and do a bit of math ;-) 12:46 < mgreenblatt> just kidding.. that's too much like work 12:47 <+pamg> Yes, the team is more than 5 people, and less than 1000. :) 12:48 < mgreenblatt> pamg.. so do they put free tshirt bins in all the satellite offices too? 12:48 < nemo> !@#$ ISP 12:48 < nemo> I swear, I'd switch to FiOS in a heartbeat if it wasn't that they blocked ports 12:48 <+pamg> Dunno. 12:49 < mgreenblatt> I've always found the way google runs the Mountain View campus mildly entertaining :-) 12:49 < DannyB> nemo: what ports do they block? 12:49 < nemo> DannyB: 80 for one 12:49 < nemo> DannyB: often 25 12:49 < DannyB> incoming? 12:49 < nemo> yes 12:49 < DannyB> intriguiing 12:49 < nemo> DannyB: I spent some time looking into it because I *did* switch to FiOS after they lied to me 12:50 < mgreenblatt> what's the environment variable that disables source update when you run gcl? 12:50 < nemo> I asked several reps prior to signing contract about port blocking 12:50 < nemo> DannyB: I discovered after reconfiguring router that it wasn't on there, called 'em, had 'em activate the CAT-5 link, plugged laptop directly in. 12:50 < nemo> DannyB: still couldn't get to 80 12:50 < nemo> so. cancelled service same day :) 12:51 < mgreenblatt> comcast was blocking 80 for a while 12:51 < nemo> mgreenblatt: not around here they weren't. I've been on comcast for around 5 years or more 12:51 < nemo> maybe 6 or 7 - I've lost track 12:51 < mgreenblatt> nemo... was it still road runner back then? 12:51 < nemo> mgreenblatt: in our area was always comcast. prior to that, I was on dialup. 12:52 < mgreenblatt> nemo.. ah.. we had a number of smaller players that were eaten by comcast 12:52 < tony^work> ieimporter seems to be broken 12:52 < tony^work> should the tree be closed? 12:54 <+pinkerton> what's ie? :) 12:55 < mgreenblatt> I swear I saw that environment variable documented somewhere... 12:56 <+pinkerton> yeah same 12:56 < mgreenblatt> aha.. DEPOT_TOOLS_UPDATE=0 12:57 <+pinkerton> CHROMIUM_DEPOT_TOOLS_UPDATE=0 12:57 <+pinkerton> ? 12:57 <+pinkerton> ah found the public page. i was looking through old email 12:58 < mgreenblatt> speaking of developer site... we should probably update the chromium source tarball at some set interval if we're not already 12:59 < tony^work> mgreenblatt: I update it nightly on my machine, but I think nsylvain is pushing it live 12:59 < tony^work> nsylvain: maybe I should just push the change nightly as well? 13:02 < mgreenblatt> tony.. how about adding a timestamp next to the download link and/or in the download filename itself? 13:02 < Iron> could it be that the chromium builds are sometimes unstable? 13:02 < Iron> tried build 2xxx and it crashed... 13:02 <+evmar> that is the point of making regular builds 13:03 < Iron> build 1880 is the most stable chromium build i found 13:03 < Iron> never crashed...and tested it with 20 people over a week 13:03 < Iron> 8h a day 13:04 < Iron> so if anybody needs a stable base..take this ;) 13:04 < mgreenblatt> Iron.. maybe that's what the official branches are for? 13:04 < Iron> hm...does the official branch uses the actual webkit 525.19? 13:05 [Users #chromium-dev] 13:05 [@ben_g ] [ Dataforce ] [ kochi__ ] [ raina ] 13:05 [+cpu ] [ dave_levi1 ] [ kov ] [ Rapiere ] 13:05 [+eglaysher ] [ dcat__ ] [ kurros ] [ rcruz ] 13:05 [+erikkay ] [ deltab ] [ kuuranne ] [ rhelmer ] 13:05 [+evmar ] [ dezelin1461] [ lilac ] [ richardus ] 13:05 [+fishd ] [ Dezzimal ] [ lisppaste9 ] [ rojer9 ] 13:05 [+ifette ] [ dglazkov ] [ lorph ] [ rvargas ] 13:05 [+kuchhal ] [ dkegel ] [ manyoso ] [ saturn___ ] 13:05 [+maruel ] [ DrPizza ] [ MattJ ] [ Savory ] 13:05 [+motownavi ] [ dsh|work ] [ MD87 ] [ schilly ] 13:05 [+nsylvain ] [ eggy ] [ mdeicaza ] [ secrgb ] 13:05 [+pamg ] [ El ] [ mgreenblatt ] [ shana ] 13:05 [+pinkerton ] [ emil` ] [ mikebelshe ] [ Simetrical ] 13:05 [+pkasting ] [ eseidel ] [ minerale ] [ sky_ ] 13:05 [+timsteele ] [ fqian ] [ mmoss ] [ slipky ] 13:05 [ [_pitch_] ] [ gabriel_ ] [ Mo_ ] [ smorgan ] 13:05 [ _ph ] [ gavin ] [ monreal ] [ Solarius ] 13:05 [ adjkerntz ] [ gdsx ] [ mpComplete ] [ spock ] 13:05 [ aguent ] [ griffin_ ] [ mwenge ] [ stalled ] 13:05 [ ajaksu_away ] [ heavyhelmet] [ mx80 ] [ stalled_ ] 13:05 [ ajmitch ] [ hjfreyer ] [ nemo ] [ steev ] 13:05 [ Alex512 ] [ huanr ] [ Onkelborg ] [ stevenknight] 13:05 [ alex_joni ] [ icalvin ] [ osmosis ] [ taplax ] 13:05 [ alp ] [ icefox ] [ over ] [ tony^work ] 13:05 [ amatus_ ] [ Inc ] [ p1mrx ] [ tor__ ] 13:05 [ anders ] [ Iron ] [ paulg-cr ] [ vt100 ] 13:05 [ apachelogger ] [ jamesr ] [ Peng_ ] [ wagnoid ] 13:05 [ asac ] [ jamessan ] [ ph8 ] [ Wardje ] 13:05 [ bear ] [ jheusala ] [ phed_ ] [ weazzle ] 13:05 [ brettw ] [ joshia ] [ pjohnson ] [ whereami ] 13:05 [ chandler ] [ jp_tix ] [ playmobil ] [ willdye ] 13:05 [ clee ] [ jshin ] [ pnb ] [ winkle ] 13:05 [ collinjackson] [ kenneo ] [ quickquestion] [ xorl ] 13:05 [ comex ] [ keunwoo ] [ radious ] [ zachb ] 13:05 [ DannyB ] [ Kmos ] [ RageOfThou ] [ Zephyrus ] 13:05 -!- Irssi: #chromium-dev: Total of 140 nicks [1 ops, 0 halfops, 14 voices, 125 normal] 13:05 < mgreenblatt> Iron.. http://src.chromium.org/viewvc/chrome/branches/ 13:06 < Iron> hm but they are under development, too 13:06 < Iron> so no stability guarantee it hink ;) 13:06 < Iron> think 13:06 < Iron> or? 13:06 < mgreenblatt> Iron.. that's why google calls all of their software "beta" ;-) 13:06 < Iron> ;) 13:07 < tony^work> mgreenblatt: I normally just wget the first mb or so of the file and untar it. it normally includes the readme file with the revision number 13:08 < tony^work> I think there is some benefit to having the filename not change daily 13:09 <+nsylvain> tony^work: I'm doing it one in a while, but I haven't done it this week yet. I guess i should do that 13:09 < mgreenblatt> tony... I agree... it would be helpful, though, to have some clue of what the date and/or most recent revision included in the tarball is, though 13:10 <+nsylvain> Eventually we'll have nightlies, and hopefully the tarball is going to be at the same revision as the last nightly 13:10 <+nsylvain> (that was my plan, but no time yet to work on that) 13:11 < mgreenblatt> perhaps generate a text document that contains just "Sept 17 3:15PM PDT, rev 2300" and include that next to the download link? 13:11 -!- Mo_ is now known as Guest91460 13:12 < mgreenblatt> that would also make it simple for anyone automating the download from a remote location for whatever reason 13:13 < mgreenblatt> and, of course, if we wanted to be totally correct you should offer a checksum file... but I won't push that since I'm one of those people who never actually check the checksum file ;-) 13:13 <+nsylvain> we do have a checksum file 13:13 <+pamg> mgreenblatt: There is a checksum file, chromium.tgz.md5 13:13 < tony^work> there you go, just check to see if the md5 file has changed 13:13 < mgreenblatt> that works... now how about a link on the wiki to the checksum file? 13:14 <+pamg> Boy, you're demanding. ;) 13:14 <+pamg> (Fine idea though.) 13:15 < mgreenblatt> pamg... I've been around open source projects for a while.. I know what people usually complain about ;-) 13:15 < mgreenblatt> chromium is still a baby :D 13:15 < mgreenblatt> I like the code review system, though.. hopefully more projects will incorporate that 13:15 -!- mode/#chromium-dev [+v pamg] by ChanServ 13:17 < mgreenblatt> you guys should put the wiki under the source control system too so that people could suggest changes without you having to do all the work ;-) 13:19 <+pinkerton> yeah, we've discussed the lack of openness in the current site project 13:19 <+pinkerton> it does suck in that regard 13:20 < mgreenblatt> another nice feature would be a public comment system, similar to what they do over at docs.php.net 13:21 < mgreenblatt> for instance: http://docs.php.net/manual/en/function.strlen.php 13:21 * evmar starts another build from scratch, *sigh* 13:22 < DannyB> it's funny to watch peopel complain about how long chrome takes to build 13:22 < DannyB> when a 16 way bootstrap + test of gcc takes 3 hours :) 13:22 < manyoso> hi, i just made a patch that compiles about 15 more files for linux port including all import FrameLoaderClient: http://codereview.chromium.org/2943 13:22 -!- ben_g is now known as beng 13:22 < mgreenblatt> dannyb.. I find it especially funny when you consider it takes about 10 times longer to build mozilla 13:22 <+pinkerton> Iron: from our product counsel: "Chromium is the open source version of Google Chrome." 13:22 < manyoso> do i need to do anything else here or is this just CC'd to review mailing list and i hear back later? 13:22 < DannyB> that's because mozilla just sucks :) 13:22 < DannyB> i kid of course 13:22 <+evmar> manyoso: click "mail comments" so a mail goes out to chrome-reviews 13:22 < DannyB> we used to have compiel time testcases for gcc from mozilla 13:23 < DannyB> but 13:23 <+evmar> (it's really not intuitive, i know) 13:23 < DannyB> we've made them all take roughyl 0 time in the actual compiler 13:23 < mgreenblatt> dannyb.. the code definitely sucks... COM-like interfaces for everything, and they put each source file in its own directory, which slows down the compile even more 13:23 < manyoso> evmar: ok, the documentation on http://dev.chromium.org/developers/contributing-code seems to imply that this mail goes off automatically 13:23 < manyoso> i didn't want to spam the list 13:23 < DannyB> mgreenblatt: all code sucks, some just sucks less 13:23 <+evmar> DannyB: it's more sighing at our crazy build system that often requries building from scratch even when you just do an update on top of an already-build tree 13:24 < DannyB> it's ahrd to make build systems that are completely idempotent for large projects 13:24 < mgreenblatt> dannyb... obviously you didn't start life as a programmer ;-) 13:24 <+pinkerton> mgreenblatt: in it's own directory? where'd you get that idea? 13:24 < Iron> @pinkerton 13:24 < Iron> i changed my advertising sentenced 13:25 < DannyB> pinkerton: shut up and make me a testshell :) 13:25 < mgreenblatt> pinkerton... let me see if I still have it installed on this machine and I'll tell you 13:25 < Iron> try our browser - based on the sourcecode behind chrome (chromium) 13:25 <+pinkerton> DannyB: we're down to 6 link errors 13:25 < DannyB> woot 13:25 < Iron> i think that is ok so 13:25 <+pinkerton> of course, we need networking....but.... 13:25 < DannyB> if there's anything i can do, let me know :) 13:25 < DannyB> networking is overrated 13:25 < DannyB> just throw a gopher implementation in there 13:25 < DannyB> problem solved 13:25 <+evmar> manyoso: wow, cpp_variant compiled? 13:25 <+evmar> manyoso: oh, it's because none of this links yet. :( 13:26 <+pinkerton> Iron: the product is called Google Chrome 13:26 < Iron> i make a fork ;) 13:26 < Iron> so i have my own product ;) 13:26 < mgreenblatt> pinkerton.. ok, I take that back... 1 to 4 files per directory :-P 13:26 < manyoso> evmar: it all links statically 13:27 <+pinkerton> Iron: but you can't talk about google's product incorrectly 13:27 <+evmar> pinkerton: !@#!@# 13:27 <+evmar> EARTH TO CHANNEL 13:27 <+pinkerton> sorry 13:27 <+pinkerton> i'll stop 13:27 <+evmar> DO NOT GIVE LEGAL ADVICE 13:27 < manyoso> evmar: i figured the point is to get it compiling first, then linking and working 13:27 * pinkerton ignores 13:27 < mgreenblatt> pinkerton.. if you watch the build, as I'm sure you have, you notice it spends about 50% of it's time changing directories 13:28 < mgreenblatt> (at least on windows.. perhaps it's better in the mac world, along with the lollypop trees and such ;-)) 13:28 <+evmar> DannyB: is it correct to say there's no pragma to disable warnings in gcc? 13:28 <+evmar> DannyB: see http://codereview.chromium.org/2943/diff/1/4?context=50 13:29 <+evmar> DannyB: we do it to sidestep warnings in webkit code, but if it doesn't work in gcc we may have to do something more drastic 13:29 < manyoso> evmar: who at google is working on linux port, or is there no specific responsibility? 13:29 < manyoso> just wondering for coordination 13:29 < DannyB> evmar: i believe we added one in 4.3 or 4.4 13:29 < DannyB> certainly it's too new to use 13:29 * icefox is also curious 13:30 < mgreenblatt> huh.. does codereview recycle issue numbers? 13:31 <+evmar> manyoso: a few people, i'm one of them. 13:31 < manyoso> ah great 13:31 < Iron> @pinktertown: where do i talk incorrectly? 13:31 -!- mode/#chromium-dev [-o beng] by ChanServ 13:31 < Iron> chromium is the sourcebase behind chrome 13:32 <+evmar> Iron: please take non-technical questions to #chromium 13:32 < mgreenblatt> does the commit message for a code review request automatically get included in the email? 13:33 <+evmar> mgreenblatt: no (recycling), and yes (included in mail) 13:33 <+evmar> manyoso: http://codereview.chromium.org/2943/diff/1/8?context=50 still has a pragma 13:33 <+evmar> manyoso: did it compile? 13:33 < mgreenblatt> evmar... I asked the recycling question because the issue I just created actually has a lower number than an issue I create a few days ago 13:34 <+evmar> yeah, i find that confusing too 13:34 < manyoso> evmar: no, i did not. that's why i didn't enable it for linux build yet 13:35 < mgreenblatt> beng: the webkit_glue issue is now @ http://codereview.chromium.org/2944 13:35 <+pinkerton> wow, spam on chromium-reviews 13:35 <+pinkerton> sigh. 13:35 <+beng> mgreenblatt: was this the thing you were discussing with evmar on chromium-dev? 13:36 < manyoso> err, "no, *it* did not" 13:36 < mgreenblatt> beng... yes 13:36 <+evmar> manyoso: i see. so i'll need to test it on windows, then? 13:36 < manyoso> evmar: yes, i think that would be good 13:36 < mgreenblatt> for future reference.. should I have conversations like that on chromium-reviews and leave chromium-dev alone? 13:36 < manyoso> i do not have windows box handy otherwise i'd do it :( 13:38 < mgreenblatt> beng: and on a related topic, is it better to upload the code and publish it, and then go hunting a reviewer? 13:39 <+beng> mgreenblatt: sure 13:40 <+beng> mgreenblatt: then you can point people at a URL to ask if they can review 13:40 <+beng> mgreenblatt: though if you ever find yourself wanting to write a lot of code, it's good to touch base with someone before you begin 13:40 < mgreenblatt> beng... makes sense 13:40 <+beng> mgreenblatt: just to make sure everyone agrees with the approach before you get invested in it. 13:41 < mgreenblatt> beng.. that's exactly the reason why I'm submitting 6 line patches instead of one large patch for test_shell 13:41 < mgreenblatt> less argument that way 13:44 <+beng> mgreenblatt: I'd say someone like tony or brettw could review your change. 13:44 <+beng> mgreenblatt: what are you working towards btw? 13:46 <+pinkerton> gotta run to get cheese for dinner bbiab 13:47 < mgreenblatt> beng... I'm creating an embedded browser control similar to IWebBrowser2 or moxctl, but without the COM 13:47 < mgreenblatt> *mozctl 13:47 <+beng> ah cool 13:48 < mgreenblatt> beng... brettw is already looking at another webkit/glue -related patch.. should I add him as reviewer on this new one, send him a private email first, or just wait and see if he volunteers? 13:49 <+evmar> mgreenblatt: doesn't hurt to put someone on it -- they can reassign as necessary 13:49 < mgreenblatt> evmar... ok, thanks 13:50 <+beng> mgreenblatt: sometimes its easier if one person or a small set of people are the primary reviewer on a group of related changes so they understand what you're working towards, so you can feel free to send it to him 13:51 < mgreenblatt> that was strange.. a delay between the time I added a reviewer and the time that reviewer actually began showing up attached to the issue 13:52 < mgreenblatt> ah.. nm, refresh problem 13:52 < mgreenblatt> you should probably disable caching on codereview.chromium.org/mine 13:54 < mgreenblatt> thanks for your time everyone... ttyl 13:57 -!- beng is now known as beng_ 13:57 -!- beng_ is now known as beng 13:58 < paulg-cr> wtc: compile error 13:59 < wtc> paulg-cr: thanks. 14:04 -!- mode/#chromium-dev [+v pamg] by ChanServ 14:08 <+pinkerton> back 14:09 < wtc> I just checked in a fix. Sorry about breaking the build. I should do release builds from now on. 14:18 <+evmar> wtc: or use the try server! 14:18 < wtc> evmar: you're right :-) 14:21 < manyoso> 'try server' ? 14:22 < jamessan> "gcl try $change" except it's internal-only, afaik 14:23 < manyoso> jamessan: yah, i figured as much 14:23 < manyoso> that would be a great service though 14:24 < doughtie> yay. Finally got chrome built on a 64-bit Ubuntu Hardy system. Not all of the base_utils unit tests work at the moment, so checking here to see if they're expected to. 14:24 < manyoso> especially for those of us who don't have boxes with all different operating systems that chrome builds on 14:25 < jamessan> it'd also be an easy avenue for a DoS attack if just anyone could push stuff to it 14:25 < doughtie> notably: src/base/nss_init.cc(17)] Check failed: NSS_NoDB_Init(".") == SECSuccess 14:27 < manyoso> jamessan: yes, i would think so 14:27 <+evmar> doughtie: we develop on 64-bit hardy, so i'd be interested to hear of problems 14:27 <+evmar> doughtie: that error sounds like a recent addition 14:28 < doughtie> well, I had to do the nastyhax to install the 32bit libs for nss and nspr4 14:28 <+evmar> yeah :( 14:28 -!- manyoso is now known as manyAway 14:28 < doughtie> the fact that the test doesn't completely crap out or segfault suggests it's broken tests or code 14:29 < doughtie> but since I just installed Hardy and tweaked all my libs and exported a custom LD_LIBRARY_PATH I thought perhaps I might just have a b0rk3d environment 14:33 <+evmar> doughtie: 14:33 <+evmar> % uname -m && ./Hammer/base_unittests 2>&1 | tail -1 14:33 <+evmar> x86_64 14:33 <+evmar> [ PASSED ] 214 tests. 14:33 -!- DannyB is now known as DannyB|away 14:34 <+pinkerton> yay! 14:35 <+pinkerton> dinner, l8r all 14:35 < doughtie> Check failed: NSS_NoDB_Init(".") == SECSuccess 14:36 < doughtie> some other path/sqlite thing? 14:36 < doughtie> I followed the 32-bit on 64 bit system instructions here: http://groups.google.com/group/chromium-dev/browse_thread/thread/eeb1b3343b4cea6b 14:39 < dkegel> doughtie, which test is failing? i.e. what's the --gtest_filter=FOO.BAR argument to just run the failing test? 14:40 < doughtie> dkegel: Hammer/base_unittests --gtest_filter=HMACTest.HmacSafeBrowsingResponseTest 14:40 <+evmar> huh, mine passes 14:40 < dkegel> [ OK ] HMACTest.HmacSafeBrowsingResponseTest 14:40 <+evmar> doughtie: time to debug! ;) 14:41 <+evmar> doughtie: i believe if you run it through gdb, 14:41 <+evmar> when the check() fails, it'll break into the debugger 14:42 < doughtie> evmar: my gosh yes, good point! Bet it's something to do with my wonky lib32 stuff. 14:43 < doughtie> evmar: NSSInitSingleton 14:44 * dkegel heads off to port TelnetServer... 14:44 <+evmar> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1234224 14:44 <+evmar> SECStatus NSS_NoDB_Init(char *reserved); 14:44 <+evmar> Parameter 14:44 <+evmar> This function has the following parameter: 14:44 <+evmar> reserved 14:44 <+evmar> Should be NULL.. 14:44 <+evmar> looks like our call is bad? 14:44 * evmar doesn't know this code at all 14:53 < doughtie> mmoss helped me fix my config, so unit tests are happy on head 14:53 < mmoss> ack, getting a build error in webkit/glue/webpreferences.h 14:53 < mmoss> anybody looking at that yet? If not, I can. 14:54 < dkegel> what was the config error? 14:55 < doughtie> wonky 32-bit library install 14:55 <+evmar> we should have better docs, then. 14:55 <+evmar> mmoss: i don't know what error you're talking about, so please go ahead. :) 14:56 < mmoss> yeah, I think it's very recent -- I just synced 14:56 < doughtie> Well, it's a "for machines inside google, do X" kind of issue, I think. 14:56 < mmoss> evmar: I can make more official 64-bit build docs, but I wasn't sure how much support we were prepared to give that 14:57 < mmoss> right now I just linked to the mailing list postings about it 14:57 < mmoss> from the build page 14:58 < mmoss> and on a related note, I think the 32-bit NSS libs are in Intrepid now 14:58 < mmoss> I got a bug update about it today 14:58 < mmoss> put into ia32-libs 14:58 < doughtie> mmoss: there's a good chance that a lot of the first few thousand linux devs will be on some sort of 64-bit box 15:02 <+evmar> wow 15:04 < DrPizza> god I hate linker errors 15:04 -!- mode/#chromium-dev [+v pamg] by ChanServ 15:04 <+erikkay> evmar, someome asking git q on #chromium 15:05 < DrPizza> Why does Visual Studio not rebuild properly, what is it about chromium that's breaking its dependency tracking? 15:05 < DrPizza> Are the timestamps screwy or something? 15:05 < DrPizza> Or is it because not all the files are within the projects 15:10 < brettw> DrPizza: If you can figure it out, please tell us 15:10 < DrPizza> brettw: so it's not just me? 15:10 < brettw> right, it seems to Just Suck (TM0 15:10 < DrPizza> I've never seen anything like it, in the past I've always found VS pretty good at knowing which things need rebuilding 15:13 < DrPizza> nice, I have three link.exes each consuming 500 MB 15:13 < DrPizza> I thought this link was taking a long time. 15:14 -!- RageOfThou is now known as MrFahrenheit 15:16 -!- mode/#chromium-dev [+v pamg] by ChanServ 15:27 < dkegel> Does anybody use the telnet server inside chrome for debugging? 15:28 < Iron> wtf? there is a telnet server inside? 15:28 <+evmar> dkegel: we've been hearing about surprising applications 15:28 <+evmar> i think tv raman (blind) was trying to use it to drive chrome 15:28 <+erikkay> dkegel, sure. why do you ask? 15:28 <+erikkay> there's not a lot of use of it, but a little. 15:29 < dkegel> Think it's worth porting to Linux next? I figured I may as well since I'm doing tcp_listen_socket. 15:29 < dkegel> arg, tcp_client_socket. 15:29 <+erikkay> dkegel, I wouldn't bother 15:29 < Iron> hm whats about a ad blocker in chrome? 15:29 <+evmar> we'd only need after everything else works (the rest of chrome), i think 15:29 < Iron> anybody plans to integrate? 15:29 < Iron> based on a urlfilter file like at opera 15:30 < Iron> i will integrate this in my fork next 15:30 <+erikkay> dkegel, it's only relevant once the entire browser is up and running 15:30 < dkegel> OK. 15:30 <+evmar> Iron, please take non-development questions to #chromium 15:30 < Iron> isn't this a developing question? 15:33 < dkegel> Are folks tired of reviewing the tcp_client_socket change yet? I'm still hoping to get an LGTM, ready to address any issues... 15:33 <+evmar> dkegel: whoops, i can look 15:33 <+evmar> dkegel: i thought darin was on it 15:34 < dkegel> He did give some good feedback, but I addressed it. 15:35 < dkegel> BTW I'm using Chromium on Wine for my main browser at work. So far only thing that failed was buying plane tickets. 15:35 <+evmar> it makes me cry to say it, but "set_non_blocking" is the wrong style :~( 15:35 <+evmar> SetNonBlocking() 15:35 < DrPizza> Oh goddammit. 15:35 < dkegel> I thought foo_bar was the official style for really cheap tiny functions? 15:35 <+evmar> no, only for getters that have no effects 15:35 < DrPizza> I will have to do a full rebuild again because this thing can't keep straight what's new and what's not 15:36 < DrPizza> right 15:36 < brettw> I would recomment unix_hacker_style for things that should be treated like variables 15:36 < Simetrical> Wait, you have different naming conventions for getters and all other functions? 15:36 -!- mode/#chromium-dev [+o beng] by ChanServ 15:36 < playmobil> motownavi: Know if anyone's working on the net::HttpNetworkLayer::CreateFactory mac link error? 15:37 < DrPizza> I wonder if visual studio is too stupid to use inherited properties properly or something 15:38 < paulg-cr> http://dev.chromium.org/developers/coding-style 15:39 < dkegel> Google style strongly encourages (but does not mandate) unix_hacker style on member functions that do so little work they're effectively free, such as simple, non-virtual getters and setters 15:39 < dkegel> OK, CamelCase it is 15:39 < DrPizza> that's PascalCase 15:39 < DrPizza> camelCase has a small initial character. 15:44 -!- DannyB|away is now known as DannyB 15:47 < dglazkov> did gcl broke with the last update? 15:47 <+evmar> dglazkov: ping jam 15:48 < dglazkov> evmar: thanks 15:51 -!- mode/#chromium-dev [-o beng] by ChanServ 15:52 <+evmar> dkegel: have you done the libevent checkin yet? 16:18 < Iron> was anybody able to compile something in 64 Bit? 16:31 <+evmar> Iron: 32-bit binaries on 64, yes, otherwise, no. 16:33 -!- manyAway is now known as manyoso 16:34 < fqian> ?def fqian 17:01 < dkegel> evmar, no, still waiting for approval from darin 17:02 <+evmar> dkegel: did you ever get the libevent side checked in? 17:02 <+evmar> darin may be out 17:03 < dkegel> Can you give an LGTM? 17:05 < sanxiyn> tony^work: Re: GetPhysicalMemoryMB changelist 17:05 * dkegel goes to get a cup of tea while /me waits for validation... 17:06 < sanxiyn> I actually started by replacing callers, but I found that dividing by 1048576 in many places doesn't look good. 17:08 < dkegel> evmar, I'm going to check in the libevent side so you can do a test build 17:09 < dkegel> Done. third_party/libevent now exists. 17:09 <+evmar> dkegel: sorry, beng had an emergency 17:09 <+evmar> lgtm, then 17:10 < dkegel> w00t! 17:10 < dkegel> It will be interesting to see what happens on the mac. 17:10 <+evmar> i wonder if we should have libevent live in deps instead 17:10 < dkegel> Checked in. 17:11 < tony^work> sanxiyn: I see 17:11 < sanxiyn> evmar: What's the difference between deps and third_party? 17:11 < tony^work> sanxiyn: perhaps we should have a wrapper method in base 17:11 <+evmar> third_party is part of the same svn tree as the rest of the project 17:11 < fqian> ?learn fqian is Feng Qian & works at Google on V8 and Chrome. 17:11 * sanxiyn commented to that effect in codereview. 17:12 < sanxiyn> ?def fqian 17:12 <+evmar> if we put it in deps, then we can use gclient to put it into place 17:12 <+evmar> that way "svn status" is faster 17:12 < sanxiyn> fqian: Apparently bot is not present. 17:12 <+evmar> but it's more annoying to make modifications to it 17:12 < tony^work> sanxiyn: e.g., base::SysInfo::AmountOfPhysicalMemoryMB 17:12 < fqian> sanxiyn, yeah, how does bot know which rooms to go? 17:12 <+evmar> dkegel++ for checking in a .patch to make future libevent upgrades easier 17:12 < dkegel> I may want to update libevent to a newer version, that would be a good time to do it. 17:13 <+evmar> i recently moved cygwin, python, and svn to deps 17:13 <+evmar> which is what lead to gclient etc freaking out 17:13 <+evmar> really we ought to be able to make gclient work, though. 17:14 < sanxiyn> evmar: How do you manage changelist if you have two changes pending which modify the same file? 17:14 < dkegel> OK, now that my change has landed, I'm going to run home. I'll check for breakage when I get there... 17:15 <+evmar> sanxiyn: some people have multiple checkouts... i personally use git 17:15 < sanxiyn> Multiple checkouts sound... scary. 17:15 <+evmar> well, it's nice because each one has its own .o files, so incremental compiles are fast 17:16 <+evmar> if you're switching git branches you have to recompile everything in the other branch 17:16 < sanxiyn> evmar: Eh, why? 17:16 < paulg-cr> dkegel: compile error 17:16 <+evmar> doh :) 17:17 < sanxiyn> evmar: Doesn't SCons recompile only changed files? 17:17 <+evmar> yeah 17:17 <+evmar> oh, i'm sorry 17:18 <+evmar> by "everything in the other branch" i meant "everythign *different* in the other branch" 17:18 < sanxiyn> ok 17:18 < sanxiyn> Since my changes are small now, doesn't particularly matter to me now. 17:18 < tony^work> ccache seems to help a lot 17:18 <+evmar> and also if your DEPS are different between branches, you have to rerun gclient sync 17:18 < sanxiyn> evmar: Oh. 17:18 < sanxiyn> Then I don't change DEPS :) 17:19 < sanxiyn> evmar: I currently manage with ad hoc scripting of gcl + quilt. 17:19 <+evmar> oh my! 17:19 < sanxiyn> qulit rules! 17:19 <+evmar> yeah, i have a good impression of it 17:19 <+evmar> i tried using stgit for a bit for chrome 17:19 <+evmar> (stgit = quilt using git for storage) 17:19 < sanxiyn> So gquilt add adds file to quilt *and* gcl, etc. 17:19 <+evmar> wow 17:20 < sanxiyn> For upload you pop everything, push only one patch, etc. :( 17:20 <+evmar> i've often wondered if our webkit forking would be less painful if we were using quilt. but it's such a huge amount of code it'd probably just be painful no matter what 17:21 < sanxiyn> evmar: Apparently git is better quilt, for some. 17:22 < roc> create a new tool called "guilt" 17:22 < sanxiyn> quilt's advantage is that you can use it anywhere: for tarball, svn, hg, git, etc. 17:22 < sanxiyn> roc: I think there already is one (not gcl+quilt, but git+quilt) 17:23 < sanxiyn> roc: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/man/ 17:25 <+evmar> whoops, just committed a revert with git-svn's commit message. :( 17:25 <+eglaysher> --amend? 17:25 <+nsylvain> ah! i was wondering where this ID was coming from 17:25 <+evmar> i was doing a demo for tony -- normally i type slower :( 17:25 < sanxiyn> "This reverts commit d6317065..." 17:26 <+evmar> sanxiyn: i'm really happy with git. http://dev.chromium.org/developers/how-tos/using-git explains how to get set up 17:26 < sanxiyn> evmar: So there's gcl for git, right? 17:26 <+evmar> sanxiyn: yeah, it's linked at the bottom of that page 17:26 < sanxiyn> Ah, doc explains that. ok. 17:27 <+evmar> oh, cool, a thread on guilt vs stgit: http://kerneltrap.org/mailarchive/git/2007/6/14/249310 17:27 <+evmar> the guy on that thread is sgrimm, who is a facebook guy who did lots of contributions to memcached, too 17:29 <+evmar> ... and it has no useful answer. :~( 17:29 < sanxiyn> still reading 17:30 < sanxiyn> evmar: http://kerneltrap.org/mailarchive/git/2007/6/15/249362 seems to be good enough for me. 17:31 < sanxiyn> "... interact with legacy SCMs". 17:33 <+evmar> yeah, but it's not clear to me *why* it interacts better with legacy scms... 17:33 < sanxiyn> evmar: Because it stores patches as patches? 17:33 <+evmar> actually-- i think he's saying that if *your* project is managed with cvs, and you're trying to maintain patches against linux (which is managed with git), then it's easier to export guilt patches into cvs. 17:33 <+evmar> yeah 17:34 <+evmar> i never understood why any of these are so complicated -- they say stgit has 41 subcommands, which seems totally crazy to me. 17:34 <+evmar> when i played with it it seemed they were trying to make an entirely new vcs atop git, while i'd prefer some extra git commands that let me manage patches like quilt. 17:35 < sanxiyn> quilt has 29. What is your expectation? 17:35 <+evmar> i dunno, three? :) 17:35 <+evmar> push, pop, refresh. :P 17:35 * evmar has only played with these briefly 17:35 < sanxiyn> Ah, I think you want something like Mercurial Queue. 17:36 <+evmar> yeah, from what little i know that does match better. 17:36 < sanxiyn> Which adds following commands to Mercurial: qinit, qpush, qpop, qrefresh, qimport, qseries and some other debris. 17:36 < sanxiyn> No add/remove! Managed by Mercurial. 17:49 < jamessan> evmar: the thing I dislike about quilt, Mercurial Queue, and most other patch management systems is that they require changes to be developed inter-dependently. 17:49 <+evmar> yeah. i want to do both independent and occasionally interdependent patches. 17:49 < sanxiyn> jamessan: What is the alternative? 17:49 < jamessan> evmar: topgit is a new git tool that lets you develop things on their own and specify dependencies when they're needed 17:49 <+evmar> and sometimes i have a patch that depends on some mixture of other patches! 17:49 < jamessan> sanxiyn: topgit ;) 17:50 <+evmar> wow! where'd you hear about this? 17:50 < sanxiyn> Indeed if patch management tools can compute patch dependency automatically (doesn't seem *too* difficult) 17:50 < sanxiyn> (Like SCons compute header dep) 17:50 < sanxiyn> That would be good. 17:50 < jamessan> evmar: it was announced on the vcs-pkg list 17:50 <+evmar> this looks awesome 17:51 < sanxiyn> jamessan: topgit homepage? 17:51 <+evmar> sanxiyn: plug it into google :P 17:51 <+evmar> http://repo.or.cz/w/topgit.git?a=blob;f=README 17:51 < sanxiyn> evmar: Wow, this does look like very similar to what you want 17:52 <+evmar> sanxiyn: tracking interdependencies between patches is effectively what darcs does. it's nice they mention it in this readme too. 17:52 < jamessan> darcs had some nasty edge cases though (which I unfortunately ran into). from what I hear, they may have finally solved those problems in 2.0 17:53 <+evmar> wow, this looks pretty much perfect. i'd actually thought of making something like this for a while but i have enough projects already... 17:53 < jamessan> :) 17:54 <+evmar> you can say "this patch depends on these other two patches", but if you change one of those other patches it knows to automatically update the dependent one 17:54 < jamessan> I've been meaning to take a look at it for some of my Debian packages but I haven't had time 17:55 < sanxiyn> evmar: It lets you manage dependency by hand, but that's better than not managing dep at all... 17:57 <+evmar> i am going to steal some ideas from this for git-cl, too. 18:06 < paulg-cr> cpu: xp-perf and xp-interactive test crashes 18:14 <+cpu> paulg-cr: looking at them 18:20 -!- ajaksu_away is now known as ajaksu 18:20 <+cpu> I am closing the tree, not sure what is going on 18:49 <+cpu> ok, now lets just wait for the bots to do one cycle 19:26 < phed_> :( chromium doesn't deal very well with "the last measure" 19:27 < phed_> or, perhaps it dealt with it too well. it was actually outlook which was the biggest culprit 19:46 <+cpu> tree is open now 21:13 -!- mode/#chromium-dev [+v abarth] by ChanServ 22:45 -!- NoOneButMe is now known as Zee 22:46 -!- Zee is now known as NoOneButMe --- Log closed Thu Sep 18 00:00:59 2008