Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Sonntag, 20. Dezember 2015 04:21:29 CEST, Kevin Kofler wrote:

The kdewin team should just point people to a flex.exe that produces files 
that work with the bitrotten C compiler included with Visual C++.


So we only need somebody who forks the hardly maintained flex/yacc tools for 
windows...

It should be simpler to point windows users to a recent MSVC (2015), gcc, 
clang, or icc (ie. mandate them for KF5, raising the bar from Qt5)

We could then indeed raise to -c99 and "guarantee" compilation only for 
compatible compilers (while older MSVC *may* still work)

I'd say it's up to the kdewin people to state their preferences here
- require bison and switch to c++ in the flex/yacc toolchain
- (soft)require a c99 compliant compiler (where MSVC 2013 *may* still work)


Another, more practical, reason is that if a bug (maybe a security issue)
affecting the generated output is fixed in Flex, the pre-generated files
would not pick up the fix.


Actually, that rather supports shipping pre-generated code (given the apparent 
support situation of flex/yacc on windows - windows users could encounter flex 
bugs none of us ever sees and the backtraces make no sense...)

Cheers,
Thomas

Re: Why is C90 enforced in KDE?

[Christian Ehrlicher]

Am 20.12.2015 um 10:24 schrieb Thomas Lübking:

On Sonntag, 20. Dezember 2015 04:21:29 CEST, Kevin Kofler wrote:

The kdewin team should just point people to a flex.exe that produces 
files that work with the bitrotten C compiler included with Visual C++.


So we only need somebody who forks the hardly maintained flex/yacc 
tools for windows...
I think this one is actively maintained: 
https://sourceforge.net/projects/winflexbison/ and I used it to compile 
Qt5.5 with msvc2013 (somewhere in the qt docs there's a link to this 
project). So it *should* work with KF5 too. But someone has to test it. 
It's out of my scope because currently I don't have a working 
environment for KF5.



Christian

Re: Why is C90 enforced in KDE?

[Kevin Kofler]

Thomas Lübking wrote:
> as a build dep requires it, "we just need //" isn't true - the
> requirements are controlled outside

Well, in that case, this:

> - pipe flex/yacc results through c++ rather than the C compiler

won't do much good, because the C++ compiler will not necessarily grok any 
other C99isms in the code. This only really helps for "//" comments.

My suggestion is:
* do not ship Flex-generated code, and
* document the compatibility issue, and let it be the user's responsibility
  to use a version of Flex compatible with their compiler, which may be an
  older or patched one.

This is entirely a compatibility issue between 2 build tools (Flex and the 
compiler), I don't see how this should be our (KDE's) problem.

Kevin Kofler

Re: Why is C90 enforced in KDE?

[Michael Pyne]

On Sun, December 6, 2015 16:08:04 Antonio Rojas wrote:
> Hi,
>  Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated
> code in libpanorama containing //-style comments, which are disallowed in
> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect,
> since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What
> is the reason for this? And is there any way to force using C99?

I'm not sure offhand... it may be due to trying to support builds using MSVC 
on Windows (which has poor C99 or later support). On the other hand even MSVC 
supports //comments in C code.

I think there's some way to get CMake to add compiler flags for .c files in 
particular; another option is to have flex generate a .cpp file, assuming that 
the code being generated is safely in the common subset of C and C++.

Regards,
 - Michael Pyne

Re: Why is C90 enforced in KDE?

[Boudhayan Gupta]

On 10 December 2015 at 12:04, Boudewijn Rempt  wrote:
> I'm right now using msvc 2015 myself -- which gives other problems with
> other
> dependencies.

Microsoft now has clang (running on the Microsoft Code Generator as
well as LLVM) - maybe we could look into using that on Windows? It's
supposed to be an (optional, IIRC) part of VS2015 and will be
continually supported and updated.

So if we can kick out cl.exe support, that's one less compiler
frontend to support. Note that clang with Microsoft CodeGen is
theoretically pretty much the same as cl.exe (in both cases the AST is
converted to machine code by MSCG only), except that with clang we get
superior parser and C++11/14 and C90 support.

-- Boudhayan

Re: Why is C90 enforced in KDE?

