<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/go-git.git/src/runtime/export_test.go, branch dev.inline</title>
<subtitle>github.com: golang/go
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/'/>
<entry>
<title>cmd/compile: do more type conversion inline</title>
<updated>2016-11-02T21:33:03+00:00</updated>
<author>
<name>Keith Randall</name>
<email>khr@golang.org</email>
</author>
<published>2016-10-28T18:37:45+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=688995d1e91fcc36ac33bf34d6303e935d1b0a70'/>
<id>688995d1e91fcc36ac33bf34d6303e935d1b0a70</id>
<content type='text'>
The code to do the conversion is smaller than the
call to the runtime.
The 1-result asserts need to call panic if they fail, but that
code is out of line.

The only conversions left in the runtime are those which
might allocate and those which might need to generate an itab.

Given the following types:
  type E interface{}
  type I interface { foo() }
  type I2 iterface { foo(); bar() }
  type Big [10]int
  func (b Big) foo() { ... }

This CL inlines the following conversions:

was assertE2T
  var e E = ...
  b := i.(Big)
was assertE2T2
  var e E = ...
  b, ok := i.(Big)
was assertI2T
  var i I = ...
  b := i.(Big)
was assertI2T2
  var i I = ...
  b, ok := i.(Big)
was assertI2E
  var i I = ...
  e := i.(E)
was assertI2E2
  var i I = ...
  e, ok := i.(E)

These are the remaining runtime calls:

convT2E:
  var b Big = ...
  var e E = b
convT2I:
  var b Big = ...
  var i I = b
convI2I:
  var i2 I2 = ...
  var i I = i2
assertE2I:
  var e E = ...
  i := e.(I)
assertE2I2:
  var e E = ...
  i, ok := e.(I)
assertI2I:
  var i I = ...
  i2 := i.(I2)
assertI2I2:
  var i I = ...
  i2, ok := i.(I2)

Fixes #17405
Fixes #8422

Change-Id: Ida2367bf8ce3cd2c6bb599a1814f1d275afabe21
Reviewed-on: https://go-review.googlesource.com/32313
Run-TryBot: Keith Randall &lt;khr@golang.org&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The code to do the conversion is smaller than the
call to the runtime.
The 1-result asserts need to call panic if they fail, but that
code is out of line.

The only conversions left in the runtime are those which
might allocate and those which might need to generate an itab.

Given the following types:
  type E interface{}
  type I interface { foo() }
  type I2 iterface { foo(); bar() }
  type Big [10]int
  func (b Big) foo() { ... }

This CL inlines the following conversions:

was assertE2T
  var e E = ...
  b := i.(Big)
was assertE2T2
  var e E = ...
  b, ok := i.(Big)
was assertI2T
  var i I = ...
  b := i.(Big)
was assertI2T2
  var i I = ...
  b, ok := i.(Big)
was assertI2E
  var i I = ...
  e := i.(E)
was assertI2E2
  var i I = ...
  e, ok := i.(E)

These are the remaining runtime calls:

convT2E:
  var b Big = ...
  var e E = b
convT2I:
  var b Big = ...
  var i I = b
convI2I:
  var i2 I2 = ...
  var i I = i2
assertE2I:
  var e E = ...
  i := e.(I)
assertE2I2:
  var e E = ...
  i, ok := e.(I)
assertI2I:
  var i I = ...
  i2 := i.(I2)
assertI2I2:
  var i I = ...
  i2, ok := i.(I2)

Fixes #17405
Fixes #8422

Change-Id: Ida2367bf8ce3cd2c6bb599a1814f1d275afabe21
Reviewed-on: https://go-review.googlesource.com/32313
Run-TryBot: Keith Randall &lt;khr@golang.org&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: improve atoi implementation</title>
<updated>2016-11-01T14:04:39+00:00</updated>
<author>
<name>Martin Möhrmann</name>
<email>martisch@uos.de</email>
</author>
<published>2016-10-29T23:54:19+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=d7b34d5f29324d77fad572676f0ea139556235e0'/>
<id>d7b34d5f29324d77fad572676f0ea139556235e0</id>
<content type='text'>
- Adds overflow checks
- Adds parsing of negative integers
- Adds boolean return value to signal parsing errors
- Adds atoi32 for parsing of integers that fit in an int32
- Adds tests

Handling of errors to provide error messages
at the call sites is left to future CLs.

Updates #17718

Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0
Reviewed-on: https://go-review.googlesource.com/32390
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Adds overflow checks
- Adds parsing of negative integers
- Adds boolean return value to signal parsing errors
- Adds atoi32 for parsing of integers that fit in an int32
- Adds tests

