#205: Repair the TracNav bar
------------------------+---------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: minor | Milestone:
Component: Trac | Version: 1.0
Keywords: system web |
------------------------+---------------------------------------------------
Since the update of Trac, many Wiki pages using the !TracNav plug-in won't
display the !TracNav bar (menu on the right of some pages), and show this
error instead :
{{{
Error: Failed to load processor TracNav
No macro or processor named 'TracNav' found
}}}
The curious thing is, the !TracNav bar is working ''sometimes''!!
To see this in action, try reloading a page several times (e.g.
CodingStyle): sometimes you'll see the bar, other times you'll get the
error.
I assume other Tracs ([https://trac.lrde.org/vaucanson/ Vaucanson's],
[https://trac.lrde.org/transformers/ Transfomers'], etc.) face the same
problem; we should discuss this issue with their maintainers. Therefore I
(Roland) am cc'ing this ticket to the `projects` mailing list as well.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/205>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
Chers collègues,
Comme certains d'entre vous le savent, j'organise depuis deux ans
maintenant, un projet Tiger à l'ISTY (l'école d'ingénieurs rattachée à
l'Université de Versailles).
Je me suis fortement inspiré du projet Tiger de l'Epita (merci encore
pour la superbe documentation !).
Mes étudiants utilisent HAVM pour tester les programmes IR et en sont
contents. Néanmoins, le bug lié à la mauvaise execution d'un jump
pendant l'évaluation d'une expression agace souvent les étudiants (même
si avec un brin de persévérance on peut le contourner).
Toujours est-il que j'ai essayé de fixer ce bug dans HAVM, mais n'étant
pas un expert Haskell, cela était difficile. Finalement, je me suis dit
que ce serait plus rapide pour moi de ré-implémenter la VM dans un
langage que je maîtrise mieux. Je vous présente donc IRVM:
https://github.com/pablooliveira/irvm
Si vous souhaitez l'utiliser ou si vous avez des retours, n'hésitez pas
à m'en faire part. La stratégie pour résoudre le problème de
l'évaluation/jump est finalement assez simple, et je pense pourrait être
portée dans HAVM par quelqu'un de doué en Haskell (si vous souhaitez
échanger la dessus, n'hésitez pas également).
Cordialement,
Pablo Oliveira
Dear HAVM maintainers,
Tiger specifications do not precisely define the expected behavior of an
integer overflow. Currently, HAVM does not coerce its arithmetic
computations to an Int32 type.
To be consistent with nolimips, spim, and most current architectures, it
would be nice that arithmetic operations in HAVM wrap around.
The tentative attached patch fixes this. (I went for the less intrusive
fix, a more radical solution would be to redefine all Int types in HAVM
to Int32.)
Regards,
Pablo Oliveira