[Boudewijn Rempt]

On Thu, 10 Dec 2015, Boudhayan Gupta wrote:


On 10 December 2015 at 12:04, Boudewijn Rempt  wrote:

I'm right now using msvc 2015 myself -- which gives other problems with
other
dependencies.


Microsoft now has clang (running on the Microsoft Code Generator as
well as LLVM) - maybe we could look into using that on Windows? It's
supposed to be an (optional, IIRC) part of VS2015 and will be
continually supported and updated.

So if we can kick out cl.exe support, that's one less compiler
frontend to support. Note that clang with Microsoft CodeGen is
theoretically pretty much the same as cl.exe (in both cases the AST is
converted to machine code by MSCG only), except that with clang we get
superior parser and C++11/14 and C90 support.


Well, it's more like "building boost with msvc 2015 doesn't add the compiler
version number to the dll names, which means that the cmake code that looks for
boost fails to find the dll's, even though they are there, because the name
pattern cmake is hard-coded for fails, so you need to manually rename the
dll's" or "msvc 2015 still insists on really small stacks, so g'mic's stack
based recursive parser, which needs 8mb of stack minimum, runs out of stack".

It's all those effing little things that add up and make building an application
with a few dozen dependencies a herculean task. And every dependency seems to
have _something_. In the Qt4 days, Qt didn't want to link to zlib.lib, it needed
libzlib.lib, for instance.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Why is C90 enforced in KDE?

[Luca Beltrame]

Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto:

> Unfortunately, Linux distros aren't the main platform anymore for the
> KDE software _I_ maintain.

Given you've said this multiple times, with my packager hat on I'll just 
mention this: just don't make it harder *for us* to work just because 
you're targeting another platform. You may not care for Linux distros, but 
there are people who *do*.

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B

Re: Why is C90 enforced in KDE?

[Scott Kitterman]

On Monday, December 07, 2015 04:33:37 PM Thomas Lübking wrote:
> On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote:
> > Given you've said this multiple times, with my packager hat on I'll just
> > mention this: just don't make it harder *for us* to work just because
> > you're targeting another platform.
> 
> I actually don't think this related at all.
> 
> Compiling C99 (beyond some minor additions like the comments, but that's not
> guaranteed to be the only usage) on MSVC is a general problem to begin with
> (if you care about elder versions of what MS calls a "compiler"), so
> Boudewijn's primary problem is the usage of flex/yacc to begin with and
> he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc being
> translated to *.cpp (where "i build every shit and just guess what the
> developer meant" MSVC still sucks, but not that much)
> 
> Distros and notably self-builders would probably prefer such as well (less
> build time dependency, yeah!), so there's no conflict.
> 
> Otoh, developers will prefer to have flex/yacc in the CI and will require a
> cmake rule to include *.l & *.y in the source list (so it's regenerated on
> local changes) but otherwise there's (afaik) no strong reason to not simply
> ship the pre-translated sources (along the lex sources which are usually
> not invoked on build)
> 
> The situation is (afaik) slightly different w/ *.moc since you might run
> into "the moc that generated this header is too old" issues (latter
> happens, so we can/should not ship pre-built mocs; but I'm not sure whether
> such problems can show up with lex as well)

As long as you also ship the source, as a Debian packager, I'm happy.  We have 
to have preferred form of modification and the ability to rebuild from that 
source.  It's not 100% required that we rebuild, but how do you know you can, 
unless you do.  I don't mind the additional dependency at all.

My preference would be that on Linux, at least, if flex/yacc are detected, the 
rebuilding is automatic.

Scott K

Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote:

Given you've said this multiple times, with my packager hat on I'll just 
mention this: just don't make it harder *for us* to work just because 
you're targeting another platform.


I actually don't think this related at all.

Compiling C99 (beyond some minor additions like the comments, but that's not guaranteed to be the 
only usage) on MSVC is a general problem to begin with (if you care about elder versions of what MS 
calls a "compiler"), so Boudewijn's primary problem is the usage of flex/yacc to begin 
with and he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc being translated to 
*.cpp (where "i build every shit and just guess what the developer meant" MSVC still 
sucks, but not that much)

Distros and notably self-builders would probably prefer such as well (less 
build time dependency, yeah!), so there's no conflict.

Otoh, developers will prefer to have flex/yacc in the CI and will require a cmake 
rule to include *.l & *.y in the source list (so it's regenerated on local 
changes) but otherwise there's (afaik) no strong reason to not simply ship the 
pre-translated sources (along the lex sources which are usually not invoked on 
build)

The situation is (afaik) slightly different w/ *.moc since you might run into "the 
moc that generated this header is too old" issues (latter happens, so we can/should 
not ship pre-built mocs; but I'm not sure whether such problems can show up with lex as 
well)

