<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/expressions.cpp, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>THE GREAT CEEIFICATION EVENT</title>
<updated>2021-05-30T01:12:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-30T00:38:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=432ad24e382681f1c13b07e8486e91063dd96e2e'/>
<id>432ad24e382681f1c13b07e8486e91063dd96e2e</id>
<content type='text'>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed checks for missing left and right operands to binary operators</title>
<updated>2017-03-23T22:42:41+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-23T22:42:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2491d5f30573d9e5e72b3c7d2eac8788bbe69dd4'/>
<id>2491d5f30573d9e5e72b3c7d2eac8788bbe69dd4</id>
<content type='text'>
 * this resulted in assertions (crashes!) for harmless typos like "+23="
 * a test case has been added
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * this resulted in assertions (crashes!) for harmless typos like "+23="
 * a test case has been added
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2017</title>
<updated>2017-03-03T14:32:57+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-03T14:32:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0bbcd7652a948424156968298e4d2f27b998cfe2'/>
<id>0bbcd7652a948424156968298e4d2f27b998cfe2</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>revised looping implementation, aggregating loops, sane $$ semantics, some optimizationa and additional checks</title>
<updated>2016-02-15T14:00:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-15T13:00:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=de7394372c77b695d4779606ea7587dfe61a35de'/>
<id>de7394372c77b695d4779606ea7587dfe61a35de</id>
<content type='text'>
 * undo tokens emitted by the expression stack no longer waste
   memory by pointing to the stack implementation.
   This uses some ugly C++ constant template arguments but
   saves 4 or 8 byte per undo token depending on the architecture.
 * Round braces are counted now and the return command $$ will
   use this information to discard all non-relevant brace levels.
 * It is an error to close a brace when none have been opened.
 * The bracing rules are still very liberal, allowing you to
   close braces in macros belonging to a higher call frame
   or leave them open at the end of a macro.
   While this is technically possible, it is perhaps a good
   idea to stricten these rules in some future release.
 * Loops no longer (ab)use the expression stack to store
   program counters and loop counters.
   This removes flow control from the responsibility of the
   expression stack which is much safer now since we can control
   where we jump to.
   This also eased implemented proper semantics for $$.
 * It is an error to leave loops open at the end of a macro
   or trying to close a loop opened in the caller of the macro.
   Similarily it is only possible to close a loop from the
   current invocation frame.
   This means it is now impossible to accidentally jump to invalid
   PCs.
 * Even though loop context stacks could be attached directly to
   the macro invocation frame, this would be inefficient.
   Instead there's a loop frame pointer now that is part of the
   invocation frame. All frames will reuse the same stack structure.
 * Loops are automatically discarded when returning using $$.
 * Special aggregating forms of the loop start (":&lt;") and loop
   end (":&gt;") commands are possible now and have been implemented.
   This improves SciTECO's capability as a stack-oriented language.
   It is no longer necessary to write recursive macros to generate
   stack values of arbitrary length dynamically or to process them.
 * All expression and loop stacks are still fixed-size.
   It may be a good idea to implement dynamic resizing (TODO).
 * Added some G_UNLIKELYs to Execute::macro(). Should improve
   the branch prediction of modern CPUs.
 * Local Q-Register tables are allocated on the stack now instead
   of on the heap (the bulk of a table is stored on the heap anyway).
   Should improve performance of macro invocations.
 * Document that "F&lt;" will jump to the beginning of the macro
   if there is no loop.
   This is not in standard TECO, but I consider it a useful feature.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * undo tokens emitted by the expression stack no longer waste
   memory by pointing to the stack implementation.
   This uses some ugly C++ constant template arguments but
   saves 4 or 8 byte per undo token depending on the architecture.
 * Round braces are counted now and the return command $$ will
   use this information to discard all non-relevant brace levels.
 * It is an error to close a brace when none have been opened.
 * The bracing rules are still very liberal, allowing you to
   close braces in macros belonging to a higher call frame
   or leave them open at the end of a macro.
   While this is technically possible, it is perhaps a good
   idea to stricten these rules in some future release.
 * Loops no longer (ab)use the expression stack to store
   program counters and loop counters.
   This removes flow control from the responsibility of the
   expression stack which is much safer now since we can control
   where we jump to.
   This also eased implemented proper semantics for $$.
 * It is an error to leave loops open at the end of a macro
   or trying to close a loop opened in the caller of the macro.
   Similarily it is only possible to close a loop from the
   current invocation frame.
   This means it is now impossible to accidentally jump to invalid
   PCs.
 * Even though loop context stacks could be attached directly to
   the macro invocation frame, this would be inefficient.
   Instead there's a loop frame pointer now that is part of the
   invocation frame. All frames will reuse the same stack structure.
 * Loops are automatically discarded when returning using $$.
 * Special aggregating forms of the loop start (":&lt;") and loop
   end (":&gt;") commands are possible now and have been implemented.
   This improves SciTECO's capability as a stack-oriented language.
   It is no longer necessary to write recursive macros to generate
   stack values of arbitrary length dynamically or to process them.
 * All expression and loop stacks are still fixed-size.
   It may be a good idea to implement dynamic resizing (TODO).
 * Added some G_UNLIKELYs to Execute::macro(). Should improve
   the branch prediction of modern CPUs.
 * Local Q-Register tables are allocated on the stack now instead
   of on the heap (the bulk of a table is stored on the heap anyway).
   Should improve performance of macro invocations.
 * Document that "F&lt;" will jump to the beginning of the macro
   if there is no loop.
   This is not in standard TECO, but I consider it a useful feature.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2016</title>