Handling of errors to provide error messages
at the call sites is left to future CLs.

Updates #17718

Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0
Reviewed-on: https://go-review.googlesource.com/32390
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime, cmd/compile: rename memclr -&gt; memclrNoHeapPointers</title>
<updated>2016-10-28T18:20:33+00:00</updated>
<author>
<name>Austin Clements</name>
<email>austin@google.com</email>
</author>
<published>2016-10-17T22:41:56+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=87e48c5afdcf5e01bb2b7f51b7643e8901f4b7f9'/>
<id>87e48c5afdcf5e01bb2b7f51b7643e8901f4b7f9</id>
<content type='text'>
Since barrier-less memclr is only safe in very narrow circumstances,
this commit renames memclr to avoid accidentally calling memclr on
typed memory. This can cause subtle, non-deterministic bugs, so it's
worth some effort to prevent. In the near term, this will also prevent
bugs creeping in from any concurrent CLs that add calls to memclr; if
this happens, whichever patch hits master second will fail to compile.

This also adds the other new memclr variants to the compiler's
builtin.go to minimize the churn on that binary blob. We'll use these
in future commits.

Updates #17503.

Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca
Reviewed-on: https://go-review.googlesource.com/31369
Reviewed-by: Keith Randall &lt;khr@golang.org&gt;
Reviewed-by: Rick Hudson &lt;rlh@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since barrier-less memclr is only safe in very narrow circumstances,
this commit renames memclr to avoid accidentally calling memclr on
typed memory. This can cause subtle, non-deterministic bugs, so it's
worth some effort to prevent. In the near term, this will also prevent
bugs creeping in from any concurrent CLs that add calls to memclr; if
this happens, whichever patch hits master second will fail to compile.

This also adds the other new memclr variants to the compiler's
builtin.go to minimize the churn on that binary blob. We'll use these
in future commits.

Updates #17503.

Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca
Reviewed-on: https://go-review.googlesource.com/31369
Reviewed-by: Keith Randall &lt;khr@golang.org&gt;
Reviewed-by: Rick Hudson &lt;rlh@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: consolidate h_allspans and mheap_.allspans</title>
<updated>2016-10-25T22:32:42+00:00</updated>
<author>
<name>Austin Clements</name>
<email>austin@google.com</email>
</author>
<published>2016-10-04T19:51:31+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=4d6207790b2f08daa00d2a7a67854a159ab2f601'/>
<id>4d6207790b2f08daa00d2a7a67854a159ab2f601</id>
<content type='text'>
These are two ways to refer to the allspans array that hark back to
when the runtime was split between C and Go. Clean this up by making
mheap_.allspans a slice and eliminating h_allspans.

Change-Id: Ic9360d040cf3eb590b5dfbab0b82e8ace8525610
Reviewed-on: https://go-review.googlesource.com/30530
Run-TryBot: Austin Clements &lt;austin@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Rick Hudson &lt;rlh@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are two ways to refer to the allspans array that hark back to
when the runtime was split between C and Go. Clean this up by making
mheap_.allspans a slice and eliminating h_allspans.

Change-Id: Ic9360d040cf3eb590b5dfbab0b82e8ace8525610
Reviewed-on: https://go-review.googlesource.com/30530
Run-TryBot: Austin Clements &lt;austin@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Rick Hudson &lt;rlh@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: remove maxstring</title>
<updated>2016-09-08T15:57:01+00:00</updated>
<author>
<name>Martin Möhrmann</name>
<email>martisch@uos.de</email>
</author>
<published>2016-09-06T08:38:16+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=252093f1203da13e1face4f71141ac75482ccf11'/>
<id>252093f1203da13e1face4f71141ac75482ccf11</id>
<content type='text'>
Before this CL the runtime prevented printing of overlong strings with the print
function when the length of the string was determined to be corrupted.
Corruption was checked by comparing the string size against the limit
which was stored in maxstring.

However maxstring was not updated everywhere were go strings were created
e.g. for string constants during compile time. Thereby the check for maximum
string length prevented the printing of some valid strings.

The protection maxstring provided did not warrant the bookkeeping
and global synchronization needed to keep maxstring updated to the
correct limit everywhere.

Fixes #16999

Change-Id: I62cc2f4362f333f75b77f199ce1a71aac0ff7aeb
Reviewed-on: https://go-review.googlesource.com/28813
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this CL the runtime prevented printing of overlong strings with the print
function when the length of the string was determined to be corrupted.
Corruption was checked by comparing the string size against the limit
which was stored in maxstring.