Cheers,
Thomas, Baseball cap - I've not hats.

Re: Why is C90 enforced in KDE?

[Boudewijn Rempt]

On Mon, 7 Dec 2015, Luca Beltrame wrote:


Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto:


Unfortunately, Linux distros aren't the main platform anymore for the
KDE software _I_ maintain.


Given you've said this multiple times,


Yes, and I'll go on saying it until I feel people are listening... Which
I feel hasn't happened yet.


with my packager hat on I'll just
mention this: just don't make it harder *for us* to work just because
you're targeting another platform.


There are two sides, of course: if making it easier for a distribution
to package KDE software makes it harder for an application to be packaged
for another distribution, where do we go? What's most important? Just
adding a dependency because all linux distributions have it so it's no
sweat can cause huge problems.


You may not care for Linux distros, but
there are people who *do*.


I care about Linux, I care for Linux distributions and I've always done.
I hate having to work on OSX (especially OSX) or Windows, but I don't
have a choice here. And if the KDE frameworks are supposed to be cross-platform,
development needs to reflect that, and anything that's making life easy
for a distribution should be weighed and considered and maybe rejected
if it's making life harder for users of the KDE frameworks on other platforms.

The alternative is doing what Gnome did: declare the KDE Frameworks
Linux-only. That would be a clear, honest step to take, and I wouldn't
actually oppose it. But it would put an end to the story that KDE Frameworks
are just additions to Qt that everyone can use.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Montag, 7. Dezember 2015 03:14:05 CEST, Kevin Kofler wrote:
not surprised that they are now using C99 comments (which ARE compliant to 
the current C standard, and have been for 16 years (!)).


Sure, but since it seems it's the only C99 feature used(?, stdint is more a library 
thing, at least gcc more or less tagged it as such¹), this looks like an intended break. 
At least I completely fail to see the advantage of c++ style comments for a machine 
(rather the opposite, since "dumb" appending to lines can now produce undesired 
results)

Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either we
- raise the bar in kdelibs/KF5 to require a C99 compliant compiler (as a build dep 
requires it, "we just need //" isn't true - the requirements are controlled 
outside
- ship only pre-produced and hand-fixed code from flex/yacc
- pipe flex/yacc results through c++ rather than the C compiler

Cheers,
Thomas

[1] https://gcc.gnu.org/c99status.html

Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)

[Thomas Lübking]

On Montag, 7. Dezember 2015 01:08:31 CEST, Nicolás Alvarez wrote:


It will look better to stick my app logo into the real-artist-designed
piece-of-paper-with-shadow than to draw an icon from scratch...


Afaiu, one should have asked the oxygen team to avoid this kind of patched 
icons.



I don't think that's the case. Surely the
preferred way to modify an icon is to edit the SVG and rasterize it
again.


Again: that's processing. The required file was the png (since svg icons were 
initially not even supported and even now the Qt svg renderer is completely not 
up to inkscape features extending vanilla svg)


If you used gimp, you should put your multilayer .xcf


**mt** - it's not simply "multilayer", that's just an intermediate result. 
The (hypothetical) icon was forged using several destructive processes to get the pixels 
colorful in the desired way - which are not documented anywhere.
It could even haven been done in the very same layer or layer merging was one 
of the required process steps.
A rastered image really completely rests in itself - no matter what tools were 
used to forge it. A vector editor is just a process detail; the same result 
could have been achieved in MS paint (with a lot of time ;-)

Cheers,
Thomas

Re: Why is C90 enforced in KDE?

