| |
| |
| |
|
Page: 1 2 3 4 5 6
<MacDomeHack> true
<MacDomeHack> ap: that could be really slick infact
<MacDomeHack> although you really want the test in run-webkit-tests more than DumpRenderTree
<MacDomeHack> ap: maybe DRT should only check if it's p***ed a --requireAhem flag
<MacDomeHack> hum...
<mitzpettel> too bad the ftx* tools aren't standard. ftxinstalledfonts could be used from run-webkit-tests
<mitzpettel> it's not really a DRT function
<MacDomeHack> mitzpettel: well, DRT doesn't always requiree it... but run-webkit-tests does
<ap> Formally true, but I have a hard time trying to imagine a person who wants to run DumpRenderTree, but doesn't need Ahem :)
<MacDomeHack> mitzpettel: we could make it so that when DRT is run in the "take from stdin" mode it requires Ahem
<MacDomeHack> agreed
<MacDomeHack> ap: if you'd like to make a small patch to DRT which bails w/ no Ahem, printing a log, that would be super-great
<ap> MacDomeHack: not right now (time to go to sleep), but I could definitely do that. Or should I bargain landing one of my patches for that? ;-)
<MacDomeHack> ap: I'll happily land multiple of your patches... w/o encoruagement
<MacDomeHack> omg
<MacDomeHack> 37 patches to land
<MacDomeHack> ap: any particular favorites?
<MacDomeHack> ap: regardless, I'll give the commit queue some lovin this afternoon
<ap> MacDomeHack: 5230 is simple, but kind of making further development harder... 5548 is P1
<ap> MacDomeHAck: though my patches are no more important than others' ones
<MacDomeHack> :)
<MacDomeHack> ap: I'll take a look while you're sleeping
<ap> thanks :). good night, all!
<mitzpettel> good night ap
<jibot> PantherMachina is OMGWTFSCO
<MacDomeHack> olliej: I'm itching to land your filter stuf...
<jibot> MacDome is a WebKit engineer who hacks on XML, XHTML, XSLT and SVG
<jibot> AlthA is our resident testcase maker extraordinare and an all-purpose bugzilla majordomo and has a weblog at http://simpleanswer.net and living in Nijmegen, The Netherlands
<AlthA> hi
<AlthA> why am i up?
<AlthA> :)
<MacDomeHack> AlthA: maybe because you want to write test cases?
<AlthA> hehe nah
<AlthA> just came from the new harry potter movie ;)\
<MacDomeHack> no capes!
<AlthA> ah it was fun
<Darien> HP was good
<MacDomeHack> wb othermaciej
<othermaciej> hey
<MacDomeHack> othermaciej: we need more external commiters :)
<DxSadEagle> hi othermaciej
<othermaciej> hi DxSadEagle
<othermaciej> MacDomeHack: tell me about it
<MacDomeHack> so they can commit their 20+ pending patches :)
<DxSadEagle> othermaciej: Q: do you know much about the arenas?
<othermaciej> like RenderArena, you mean?
<DxSadEagle> yeah
<DxSadEagle> I don't have a high-level idea of what it's doing.
<DxSadEagle> (and page teardown times are surprisingly bad)
<othermaciej> main problem with page teardown (per hyatt) is that it is wasteful to do it from the inside out instead of outside in, since when inner render nodes are removed they waste time updating their parents
<DxSadEagle> that's part of things. I was just surprised to see a huge % in arena clear, and quite a bit of deletion...
<DxSadEagle> --- so I am wondering what's the idea behind the arenas.
<othermaciej> the idea is, since all render objects for a page die at a specific predefined moment, you allocate them in arenas that you can clear at one go
<othermaciej> don't know the details of the algorithms
<othermaciej> and we haven't re-tested if it actually helps since switching to a custom malloc
<othermaciej> it did help speed at the time it was added
<DxSadEagle> I thought so -- but the "clear at one go" seems to be taking... a whole lot of time
<jibot> bdash is Brian Dash
<othermaciej> well, presumably it would be taking more time otherwise
<othermaciej> I think it still calls all the individual destructors
<DxSadEagle> that'd be at deletion time, not the arena clear time, no?
<DxSadEagle> e.g., I am seeing the recursive detach take 300ms, the deletion or the arena take 127ms.
<DxSadEagle> which to me is surprising, and so I was wondering whether I got the high-level wrong... Though, well, I am not really feeling like digging into misc/arena.cpp code, it ain't pretty
<othermaciej> it's copied from mozilla
<othermaciej> I'm not sure it is all that great
<MacDomeHack> om_afk: when you get a moment this evening, I would love a review: http://bugzilla.opendarwin.org/show_bug.cgi?id=5839
<olliej> hey MacDomeHack
<MacDomeHack> OLLIEJ!
<MacDomeHack> wb
<MacDomeHack> olliej: have I mentioned recently how excited I am about your filters patch??!?
<MacDomeHack> have I? have I?
<MacDomeHack> and wait for om_afk to review one of his...
<olliej> MacDomeHack: down to ficing specular lighting
<MacDomeHack> sweet
<SadEagle> om_afk: yeah. And I almost feel like it's less effort to write something myself then trying to figure it out :-)
<MacDomeHack> wb othermaciej
<MacDomeHack> 8 commits down! only 29 left to go...
<othermaciej> I will commit some stuff soo
<othermaciej> MacDomeHack: it just globally renames InterpreterLock to JSLock via script
<othermaciej> MacDomeHack: can I consider that de facto reviewed?
<MacDomeHack> othermaciej: yes
<MacDomeHack> othermaciej: so long as you post the script for posterity
<MacDomeHack> dammit... looks like one of the patches I just commited brok stuff under 4.0
<MacDomeHack> fixin gnow.
<othermaciej> lisppaste3: help
<lisppaste3> To use the lisppaste bot, visit http://paste.lisp.org/new/webkit and enter your paste.
<lisppaste3> othermaciej pasted "the script" at http://paste.lisp.org/display/14042
<MacDomeHack> othermaciej: well, I meant in a bug, but sure.
<othermaciej> MacDomeHack: this is a script I edit to reuse, so has some irrelevant commented stuff
<MacDomeHack> othermaciej: yeah, it looks fine
<MacDomeHack> I do the same thing w/ my scripts :)
<SadEagle> InterpreterLock seems quite safe as far as things to substitute go
<MacDomeHack> dammit, I broke the build for real
<othermaciej> the code does compile and work
<othermaciej> oops
<Blafasel> Hi there. Is this the right place to ask for help, if I have problems with Safari rendering a specific site (most probably related to the content-type)?
<othermaciej> Blafasel: best thing to do is file a bug report, but asking here might help
<MacDomeHack> http://bugzilla.opendarwin.org/attachment.cgi?id=4371 must not have applied right.
<MacDomeHack> Blafasel: http://www.webkit.org/ has lots of info on how to file a good bug report
<MacDomeHack> where to do so, etc.
<othermaciej> Blafasel: there's usually helpful people in this channel though, so if you have questions you can probably just ask away
<MacDomeHack> hum... I guess I didn't break the build. xcode was just confused
<othermaciej> MacDomeHack: probably a good idea to build and run tests after applying patches
<Blafasel> othermaciej: I have a site that delivers "Content-type: multipart/mixed;boundary=***newpage***" with several parts that all have a "Content-type: text/html".. While every Browser so far renders this site as html (IE, FF, Opera, even dillo afaik) it's treated as unknown content by Safari and in my default setup it ends up as download..
<MacDomeHack> othermaciej: I did, that was what surprised me :)
<MacDomeHack> othermaciej: it was after updating from cvs on the other machine it seemed broken
<Blafasel> MacDomeHack: I'll submit a bug as soon as I'm rather sure that it's one.. ;) Thanks for the link, though
<othermaciej> I'm gonna switch to Deployment because I ***ume you have Development and best to test both ways
<MacDomeHack> othermaciej: I've been building after every patch, and running fast/ :)
<othermaciej> Blafasel: which version of Safari?
<Blafasel> Latest release. Mom
<othermaciej> Blafasel: we only added multipart support recently
<othermaciej> hmm
<MacDomeHack> othermaciej: agreed, I think I have development on one machine and deployment on the other.
<MacDomeHack> I was commiting from both for a while...
<othermaciej> oh
<MacDomeHack> was kinda crazy
<Blafasel> 2.0.2
<othermaciej> Blafasel: I think we only recognize mutlipart/x-mixed-replace, not multipart/mixed
<othermaciej> Blafasel: what is the intended semantic, showing all the documents, showing just the last?
<Blafasel> Showing just the last
<othermaciej> so I guess it should work the same as multipart/x-mixed-replace
<Blafasel> It's not a page of mine (so I can't do anything about it), but I wondered why it fails and checked the header to find a problem..
<Blafasel> I try to find a RFC for that..
<othermaciej> I think you are tight that it is a content type issue
<Blafasel> But - is support for multipart planned to change/widen?
<MacDomeHack> Cryo: around?
<othermaciej> Blafasel: odds are higher if you file a bug report :-)
<MacDomeHack> Cryo: ping me when you come back
<othermaciej> but I think this one actually will go to the networking layer code, which isn't technically part of webkit
<Blafasel> othermaciej: Good point ;)
<othermaciej> Blafasel: so best to file it at http://bugreport.apple.com if you don't mind
<MacDomeHack> othermaciej: well, some support is needed in webcore iirc.
<Blafasel> Oh - didn't know that. I thought it's content-related and therefor should end up here ;)
<othermaciej> I think it requires a free ADC account
<Blafasel> *sigh* Guessed so ;)
<othermaciej> MacDomeHack: as far as I can tell it should work just like multipart/x-mixed/replace
<othermaciej> Blafasel: you can file it in bugzilla if you want - will just take longer to get to the right person that way
<SadEagle> othermaciej: as an animation? ;-)
<MacDomeHack> Blafasel: well, it sounds like a compatibility issue... someone supports that content type (WinIE, FireFox?) so we probably should too
<MacDomeHack> othermaciej: if I do nothing else this week, I want to work with tim to have subversion up by friday
<MacDomeHack> othermaciej: this is getting rediculous
<othermaciej> might be worth testing other browsers on the test
<MacDomeHack> I've lost more time waiting for update-webkit...
<othermaciej> MacDomeHack: that would be nice
<othermaciej> we desperately need a test server too
<othermaciej> tim seems really excited about the inspector though
Return to webkit
or
Go to some related
logs:
XIOS FTP"
chatzone
|
|