Home » Uncategories » Moses-support Digest, Vol 111, Issue 26

Moses-support Digest, Vol 111, Issue 26

Send Moses-support mailing list submissions to
moses-support@mit.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu

You can reach the person managing the list at
moses-support-owner@mit.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."


Today's Topics:

1. Re: Error when running moses server with sample code
(Ulrich Germann)
2. Re: Error when running moses server with sample code
(Lane Schwartz)


----------------------------------------------------------------------

Message: 1
Date: Tue, 12 Jan 2016 18:43:18 +0000
From: Ulrich Germann <ulrich.germann@gmail.com>
Subject: Re: [Moses-support] Error when running moses server with
sample code
To: Lane Schwartz <dowobeha@gmail.com>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Barry Haddow
<bhaddow@staffmail.ed.ac.uk>
Message-ID:
<CAHQSRUptjsJKW5M188YGMxNifhKe0Lu_y5Bpi+3_bBSPnFU1dw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Fixed, but chances are you won't like the output. --report-all-factors
appears to be a legacy debugging switch that dumps the value of all factor
slots provided by moses (the maximum number of factors is set at compile
time), regardless of whether or not they are used by the system. Normal
users of Moses are unlikely to have any use for it. With
--report-all-factors, the output for a standard compile looks like this:

Do|UNK|UNK|UNK you|UNK|UNK|UNK really|UNK|UNK|UNK want|UNK|UNK|UNK
that|UNK|UNK|UNK ?|UNK|UNK|UNK

- Uli


On Tue, Jan 12, 2016 at 4:04 PM, Lane Schwartz <dowobeha@gmail.com> wrote:

> Looks like this is not specific to mosesserver. Same error occurs when
> running moses with --report-all-factors.
>
> On Tue, Jan 12, 2016 at 9:59 AM, Lane Schwartz <dowobeha@gmail.com> wrote:
>
>> Never mind. I figured out how.
>>
>> (gdb) bt
>>> #0 0x00007ffff5d905e9 in raise () from /lib64/libc.so.6
>>> #1 0x00007ffff5d91cf8 in abort () from /lib64/libc.so.6
>>> #2 0x00007ffff68b09b5 in __gnu_cxx::__verbose_terminate_handler() ()
>>> from /lib64/libstdc++.so.6
>>> #3 0x00007ffff68ae926 in ?? () from /lib64/libstdc++.so.6
>>> #4 0x00007ffff68ae953 in std::terminate() () from /lib64/libstdc++.so.6
>>> #5 0x00007ffff68aeb73 in __cxa_throw () from /lib64/libstdc++.so.6
>>> #6 0x000000000073a695 in Moses::Manager::OutputSurface
>>> (this=0x7ffe4e9e6980, out=..., edge=..., recursive=false) at
>>> moses/Manager.cpp:1726
>>> Python Exception <type 'exceptions.IndexError'> list index out of range:
>>> #7 0x000000000088c6f3 in
>>> MosesServer::TranslationRequest::pack_hypothesis (this=0x1848b40,
>>> manager=..., edges=std::vector of length 13, capacity 16 = {...},
>>> key="text", dest=std::map with 0 elements) at
>>> moses/server/TranslationRequest.cpp:358
>>> Python Exception <type 'exceptions.IndexError'> list index out of range:
>>> #8 0x000000000088d02c in
>>> MosesServer::TranslationRequest::pack_hypothesis (this=0x1848b40,
>>> manager=..., h=0x0, key="text", dest=std::map with 0 elements) at
>>> moses/server/TranslationRequest.cpp:393
>>> #9 0x000000000088d128 in
>>> MosesServer::TranslationRequest::run_phrase_decoder (this=0x1848b40) at
>>> moses/server/TranslationRequest.cpp:403
>>> #10 0x0000000000888483 in MosesServer::TranslationRequest::Run
>>> (this=0x1848b40) at moses/server/TranslationRequest.cpp:70
>>> #11 0x00000000006d4b9e in Moses::ThreadPool::Execute (this=0x18ae028) at
>>> moses/ThreadPool.cpp:58
>>> #12 0x00000000006d7071 in boost::_mfi::mf0<void,
>>> Moses::ThreadPool>::operator() (this=0x189a398, p=0x18ae028) at
>>> /usr/local/include/boost/bind/mem_fn_template.hpp:49
>>> #13 0x00000000006d6fd4 in
>>> boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
>>> >::operator()<boost::_mfi::mf0<void, Moses::ThreadPool>, boost::_bi::list0>
>>> (this=0x189a3a8, f=..., a=...) at /usr/local/include/boost/bind/bind.hpp:255
>>> #14 0x00000000006d6f83 in boost::_bi::bind_t<void,
>>> boost::_mfi::mf0<void, Moses::ThreadPool>,
>>> boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*> > >::operator()
>>> (this=0x189a398) at /usr/local/include/boost/bind/bind_template.hpp:20
>>> #15 0x00000000006d6f48 in
>>> boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void,
>>> Moses::ThreadPool>, boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
>>> > > >::run (this=0x189a1e0) at
>>> /usr/local/include/boost/thread/detail/thread.hpp:116
>>> #16 0x000000000098d78f in thread_proxy ()
>>> #17 0x00007ffff6123df3 in start_thread () from /lib64/libpthread.so.0
>>> #18 0x00007ffff5e511ed in clone () from /lib64/libc.so.
>>
>>
>> The error occurs when the python client sets "report-all-factors":"true".
>>
>>
>>
>> On Tue, Jan 12, 2016 at 9:47 AM, Lane Schwartz <dowobeha@gmail.com>
>> wrote:
>>
>>> I compiled with variant=debug. What else do I need to do to get a stack
>>> trace?
>>>
>>> On Tue, Jan 12, 2016 at 3:16 AM, Barry Haddow <
>>> bhaddow@staffmail.ed.ac.uk> wrote:
>>>
>>>> Hi Lane
>>>>
>>>> Can you get a stack trace to see which line the message is coming from?
>>>> That error message is repeated in a few files.
>>>>
>>>> From looking at the code, I'd guess that the OutputFactorOrder is not
>>>> being initialised correctly. Possibly due to the refactoring of the config
>>>> code. Does your example work with an earlier version of Moses?
>>>>
>>>> cheers - Barry
>>>>
>>>>
>>>> On 11/01/16 21:43, Lane Schwartz wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm trying out mosesserver for the first time. I have a config file for
>>>> fr-en that uses a smallish TM and LM, that work fine when run with Moses.
>>>> When I try running the same config using mosesserver, and then use the
>>>> sample Perl or Python code in contrib/server, mosesserver dies with the
>>>> following error:
>>>>
>>>> Defined parameters (per moses.ini or switch):
>>>>> config: moses.tuned.ini.2.probing.noLexRO
>>>>> cube-pruning-pop-limit: 400
>>>>> distortion-limit: 6
>>>>> feature: UnknownWordPenalty WordPenalty PhrasePenalty ProbingPT
>>>>> name=TranslationModel0 num-features=4
>>>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>>>> table-limit=20 Distortion KENLM lazyken=1 name=LM0 factor=0
>>>>> path=europarl.kenlm order=5
>>>>> input-factors: 0
>>>>> mapping: 0 T 0
>>>>> max-phrase-length: 20
>>>>> n-best-list: nbest.txt 111
>>>>> output-hypo-score: 1
>>>>> search-algorithm: 0
>>>>> server:
>>>>> threads: 1
>>>>> weight: Distortion0= 0.0222366 LM0= 0.0834208 WordPenalty0= -0.0654626
>>>>> PhrasePenalty0= 0.0220686 TranslationModel0= 0.0520176 0.0415173
>>>>> 0.124293 0.027126 UnknownWordPenalty0= 1
>>>>>
>>>>> line=UnknownWordPenalty
>>>>> FeatureFunction: UnknownWordPenalty0 start: 0 end: 0
>>>>> line=WordPenalty
>>>>> FeatureFunction: WordPenalty0 start: 1 end: 1
>>>>> line=PhrasePenalty
>>>>> FeatureFunction: PhrasePenalty0 start: 2 end: 2
>>>>> line=ProbingPT name=TranslationModel0 num-features=4
>>>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>>>> table-limit=20
>>>>> FeatureFunction: TranslationModel0 start: 3 end: 6
>>>>> line=Distortion
>>>>> FeatureFunction: Distortion0 start: 7 end: 7
>>>>> line=KENLM lazyken=1 name=LM0 factor=0 path=europarl.kenlm order=5
>>>>> FeatureFunction: LM0 start: 8 end: 8
>>>>> Loading UnknownWordPenalty0
>>>>> Loading WordPenalty0
>>>>> Loading PhrasePenalty0
>>>>> Loading Distortion0
>>>>> Loading LM0
>>>>> Loading TranslationModel0
>>>>> Initialized successfully!
>>>>>
>>>>> RUN SERVER at pid 1733327039
>>>>> [moses/server/Server.cpp:49] Listening on port 8080
>>>>> [moses/server/TranslationRequest.cpp:281] Input: il a souhait? que la
>>>>> pr?sidence trace ? nice le chemin pour l' avenir .
>>>>> Translating: il a souhait? que la pr?sidence trace ? nice le chemin
>>>>> pour l' avenir .
>>>>>
>>>>> Line 0: Collecting options took 0.038 seconds at moses/Manager.cpp
>>>>> Line 141
>>>>> Line 0: Search took 0.674 seconds
>>>>> terminate called after throwing an instance of 'util::Exception'
>>>>> what(): No factor 1 at position 0
>>>>
>>>>
>>>> Any idea what's going on here? I'm using a basic single-factor model,
>>>> so I don't get why it would be complaining about factors. I'm using the
>>>> latest moses from git.
>>>>
>>>> Thanks,
>>>> Lane
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>>>
>>>>
>>>>
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>>
>>>>
>>>
>>>
>>> --
>>> When a place gets crowded enough to require ID's, social collapse is not
>>> far away. It is time to go elsewhere. The best thing about space travel
>>> is that it made it possible to go elsewhere.
>>> -- R.A. Heinlein, "Time Enough For Love"
>>>
>>
>>
>>
>> --
>> When a place gets crowded enough to require ID's, social collapse is not
>> far away. It is time to go elsewhere. The best thing about space travel
>> is that it made it possible to go elsewhere.
>> -- R.A. Heinlein, "Time Enough For Love"
>>
>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away. It is time to go elsewhere. The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>


