I'm guessing because mingw is providing a special implementation for printf
(and related functions) that supports %zu instead of linking to the old C89
one, but the GCC attribute checker is not aware of that.
On Fri, Jan 3, 2020 at 12:43 PM jp charras wrote:
> After some tests:
>
> printf("test
After some tests:
printf("test %zu", size_t(1) );
works, and there is no compil warning.
Functions that generate a warning about %zu format are:
StrPrintf()
OUTPUTFORMATTER::Print()
(see richio.h)
they have the attribute:
__attribute__ ((format (printf, 2, 3)))
or
__attribute__ ((format
Le 03/01/2020 à 16:02, Ian McInerney a écrit :
> JP, is that mingw32 directly, or was it provided by mingw-w64
> indirectly? It appears that mingw32 (the original compiler version)
> doesn't have the compatibility enabled but the forked version mingw-w64
> does. (there was discussion about this on
wxWidgets has a interesting maze of macros to determine how to do
printf on Windows. I wonder what it ends up doing. There is a special
case just for MINGW32 but not MINGW64.
https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84
On
Le 03/01/2020 à 15:58, Jon Evans a écrit :
> So maybe it's a 32-bits vs 64-bits thing.
> If you add a line like
> #define __USE_MINGW_ANSI_STDIO 1
> at the top of that source file, does it work?
No.
I still have the compil message:
warning: unknown conversion type character 'z' in format
JP, is that mingw32 directly, or was it provided by mingw-w64 indirectly?
It appears that mingw32 (the original compiler version) doesn't have the
compatibility enabled but the forked version mingw-w64 does. (there was
discussion about this on the mingw users mailing list:
So maybe it's a 32-bits vs 64-bits thing.
If you add a line like
#define __USE_MINGW_ANSI_STDIO 1
at the top of that source file, does it work?
On Fri, Jan 3, 2020 at 9:32 AM jp charras wrote:
> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> >
I found it defined in
C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h on
my machine.
@JP -- what platform did you use (Windows version / MSYS version / etc)
where you saw the issue?
On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand wrote:
> On 2020-01-02 17:19, Jon Evans
Le 03/01/2020 à 15:10, Jon Evans a écrit :
> I found it defined in
> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> on my machine.
> @JP -- what platform did you use (Windows version / MSYS version / etc)
> where you saw the issue?
I confirm the %zu is not working on
On 2020-01-02 17:19, Jon Evans wrote:
Hi all,
Context:
https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
I have heard there are issues using "%zu" format specifier on
Windows/mingw, because mingw links against a very old Windows library
that does not support the C99
Is __USE_MINGW_ANSI_STDIO actually defined in the wxWidgets builds we use?
A quick search through their codebase for that symbol only shows them
testing for it and never actually defining it.
-Ian
On Fri, Jan 3, 2020 at 1:20 AM Jon Evans wrote:
> Hi all,
>
> Context:
>
Hi all,
Context:
https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
I have heard there are issues using "%zu" format specifier on
Windows/mingw, because mingw links against a very old Windows library that
does not support the C99 standard.
I have also heard that this isn't an
It might be handy in debug builds to show the dangling state for
development purposes but I don't see this being useful for users.
On 4/4/2019 1:39 PM, Jon Evans wrote:
> I bet it's an oversight. Dangling flags are in the category of "live
> ERC warnings" in my opinion, and should never be
I bet it's an oversight. Dangling flags are in the category of "live ERC
warnings" in my opinion, and should never be printed.
On Thu, Apr 4, 2019 at 1:11 PM Jeff Young wrote:
> SCH_BUS_ENTRY is the only item which *prints* its dangling flags.
> (Everything else only draws them on screen.)
>
SCH_BUS_ENTRY is the only item which prints its dangling flags. (Everything
else only draws them on screen.)
Is this an oversight or intentional?
Thanks,
Jeff.___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
On 28.04.2015 16:53, jp charras wrote:
Le 28/04/2015 15:43, Sergey A. Borshch a écrit :
Hi everyone.
Someone broke printing again.
bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong
direction(?).
See attached screenshots.
AFAIK, there is no changes in printing/drawing
Le 29/04/2015 09:34, Sergey A. Borshch a écrit :
On 28.04.2015 16:53, jp charras wrote:
Le 28/04/2015 15:43, Sergey A. Borshch a écrit :
Hi everyone.
Someone broke printing again.
bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong
direction(?).
See attached
On 29.04.2015 11:02, jp charras wrote:
Le 29/04/2015 09:34, Sergey A. Borshch a écrit :
On 28.04.2015 16:53, jp charras wrote:
Le 28/04/2015 15:43, Sergey A. Borshch a écrit :
Hi everyone.
Someone broke printing again.
bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong
Hi everyone.
Someone broke printing again.
bzr rev. 5596 prints ok, while today bzr rev. 5628 print arcs in wrong
direction(?).
See attached screenshots.
--
Regards,
Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia
Le 27/03/2015 12:42, Sergey A. Borshch a écrit :
On 26.03.2015 15:14, jp charras wrote:
Le 26/03/2015 13:36, Sergey A. Borshch a écrit :
I am pretty sure this component was not build with libedit. (Arcs have
bugs).
Can you confirm that?
No, I can't confirm yet. This component was published
On 25.03.2015 19:35, Maciej Sumiński wrote:
Hi Sergey,
Thank you for the report, screenshots were very helpful. Could you try
the latest revision? (5536 up)
Excellent. Now it works without any visible issues. Thank You once more.
--
Regards,
Sergey A. Borshchmailto:
Hi Maciej,
On 25.03.2015 19:35, Maciej Sumiński wrote:
Hi Sergey,
Thank you for the report, screenshots were very helpful. Could you try
the latest revision? (5536 up)
As I wrote, printing on my schematics and pcb works great now.
But one man reported that transformer from attached library
Le 26/03/2015 13:36, Sergey A. Borshch a écrit :
Hi Maciej,
On 25.03.2015 19:35, Maciej Sumiński wrote:
Hi Sergey,
Thank you for the report, screenshots were very helpful. Could you try
the latest revision? (5536 up)
As I wrote, printing on my schematics and pcb works great now.
But
On 26.03.2015 15:14, jp charras wrote:
Le 26/03/2015 13:36, Sergey A. Borshch a écrit :
I am pretty sure this component was not build with libedit. (Arcs have
bugs).
Can you confirm that?
No, I can't confirm yet. This component was published on one russian forum, but
I forwarded your
On 25.03.2015 13:02, Maciej Sumiński wrote:
I have just pushed a patch that should resolve the printing issues. I
did my best to test it with Windows and Linux, but it would be great if
you could try it in your system too. Printing preview is quite accurate,
so if you do not have a printer - it
Orson,
Thanks for looking into this. Linux users will appreciate your efforts.
As far as I can tell, it didn't break anything on windows. The mirrored
printing is still broken on windows with wx 3.0.2 but that has nothing
to do with your changes. I have to keep a build of 3.0.1 to do mirrored
25/03/15, 17:36, Wayne Stambaugh kirjoitti:
to do with your changes. I have to keep a build of 3.0.1 to do mirrored
printing so I can etch prototype boards. I'll test this on linux when I
Even nicer for prototyping is importing the .ps or .pdf to Inkscape, do
panelization and alignment,
On 25.03.2015 18:24, Wayne Stambaugh wrote:
On 3/25/2015 12:22 PM, jp charras wrote:
Le 25/03/2015 16:36, Wayne Stambaugh a écrit :
Orson,
Thanks for looking into this. Linux users will appreciate your efforts.
As far as I can tell, it didn't break anything on windows. The mirrored
On 03/25/2015 01:40 PM, Sergey A. Borshch wrote:
On 25.03.2015 13:02, Maciej Sumiński wrote:
I have just pushed a patch that should resolve the printing issues. I
did my best to test it with Windows and Linux, but it would be great if
you could try it in your system too. Printing preview is
Le 25/03/2015 16:36, Wayne Stambaugh a écrit :
Orson,
Thanks for looking into this. Linux users will appreciate your efforts.
As far as I can tell, it didn't break anything on windows. The mirrored
printing is still broken on windows with wx 3.0.2 but that has nothing
to do with your
On 3/25/2015 1:02 PM, Vesa Solonen wrote:
25/03/15, 17:36, Wayne Stambaugh kirjoitti:
to do with your changes. I have to keep a build of 3.0.1 to do mirrored
printing so I can etch prototype boards. I'll test this on linux when I
Even nicer for prototyping is importing the .ps or .pdf to
Le 25/03/2015 18:24, Wayne Stambaugh a écrit :
On 3/25/2015 12:22 PM, jp charras wrote:
Le 25/03/2015 16:36, Wayne Stambaugh a écrit :
Orson,
Thanks for looking into this. Linux users will appreciate your efforts.
As far as I can tell, it didn't break anything on windows. The mirrored
I have just pushed a patch that should resolve the printing issues. I
did my best to test it with Windows and Linux, but it would be great if
you could try it in your system too. Printing preview is quite accurate,
so if you do not have a printer - it might be the way to check the result.
It
Done.
29 февраля 2012, 19:21 от Dick Hollenbeck d...@softplc.com:
On 02/29/2012 03:20 AM, Alexander Zakamaldin wrote:
Hi, Dick!
I am sorry in advance, but I think there is no need for you to investigate
this
problem. Just because I have already fixed it. The bug is deep inside
29 февраля 2012, 20:42 от Alexander Zakamaldin zak...@mail.ru:
Done.
Hi, Alexander!
Very good work.
distr - mageia x86_64
Direct printing from kicad - OK!
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Hi!
Well, we can assume the landscape printing is fixed. Another big disadvantage
for wxGnomePrint users is a 72 dpi limitation. As I can see, initial workaround
for this issue is done in wx 2.9.3. It should be mentioned, that this is a
wxGnomePrint
issue. And I think, this work must have been
Please explain in detail what are the symptoms of the problem. That
is, how do you know it is not working.
:
By the way, these arguments do not apply to the current
implementation of Kicad testing branch. These assumptions are
significant if we are going to implement page orientation
Are you having problems with the margin?
I see that for KICAD_GOST there is an asymmetrical margin, and a rotation of
the paper
without a corresponding rotation of the margins might be giving you grief.
Is this what the problem is?
___
Mailing
Yes, sure. I wrote about US Ledger paper size.
It should be mentioned, the US Ledger's size confuses not only me, but
Gnomeprint job also.
So, what is the best choice to do?
1. Assume the US Ledger is 11x17 inches size, just the same as 'Inkscape'
project is doing.
2. Replace US Ledger with US
http://www.graphic-design-employment.com/tabloid-paper-dimensions.html
http://www.graphic-design-employment.com/ledger-paper-dimensions.html
It seems there is no portrait tabloid or landscape ledger. This paper size
confusion shows a good example why well thought standard is usually a good
On 02/27/2012 02:50 AM, Alexander Zakamaldin wrote:
Yes, sure. I wrote about US Ledger paper size.
It should be mentioned, the US Ledger's size confuses not only me, but
Gnomeprint job also.
Please explain in detail what are the symptoms of the problem. That is how do
you know it
is not
41 matches
Mail list logo
