uild, if you like, for your personal use.
>
>On Fri, Feb 23, 2024 at 12:19 AM David Turner wrote:
>>
>> In FreeSerif, the quarter note 1D15F seems to overlap the following
>> character -- it seems the width isn't large enough. In case it matters,
>> the quarter note 2669 seem
In FreeSerif, the quarter note 1D15F seems to overlap the following
character -- it seems the width isn't large enough. In case it matters,
the quarter note 2669 seems fine. I'm not really a font person, so I
don't know immediately how to fix this (and anyway, my Savannah account
seems to be
Package: g++-12
Version: 12.2.0-14
Severity: normal
Tags: upstream
X-Debbugs-Cc: david.turner+...@raspberrypi.com
Dear Maintainer,
The attached C++ file fails to compile in GCC 12.2 using the command
`g++ --std=c++17 -c 1862683_reproducer.cpp`, but works correctly with 12.3 and
with clang
Package: g++-12
Version: 12.2.0-14
Severity: normal
Tags: upstream
X-Debbugs-Cc: david.turner+...@raspberrypi.com
Dear Maintainer,
The attached C++ file fails to compile in GCC 12.2 using the command
`g++ --std=c++17 -c 1862683_reproducer.cpp`, but works correctly with 12.3 and
with clang
its
uses, implementation, or would like to contribute. I hope you find it as
useful as I have.
David Turner
Sony Interactive Entertainment
[1] https://github.com/ceph/cephbot-slack
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send
On Tue, Apr 18, 2023 at 10:47 AM Daniel P. Berrangé
wrote:
> On Fri, Apr 07, 2023 at 11:25:14AM +0200, David Turner wrote:
> > I meant glibc-2.17, I am using a sysroot to ensure the generated binaries
> > run on older Linux distributions.
>
> I think that would be considere
On Fri, Apr 7, 2023 at 11:46 AM Michael S. Tsirkin wrote:
> On Fri, Apr 07, 2023 at 11:29:46AM +0200, David Turner wrote:
> > So it looks like that for some reason, the QEMU linux-headers directory
> is not
> > in the include search path for this compilation command, and t
to do that instead.
On Fri, Apr 7, 2023 at 11:29 AM David Turner wrote:
> So it looks like that for some reason, the QEMU linux-headers directory is
> not in the include search path for this compilation command, and that the
> system-or-sysroot provided is picked instead. Fixing thi
to do that yet though. Do you have any recommendations?
On Fri, Apr 7, 2023 at 11:25 AM David Turner wrote:
> I meant glibc-2.17, I am using a sysroot to ensure the generated binaries
> run on older Linux distributions.
>
> On Fri, Apr 7, 2023 at 11:24 AM David Turner wrote:
>
I meant glibc-2.17, I am using a sysroot to ensure the generated binaries
run on older Linux distributions.
On Fri, Apr 7, 2023 at 11:24 AM David Turner wrote:
> The of glib-2.17 begins with:
>
> #ifndef _LINUX_VHOST_H
> #define _LINUX_VHOST_H
> /* Userspace interface for i
The of glib-2.17 begins with:
#ifndef _LINUX_VHOST_H
#define _LINUX_VHOST_H
/* Userspace interface for in-kernel virtio accelerators. */
/* vhost is used to reduce the number of system calls involved in virtio.
*
* Existing virtio net code is used in the guest without modification.
*
* This
On Wed, Apr 5, 2023 at 6:41 PM Peter Maydell
wrote:
> On Wed, 5 Apr 2023 at 16:55, Cornelia Huck wrote:
> >
> > On Wed, Apr 05 2023, David Turner wrote:
> >
> > > On Wed, Apr 5, 2023 at 3:06 PM Cornelia Huck
> wrote:
> > >
> > >&
On Wed, Apr 5, 2023 at 3:06 PM Cornelia Huck wrote:
> On Wed, Apr 05 2023, "David 'Digit' Turner" wrote:
>
> > Add , used by hw/display/virtio-gpu-udmabuf.c
> > Add , used by qga/commands-posix.c
> > Add used by kvm-all.c, which requires
> > the _BITUL() macro definition to be available.
> >
>
[
https://issues.apache.org/jira/browse/LUCENE-10677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577853#comment-17577853
]
David Turner edited comment on LUCENE-10677 at 8/10/22 9:42 AM:
>
[
https://issues.apache.org/jira/browse/LUCENE-10677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577853#comment-17577853
]
David Turner commented on LUCENE-10677:
---
> I'm opposed to the use of string.intern by the luc
David Turner created LUCENE-10676:
-
Summary: FieldInfo#name contributes significantly to heap usage at
scale
Key: LUCENE-10676
URL: https://issues.apache.org/jira/browse/LUCENE-10676
Project: Lucene
We receive the data every two weeks and then use django-import-export to import
the data into our database. There is no mention of the account manager in these
as this is something on our side. Am I missing the point in that by having the
foreign key to the account manager this would impact on
be for diagnosing either of
these issues? Thank you.
-David Turner
[1] $ sudo ceph daemon mds.mon1 dump_blocked_ops
{
"ops": [
{
"description": "client_request(client.17709580:39254 open
#0x10001c99cd4 2022-02-22T16:25:40.231547+ c
Le jeu. 10 févr. 2022 à 05:32, Alexei Podtelezhnikov a
écrit :
> Hi All,
>
> As Werner is working on improving the SBIX table support
> (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139),
> a topic of compressed images came up. Right now, FreeType depends on
> libpng to
I have specific worries about what is being proposed here:
- First, the proposed merge requests adds a ton of conditional code
paths that are impossible to properly review now or even maintain over
time. Since there is no proper distinction in the source code between what
is supposed
go around might as well ask.
> >>
> >> If you know a better place to ask these, please reply and add them.
> >
> > Just a quick ping, plus adding -devel since it looks like this
> > hasn't made it to archives.
>
> Indeed, I haven't seen your orig
go around might as well ask.
> >>
> >> If you know a better place to ask these, please reply and add them.
> >
> > Just a quick ping, plus adding -devel since it looks like this
> > hasn't made it to archives.
>
> Indeed, I haven't seen your orig
Is there a release of the Maven dependency plugin scheduled?
I am very excited about the return of verbose with
https://issues.apache.org/jira/browse/MDEP-644, and I'm sure I'm not the only
one. Thanks!
-
To unsubscribe,
We just upgraded a cephfs cluster from 12.2.12 to 14.2.11. Our next step is
to upgrade to 14.2.16 to troubleshoot this issue, but I thought I'd reach
out here first if anyone had any ideas. The clients are still running an
older version of ceph-fuse 12.2.4 and it's very difficult to remount all of
Le ven. 18 sept. 2020 à 16:22, Alexei Podtelezhnikov a
écrit :
> Let's not clog the src folder please
>
> src/base/amiga (not src/amiga)
> src/base/unix (not src/unix)
>
> What about using a _.c suffix, as in:
src/base/ftsystem_amiga.c
src/base/ftsystem_win32.c
etc..
We are no longer limited
PS: This introduces several python scripts, I have been using the "yapf"
>> tool to format them. If you know of a better python reformatter, let me
>> know.
>>
>
> Black It's the best
>
>>
From 8dcb5c0789a8065947eb66d08ceae730b6afae87 Mon Sep 17 00:00
Le ven. 18 sept. 2020 à 14:18, Alexei Podtelezhnikov a
écrit :
>
>
> On Fri, Sep 18, 2020 at 7:18 AM David Turner wrote:
>
>> Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG a écrit :
>>
>>> > These are some horrible numbers that essentially test
bout these.
- Digit
PS: This introduces several python scripts, I have been using the "yapf"
tool to format them. If you know of a better python reformatter, let me
know.
From 45017badeade312778b7e0107873e9649ff52e34 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45
Le jeu. 17 sept. 2020 à 15:42, Alexei Podtelezhnikov a
écrit :
> > Patch attached for avoid adding lib prefix when compiling with mingw and
> also letting to use FT_CONFIG_OPTION_ERROR_STRINGS from cmake command line.
>
> The lib prefix is your personal aversion.
It depends. There is value for
Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG a écrit :
>
> > These are some horrible numbers that essentially test FT_Load_Glyph
> > from compressed unifont.pcf.gz in reverse order: [...]
> >
> > real0m6.062s
> >
> > The same string forward is much faster: [...]
> >
> > real0m0.486s
>
>
Le lun. 24 août 2020 à 22:34, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > - builds/meson/ftconfig.h.in: template versions of
> > ftconfig.h to be used by the Meson build. It is processed
> > by Meson, which will turn #mesondefine statements into
> > #define / #undef depending on
version of
the patch that does just that with a helper script.
I'd like to extend this scheme to more configuration variables in the
future, but after we complete this build transition.
- David
Thank you,
> Alexei
>
>
>
> On Mon, Aug 24, 2020 at 10:55 AM David Turner wrote:
> >
t; regards
>
> Vincent Torri
>
From 0035aef6df4d09924f987033228e56f32bd30166 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.
This adds a few files to build the FreeType 2 library
with the Meson build system:
- meson.build
ve you begun this work ? If yes, is it available so i can
> try it ?
>
> thank you
>
> Vincent Torri
>
From 63b49d6dd47df4f90cd08bc41e7ce9524dfe926d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.
This
)
Very fortunately, this is not part of a critical performance loop,
otherwise, we would do things differently.
> Vincent Torri
>
> On Fri, Jul 24, 2020 at 5:02 AM David Turner wrote:
> >
> > A better answer is to actually get rid of strcpy() / strcat() /
> sprintf() b
Le jeu. 23 juil. 2020 à 13:19, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Here's a patch to add a .clang-format style file to the directory.
>
> Thanks. I've slightly improved it, but I think there is still room
> for more fixes.
Good, can you share your updated version? We may not get
rncat are in function `Cur_U_Line'.)
>
> Hmm. The answer to
>
>
> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice
>
> recommends to switch off the warning if the code does exactly ...
>
>
> Werner
>
>
From dc5
.
- David
> By the way, do you have a reason to mix `FT_Set_Transform` with
> `FT_Glyph_Transform` to get the same advance widths? Otherwise, the
> difference shouldn't be an issue, right?
>
>
> Werner
>
From 631c16837f08cdabaa1d0fe76e0fe7dc3343a928 Mon Sep 17 00:00:00 2001
Fro
itionally, such a change should be
> introduced right after a release.
>
> > here's another patch that tries to fix this. Sorry about that.
> > Also Ben Wagner noticed me that some third-party code is using
> > FT_UNUSED(), so I've moved it back to public-macros.h to avoid
&g
ething after a switch to a new build system
> IMHO.
>
>
> Werner
>
From 0cfacffe05ae6eeffe2df0d0663fa4666a8b6afc Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.
The following builds were failing due to pr
o issues for you, David :-)
>
>
> Werner
>
From 8abef31464aea930e3d947fa611845eff97d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.
The following builds were failing due to previous changes:
make multi
make multi CC="c++"
Le mar. 30 juin 2020 à 15:27, Werner LEMBERG a écrit :
>
> > Here's the rebased and updated patch then.
>
> Thanks. However, what you've sent are actually two completely
> separate things: The splitting of `ftconfig.h` into smaller files, and
> the modification of `FT_BASE' and friends. Please
everyone.
>
> I definitely prefer '-' over '_'.
>
> Thanks, let's go with it. Here's the rebased and updated patch then.
>
> Werner
>
From 1d2fe6e959f4fb4a3321eab1a104298118273541 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Tue, 23 Jun 2020 20:54:41 +0200
S
Le mer. 24 juin 2020 à 13:49, Alexei Podtelezhnikov a
écrit :
> Hello David,
>
> > create mode 100644 include/freetype/config/compiler_macros.h
> > create mode 100644 include/freetype/config/integer_types.h
> > create mode 100644 include/freetype/config/mac_support.h
> > create mode 100644
avid
[1] Except if each thread has its own FT_Library instance (and
corresponding set of FT_Face/FT_Size/FT_GlyphSlot objects.
I will keep trying to comment on the two GSoC projects, and eventually get
> to write about the health of the freetype as a community project.
>
> Cheers,
> behda
code works as expected though?
Thanks
- David
Le mar. 23 juin 2020 à 20:16, David Turner a écrit :
>
>
> Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov
> a écrit :
>
>> Hi again,
>>
>> The oversampling is implemented though inflating the outline and then
>>
And the previous patch didn't handle CMakeLists.txt properly, so here's a
third version that fixes the issue.
Le mar. 23 juin 2020 à 22:25, David Turner a écrit :
> Good catch, here's the updated patch that also modifies
> builds/vms/ftconfig.h
>
> We might remove support for __BORL
and implement so far :)
Thank you
Le mar. 23 juin 2020 à 22:03, Alexei Podtelezhnikov a
écrit :
> On Tue, Jun 23, 2020 at 3:05 PM David Turner wrote:
> >
> > [build] Simplify
> >
> > This patch simplifies the content of ftconfig.h by
> > moving things around
From: David Turner
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify
This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:
- Move public compiler macros needed by the FreeType
API headers to ,
while all other macros that are only used
Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov a
écrit :
> Hi again,
>
> The oversampling is implemented though inflating the outline and then
> averaging the increased number of cells using FT_RASTER_FLAG_DIRECT
> mechanism. The first two patches set the stage by splitting the code
> paths
Le dim. 14 juin 2020 à 07:06, Stephen McDowell a
écrit :
> Hi Alexei,
>
> It's only __builtin_shuffle that's a problem. I'm a simd novice at best
> hehe. I played around for a good long while trying to find an equivalent
> shuffle intrinsic, for now I was just working off of the GCC examples
Hello everyone,
Le mar. 9 juin 2020 à 14:14, Alexei Podtelezhnikov a
écrit :
> Hi David,
>
> I actually thought about FT_Add_Module as a visionary interface for
> dynamically plugging alternative renderers:
>
> https://github.com/raphlinus/font-rs
> https://github.com/mooman219/fontdue
>
Thanks Werner, the patch looks good to me :-)
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit :
>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason why the FT_LONG_HEADER_NAME_H macros
> > were
Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov a
écrit :
>
> >> We can remove as well, can't we? It is only used to
> >> define the macros. So it is either ft2build.h and macros or neither.
> >
> > Not until all the consumers of FreeType are adapted to use direct
> > header inclusion
Le sam. 6 juin 2020 à 21:53, Greg Williamson a écrit :
> So autotools is the current build system but that will only work on linux
> and mingw correct? I can certainly check freetype builds with autotools on
> those platforms but I don't think it's compatible with msvc & xcode. I
> can't really
Le sam. 6 juin 2020 à 15:31, Werner LEMBERG a écrit :
>
> Hello Greg,
>
>
> > So over the week I started writing continuous integration build
> > tests for several platforms. You can preview them here:
> >
> https://dev.azure.com/fundies/freetype2/_build/results?buildId=146=results
>
> this
Le ven. 5 juin 2020 à 00:00, Werner LEMBERG a écrit :
>
> This is the first time ever that I got a git bundle to handle, and I'm
> stuck. I don't know how to apply it to the git repository. Trying
>
> git pull freetype2-remove-macro-includes.bundle
>
> results in
>
> fatal: Couldn't find
And here's the patch to fix freetype2-demos compilation first.
Le jeu. 4 juin 2020 à 02:42, David Turner a écrit :
> Since nobody does development on DOS or Windows 9x anymore, we can finally
> drop the requirement to use file names limited to the 8.3 format, which was
> the r
Le mar. 19 mai 2020 à 09:30, Priyesh kumar a
écrit :
> Thanks for the reply,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *>Basically yes. As an improvement, I would like that the value of
> the>`FT_COMPONENT` macro can be displayed optionally, e.g.>[afhints] foo
> bar>[ttgxvar] sproink>...>The idea is that
Le mar. 19 mai 2020 à 14:09, Hugh McMaster a
écrit :
> On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > > - Meson as the primary build system for FreeType developers, which
> > > includes the ability to run tests, sanitizers, coverage analysis,
> > > etc.
> >
> > It seems that Meson
Le lun. 18 mai 2020 à 10:49, Priyesh kumar a
écrit :
> Thanks for the reply...
>
> *>I recommend not baking details of the logging library into the rest of
> FreeType whenever possible. One thing that can be done is to send
> structured logs from FreeType, i.e. instead of >FT_Message() sending a
It turns out the macro is never used, anad is never included.
From 3d9ce21da3fb4af2a90147ee513add6542808dcd Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:33:38 +0200
Subject: [build] Remove obsolete HAVE_STDINT_H probing macro.
This macro was updated by the unix
Here are two patches to remove the Jamrules/Jamfiles from the build and
documentation.
- David
From bfae69d8320e269975ba59f6293031242e9d7653 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:16:12 +0200
Subject: [build] Remove Jamfile files from the tree.
These have not been
Le lun. 18 mai 2020 à 09:03, Priyesh kumar a
écrit :
> Hey,
> I wanted to ask that after selecting desirable external library how should
> I proceed:
> 1. Should I stick to the existing debugging facility in which filtering of
> log messages is based on debug level comparisons of various
I agree with Alexei that it's probably a good idea to start writing a
prototype with whatever language / format you feel the more fluent first so
we can look at the algorithms and the outputted data.
This can later be rewritten into something more FreeType-specific (e.g.
fixed-floats are better
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler a
écrit :
> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means
That's actually great feedback, thanks Piotr, we'll have a look.
Le dim. 17 mai 2020 à 20:47, Alexei Podtelezhnikov a
écrit :
> >> From the image, it is evident that both FreeType and TD renderer (my
> own renderer that relies on FreeType but uses my own rasterizer,
>
Le jeu. 14 mai 2020 à 20:35, piotrunio-2...@wp.pl a
écrit :
> The standard ppem of the test font is: 16
> The standard string of the test font is: !"#$%
>
> From the image, it is evident that both FreeType and TD renderer (my own
> renderer that relies on FreeType but uses my own rasterizer,
>
le. Any informed opinions on this?
I'm adding two git bundles related to the experiments I've described there
(nothing to consider for submission, imho, for now).
I'll prepare some patches to simplify our existing build files and
customization process as explained above, unless someone has bette
Do you have access to another Ceph cluster with enough available space to
create rbds that you dd these failing disks into? That's what I'm doing
right now with some failing disks. I've recovered 2 out of 6 osds that
failed in this way. I would recommend against using the same cluster for
this,
et through
it without data loss.
On Thu, Apr 30, 2020 at 10:14 PM David Turner wrote:
> I have 2 filestore OSDs in a cluster facing "Caught signal (Bus error)" as
> well and can't find anything about it. Ceph 12.2.12. The disks are less
> than 50% full and basic writes hav
mmit message to look like
what is currently in the git log.
> and track them in ChangeLog, which is debatable
>
> Yes, it seems a bit odd these days, but I'll let Werner be the judge on
that :-)
From 1b44f35d259622ebb837d9d00833502ac751df13 Mon Sep 17 00:00:00 2001
From: David Turner
From: David Turner
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: Fix compilation warnings
Fix various compiler warnings when building the FreeType 2
demo programs:
- graph/x11/grx11.c: Changed the return type of
gr_x11_surface_listen_event() to match the expected type.
- src/: Remove
Yes, none of that is urgent :) Feel free to not push them to master for now
(branch or no branch).
I'd still value your input on the content though, hope it's not too scary :)
Le ven. 1 mai 2020 à 10:25, Werner LEMBERG a écrit :
>
> > Here are two cumulative patches that try to simplify the
Le ven. 1 mai 2020 à 10:12, Albert Astals Cid a écrit :
>
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you
> could please explain what's wrong with it so I can try to improve myself in
> the future.
>
>
I have 2 filestore OSDs in a cluster facing "Caught signal (Bus error)" as
well and can't find anything about it. Ceph 12.2.12. The disks are less
than 50% full and basic writes have been successful. Both disks are on
different nodes. The other 14 disks on each node are unaffected.
Restarting the
Le jeu. 30 avr. 2020 à 10:40, Nikolaus Waxweiler a
écrit :
> One thing regarding build systems and IDE/tool integration:
>
> Cmake and others can generate a
> https://clang.llvm.org/docs/JSONCompilationDatawas a portabililty
> nightmarebase.html
>
Le jeu. 30 avr. 2020 à 03:30, Alexei Podtelezhnikov a
écrit :
> On Wed, Apr 29, 2020 at 8:34 PM David Turner wrote:
> >
> > Starting a thread here to discuss potential build system improvements
> for FreeType.
> >
> > The current FreeType 2 build system
r the
> > next few months I expect us to remove our cmake one and eventually the
> > autotools one (which is the "official" one right now).
> >
> > Hope that helps,
> > behdad
> >
> > On Wed, Apr 29, 2020 at 5:34 PM David Turner wrote:
> >
>
system at all!
- David
From 4095fc04234a73b825dc122b86d903835988863d Mon Sep 17 00:00:00 2001
From: David Turner
Date: Thu, 30 Apr 2020 11:03:33 +0200
Subject: build: Simplify module.mk syntax
This patch modifies the syntax expected from module.mk
files to make it considerably simpler. Now, each fi
ype 1.3.1 !!
ReactOS: ??
Skia: https://github.com/google/skia/tree/master/third_party/freetype2
modules: no raster1, type1, pfr, bitmapped formats
options: seems to be using the default, i.e. no subpixel rendering, no
harfbuzz, no adobe glyph list
Le ven. 24 avr. 2020 à 16:02, David Turner a écrit :
Le ven. 24 avr. 2020 à 22:46, Nikolaus Waxweiler a
écrit :
> Woah
>
> My favorite pet issue I never got around to fixing: make stem darkening
> for the autohinter be as good as the CFF variant. Also, at least basic
> stem darkening for bytecode'd TTFs.
Can you clarify what that means
Thank you, filed as https://savannah.nongnu.org/bugs/index.php?58275 now
Le mer. 29 avr. 2020 à 18:18, WILSON, MICHAEL a
écrit :
> Good afternoon,
>
>
>
> When building FreeType, GCC is warning of strncpy() calls which are not
> nul terminated.
>
> Probably not a big problem in view of the
Starting a thread here to discuss potential build system improvements for
FreeType.
The current FreeType 2 build system has many flaws. To its credit, it was
designed in a very different time, when things like CMake / Meson / Ninja/
Maven / GN / Bazel didn't even exist, when Autotools was
f someone is opposed to that, please speak up!
- David
> best regards
>
> Vincent Torri
>
> On Fri, Apr 24, 2020 at 10:02 PM David Turner wrote:
> >
> > Hello freetype-devel@ list members,
> >
> > It's been a very very long time, but I have some free time in
this in small
incremental steps.
Voila, I'd be happy to read your suggestions, Happy to be here.
- David Turner
[
https://issues.apache.org/jira/browse/LUCENE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Turner updated LUCENE-9138:
-
Description:
I think this is a documentation issue, rather than anything actually wrong
[
https://issues.apache.org/jira/browse/LUCENE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Turner updated LUCENE-9138:
-
Description:
I think this is a documentation issue, rather than anything actually wrong
[
https://issues.apache.org/jira/browse/LUCENE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Turner updated LUCENE-9138:
-
Description:
I think this is a documentation issue, rather than anything actually wrong
[
https://issues.apache.org/jira/browse/LUCENE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Turner updated LUCENE-9138:
-
Description:
I think this is a documentation issue, rather than anything actually wrong
David Turner created LUCENE-9138:
Summary: Behaviour of concurrent calls to IndexInput#clone is
unclear
Key: LUCENE-9138
URL: https://issues.apache.org/jira/browse/LUCENE-9138
Project: Lucene - Core
New submission from David Turner :
Trying to set up shortcut function to clear screen but its not working as
expected on my Mac OS Catalina -- below is txt from idle
import os
>>> cls= lambda: os.system('clear')
>>> cls()
256
--
messages: 358908
nosy: twiste...@
This is a tangent on Paul Emmerich's response to "[ceph-users] Correct
Migration Workflow Replicated -> Erasure Code". I've tried Paul's method
before to migrate between 2 data pools. However I ran into some issues.
The first issue seems like a bug in RGW where the RGW for the new zone was
able
Of the top of my head, if say your cluster might have the wrong tunables
for crush-compat. I know I ran into that when I first set up the balancer
and nothing obviously said that was the problem. Only researching find it
for me.
My real question, though, is why aren't you using upmap? It is
Most times you are better served with simpler settings like
osd_recovery_sleep, which has 3 variants if you have multiple types of OSDs
in your cluster (osd_recovery_sleep_hdd, osd_recovery_sleep_sdd,
osd_recovery_sleep_hybrid).
Using those you can tweak a specific type of OSD that might be having
Yes, there is nothing wrong with this and had been a common scenario for
people during their migration from filestore to bluestore.
On Tue, Oct 22, 2019, 9:46 PM Frank R wrote:
> Is it ok to create a new OSD using ceph-volume on a server where the other
> OSDs were created with ceph-disk?
>
>
I did a set of 30GB OSDs before with extra disk space on my SSDs for the
metadata pool on cephfs and my entire cluster locked up about 3 weeks
later. Some metadata operation was happening, filled some of the 30GB disks
to 100%, and all IO was blocked in the cluster. I did some trickery of
deleting
ain David
>
> On 16/10/2019 14.22, 'David Turner' via Django users wrote:
>> Thanks for pointing me in the right direction.
>
> No problem. Happy to help.
>
> Just a pedantic note on your solution:
>
>> I added a simple
>> try:
>> y = fl
1 - 100 of 4208 matches
Mail list logo
