Le 04/10/2014 12:07, stepharo a écrit :
NativeBoost is not unstable for me, but why libcgit is on a bleeding
edge NativeBoost version then?
I do not get what you want to say. May be restating will help me
understand.
Last time I checked, libcgit was tied to an experimental NativeBoost
version (or bleeding edge version).
The changes needed by libcgit should have been integrated in Pharo instead.
Athens is stable for me, but I believe that TxText requires a bleeding
edge Athens.
Igor improve Athens each time it is needed and it does not make athens
unstable.
But basically TxText is on a fork of mainline Athens. It's the "Windows
undocumented" approach: I'm on TxText, I need something from Athens, I
just add the stuff to Athens; anyway, I'm not on the main Athens, I can
get my own customized version.
Now, when merging TxText, you'll have to merge a new Athens as well, and
I hope that you won't find by then that this new Athens breaks Roassal.
I can understand why you may want to work like that. From the outside,
I'm not impressed by the process.
Libcgit is like that: its Pharo 4 + Bleeding edge native boost not yet
in Pharo 4 + libcgit (and from ESUG, I get that it will require an
entire refactoring of Monticello and a complete new on disk format).
It's really shaping up like a long, long term target.
So for you it would be better that we move faster :)
Not slowler.
Not really. If you had a few million € to burn, I'd say "perfect". With
the amount of resources we have, I'm saying: this is really risky. And
hard to contribute to, so I can't help.
You see if there is a bug in a cache on the system somehwere what can we
do. Igot told to alex to use another font and it solved the problem.
TxText will be pushed soon in Pharo 40.
I tried to work on that cache issue because my demos with Roassal had
the issue, but I couldn't find Igor's description in the archives. I
know it's there... Igor, if you are listening, can you tell us again?
Thierry