[Boudewijn Rempt]

On Mon, 7 Dec 2015, Kevin Kofler wrote:


+1, of course we should not. Generated files have no business being in a
source control or in source tarballs. "BuildRequires: flex" is one line in a
distro specfile.


Unfortunately, Linux distros aren't the main platform anymore for
the KDE software _I_ maintain.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote:


There are two sides, of course: if making it easier for a distribution
to package KDE software makes it harder for an application to be packaged
for another distribution, where do we go? What's most important? Just
adding a dependency because all linux distributions have it so it's no
sweat can cause huge problems.


Back on topic: do you actually have trouble with invoking flex/yacc* to 
generate code or do you have a problem with the generated (C99) code (what 
seems to be a pretty new problem - and is on Linux/any distro because KF5 does 
--std=c90)?

Or was this just a general "Hey, there's a world beyond Linux" remark?

You also may have some (personal, at least) data on relevant MSVC 2013 is in 
practice?
Because every gcc in the wild as well as clang should be able to handle C99 - 
and so should MSVC 2015 and the intel compiler(s of the past). Afaics, MSVC 
2013 is the deal breaker here; but no warranty on that statement...

Cheers,
Thomas

* other than "install it" - Windows doesn't come with a compiler by default 
either.

Re: Why is C90 enforced in KDE?

[Patrick Spendrin]

Am 07.12.2015 um 21:36 schrieb Thomas Lübking:
> On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote:
> 
>> There are two sides, of course: if making it easier for a distribution
>> to package KDE software makes it harder for an application to be packaged
>> for another distribution, where do we go? What's most important? Just
>> adding a dependency because all linux distributions have it so it's no
>> sweat can cause huge problems.
> 
> Back on topic: do you actually have trouble with invoking flex/yacc* to
> generate code or do you have a problem with the generated (C99) code
> (what seems to be a pretty new problem - and is on Linux/any distro
> because KF5 does --std=c90)?
> 
> Or was this just a general "Hey, there's a world beyond Linux" remark?
> 
> You also may have some (personal, at least) data on relevant MSVC 2013
> is in practice?
> Because every gcc in the wild as well as clang should be able to handle
> C99 - and so should MSVC 2015 and the intel compiler(s of the past).
> Afaics, MSVC 2013 is the deal breaker here; but no warranty on that
> statement...

IIRC the problem here is(was) the version of flex/bison used. There was
only a very outdated version of flex/bison available for a long time,
and this one produced different results from a more modern version. When
I looked last, there was a newer build available for both, which was
recent enough and which also produced valid results (in at least some
cases).
I would recommend thus to test those two first, to see if there is a
problem at that point at all (and if needed, then it is possible to
decide that on a case by case basis - there shouldn't be to many
flex/bison uses in total KDE code).

About C99:
I am not sure which compiler is currently required with MSVC, but if it
is 2013 or below, then only some C99 features are supported.

I tried to create a C99-to-C90 compiler with the help of clang, but this
failed pretty early.

So my advice would be to not make C90 default, but to allow some C99
features, but with improved CI instead.

regards,
Patrick

Re: Why is C90 enforced in KDE?

[Thiago Macieira]

On Monday 07 December 2015 09:29:59 Thomas Lübking wrote:
> Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either
> we

Qt 5.6 supports MSVC 2008. Qt 5.7 raises the minimum to MSVC 2012.

Neither compiler supports stdint.h or some other nice C99 functions, like 
isnanf. You need MSVC 2013 for that.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Why is C90 enforced in KDE?

[Thiago Macieira]

On Monday 07 December 2015 21:36:13 Thomas Lübking wrote:
> You also may have some (personal, at least) data on relevant MSVC 2013 is in
> practice? Because every gcc in the wild as well as clang should be able to
> handle C99 - and so should MSVC 2015 and the intel compiler(s of the past).
> Afaics, MSVC 2013 is the deal breaker here; but no warranty on that
> statement...

MSVC 2013 has good support for C99. MSVC 2012 does not.

I should point all that MSVC has supported // comments in C sources since 
before it was known as Visual.

