Especially when you have the current mix of HTML4 or XHTML, RDFa, SVG and MathML. So how do you advertise that the site you are using supports HTML+RDFa+SVG (or some other combination)?
Then you have all the websites saying they are version XYZ, but are not valid against that version, or have some weird tag soup and expect it to work. A current issue is where Firefox renders some content bolder when using Win7 Direct2D if you have two bold styling attributes on a text section (e.g. GMail Apply button).
I've even seen some documents advertised as XHTML that don't parse as XML for a variety of reasons and are just HTML4 restyled as XHTML.
I haven't had a problem using Aero Snap with the new FF on Windows 7 to switch the window between screens as of yet. I've only been using it for ~3 days, so time will tell.
How about requiring patent holders to have a product that they sell in order to hold the patent.
This would get rid of the holding/shell companies that just buy patents for the purpose of sueing other companies to make their money. It would also mean that a company has to actually produce something that uses the patent in question first, instead of saying "hay, we could move into this direction in the future, so lets patent it to reduce the competition.".
How hard was it to create that test framework? You don't need something that is overly complex, just something that will pass if the test succeeds or fails if it doesn't. You can then improve the test cases/framework as you go along -- look at the Wine project for example. They didn't create http://test.winehq.org/data/ over night, it was built up gradually, starting with getting the tests running as part of the build and slowly defining a wine test API as needed.
Collecting metrics and reporting them should be done automatically, but not initially.
Tests can fails either due to the code under test, the test code or the environment.
Tests form a contract between teams (e.g. defining the way a protocol works, invalid and valid data with the expected results). They also serve as a form of documentation -- this is how you use this class; we need to support this corner case; this test checks that we don't regress this security bug.
Tests also document what your assumptions are -- e.g. does this method allow NULL pointer strings or not? One of my primary testing axioms is: assume nothing, assert everything. In the previous example, this means that there is an assumption that passing a NULL pointer to a function taking a string argument is valid; this axiom states that there needs to be an assertion/test case to check that the assumption holds.
When creating test cases, you need to define how the program will behave under certain circumstances. With sufficient coverage it then gives you the confidence that you haven't regressed anything.
But as always, start small and build up from there.
The article describes how a certain bug is recurring. Explain to your managers/team that this bug keeps cropping up (using evidence from the bug tracker). Write a test case for just that and include it as part of the build process. The issue should then be picked up on the developers machine, or on the daily/incremental build and not during the manual test cycle for a release. This can then be used as evidence to support adding tests for any bugs that are found. You can build it up from there.
Exactly.
Going from interpreted to a (simplistic code generation) method jit is reasonably straightforward (assuming you know how compilers and assembly language works).
From there, you can analyse the parts of the code generation that are slow and produce better code for them (e.g. using the INC operation for ++i instead of ADD 1).
Then you need to start doing run-time hot-loop/hot-code optimisations on the fly which is what tracemonkey and this are doing. Getting this working is around the same complexity as the method jit, integrating the two is harder (when to run the optimiser, when to bail out).
After that, you are into type inference/static analysis territory. Some experimental patches that the Firefox team are working on show ~35-40ms improvement on the spidermonkey tests. Other optimisations are possible from the inbuilt knowledge of the types.
There is no one single magic bullet to say do XYZ and the desktop usage will be super awesome responsive. That is because there are different situations and conditions that can affect performance.
This specific patch is to handle the case where running background tasks (updating, backup, searching the filesystem to index files and other things the computer can do) that eat up CPU causes the system to become unresponsive (especially on lower spec machines that don't have enough CPUs to handle moderately complex workloads). The reason the "make -j64" was used was not to say that this is great for developers or people building stuff in the background while watching video (which it will be), but to simulate the system under stress.
The return statement was "return;" i.e. a return statement that did not return anything. Looking at the other JavaScript engines, that line added at most 1ms, while with the IE engine it added 19ms. If the IE9 JS engine is handling this function in a super-efficient way that is not due to cheating, the optimisation must be highly sensitive to variance.
One way to check if the IE9 engine is doing some sort of special casing (e.g. hashing the text for the function) would be to change the name of a variable. This should not change the behaviour of the engine as it is the same code (there are no extra elements in the tree, like additional returns). If the IE9 engine is cheating, this should jump from 1ms to 20ms like the other variances. If it is an optimisation bug, the performance should be 1ms for both cases.
Parrot? That is a VM that can run a lot of different languages.
You could always take one of the JavaScript engines -- V8, TraceMonkey+JaegerMonkey, JSC, etc. -- and adapt it to run python if you were so inclined.
Also, if you like C# as a language, you could use Vala.
And fossils C and C++ may be, but a lot of software is built with them including the major OSs, Web Browsers, Compilers and Virtual Machines/JIT engines.
Basically, JavaScript engines used to interpret the code they were running. Chrome introduced v8 that started producing native machine code for the JavaScript code (so-called method JIT (Just-In-Time) compilation), as does the apple nitro engine and now the IE9 engine and Firefox's JaegerMonkey engine. Firefox also has a TraceMonkey engine (introduced in 3.5) that looks for loops that are behaving in a predictable way that can then be optimised and executed by the CPU. The current Firefox engine uses a combination of the JaegerMonkey engine and the TraceMonkey engine, using some heuristics to decide when to use one or the other.
With the basic code generation in place, it is a matter of analysing code that is slow, extracting a test case for it, and optimising it.
Each of the circles on the graphs on arewefastyet correspond to commits that implement a certain optimisation or change (including chrome/v8 and safari/nitro changes). The regress-x86 and regress-x64 versions have a finer-grained look at the change history.
Hovering over these, you will see a black hover tooltip that contains various information. Contained here is a 'rev' line (i.e. revision) that has the id of the commit. Moving onto the underlined revision number provides you with a link to the commit in the corresponding code tracker.
For example, the big 5% speedup for firefox on the v8 benchmark is: tracemonkey - changeset - 52721:24749e6ae6e9 "Bug 581595 - Optimize creation of RegExp.prototype.exec's return value. r=lw."
In the changelist description for the firefox changes, you will see "bug 12345" or "b=12345". These correspond to the bug number in bugzilla.mozilla.org that is associated with the change. On the mozilla code tracker, these will appear as links that will take you to the bug in question.
On that bug, you will see the discussion of what went into that particular optimisation.
... broken your leg ... wearing high-healed shoes for the first time (or different sized heel) ... wearing rugby shoes or other similar shoes (e.g. with spikes to grip ice when climbing) ... walking on icy/slippery ground ... dancing/skipping while walking
there are many situations in which your gait can change
Re:And the world becomes productive once again
on
Facebook Is Down
·
· Score: 1
HTML5 supports a ping attribute on the anchor ('a') tag to notify a second url when the user clicks on the link if the user has enabled this feature (as browsers implementing this should have a configuration option to enable/disable it). This reduces the issues with url redirection on sites like google.com that use the information for analytical/advertising/tracking purposes provided that (a) all or most browsers adopt it, (b) users browse the web using one of these browsers and (c) these websites use the ping attribute in preference to other means when browsers expose it.
This does not solve the other main use of redirects: URL shortening. These sites provide short URLs that redirect you to the full URL when you navigate to them and are used by twitter to keep you within the 140 character limit. These are worse in many ways because:
a/ you don't know where you are navigating to (without using an addon or other utility);
b/ can be exploited in some cases (like tinyurl);
c/ break a lot of pages if the shortening URL site goes down (e.g. most of twitter's information would be useless if bit.ly went down);
d/ don't work well with archiving.
Yes, but only upto DirectX 9. Direct X 10 (and possibly bits of 11 too) are in the works, but it is slow going.
Just having the shader part of DX10/11 is not enough. It interacts with other Windows APIs like HWND (to create windows and process messages), HDC (to do some 2D drawing), Direct2D (for accelerated 2D rendering), DirectWrite (for accelerated text rendering), GDI+ (the XP-era acceleration APIs) and other APIs. Therefore, you need to pull in a lot of Windows APIs and behaviour to get games working properly.
Slashdot Mirror
- Major Grace Hopper ...
- Tim Berners Lee (the internet)
- Lady Ada Lovelace
- Charles Babbage
-
Especially when you have the current mix of HTML4 or XHTML, RDFa, SVG and MathML. So how do you advertise that the site you are using supports HTML+RDFa+SVG (or some other combination)?
Version numbers? Where we are going, we don't *need* version numbers!
Disabled users? Does your site work using lynx? Can it be used through a screen reader/assistive technologies?
I'm sorry, I don't speak either italic or bold! Do you speak small caps?
Then you have all the websites saying they are version XYZ, but are not valid against that version, or have some weird tag soup and expect it to work. A current issue is where Firefox renders some content bolder when using Win7 Direct2D if you have two bold styling attributes on a text section (e.g. GMail Apply button).
I've even seen some documents advertised as XHTML that don't parse as XML for a variety of reasons and are just HTML4 restyled as XHTML.
An upcoming revision will make HTML Multi-Freded.
World of KirbyCraft?
I find the awesome bar extremely useful. Especially if I can remember part of the title and not the url for something.
I haven't had a problem using Aero Snap with the new FF on Windows 7 to switch the window between screens as of yet. I've only been using it for ~3 days, so time will tell.
How about requiring patent holders to have a product that they sell in order to hold the patent.
This would get rid of the holding/shell companies that just buy patents for the purpose of sueing other companies to make their money. It would also mean that a company has to actually produce something that uses the patent in question first, instead of saying "hay, we could move into this direction in the future, so lets patent it to reduce the competition.".
#include "myclass.h"
#include "assert.h"
void test_bug123()
{
myclass a(10);
assert(a.value() == 10);
}
int main()
{
test_bug123();
}
---
How hard was it to create that test framework? You don't need something that is overly complex, just something that will pass if the test succeeds or fails if it doesn't. You can then improve the test cases/framework as you go along -- look at the Wine project for example. They didn't create http://test.winehq.org/data/ over night, it was built up gradually, starting with getting the tests running as part of the build and slowly defining a wine test API as needed.
Collecting metrics and reporting them should be done automatically, but not initially.
Tests can fails either due to the code under test, the test code or the environment.
Tests form a contract between teams (e.g. defining the way a protocol works, invalid and valid data with the expected results). They also serve as a form of documentation -- this is how you use this class; we need to support this corner case; this test checks that we don't regress this security bug.
Tests also document what your assumptions are -- e.g. does this method allow NULL pointer strings or not? One of my primary testing axioms is: assume nothing, assert everything. In the previous example, this means that there is an assumption that passing a NULL pointer to a function taking a string argument is valid; this axiom states that there needs to be an assertion/test case to check that the assumption holds.
When creating test cases, you need to define how the program will behave under certain circumstances. With sufficient coverage it then gives you the confidence that you haven't regressed anything.
But as always, start small and build up from there.
The article describes how a certain bug is recurring. Explain to your managers/team that this bug keeps cropping up (using evidence from the bug tracker). Write a test case for just that and include it as part of the build process. The issue should then be picked up on the developers machine, or on the daily/incremental build and not during the manual test cycle for a release. This can then be used as evidence to support adding tests for any bugs that are found. You can build it up from there.
Firefox 4.0b9pre (Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20101224 Firefox/4.0b9pre)
Score: 7203/50000
#1 -- 438 iterations, JS/engine: 10, DOM: 8, JS/mem: 3. Math: 1, JS/flow: 4, Graphics: 9
#2 -- 37 iterations, JS/engine: 5, DOM: 10, JS/mem: 0. Math: 2, JS/flow: 10, Graphics: 10
#3 -- 4208 iterations, JS/engine: 6, DOM: 0, JS/mem: 0. Math: 5, JS/flow: 10, Graphics: 1
Ubuntu 10.10 x64 (Gnome 2.32.0 / Kernel 2.6.35-22-generic) on a 4GB Intel i7 (Q720 @ 1.60GHz) with 1GB NVidia GeForce GT 230M using NVidia driver 260.19.06
Exactly. Going from interpreted to a (simplistic code generation) method jit is reasonably straightforward (assuming you know how compilers and assembly language works). From there, you can analyse the parts of the code generation that are slow and produce better code for them (e.g. using the INC operation for ++i instead of ADD 1). Then you need to start doing run-time hot-loop/hot-code optimisations on the fly which is what tracemonkey and this are doing. Getting this working is around the same complexity as the method jit, integrating the two is harder (when to run the optimiser, when to bail out). After that, you are into type inference/static analysis territory. Some experimental patches that the Firefox team are working on show ~35-40ms improvement on the spidermonkey tests. Other optimisations are possible from the inbuilt knowledge of the types.
There is no one single magic bullet to say do XYZ and the desktop usage will be super awesome responsive. That is because there are different situations and conditions that can affect performance.
This specific patch is to handle the case where running background tasks (updating, backup, searching the filesystem to index files and other things the computer can do) that eat up CPU causes the system to become unresponsive (especially on lower spec machines that don't have enough CPUs to handle moderately complex workloads). The reason the "make -j64" was used was not to say that this is great for developers or people building stuff in the background while watching video (which it will be), but to simulate the system under stress.
The return statement was "return;" i.e. a return statement that did not return anything. Looking at the other JavaScript engines, that line added at most 1ms, while with the IE engine it added 19ms. If the IE9 JS engine is handling this function in a super-efficient way that is not due to cheating, the optimisation must be highly sensitive to variance.
One way to check if the IE9 engine is doing some sort of special casing (e.g. hashing the text for the function) would be to change the name of a variable. This should not change the behaviour of the engine as it is the same code (there are no extra elements in the tree, like additional returns). If the IE9 engine is cheating, this should jump from 1ms to 20ms like the other variances. If it is an optimisation bug, the performance should be 1ms for both cases.
Parrot? That is a VM that can run a lot of different languages. You could always take one of the JavaScript engines -- V8, TraceMonkey+JaegerMonkey, JSC, etc. -- and adapt it to run python if you were so inclined. Also, if you like C# as a language, you could use Vala. And fossils C and C++ may be, but a lot of software is built with them including the major OSs, Web Browsers, Compilers and Virtual Machines/JIT engines.
Basically, JavaScript engines used to interpret the code they were running. Chrome introduced v8 that started producing native machine code for the JavaScript code (so-called method JIT (Just-In-Time) compilation), as does the apple nitro engine and now the IE9 engine and Firefox's JaegerMonkey engine. Firefox also has a TraceMonkey engine (introduced in 3.5) that looks for loops that are behaving in a predictable way that can then be optimised and executed by the CPU. The current Firefox engine uses a combination of the JaegerMonkey engine and the TraceMonkey engine, using some heuristics to decide when to use one or the other.
With the basic code generation in place, it is a matter of analysing code that is slow, extracting a test case for it, and optimising it.
Each of the circles on the graphs on arewefastyet correspond to commits that implement a certain optimisation or change (including chrome/v8 and safari/nitro changes). The regress-x86 and regress-x64 versions have a finer-grained look at the change history.
Hovering over these, you will see a black hover tooltip that contains various information. Contained here is a 'rev' line (i.e. revision) that has the id of the commit. Moving onto the underlined revision number provides you with a link to the commit in the corresponding code tracker.
For example, the big 5% speedup for firefox on the v8 benchmark is: tracemonkey - changeset - 52721:24749e6ae6e9 "Bug 581595 - Optimize creation of RegExp.prototype.exec's return value. r=lw."
In the changelist description for the firefox changes, you will see "bug 12345" or "b=12345". These correspond to the bug number in bugzilla.mozilla.org that is associated with the change. On the mozilla code tracker, these will appear as links that will take you to the bug in question.
On that bug, you will see the discussion of what went into that particular optimisation.
Don't you mean Web3D?
... broken your leg
... wearing high-healed shoes for the first time (or different sized heel)
... wearing rugby shoes or other similar shoes (e.g. with spikes to grip ice when climbing)
... walking on icy/slippery ground
... dancing/skipping while walking
there are many situations in which your gait can change
Press the refresh button a lot!
That annoys me too. The BBC iPlayer has this behaviour as well (presumably to track things like the Most Popular data).
HTML5 supports a ping attribute on the anchor ('a') tag to notify a second url when the user clicks on the link if the user has enabled this feature (as browsers implementing this should have a configuration option to enable/disable it). This reduces the issues with url redirection on sites like google.com that use the information for analytical/advertising/tracking purposes provided that (a) all or most browsers adopt it, (b) users browse the web using one of these browsers and (c) these websites use the ping attribute in preference to other means when browsers expose it.
This does not solve the other main use of redirects: URL shortening. These sites provide short URLs that redirect you to the full URL when you navigate to them and are used by twitter to keep you within the 140 character limit. These are worse in many ways because:
a/ you don't know where you are navigating to (without using an addon or other utility);
b/ can be exploited in some cases (like tinyurl);
c/ break a lot of pages if the shortening URL site goes down (e.g. most of twitter's information would be useless if bit.ly went down);
d/ don't work well with archiving.
Yes, but only upto DirectX 9. Direct X 10 (and possibly bits of 11 too) are in the works, but it is slow going.
Just having the shader part of DX10/11 is not enough. It interacts with other Windows APIs like HWND (to create windows and process messages), HDC (to do some 2D drawing), Direct2D (for accelerated 2D rendering), DirectWrite (for accelerated text rendering), GDI+ (the XP-era acceleration APIs) and other APIs. Therefore, you need to pull in a lot of Windows APIs and behaviour to get games working properly.