<updated>2016-01-28T01:45:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-01-28T01:25:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e3818dae4b4a5fa2af9c982a0b3a3cf4d15cb373'/>
<id>e3818dae4b4a5fa2af9c982a0b3a3cf4d15cb373</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>cleaned up operator precedence code</title>
<updated>2015-09-24T02:15:04+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-09-24T02:07:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=db510ba69e90039a9649a4bf3c8e6b7bdc5a09bd'/>
<id>db510ba69e90039a9649a4bf3c8e6b7bdc5a09bd</id>
<content type='text'>
 * use small values for low precedence
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * use small values for low precedence
</pre>
</div>
</content>
</entry>
<entry>
<title>different operators can have the same precedence now</title>
<updated>2015-09-23T15:53:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-09-23T15:53:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ecbc58fb917c292f05bed401afe7be0a80971d80'/>
<id>ecbc58fb917c292f05bed401afe7be0a80971d80</id>
<content type='text'>
 * SciTECO now has the same operator precedence table as C.
 * It is numerically important whether different operators
   have the same precedence. E.g. "5*2/4" used to be evaluated
   by SciTECO as "5*(2/4)" since division had a higher precedence
   than multiplication. Within in real (!) numbers this would
   be the expected evaluation order.
   Users of other programming languages however would expect
   the expression to be evaluated as "(5*2)/4" which makes
   a numerical difference when working with integers.
 * Operator precedence has been implemented by encoding it
   into the enumeration values used to represent different
   operators.
   Calculating the precedence of a given operator can then
   be done very efficiently and elegantly (in our case using
   a plain right shift operation).
 * documentation updated. We use a precedence table now.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * SciTECO now has the same operator precedence table as C.
 * It is numerically important whether different operators
   have the same precedence. E.g. "5*2/4" used to be evaluated
   by SciTECO as "5*(2/4)" since division had a higher precedence
   than multiplication. Within in real (!) numbers this would
   be the expected evaluation order.
   Users of other programming languages however would expect
   the expression to be evaluated as "(5*2)/4" which makes
   a numerical difference when working with integers.
 * Operator precedence has been implemented by encoding it
   into the enumeration values used to represent different
   operators.
   Calculating the precedence of a given operator can then
   be done very efficiently and elegantly (in our case using
   a plain right shift operation).
 * documentation updated. We use a precedence table now.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed invalid memory accesses in the expression stack and reworked expression stack</title>
<updated>2015-03-17T19:18:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-03-17T19:18:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=14ebd5d58be3fcb5d2208f890498dd8c57f4d165'/>
<id>14ebd5d58be3fcb5d2208f890498dd8c57f4d165</id>
<content type='text'>
this was probably a regression from d94b18819ad4ee3237c46ad43a962d0121f0c3fe
and should not be in v0.5.
The return value of Expressions::find_op() must always be checked since
it might not find the operator, returning 0 (it used to be 0).
A zero index pointed to uninitialized memory - in the worst case it
pointed to invalid memory resulting in segfaults.
Too large indices were also not handled.
This was probably responsible for recent PPA build issues.
Valgrind/memcheck reports this error but I misread it as a bogus warning.

I took the opportunity to clean up the ValueStack implementation and
made it more robust by adding a few assertions.
ValueStacks now grow from large to small addresses (like stack data
structures usually do).
This means, there is no need to work with negative indices into the
stack pointer.
To reduce the potential for invalid stack accesses, stack indices are
now unsigned and have origin 0. Previously, all indices &lt; 1 were
faulty but weren't checked.
Also, I added some minor optimizations.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this was probably a regression from d94b18819ad4ee3237c46ad43a962d0121f0c3fe
and should not be in v0.5.
The return value of Expressions::find_op() must always be checked since
it might not find the operator, returning 0 (it used to be 0).
A zero index pointed to uninitialized memory - in the worst case it
pointed to invalid memory resulting in segfaults.
Too large indices were also not handled.
This was probably responsible for recent PPA build issues.
Valgrind/memcheck reports this error but I misread it as a bogus warning.

I took the opportunity to clean up the ValueStack implementation and
made it more robust by adding a few assertions.
ValueStacks now grow from large to small addresses (like stack data
structures usually do).
This means, there is no need to work with negative indices into the
stack pointer.
To reduce the potential for invalid stack accesses, stack indices are
now unsigned and have origin 0. Previously, all indices &lt; 1 were
faulty but weren't checked.
Also, I added some minor optimizations.
</pre>
</div>
</content>
</entry>
<entry>
<title>use g_assert_not_reached() instead of g_assert(false): works around Clang++ warnings</title>
<updated>2015-03-02T16:31:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-03-02T16:31:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=03be83f5a444183083f895352133f04b24fcc48f'/>
<id>03be83f5a444183083f895352133f04b24fcc48f</id>
<content type='text'>
 * Clang++ does not see that the PC will never go beyong g_assert(false),
   and so reports about possible unitialized variables
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Clang++ does not see that the PC will never go beyong g_assert(false),
   and so reports about possible unitialized variables
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2015</title>
<updated>2015-02-11T05:24:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-02-11T05:24:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e7d275367c8f0ecbe7a47b00efa1d42c84ce09de'/>
<id>e7d275367c8f0ecbe7a47b00efa1d42c84ce09de</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
