Re: [webkit-dev] Could not find answer: Build and run Cairo Webkit on XP
Hello Brent, thank you for your fast reply and action. I'll try out the new WinCairoRequirements.zip later today. Christoph -- View this message in context: http://old.nabble.com/Could-not-find-answer%3A-Build-and-run-Cairo-Webkit-on-XP-tp33158989p33168083.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] *.webkit.org is down
Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
On Jan 19, 2012, at 5:19 PM, Alexis Menard wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I meant trac.webkit.org (Mac OS Lion auto-correction is too efficient). Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
20.01.2012, 00:19, Alexis Menard alexis.men...@openbossa.org: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? For Moscow both sites are up. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.orgwrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
Hey Bill, Still having trouble, my IP is 186.213.109.123, but it looks like the problem is in the path between Brazil and your datacenter. Huge packet losses as soon as we get into the telefonica network: kov@goiaba ~ mtr -w -r -c 100 bugs.webkit.org HOST: goiaba Loss% Snt Last Avg Best Wrst StDev […] 4.|-- 187.115.193.162.static.host.gvt.net.br 0.0% 1005.0 9.9 4.8 137.1 20.6 5.|-- 187.115.215.54.static.host.gvt.net.br 0.0% 1009.1 12.2 5.1 23.3 4.0 6.|-- 187.115.216.33.static.host.gvt.net.br 0.0% 100 18.4 21.4 13.3 34.3 4.1 7.|-- 187.115.216.157.static.host.gvt.net.br 0.0% 100 37.8 40.5 36.8 56.5 4.4 8.|-- 187.115.216.174.static.host.gvt.net.br 0.0% 100 37.9 38.3 37.0 52.2 2.4 9.|-- Xe0-1-0-0-grtssatw1.red.telefonica-wholesale.net.7.16.84.in-addr.arpa 91.0% 100 215.4 225.5 213.9 302.6 28.9 10.|-- Xe5-2-0-0-grtfortw1.red.telefonica-wholesale.net 86.0% 100 239.6 221.7 214.6 239.6 5.9 11.|-- Xe11-0-0-0-grtmiabr4.red.telefonica-wholesale.net.123.142.94.in-addr.arpa 90.0% 100 243.9 231.7 215.0 274.1 19.0 12.|-- Xe0-1-6-0-grtmiana3.red.telefonica-wholesale.net 91.0% 100 214.0 233.6 214.0 345.1 42.9 | `|-- 176.52.249.150 | |-- 94.142.119.229 | |-- 213.140.36.89 | |-- 94.142.123.1 | |-- 176.52.249.146 | |-- 213.140.37.77 | |-- 213.140.43.141 13.|-- Xe3-0-0-0-grtmcacc1.red.telefonica-wholesale.net 93.0% 100 213.9 216.4 210.7 220.1 3.5 | `|-- 213.140.37.25 14.|-- GE4-3-2-0-gramtyma2.red.telefonica-wholesale.net.127.142.94.in-addr.arpa 87.0% 100 215.7 214.7 212.7 216.8 1.3 15.|-- 84.16.14.50 86.0% 100 217.1 216.3 212.8 222.1 2.6 16.|-- Xe1-1-1-0-grtdaleq3.red.telefonica-wholesale.net.122.142.94.in-addr.arpa 88.9% 99 210.4 226.8 210.4 274.0 23.1 17.|-- 192.205.35.249 90.8%98 222.6 227.4 213.9 263.1 17.4 | `|-- 213.140.53.62 18.|-- cr2.dlstx.ip.att.net 83.7%98 263.8 262.5 258.6 265.6 2.5 19.|-- cr2.la2ca.ip.att.net 85.6%97 260.6 269.4 260.6 315.9 15.2 20.|-- cr2.sffca.ip.att.net 83.3%96 260.9 263.6 255.1 272.3 3.8 21.|-- cr84.sffca.ip.att.net 84.2%95 260.7 261.3 259.0 263.7 1.4 22.|-- gar1.placa.ip.att.net 86.2%94 256.3 261.6 256.3 291.7 9.2 23.|-- ??? 100.0930.0 0.0 0.0 0.0 0.0 24.|-- ??? 100.0900.0 0.0 0.0 0.0 0.0 25.|-- ??? 100.0900.0 0.0 0.0 0.0 0.0 26.|-- bugs.webkit.org 89.9%89 259.8 261.6 258.3 265.9 2.5 The good news is the path to us.logon.battle.net is fine, so we can go play WoW instead of hacking WebKit =X Cheers, On Thu, 2012-01-19 at 13:05 -0800, William Siegrist wrote: If you are still having trouble access the site, send me your IP address and I will see if its anything on the server. -Bill On Jan 19, 2012, at 12:34 PM, Jesus Sanchez-Palencia wrote: I'm also in Brazil and I can confirm it doesn't work for me as well. I guess kov is also in Brazil and I just saw him mentioning on IRC that both bugs.webkit.org and git.webkit.org are timing out... Cheers, Jesus On Thu, Jan 19, 2012 at 5:24 PM, Philip Rogers p...@google.com wrote: http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to
Re: [webkit-dev] Removing deprecatedFrameEncoding
We don't typically add #ifdefs to cross-platform WebKit code solely to make different choices about web standards and web compatibility in different ports. (Have we ever done that before?) It strikes me as destructive to WebKit and the web to start doing so now. I'm strongly opposed to this option. Really? Yes, really. https://lists.webkit.org/pipermail/webkit-dev/2012-January/019105.html The URL you pasted shows Jon removing a feature that isn't used by the web (not analogous to this situation), after no objection (not analogous to this situation), and proposing removing it for the whole project on the same grounds (consistent with the goals I've stated). Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New CSS property -webkit-control-text-overflow
Fair enough, reusing text-overflow introduces the fewest changes, and would be the best option for authors to use. I will update the bug patch to use that property instead, and close the issue on the www-style list. Thanks for everyone's input! Jon On Jan 16, 2012, at 1:54 PM, David Hyatt wrote: I strongly disagree with the reasoning in that post. You say: As an author, I would find it strange that upon focus of a text input the ellipsis would just disappear. I think it would be even stranger for the ellipsis not to disappear and to be editing a truncated version of the input field's value. What does that that even mean? I'd rather the author be surprised than the user! It seems like the options are: (1) Ignore text-overflow completely on text fields. Support a new property for the dynamic display of the full text when focused. (2) Honor text-overflow strictly on text fields. Support a new property for the dynamic display of the full text when focused. (3) Use text-overflow for the dynamic display of the full text when focused. To me (3) is clearly the most attractive choice. (1) would surprise authors by having text-overflow not work. (2) would surprise both authors and users by having text-overflow work badly when you focused the control. I see absolutely no reason to introduce a new property here, especially after hearing that Gecko just made text-overflow do this already. My expectation is that we would match Gecko's behavior and not introduce a new property. dave (hy...@apple.com) On Jan 16, 2012, at 1:53 PM, Jon Lee wrote: There is a thread on the www-style list that discusses this point: http://lists.w3.org/Archives/Public/www-style/2012Jan/0687.html On Jan 16, 2012, at 11:41 AM, David Hyatt wrote: I have the same question. Can you explain why text-overflow is insufficient? I think in this case it would be acceptable behavior to just make text-overflow behave the way you want, i.e., no longer showing the ellipsis while the user is actively typing in the focused control seems like fine behavior even for text-overflow. dave (hy...@apple.com) On Jan 13, 2012, at 2:45 PM, Ojan Vafai wrote: Is this specced anywhere? Do we need a new CSS property? Could we just make text-overflow work on text inputs? On Wed, Jan 11, 2012 at 11:30 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! I wanted to let you know that we would like to add a new CSS property -webkit-control-text-overflow. It is a non-inheritable property that can only be applied to single-line text inputs. Acceptable values are the same as text-overflow, i.e. clip and ellipsis. When the input is set with the ellipsis value, both the placeholder and inner text value of the input render with an ellipsis if the text overflows and the input is not focused. When the input becomes focused, the placeholder or text value renders clipped, as before. Although this is a small enhancement to text controls, we think this is especially useful for authors developing on the mac platform, since the analog native widgets behave similarly. The bug that tracks this is: https://bugs.webkit.org/show_bug.cgi?id=76118 Jon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing deprecatedFrameEncoding
On Thu, Jan 19, 2012 at 1:38 PM, Geoffrey Garen gga...@apple.com wrote: We don't typically add #ifdefs to cross-platform WebKit code solely to make different choices about web standards and web compatibility in different ports. (Have we ever done that before?) It strikes me as destructive to WebKit and the web to start doing so now. I'm strongly opposed to this option. Really? Yes, really. https://lists.webkit.org/pipermail/webkit-dev/2012-January/019105.html The URL you pasted shows Jon removing a feature that isn't used by the web (not analogous to this situation), after no objection (not analogous to this situation), and proposing removing it for the whole project on the same grounds (consistent with the goals I've stated). I'm not sure I understand the difference. Anyway, thanks for taking the time to engage in this discussion. I'm going to write up a summary of the various points of view and propose a path forward. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
If you are still having trouble access the site, send me your IP address and I will see if its anything on the server. -Bill On Jan 19, 2012, at 12:34 PM, Jesus Sanchez-Palencia wrote: I'm also in Brazil and I can confirm it doesn't work for me as well. I guess kov is also in Brazil and I just saw him mentioning on IRC that both bugs.webkit.org and git.webkit.org are timing out... Cheers, Jesus On Thu, Jan 19, 2012 at 5:24 PM, Philip Rogers p...@google.com wrote: http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] *.webkit.org is down
It's back! :) cheers, jesus On Thu, Jan 19, 2012 at 7:26 PM, William Siegrist wsiegr...@apple.comwrote: I think you have the same problem as Gustavo. His email to webkit-dev seems to imply a problem in between Brazil and webkit.org. -Bill On Jan 19, 2012, at 2:00 PM, Alexis Menard wrote: Hi, I can't also access from home : IP - 186.215.1.122 Thanks. On Thu, Jan 19, 2012 at 6:05 PM, William Siegrist wsiegr...@apple.com wrote: If you are still having trouble access the site, send me your IP address and I will see if its anything on the server. -Bill On Jan 19, 2012, at 12:34 PM, Jesus Sanchez-Palencia wrote: I'm also in Brazil and I can confirm it doesn't work for me as well. I guess kov is also in Brazil and I just saw him mentioning on IRC that both bugs.webkit.org and git.webkit.org are timing out... Cheers, Jesus On Thu, Jan 19, 2012 at 5:24 PM, Philip Rogers p...@google.com wrote: http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML notification usage
TLDR Sorry for the long delay in responding but the chromium folks need to delay slight longer before giving a response. On Mon, Jan 16, 2012 at 1:36 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Could anyone brief explain the relation to http://www.html5rocks.com/en/tutorials/notifications/quick/ and http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html ? I haven't followed the work with regard to notifications, so is that work dead or are we removing legacy code? afaik Chromium is the only browser to support HTML notifications (maybe QT does as well? I thought I saw some patch there) and I don't think any other browser wants to support them. However other browsers are supporting text notifications. There are some Chromium extensions that potentially use them, so that creates some trouble for us to remove them but it doesn't necessarily make it impossible. On Mon, Jan 16, 2012 at 10:25 PM, Jon Lee jon...@apple.com wrote: Hello all, I've removed support for HTML notifications on the Mac via http://trac.webkit.org/changeset/105086. Does anyone find much usage for this kind of notification on their respective platforms? Would it be appropriate to remove support for this altogether? We're discussing this with folks that have the biggest stake. We're working as fast as we can and making progress in reaching a consensus -- thanks to Jian Li -- (but have been slightly slowed down by the snow fall up here in the Seattle are which has made our communications). Personally, I'd like to get rid of them BUT that decision isn't up to me, so we need a few more days to talk to people and come up with an appropriate course of action. (If we want to get rid of it, we'll likely need to leave it in for a bit to give users a little time to transition off of it.) (Hopefully the snow will melt shortly and it will make people more accessible.) dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Introducing run-perf-tests and Adding Performance Bots
Hi WebKittens, *Executive Summary* - I've added Tools/Scripts/run-perf-test, try out - Please add --no-timeout and --timeout options to your DRT - Perf-o-matic coming on webkit-perf.appspot.com, a clone of graphs.mozilla.org - Chromium Mac perf bots coming on build.webkit.org - Use PerformanceTests/Parser/resources/runner.js to write new performance tests *Background* We have some performance tests in PerformanceTests but they're not ran by any bots. In fact, there are no performance bots at all on build.webkit.org. While Chromium has perf botshttp://build.chromium.org/p/chromium.perf/console, we can only see progressions and regressions triggered by WebKit changes when Chromium gets a WebKit roll (pulling newer version of WebKit), which happens only a handful times a day. It doesn't scale to the rate at which we're making changes to WebKit and the visibility and the usability of bots are not great for non-Chromium WebKit contributors. Furthermore, Chromium perf bots will not catch JSC progressions and regressions at all. *Means to Run Performance Tests* I've added Tools/Scripts/run-perf-tests to run PerformanceTests in DRT based on the work Ilya Tikhonovsky (loislo) has done for run-inspector-perf-tests.py. The script aims to run performance tests both locally and on bots similar to the way run-webkit-tests works and runs on Mac (WebKit1) and Chromium ports. Please try it out and give me a feedback (you can file a bug with run-perf-tests: in the summary and cc me). I didn't merge it into run-webkit-tests because performance tests don't pass/fail but instead give us some values that fluctuate over time. While Chromium takes an approach to hard-code the rage of acceptable values, such an approach has a high maintenance cost and prone to problems such as having to increase the range periodically as the score slowly degrades over time. Also, as you can see on Chromium perf botshttp://build.chromium.org/p/chromium.perf/console, the test results tend to fluctuate a lot so hard-coding a tight range of acceptable value is tricky. Unlike run-webkit-tests, run-perf-tests doesn't generate any HTML or JSON files to summarize the results by default since only output you get out of performance tests are time took to run tests or scores, which are already reported on stdout. The output of run-perf-tests is designed to be compatible with Chromium perf bots but we can easily change that to something more human friendly if people are so inclined. The script optionally generates a JSON file to be used by perf bots. In order for other ports (e.g. Windows, Qt, GTK, etc...) to support run-perf-tests, simply their respective DRT needs to support --no-timeoutoption that disables the watchdog timer. This is necessary as some performance tests take a long time to run. Also, we'll appreciate your help if you could add --timeout option per https://bugs.webkit.org/show_bug.cgi?id=76662 for the code sanity. *Adding Performance Bots* In the next couple of days, I'm going to post a patch to add a Chromium Mac Perf bot to build.webkit.org (of course, upon appropriate reviews) that runs run-perf-tests and uploads a JSON file to webkit-perf.appspot.com, a clone of graphs.mozilla.org. While we could have adopted Chromium's perf bot output where each slave generates a JSON file with a html front end that loads the JSON, the approach didn't scale well for Chromium when the number of historical values stored on each slave soared and the size of JSON increased proportionally over time. Furthermore, it's hard to compare values between different bots or tests. On the other hand, creating a new front end seemed like a too much work. As such, I've decided to port Mozilla's Graph Serverhttps://github.com/mozilla/graphsto WebKit after consulting with tony^work, ojan, and evmar. While we could have added another dedicated apache server with all nice features Graph Server's native backend provides, the maintenance cost of maintaining such a server seemed too high. Also, Robert Helmer (rhelmer), a Mozilla contributor who is actively working on the Graph Server, told me that Mozilla is planning to replace the backend with a key-value database. Given these circumstances and some experimentations, I wrote our own backend using Google App Engine http://code.google.com/appengine/ for its low maintenance cost and ease of use; note App Engine is already used by commit-queue and flakiness dashboard. My work to port the Graph Server is near completion and I expect it to be working in the next couple of days just as I add a Chromium Mac Perf bot. If you're interested in adding new perf bots for your port, please contact me directly and I'll give you a detailed instruction on what needs to happen (it's super trivial but involves giving out or receiving a password). *How to Write Performance Tests* If you're interested in adding more performance tests (you should be!), then use