But that's not the problem. The problem is the C99 Library, which MSVC did not 
support until 2013 and it only did so because C++11 imported it by reference.

Microsoft does not care for C. They didn't implement C99 because they didn't 
want to, not because their compiler team was unable to.

So my recommendation: write C++ code.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Why is C90 enforced in KDE?

[Allen Winter]

On Sunday, December 06, 2015 04:08:04 PM Antonio Rojas wrote:
> Hi,
>  Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated 
> code in libpanorama containing //-style comments, which are disallowed in 
> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, 
> since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What 
> is the reason for this? And is there any way to force using C99?
> 
We have (had?) a policy that flex/yacc generated source files should be part of 
the repo.
do not make everyone run flex/yacc when building.

Re: Why is C90 enforced in KDE?

[Nicolás Alvarez]

2015-12-06 12:54 GMT-03:00 Thomas Lübking :
> On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote:
>>
>> C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any
>> effect, since it is overriden by kdelibs (and by extra-cmake-modules in
>> KF5). What is the reason for this?
>
>
> I guess because of poor compiler support.
> One needs MSVC 2013 for at least *some* C99 support :-P
> (2015 should be somewhat complete, though)

I guess -std=c90 is used to make sure nobody accidentally introduces
C99 features that will break in older compilers. However, all
compilers we care about support // comments in C code... I didn't find
any way for gcc to allow // but disallow other C99 features.

Maybe we should use -std=gnuc90 -Wpedantic in gcc instead of -std=c90,
so that GNU extensions (including // comments) are allowed but give
warnings. Then we ignore warnings about // comments and pay attention
to others (in case someone accidentally introduces a GNU extension and
breaks the build in other compilers).

Of course, another way to get what we want is to not use -std=c90, but
have proper CI for MSVC. That way we'll know if someone adds
unsupported C99 features :)

-- 
Nicolás

Why is C90 enforced in KDE?

[Antonio Rojas]

Hi,
 Kipi-plugins fails to build with flex 2.6. This is due to the autogenerated 
code in libpanorama containing //-style comments, which are disallowed in 
C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, 
since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What 
is the reason for this? And is there any way to force using C99?

Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote:
C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, 
since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What 
is the reason for this?


I guess because of poor compiler support.
One needs MSVC 2013 for at least *some* C99 support :-P
(2015 should be somewhat complete, though)

Cheers,
Thomas

Re: Why is C90 enforced in KDE?

[Nicolás Alvarez]

2015-12-06 13:13 GMT-03:00 Allen Winter :
> We have (had?) a policy that flex/yacc generated source files should be part 
> of the repo.
> do not make everyone run flex/yacc when building.

I disagree with this. It has happened to me more than once that I
modify a flex file, regenerate it, and find it has been broken for
*years* due to incompatibilities with newer flex versions and nobody
noticed. Or I forget to regenerate it.

Should we put .mo files in the SVN translation directories so that
people don't need msgfmt? Should we put .moc files in git?
kdevelop-pg-qt generated parsers? Code made from .ui files? Code made
by kconfig_compiler from .kcfg files? kapptemplate tarballs?

If it was up to me, there wouldn't even be .png icons in git version
control, they would be generated from their .svg files at compile
time.

-- 
Nicolás

Re: Why is C90 enforced in KDE?

[Allen Winter]

On Sunday, December 06, 2015 01:34:51 PM Nicolás Alvarez wrote:
> 2015-12-06 13:13 GMT-03:00 Allen Winter :
> > We have (had?) a policy that flex/yacc generated source files should be 
> > part of the repo.
> > do not make everyone run flex/yacc when building.
> 
> I disagree with this. It has happened to me more than once that I
> modify a flex file, regenerate it, and find it has been broken for
> *years* due to incompatibilities with newer flex versions and nobody
> noticed. Or I forget to regenerate it.
> 
> Should we put .mo files in the SVN translation directories so that
> people don't need msgfmt? Should we put .moc files in git?
> kdevelop-pg-qt generated parsers? Code made from .ui files? Code made
> by kconfig_compiler from .kcfg files? kapptemplate tarballs?
> 
> If it was up to me, there wouldn't even be .png icons in git version
> control, they would be generated from their .svg files at compile
> time.
> 
I said the policy is flex/yacc generated. not all generated. 

