Hi Behdad,
I just returned and saw with great pleasure a new release which
fixes the problem.
I confirm that xetex now runs like hell again ;-)
Thanks for the great support and help, I will surely disturb you again
in case of problem.
Thanks also to Hilmar for doing the last rounds of testing
Thanks Norbert. Was a pleasure working with you.
Cheers,
behdad
On 14-08-19 10:53 AM, Norbert Preining wrote:
Hi Behdad,
I just returned and saw with great pleasure a new release which
fixes the problem.
I confirm that xetex now runs like hell again ;-)
Thanks for the great support
On 14-08-13 12:14 PM, Hilmar Preusse wrote:
On 12.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi Behdad,
Attached.
I just wanted confirm that then patch solves the problem. The
harfbuzz maintainer has uploaded a new package to Debian.
Thanks Hilmer. I'll make a release today.
--
On 12.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi Behdad,
Attached.
I just wanted confirm that then patch solves the problem. The
harfbuzz maintainer has uploaded a new package to Debian.
Hilmar
--
sigmentation fault
signature.asc
Description: Digital signature
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi,
Before the return, add something like this:
printf(DEBUG props %d features %d default_shaper %d shaper_list %d plan
func %p proposal func %p\n,
hb_segment_properties_equal (shape_plan-props, proposal-props),
Humm. Ok, it looks suspicious, but also helpful. Let me think about it.
On 14-08-12 07:12 AM, Hilmar Preusse wrote:
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi,
Before the return, add something like this:
printf(DEBUG props %d features %d default_shaper %d shaper_list %d
Ok, confirmed as HarfBuzz bug. Reproduced. Working on a fix.
On 14-08-12 07:12 AM, Hilmar Preusse wrote:
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi,
Before the return, add something like this:
printf(DEBUG props %d features %d default_shaper %d shaper_list %d plan
func
The cache wasn't working if more than one (valid) shapers were passed in.
Fixed now:
https://github.com/behdad/harfbuzz/commit/8d5eebc0c6ada01128c6ee384340efdbef7ba29d
behdad
On 14-08-12 07:12 AM, Hilmar Preusse wrote:
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi,
Before the
On 12.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi Behdad,
https://github.com/behdad/harfbuzz/commit/8d5eebc0c6ada01128c6ee384340efdbef7ba29d
I'm failing to pull a raw unified diff out of github. Could you post
it here?
Tnanks,
Hilmar
--
sigmentation fault
signature.asc
On 12.08.14 Norbert Preining (prein...@logic.at) wrote:
Hi Norbert,
This is a harfbuzz bug? Should be re-assign that bug?
Let us wait. It could also be one of the many gcc 4.9 compiler bugs.
Can you try compiling harfbuzz and/or xetex with gcc 4.8 instead
and see if that changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached.
On 14-08-12 05:31 PM, Hilmar Preusse wrote:
On 12.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi Behdad,
https://github.com/behdad/harfbuzz/commit/8d5eebc0c6ada01128c6ee384340efdbef7ba29d
I'm failing to pull a raw unified
This looks fine. Try passing NULL for shaperList and see if that changes
anything.
If it doesn't, then something in our shape_plan_cache isn't working. I
have a hard time imagining what though.
On Mon, Aug 11, 2014 at 1:55 AM, Norbert Preining prein...@logic.at wrote:
Hi Behdad,
I have
Hi,
This looks fine. Try passing NULL for shaperList and see if that changes
anything.
This is about 100 times faster total runtime on that document, with debug
output, real 1.845s.
What can I try next?
For completeness: Debian/sid, harfbuzz shared lib, amd64.
Thanks a lot
Norbert
Hi
I think I found the bug:
On Mon, 11 Aug 2014, Norbert Preining wrote:
This is about 100 times faster total runtime on that document, with
debug output, real 1.845s.
I recompiled harfbuzz with some debug statements in the
function, and it turned out that when I do that:
(in
On 11.08.14 Norbert Preining (prein...@logic.at) wrote:
Hi,
I think I found the bug:
Many thanks for investigation!
On Mon, 11 Aug 2014, Norbert Preining wrote:
This is about 100 times faster total runtime on that document, with
debug output, real 1.845s.
I recompiled
That certainly isn't working as intended. I tested the cache locally (not in
the context of XeTeX) and it works fine.
Can you dig into hb_shape_plan_matches() and see why it's never matching?
On 14-08-11 06:01 AM, Norbert Preining wrote:
Hi
I think I found the bug:
On Mon, 11 Aug 2014,
I'll do, after I am back from holidays ;-)
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3
Cold turkey!
On 14-08-11 04:06 PM, Norbert Preining wrote:
I'll do, after I am back from holidays ;-)
PREINING, Norbert http://www.preining.info
http://www.preining.info/
JAIST, Japan
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote:
Hi Behdad,
That certainly isn't working as intended. I tested the cache locally (not in
the context of XeTeX) and it works fine.
At least I can reproduce the growing loops Norbert has seen, after
applying the debug patch.
Can you dig
Thanks Hilmar. See below:
On Mon, Aug 11, 2014 at 5:40 PM, Hilmar Preusse hill...@web.de wrote:
static hb_bool_t
hb_shape_plan_matches (const hb_shape_plan_t *shape_plan,
const hb_shape_plan_proposal_t *proposal)
{
return hb_segment_properties_equal
Hi Hilmar,
This is a harfbuzz bug? Should be re-assign that bug?
Let us wait. It could also be one of the many gcc 4.9 compiler bugs.
Can you try compiling harfbuzz and/or xetex with gcc 4.8 instead and see if
that changes anything?
Anyway, when I'm back from Hokkaido I can investigate
On 14-08-09 11:47 AM, Khaled Hosny wrote:
On Tue, Aug 05, 2014 at 03:04:03PM +0900, Norbert Preining wrote:
Hi Khaled,
concerning the slowness in xelatex and context/xetex, I found now
which call is so delaying. I interspersed lots of printf and found that
most time the xelatex process is
Hi Behdad,
thanks for your answer, and looking into it.
On Sun, 10 Aug 2014, Behdad Esfahbod wrote:
Not without more context (haha).
I can give more context, easily, but I need some explanation
on *how* to print out information concerning
hbFace
segment_props
On Sun, Aug 10, 2014 at 11:17 PM, Norbert Preining prein...@logic.at
wrote:
Hi Behdad,
thanks for your answer, and looking into it.
On Sun, 10 Aug 2014, Behdad Esfahbod wrote:
Not without more context (haha).
I can give more context, easily, but I need some explanation
on *how* to print
Hi
thanks
Ok, best that you get that printout first then.
I will try as soon as I can, but I am leaving for long overdue
holiday of one week tomorrow - without my laptop!!!
;-) :-D
All the best
Norbert
PREINING,
Hi Behdad,
I have now done the following changes in XeTeXLayoutInterface.cpp
(somewhere aboce the surrounding function, declar curtime and nxttime)
static time_t curtime;
static time_t nxttime;
int
layoutChars(XeTeXLayoutEngine engine, uint16_t chars[], int32_t offset, int32_t
count, int32_t
On Tue, Aug 05, 2014 at 03:04:03PM +0900, Norbert Preining wrote:
Hi Khaled,
concerning the slowness in xelatex and context/xetex, I found now
which call is so delaying. I interspersed lots of printf and found that
most time the xelatex process is stucked in the following line
from
Hi Khaled,
concerning the slowness in xelatex and context/xetex, I found now
which call is so delaying. I interspersed lots of printf and found that
most time the xelatex process is stucked in the following line
from XeTeXLayoutInterface.cpp:
shape_plan =
On Mon, Jun 09, 2014 at 08:59:01PM +0900, Norbert Preining wrote:
Hi Khaled,
(please keep Debian bug in Cc)
I already have asked Taco and Hans, but it seems that the same problem
occurs also with xelatex, so I thought I ask you for ideas.
We got a report here at Debian that context when
Hi Khaled,
(please keep Debian bug in Cc)
I already have asked Taco and Hans, but it seems that the same problem
occurs also with xelatex, so I thought I ask you for ideas.
We got a report here at Debian that context when run over xetex
is extremely slow, which I can confirm. THe same happens
One more thing - I build the Debian package with
-pg
for profiling, but xetex runs did not produce a gmon.out, so
there is something strange...
On Mon, 09 Jun 2014, Norbert Preining wrote:
Hi Khaled,
(please keep Debian bug in Cc)
I already have asked Taco and Hans, but it seems
Hi Hans, hi Taco,
(please keep the Debian bug report in Cc)
We got a report here at Debian that context when run over xetex
is extremely slow, which I can confirm.
It is interesting that when I drop the original TeX Live (not Debian)
xetex into our /usr/bin, then it is getting fast again.
On
On 6/8/2014 9:26 AM, Norbert Preining wrote:
Hi Hans, hi Taco,
(please keep the Debian bug report in Cc)
We got a report here at Debian that context when run over xetex
is extremely slow, which I can confirm.
It is interesting that when I drop the original TeX Live (not Debian)
xetex into our
Hi Hans,
thanks for your ideas.
Can you see if (in the background) the xetex font database gets
regenerated? I remember that long ago on windows we had a problem
I didn't see anything running in the background. I also doubt that
this is the reason, because xetex on linux will not call
34 matches
Mail list logo
