Running test/garbage/parser.out.
On a 4-core Lenovo X201s (Linux):
31.12u 0.60s 31.74r 1 cpu, no atomics
32.27u 0.58s 32.86r 1 cpu, atomic instructions
33.04u 0.83s 27.47r 2 cpu
On a 16-core Xeon (Linux):
33.08u 0.65s 33.80r 1 cpu, no atomics
34.87u 1.12s 29.60r 2 cpu
36.00u 1.87s 28.43r 3 cpu
36.46u 2.34s 27.10r 4 cpu
38.28u 3.85s 26.92r 5 cpu
37.72u 5.25s 26.73r 6 cpu
39.63u 7.11s 26.95r 7 cpu
39.67u 8.10s 26.68r 8 cpu
On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5):
39.43u 1.45s 41.27r 1 cpu, no atomics
43.98u 2.95s 38.69r 2 cpu
On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1):
48.81u 2.12s 51.76r 1 cpu, no atomics
57.15u 4.72s 51.54r 2 cpu
The handoff algorithm is really only good for two cores.
Beyond that we will need to so something more sophisticated,
like have each core hand off to the next one, around a circle.
Even so, the code is a good checkpoint; for now we'll limit the
number of gc procs to at most 2.
R=dvyukov
CC=golang-dev
https://golang.org/cl/4641082
This is a possible optimization. I'm not sure the complexity is worth it.
The new benchmark in escape_test is 46us without and 35us with the optimization.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5168041
This removes a few cases from escapeAction and clarifies the
responsibilities of urlFilter which no longer does any
escaping or normalization. It is now solely a filter.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5162043
The letter is a holdover from C and unnecessary in Go.
Gofix module included.
Fixes#2306.
R=golang-dev, gri, dsymonds
CC=golang-dev
https://golang.org/cl/5158043
HTML5 allows embedded SVG and MathML.
Code searches show SVG is used for graphing.
This changes transition to deal with constructs like
<svg xmlns:xlink="http://www.w3.org/1999/xlink">
It changes attr and clients to call a single function that combines
the name lookup and "on" prefix check to determine an attribute
value type given an attribute name.
That function uses heuristics to recognize that
xlink:href and svg:href
have URL content, and that data-url is likely contains URL content,
since "javascript:" injection is such a problem.
I did a code search over a closure templates codebase to determine
patterns of custom attribute usage. I did something like
$ find . -name \*.soy | \
xargs egrep perl -ne 'while (s/\b((data-|\w+:)\w+)\s*=//) { print "$1\n"; }' | \
sort | uniq
to produce the list at the bottom.
Filtering that by egrep -i 'src|url|uri' produces
data-docConsumptionUri
data-docIconUrl
data-launchUrl
data-lazySrc
data-pageUrl
data-shareurl
data-suggestServerUrl
data-tweetUrl
g:secondaryurls
g:url
which seem to match all the ones that are likely URL content.
There are some short words that match that heuristic, but I still think it decent since
any custom attribute that has a numeric or enumerated keyword value will be unaffected by
the URL assumption.
Counterexamples from /usr/share/dict:
during, hourly, maturity, nourish, purloin, security, surly
Custom attributes present in existing closure templates codebase:
buzz:aid
data-a
data-action
data-actor
data-allowEqualityOps
data-analyticsId
data-bid
data-c
data-cartId
data-categoryId
data-cid
data-command
data-count
data-country
data-creativeId
data-cssToken
data-dest
data-docAttribution
data-docConsumptionUri
data-docCurrencyCode
data-docIconUrl
data-docId
data-docPrice
data-docPriceMicros
data-docTitle
data-docType
data-docid
data-email
data-entityid
data-errorindex
data-f
data-feature
data-fgid
data-filter
data-fireEvent
data-followable
data-followed
data-hashChange
data-height
data-hover
data-href
data-id
data-index
data-invitable
data-isFree
data-isPurchased
data-jid
data-jumpid
data-launchUrl
data-lazySrc
data-listType
data-maxVisiblePages
data-name
data-nid
data-nodeid
data-numItems
data-numPerPage
data-offerType
data-oid
data-opUsesEquality
data-overflowclass
data-packageName
data-pageId
data-pageUrl
data-pos
data-priceBrief
data-profileIds
data-query
data-rating
data-ref
data-rentalGrantPeriodDays
data-rentalactivePeriodHours
data-reviewId
data-role
data-score
data-shareurl
data-showGeLe
data-showLineInclude
data-size
data-sortval
data-suggestServerType
data-suggestServerUrl
data-suggestionIndex
data-tabBarId
data-tabBarIndex
data-tags
data-target
data-textColor
data-theme
data-title
data-toggletarget
data-tooltip
data-trailerId
data-transactionId
data-transition
data-ts
data-tweetContent
data-tweetUrl
data-type
data-useAjax
data-value
data-width
data-x
dm:index
dm:type
g:aspects
g:decorateusingsecondary
g:em
g:entity
g:groups
g:id
g:istoplevel
g:li
g:numresults
g:oid
g:parentId
g:pl
g:pt
g:rating_override
g:secondaryurls
g:sortby
g:startindex
g:target
g:type
g:url
g:value
ga:barsize
ga:css
ga:expandAfterCharsExceed
ga:initialNumRows
ga:nocancelicon
ga:numRowsToExpandTo
ga:type
ga:unlockwhenrated
gw:address
gw:businessname
gw:comment
gw:phone
gw:source
ng:controller
xlink:href
xml:lang
xmlns:atom
xmlns:dc
xmlns:jstd
xmlns:ng
xmlns:og
xmlns:webstore
xmlns:xlink
R=nigeltao
CC=golang-dev
https://golang.org/cl/5119041
The normalization that prevents element name and comment injection in
<{{.}}
by converting it to
<{{.}}
breaks
<!DOCTYPE html>
Instead of splitting states to have a start of document state and a text
state, I whitelist <!DOCTYPE.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5131051
*** This is a design review, not a code review. ***
Feel free to reply to the mail instead of picking out
individual lines to comment on in Rietveld.
This command, go, will replace both gomake/make and goinstall.
Make will stick around only for building our C commands
and perhaps package runtime.
In normal use while developing you'd run commands like
go compile
go test
go clean
go install
which apply to the package in the current directory.
To operate on code written by others, you add an explicit
package path:
go get gopath.googlecode.com/hg/oauth
go test gopath.googlecode.com/hg/oauth
The script.txt file is a script showing the output of
the various help commands that the command has.
(Right now, all the command can do is print help messages.)
R=golang-dev, bradfitz, kevlar, r, edsrzf, gri, adg, rogpeppe, r
CC=golang-dev
https://golang.org/cl/5019045
This is just a new API to do many replacements at once.
While the point of this API is to be faster than doing replacements one
at a time, the implementation in this CL has the optimizations removed
and may actually be slower.
Future CLs will bring back & add optimizations.
R=r, rsc, rogpeppe
CC=golang-dev
https://golang.org/cl/5081042
In
{{$x := . | foo}}
{{$x}}
the first action is a variable assignment that contributes
nothing to the output while the first is a use that needs
to be escaped.
This CL fixes escapeAction to distinguish assignments from
interpolations and to only modify interpolations.
R=nigeltao, r
CC=golang-dev
https://golang.org/cl/5143048
CL 5040041 (https://golang.org/cl/5040041)
changed the use of []int to []int32 internally so
that encoding/binary could be used. This is no
longer needed (gobs can encode ints), and using
[]int is more in sync w/ the semantics of the data
structure (the index elements are indices which are
ints). Changing it back.
R=r
CC=golang-dev
https://golang.org/cl/5141049
Does some TODOs and changes the term "div" in an error message
to "division" to avoid confusion with "<div>".
R=nigeltao, r
CC=golang-dev
https://golang.org/cl/5141047
Case-insensitive strcmp without using ToLower.
(Using ToLower is not always correct, and it allocates.)
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5143044
Also work around Mercurial issue 3023.
If anyone has local changes in their repo (due to
patch queues or whatever) stop them from leaking
into the main repository.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5144043
The 512 MB array causes load delays on some systems.
Now that we have recover, we can do all the tests in
one binary, so that the delay is incurred just once.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5142044
Alex Brainman reports that this is the only test
that keeps us from running test/run.
R=alex.brainman, lucio.dere, bradfitz, hectorchu
CC=golang-dev
https://golang.org/cl/4777043
This makes sure that all JS newlines are encoded in JSON.
It also moots a TODO about possibly escaping supplemental codepoints.
I served:
Content-Type: text/javascript;charset=UTF-8
var s = "%s";
document.write("<p>", s, "</p><ol>");
for (var i = 0; i < s.length; i++) {
document.write("<li>", s.charCodeAt(i).toString(16), "</li>");
}
document.write("</l>");
where %s was replaced with bytes "\xf0\x9d\x84\x9e" to test
straight UTF-8 instead of encoding surrogates separately.
Recent Firefox, Chrome, and Safari all decoded it properly.
I have yet to try it on IE or older versions.
R=nigeltao
CC=golang-dev
https://golang.org/cl/5129042