perhaps flex is more consistently available on all platforms these days.
last I recall flex on Windows proved difficult to deal with, but maybe things 
are better these days.

Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)

[Nicolás Alvarez]

2015-12-06 18:46 GMT-03:00 Thomas Lübking :
> On Sonntag, 6. Dezember 2015 22:23:01 CEST, Nicolás Alvarez wrote:
>
>> I am aware that Nuno manually chose rendering engine and scaling
>> method for every individual Oxygen icon based on seeing which one gave
>> (subjectively) better results. That is not documented anywhere
>
> Seriously? I mean, are you saying the choices where not recorded anywhere?
> (To automize re-generation on a rule base)

As far as I know they weren't. I will be grateful if you can find the
record of those choices, so far I couldn't :)

>> If I want to make an Oxygen-style icon
>
> of vastly inferior quality ... :-P

It will look better to stick my app logo into the real-artist-designed
piece-of-paper-with-shadow than to draw an icon from scratch...

>> I could even bring licensing into the discussion.
>
>
> Afaiu you can't - png is the "source", because they were post-processed in
> addition?!?

Both Oxygen and Breeze icons are under the LGPL, so I *can* bring
licensing into discussion. If you think png is the real source, that's
a possible answer to my question, it doesn't mean my question is N/A
:)

If the Preferred Form of Modification is the PNGs, it means the best
way to modify an existing icon is to modify the PNG, so we shouldn't
need the SVG around at all. I don't think that's the case. Surely the
preferred way to modify an icon is to edit the SVG and rasterize it
again. In that case part of the Corresponding Source is missing: how
it was rasterized.

> Even if not: it doesn't matter whether you use inkscape or gimp or krita or
> illustrator or photoshop or MS paint to create a raster image (or whether
> you provide intermediate results as well) - otherwise things would get
> *really* complex, because the *entire* production process of the image would
> have to be documented to eg. allow recretation of a png drawn in gimp (Mask
> here, gradient there. Gaussian blur, 40% overlay. Flatten, displacement
> noise, yaddayaddayadda...)

If you used gimp, you should put your multilayer .xcf in version
control, although in that case I may concede that re-rendering it at
build time is a pain, and a .png should be committed too. But at least
it's easy to reproduce the exact same bitmap if needed.

-- 
Nicolás

Generated files in version control (was: Re: Why is C90 enforced in KDE?)

[Nicolás Alvarez]

2015-12-06 17:28 GMT-03:00 Ingo Klöcker :
> On Sunday 06 December 2015 13:34:51 Nicolás Alvarez wrote:
>> If it was up to me, there wouldn't even be .png icons in git version
>> control, they would be generated from their .svg files at compile
>> time.
>
> You do not seem to be aware of the fact that (AFAIK) the PNGs were hand-
> optimized by Nuno and others. I'm pretty sure that Nuno would personally
> hunt down each and everyone of us ignorant non-designers if we replaced
> the PNGs with auto-generated ones. :-)

I am aware that Nuno manually chose rendering engine and scaling
method for every individual Oxygen icon based on seeing which one gave
(subjectively) better results. That is not documented anywhere, and we
can't modify an icon and re-render it with the same quality unless we
ship Nuno's brain along with oxygen-icons.tar.bz2 (I don't think there
is any working implementation of RFC1437), because we don't know what
rendering engine, scaling method, and bitmap modifications were used.

If I want to make an Oxygen-style icon for my application's document
format, I can copy the .svg for an existing file format icon, put my
application logo, leave the paper, and... who knows how to produce the
magic .png from that. No documentation, no script.

I could even bring licensing into the discussion. What is the
"preferred form for modification" (in the GPL sense) of oxygen icons?
What is the Corresponding Source (in the GPL sense) of the .png files?

-- 
Nicolás

Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)

[Thomas Lübking]

On Sonntag, 6. Dezember 2015 22:23:01 CEST, Nicolás Alvarez wrote:


I am aware that Nuno manually chose rendering engine and scaling
method for every individual Oxygen icon based on seeing which one gave
(subjectively) better results. That is not documented anywhere