--
Ulrich Germann
Senior Researcher
School of Informatics
University of Edinburgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160112/8b14e9d4/attachment-0001.html

------------------------------

Message: 2
Date: Tue, 12 Jan 2016 12:52:42 -0600
From: Lane Schwartz <dowobeha@gmail.com>
Subject: Re: [Moses-support] Error when running moses server with
sample code
To: Ulrich Germann <ugermann@inf.ed.ac.uk>
Cc: "moses-support@mit.edu" <moses-support@mit.edu>, Barry Haddow
<bhaddow@staffmail.ed.ac.uk>
Message-ID:
<CABv3vZn1Fp-2a3Q3zdtuNkoXBA2n1D2iJqLo_sSDdO=CRhBazA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks. I don't use the switch. I just found that it was enabled in the
sample client.py

On Tue, Jan 12, 2016 at 12:43 PM, Ulrich Germann <ulrich.germann@gmail.com>
wrote:

> Fixed, but chances are you won't like the output. --report-all-factors
> appears to be a legacy debugging switch that dumps the value of all factor
> slots provided by moses (the maximum number of factors is set at compile
> time), regardless of whether or not they are used by the system. Normal
> users of Moses are unlikely to have any use for it. With
> --report-all-factors, the output for a standard compile looks like this:
>
> Do|UNK|UNK|UNK you|UNK|UNK|UNK really|UNK|UNK|UNK want|UNK|UNK|UNK
> that|UNK|UNK|UNK ?|UNK|UNK|UNK
>
> - Uli
>
>
> On Tue, Jan 12, 2016 at 4:04 PM, Lane Schwartz <dowobeha@gmail.com> wrote:
>
>> Looks like this is not specific to mosesserver. Same error occurs when
>> running moses with --report-all-factors.
>>
>> On Tue, Jan 12, 2016 at 9:59 AM, Lane Schwartz <dowobeha@gmail.com>
>> wrote:
>>
>>> Never mind. I figured out how.
>>>
>>> (gdb) bt
>>>> #0 0x00007ffff5d905e9 in raise () from /lib64/libc.so.6
>>>> #1 0x00007ffff5d91cf8 in abort () from /lib64/libc.so.6
>>>> #2 0x00007ffff68b09b5 in __gnu_cxx::__verbose_terminate_handler() ()
>>>> from /lib64/libstdc++.so.6
>>>> #3 0x00007ffff68ae926 in ?? () from /lib64/libstdc++.so.6
>>>> #4 0x00007ffff68ae953 in std::terminate() () from /lib64/libstdc++.so.6
>>>> #5 0x00007ffff68aeb73 in __cxa_throw () from /lib64/libstdc++.so.6
>>>> #6 0x000000000073a695 in Moses::Manager::OutputSurface
>>>> (this=0x7ffe4e9e6980, out=..., edge=..., recursive=false) at
>>>> moses/Manager.cpp:1726
>>>> Python Exception <type 'exceptions.IndexError'> list index out of
>>>> range:
>>>> #7 0x000000000088c6f3 in
>>>> MosesServer::TranslationRequest::pack_hypothesis (this=0x1848b40,
>>>> manager=..., edges=std::vector of length 13, capacity 16 = {...},
>>>> key="text", dest=std::map with 0 elements) at
>>>> moses/server/TranslationRequest.cpp:358
>>>> Python Exception <type 'exceptions.IndexError'> list index out of
>>>> range:
>>>> #8 0x000000000088d02c in
>>>> MosesServer::TranslationRequest::pack_hypothesis (this=0x1848b40,
>>>> manager=..., h=0x0, key="text", dest=std::map with 0 elements) at
>>>> moses/server/TranslationRequest.cpp:393
>>>> #9 0x000000000088d128 in
>>>> MosesServer::TranslationRequest::run_phrase_decoder (this=0x1848b40) at
>>>> moses/server/TranslationRequest.cpp:403
>>>> #10 0x0000000000888483 in MosesServer::TranslationRequest::Run
>>>> (this=0x1848b40) at moses/server/TranslationRequest.cpp:70
>>>> #11 0x00000000006d4b9e in Moses::ThreadPool::Execute (this=0x18ae028)
>>>> at moses/ThreadPool.cpp:58
>>>> #12 0x00000000006d7071 in boost::_mfi::mf0<void,
>>>> Moses::ThreadPool>::operator() (this=0x189a398, p=0x18ae028) at
>>>> /usr/local/include/boost/bind/mem_fn_template.hpp:49
>>>> #13 0x00000000006d6fd4 in
>>>> boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
>>>> >::operator()<boost::_mfi::mf0<void, Moses::ThreadPool>, boost::_bi::list0>
>>>> (this=0x189a3a8, f=..., a=...) at /usr/local/include/boost/bind/bind.hpp:255
>>>> #14 0x00000000006d6f83 in boost::_bi::bind_t<void,
>>>> boost::_mfi::mf0<void, Moses::ThreadPool>,
>>>> boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*> > >::operator()
>>>> (this=0x189a398) at /usr/local/include/boost/bind/bind_template.hpp:20
>>>> #15 0x00000000006d6f48 in
>>>> boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void,
>>>> Moses::ThreadPool>, boost::_bi::list1<boost::_bi::value<Moses::ThreadPool*>
>>>> > > >::run (this=0x189a1e0) at
>>>> /usr/local/include/boost/thread/detail/thread.hpp:116
>>>> #16 0x000000000098d78f in thread_proxy ()
>>>> #17 0x00007ffff6123df3 in start_thread () from /lib64/libpthread.so.0
>>>> #18 0x00007ffff5e511ed in clone () from /lib64/libc.so.
>>>
>>>
>>> The error occurs when the python client sets "report-all-factors":
>>> "true".
>>>
>>>
>>>
>>> On Tue, Jan 12, 2016 at 9:47 AM, Lane Schwartz <dowobeha@gmail.com>
>>> wrote:
>>>
>>>> I compiled with variant=debug. What else do I need to do to get a stack
>>>> trace?
>>>>
>>>> On Tue, Jan 12, 2016 at 3:16 AM, Barry Haddow <
>>>> bhaddow@staffmail.ed.ac.uk> wrote:
>>>>
>>>>> Hi Lane
>>>>>
>>>>> Can you get a stack trace to see which line the message is coming
>>>>> from? That error message is repeated in a few files.
>>>>>
>>>>> From looking at the code, I'd guess that the OutputFactorOrder is not
>>>>> being initialised correctly. Possibly due to the refactoring of the config
>>>>> code. Does your example work with an earlier version of Moses?
>>>>>
>>>>> cheers - Barry
>>>>>
>>>>>
>>>>> On 11/01/16 21:43, Lane Schwartz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying out mosesserver for the first time. I have a config file
>>>>> for fr-en that uses a smallish TM and LM, that work fine when run with
>>>>> Moses. When I try running the same config using mosesserver, and then use
>>>>> the sample Perl or Python code in contrib/server, mosesserver dies with the
>>>>> following error:
>>>>>
>>>>> Defined parameters (per moses.ini or switch):
>>>>>> config: moses.tuned.ini.2.probing.noLexRO
>>>>>> cube-pruning-pop-limit: 400
>>>>>> distortion-limit: 6
>>>>>> feature: UnknownWordPenalty WordPenalty PhrasePenalty ProbingPT
>>>>>> name=TranslationModel0 num-features=4
>>>>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>>>>> table-limit=20 Distortion KENLM lazyken=1 name=LM0 factor=0
>>>>>> path=europarl.kenlm order=5
>>>>>> input-factors: 0
>>>>>> mapping: 0 T 0
>>>>>> max-phrase-length: 20
>>>>>> n-best-list: nbest.txt 111
>>>>>> output-hypo-score: 1
>>>>>> search-algorithm: 0
>>>>>> server:
>>>>>> threads: 1
>>>>>> weight: Distortion0= 0.0222366 LM0= 0.0834208 WordPenalty0= -0.
>>>>>> 0654626 PhrasePenalty0= 0.0220686 TranslationModel0= 0.0520176
>>>>>> 0.0415173 0.124293 0.027126 UnknownWordPenalty0= 1
>>>>>>
>>>>>> line=UnknownWordPenalty
>>>>>> FeatureFunction: UnknownWordPenalty0 start: 0 end: 0
>>>>>> line=WordPenalty
>>>>>> FeatureFunction: WordPenalty0 start: 1 end: 1
>>>>>> line=PhrasePenalty
>>>>>> FeatureFunction: PhrasePenalty0 start: 2 end: 2
>>>>>> line=ProbingPT name=TranslationModel0 num-features=4
>>>>>> path=phrase-table.2.pruned100.probing/ input-factor=0 output-factor=0
>>>>>> table-limit=20
>>>>>> FeatureFunction: TranslationModel0 start: 3 end: 6
>>>>>> line=Distortion
>>>>>> FeatureFunction: Distortion0 start: 7 end: 7
>>>>>> line=KENLM lazyken=1 name=LM0 factor=0 path=europarl.kenlm order=5
>>>>>> FeatureFunction: LM0 start: 8 end: 8
>>>>>> Loading UnknownWordPenalty0
>>>>>> Loading WordPenalty0
>>>>>> Loading PhrasePenalty0
>>>>>> Loading Distortion0
>>>>>> Loading LM0
>>>>>> Loading TranslationModel0
>>>>>> Initialized successfully!
>>>>>>
>>>>>> RUN SERVER at pid 1733327039
>>>>>> [moses/server/Server.cpp:49] Listening on port 8080
>>>>>> [moses/server/TranslationRequest.cpp:281] Input: il a souhait? que la
>>>>>> pr?sidence trace ? nice le chemin pour l' avenir .
>>>>>> Translating: il a souhait? que la pr?sidence trace ? nice le chemin
>>>>>> pour l' avenir .
>>>>>>
>>>>>> Line 0: Collecting options took 0.038 seconds at moses/Manager.cpp
>>>>>> Line 141
>>>>>> Line 0: Search took 0.674 seconds
>>>>>> terminate called after throwing an instance of 'util::Exception'
>>>>>> what(): No factor 1 at position 0
>>>>>
>>>>>
>>>>> Any idea what's going on here? I'm using a basic single-factor model,
>>>>> so I don't get why it would be complaining about factors. I'm using the
>>>>> latest moses from git.
>>>>>
>>>>> Thanks,
>>>>> Lane
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moses-support mailing listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>
>>>>>
>>>>>
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> When a place gets crowded enough to require ID's, social collapse is not
>>>> far away. It is time to go elsewhere. The best thing about space
>>>> travel
>>>> is that it made it possible to go elsewhere.
>>>> -- R.A. Heinlein, "Time Enough For Love"
>>>>
>>>
>>>
>>>
>>> --
>>> When a place gets crowded enough to require ID's, social collapse is not
>>> far away. It is time to go elsewhere. The best thing about space travel
>>> is that it made it possible to go elsewhere.
>>> -- R.A. Heinlein, "Time Enough For Love"
>>>
>>
>>
>>
>> --
>> When a place gets crowded enough to require ID's, social collapse is not
>> far away. It is time to go elsewhere. The best thing about space travel
>> is that it made it possible to go elsewhere.
>> -- R.A. Heinlein, "Time Enough For Love"
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
> --
> Ulrich Germann
> Senior Researcher
> School of Informatics
> University of Edinburgh
>



--
When a place gets crowded enough to require ID's, social collapse is not
far away. It is time to go elsewhere. The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20160112/795ef4ec/attachment.html

------------------------------

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


End of Moses-support Digest, Vol 111, Issue 26
**********************************************

0 Response to "Moses-support Digest, Vol 111, Issue 26"

Post a Comment

Subscribe to: Post Comments (Atom)