However maxstring was not updated everywhere were go strings were created
e.g. for string constants during compile time. Thereby the check for maximum
string length prevented the printing of some valid strings.

The protection maxstring provided did not warrant the bookkeeping
and global synchronization needed to keep maxstring updated to the
correct limit everywhere.

Fixes #16999

Change-Id: I62cc2f4362f333f75b77f199ce1a71aac0ff7aeb
Reviewed-on: https://go-review.googlesource.com/28813
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: fix CPU underutilization</title>
<updated>2016-05-03T10:06:32+00:00</updated>
<author>
<name>Dmitry Vyukov</name>
<email>dvyukov@google.com</email>
</author>
<published>2016-03-18T15:34:11+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=fcd7c02c70a110c6f6dbac30ad4ac3eb435ac3fd'/>
<id>fcd7c02c70a110c6f6dbac30ad4ac3eb435ac3fd</id>
<content type='text'>
Runqempty is a critical predicate for scheduler. If runqempty spuriously
returns true, then scheduler can fail to schedule arbitrary number of
runnable goroutines on idle Ps for arbitrary long time. With the addition
of runnext runqempty predicate become broken (can spuriously return true).
Consider that runnext is not nil and the main array is empty. Runqempty
observes that the array is empty, then it is descheduled for some time.
Then queue owner pushes another element to the queue evicting runnext
into the array. Then queue owner pops runnext. Then runqempty resumes
and observes runnext is nil and returns true. But there were no point
in time when the queue was empty.

Fix runqempty predicate to not return true spuriously.

Change-Id: Ifb7d75a699101f3ff753c4ce7c983cf08befd31e
Reviewed-on: https://go-review.googlesource.com/20858
Reviewed-by: Austin Clements &lt;austin@google.com&gt;
Run-TryBot: Dmitry Vyukov &lt;dvyukov@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Runqempty is a critical predicate for scheduler. If runqempty spuriously
returns true, then scheduler can fail to schedule arbitrary number of
runnable goroutines on idle Ps for arbitrary long time. With the addition
of runnext runqempty predicate become broken (can spuriously return true).
Consider that runnext is not nil and the main array is empty. Runqempty
observes that the array is empty, then it is descheduled for some time.
Then queue owner pushes another element to the queue evicting runnext
into the array. Then queue owner pops runnext. Then runqempty resumes
and observes runnext is nil and returns true. But there were no point
in time when the queue was empty.

Fix runqempty predicate to not return true spuriously.

Change-Id: Ifb7d75a699101f3ff753c4ce7c983cf08befd31e
Reviewed-on: https://go-review.googlesource.com/20858
Reviewed-by: Austin Clements &lt;austin@google.com&gt;
Run-TryBot: Dmitry Vyukov &lt;dvyukov@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: fix pagesInUse accounting</title>
<updated>2016-04-04T15:33:26+00:00</updated>
<author>
<name>Austin Clements</name>
<email>austin@google.com</email>
</author>
<published>2016-03-29T16:28:24+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=61f56e925ea97b82090d30f05cde3cd7a2668ed0'/>
<id>61f56e925ea97b82090d30f05cde3cd7a2668ed0</id>
<content type='text'>
When we grow the heap, we create a temporary "in use" span for the
memory acquired from the OS and then free that span to link it into
the heap. Hence, we (1) increase pagesInUse when we make the temporary
span so that (2) freeing the span will correctly decrease it.

However, currently step (1) increases pagesInUse by the number of
pages requested from the heap, while step (2) decreases it by the
number of pages requested from the OS (the size of the temporary
span). These aren't necessarily the same, since we round up the number
of pages we request from the OS, so steps 1 and 2 don't necessarily
cancel out like they're supposed to. Over time, this can add up and
cause pagesInUse to underflow and wrap around to 2^64. The garbage
collector computes the sweep ratio from this, so if this happens, the
sweep ratio becomes effectively infinite, causing the first allocation
on each P in a sweep cycle to sweep the entire heap. This makes
sweeping effectively STW.

Fix this by increasing pagesInUse in step 1 by the number of pages
requested from the OS, so that the two steps correctly cancel out. We
add a test that checks that the running total matches the actual state
of the heap.

Fixes #15022. For 1.6.x.

