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

Reply via email to