Seriously? I mean, are you saying the choices where not recorded anywhere? (To 
automize re-generation on a rule base)



I don't think there is any working implementation of RFC1437

Rumor has it that Dr. Ira Graves will have made some progress on this 
particular issue.


If I want to make an Oxygen-style icon


of vastly inferior quality ... :-P


for my application's document format, I can copy the .svg for an existing
file format icon, put my application logo, leave the paper,
and... who knows how to produce the magic .png from that. No documentation,
no script.


Is this a real world issue or is the solution being "breeze"?



I could even bring licensing into the discussion.


Afaiu you can't - png is the "source", because they were post-processed in 
addition?!?
Even if not: it doesn't matter whether you use inkscape or gimp or krita or 
illustrator or photoshop or MS paint to create a raster image (or whether you 
provide intermediate results as well) - otherwise things would get *really* 
complex, because the *entire* production process of the image would have to be 
documented to eg. allow recretation of a png drawn in gimp (Mask here, gradient 
there. Gaussian blur, 40% overlay. Flatten, displacement noise, 
yaddayaddayadda...)

IOW, iamges don't fit code licenses at all.

Cheers,
Thomas

Re: Why is C90 enforced in KDE?

[Kevin Kofler]

Nicolás Alvarez wrote:
> I disagree with this. It has happened to me more than once that I
> modify a flex file, regenerate it, and find it has been broken for
> *years* due to incompatibilities with newer flex versions and nobody
> noticed. Or I forget to regenerate it.
> 
> Should we put .mo files in the SVN translation directories so that
> people don't need msgfmt? Should we put .moc files in git?
> kdevelop-pg-qt generated parsers? Code made from .ui files? Code made
> by kconfig_compiler from .kcfg files? kapptemplate tarballs?

+1, of course we should not. Generated files have no business being in a 
source control or in source tarballs. "BuildRequires: flex" is one line in a 
distro specfile.

Kevin Kofler

Re: Why is C90 enforced in KDE?

[Kevin Kofler]

Thomas Lübking wrote:
> Wtf does flex/yacc produce incompliant comments?
> Seriously, COMMENTS!
> That's a convenience thing.

I remember a mail from several years ago where Flex developers said they had 
no interest in supporting an ancient C standard when C99 has been out for 
years. (I think it was about using stdint.h or something like that.) So I am 
not surprised that they are now using C99 comments (which ARE compliant to 
the current C standard, and have been for 16 years (!)).

Kevin Kofler

Re: Why is C90 enforced in KDE?

[Thomas Lübking]

On Sonntag, 6. Dezember 2015 17:41:07 CEST, Nicolás Alvarez wrote:

Then we ignore warnings about // comments and pay attention
to others


Wtf does flex/yacc produce incompliant comments?
Seriously, COMMENTS!
That's a convenience thing.

int foo = bar; // bar defined in wherever

is simpler than

int foo = bar; /* bar defined in wherever */

but a code generator isn't lazy.
There must be a way to avoid that?

Otherwise one might convince them to create cpp/cxx suffixes so that compilers 
will invoke the C++ compiler?

Cheers,
Thomas

Re: Why is C90 enforced in KDE?

[Nicolás Alvarez]

2015-12-06 18:59 GMT-03:00 Thomas Lübking :
> On Sonntag, 6. Dezember 2015 17:41:07 CEST, Nicolás Alvarez wrote:
>>
>> Then we ignore warnings about // comments and pay attention
>> to others
>
>
> Wtf does flex/yacc produce incompliant comments?
> Seriously, COMMENTS!
> That's a convenience thing.
>
> int foo = bar; // bar defined in wherever
>
> is simpler than
>
> int foo = bar; /* bar defined in wherever */
>
> but a code generator isn't lazy.
> There must be a way to avoid that?
>
> Otherwise one might convince them to create cpp/cxx suffixes so that
> compilers will invoke the C++ compiler?

I have never used yacc, but I know you can make flex produce a file
named .cpp and even use C++ code inside your actions. There is even an
(experimental, unstable) flex option to make it output an actual C++
parser class.

-- 
Nicolás