Change-Id: Iefd9d6abe37d0d447cbdbdf9941662e4f18eeffc
Reviewed-on: https://go-review.googlesource.com/21280
Run-TryBot: Austin Clements &lt;austin@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Russ Cox &lt;rsc@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we grow the heap, we create a temporary "in use" span for the
memory acquired from the OS and then free that span to link it into
the heap. Hence, we (1) increase pagesInUse when we make the temporary
span so that (2) freeing the span will correctly decrease it.

However, currently step (1) increases pagesInUse by the number of
pages requested from the heap, while step (2) decreases it by the
number of pages requested from the OS (the size of the temporary
span). These aren't necessarily the same, since we round up the number
of pages we request from the OS, so steps 1 and 2 don't necessarily
cancel out like they're supposed to. Over time, this can add up and
cause pagesInUse to underflow and wrap around to 2^64. The garbage
collector computes the sweep ratio from this, so if this happens, the
sweep ratio becomes effectively infinite, causing the first allocation
on each P in a sweep cycle to sweep the entire heap. This makes
sweeping effectively STW.

Fix this by increasing pagesInUse in step 1 by the number of pages
requested from the OS, so that the two steps correctly cancel out. We
add a test that checks that the running total matches the actual state
of the heap.

Fixes #15022. For 1.6.x.

Change-Id: Iefd9d6abe37d0d447cbdbdf9941662e4f18eeffc
Reviewed-on: https://go-review.googlesource.com/21280
Run-TryBot: Austin Clements &lt;austin@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Russ Cox &lt;rsc@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: use unaligned loads on ppc64</title>
<updated>2016-03-18T19:21:53+00:00</updated>
<author>
<name>Keith Randall</name>
<email>khr@golang.org</email>
</author>
<published>2016-03-17T20:28:04+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=15ea61146e49b91b84b7b3a3096b13ddfb4cc01f'/>
<id>15ea61146e49b91b84b7b3a3096b13ddfb4cc01f</id>
<content type='text'>
benchmark                      old ns/op     new ns/op     delta
BenchmarkAlignedLoad-160       8.67          7.42          -14.42%
BenchmarkUnalignedLoad-160     8.63          7.37          -14.60%

Change-Id: Id4609d7b4038c4d2ec332efc4fe6f1adfb61b82b
Reviewed-on: https://go-review.googlesource.com/20812
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
benchmark                      old ns/op     new ns/op     delta
BenchmarkAlignedLoad-160       8.67          7.42          -14.42%
BenchmarkUnalignedLoad-160     8.63          7.37          -14.60%

Change-Id: Id4609d7b4038c4d2ec332efc4fe6f1adfb61b82b
Reviewed-on: https://go-review.googlesource.com/20812
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>runtime: move testSchedLocalQueue* to export_test</title>
<updated>2016-03-13T00:34:58+00:00</updated>
<author>
<name>Emmanuel Odeke</name>
<email>emm.odeke@gmail.com</email>
</author>
<published>2016-03-12T23:41:08+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=6dfcc336c520efc85c5aab06ea9d6c45d0aad214'/>
<id>6dfcc336c520efc85c5aab06ea9d6c45d0aad214</id>
<content type='text'>
Move functions testSchedLocalQueueLocal and testSchedLocalQueueSteal
from proc.go to export_test.go, the only site that they are used.

Fixes #14796

Change-Id: I16b6fa4a13835eab33f66a2c2e87a5f5c79b7bd3
Reviewed-on: https://go-review.googlesource.com/20640
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move functions testSchedLocalQueueLocal and testSchedLocalQueueSteal
from proc.go to export_test.go, the only site that they are used.

Fixes #14796

Change-Id: I16b6fa4a13835eab33f66a2c2e87a5f5c79b7bd3
Reviewed-on: https://go-review.googlesource.com/20640
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>all: make copyright headers consistent with one space after period</title>
<updated>2016-03-01T23:34:33+00:00</updated>
<author>
<name>Brad Fitzpatrick</name>
<email>bradfitz@golang.org</email>
</author>
<published>2016-03-01T22:57:46+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/go-git.git/commit/?id=519474451a44b861e54466998a893a173bd54c4b'/>
<id>519474451a44b861e54466998a893a173bd54c4b</id>
<content type='text'>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.

Go policy has been single space after periods in comments for some time.

The copyright header template at:

    https://golang.org/doc/contribute.html#copyright

also uses a single space.

Make them all consistent.

Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Matthew Dempsky &lt;mdempsky@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.

Go policy has been single space after periods in comments for some time.

The copyright header template at:

    https://golang.org/doc/contribute.html#copyright

also uses a single space.

Make them all consistent.

Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Matthew Dempsky &lt;mdempsky@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
