Baby X

Discussion in 'C Programming' started by Malcolm McLean, Aug 4, 2013.

  1. I proudly announce Baby X v0.0, the baby X windows toolkit. It's a prototype version, usable and with the central features present.

    The goal is to keep Baby X small, so that it's natural to distribute it with
    projects as C source. But it also needs to support everything that a
    writer of small windowing programs would want. I'm trialling it with the
    comp.lang.c community before putting it out to a wider public, on the basis
    that any design flaws can be addressed at this stage.
    Its currently available only for xlib. One issue is whether it's sensible to
    produce a Windows version.

    The project is available at
    http://www.malcolmmclean.site11.com/www

    click on the Baby X link.
    Malcolm McLean, Aug 4, 2013
    #1
    1. Advertising

  2. Malcolm McLean

    Jorgen Grahn Guest

    On Sat, 2013-08-03, Malcolm McLean wrote:
    > I proudly announce Baby X v0.0, the baby X windows toolkit. [...]
    >

    ....
    > I'm trialling it with the
    > comp.lang.c community before putting it out to a wider public, on the basis
    > that any design flaws can be addressed at this stage.
    > Its currently available only for xlib. One issue is whether it's sensible to
    > produce a Windows version.
    >
    > The project is available at
    > http://www.malcolmmclean.site11.com/www
    >
    > click on the Baby X link.


    A Git repository would have been nice. Or failing that, a tar.gz
    archive instead of a .zip.

    Also, the PDF seems broken. Neither Ghostscript nor evince can
    display it.

    (I'm not in the market for an X toolkit -- I gave up on GUI
    programming a long time ago -- but found this intriguing.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Aug 4, 2013
    #2
    1. Advertising

  3. Malcolm McLean

    BartC Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > On Sat, 2013-08-03, Malcolm McLean wrote:
    >> I proudly announce Baby X v0.0, the baby X windows toolkit. [...]


    >> http://www.malcolmmclean.site11.com/www
    >>
    >> click on the Baby X link.

    >
    > A Git repository would have been nice. Or failing that, a tar.gz
    > archive instead of a .zip.
    >
    > Also, the PDF seems broken. Neither Ghostscript nor evince can
    > display it.


    So is the ZIP file.

    --
    Bartc
    BartC, Aug 4, 2013
    #3
  4. On Sunday, August 4, 2013 10:29:40 AM UTC+1, Bart wrote:
    > "Jorgen Grahn" <> wrote in message
    >
    > news:...
    >
    > > On Sat, 2013-08-03, Malcolm McLean wrote:

    >
    > >> I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

    >
    >
    >
    > >> http://www.malcolmmclean.site11.com/www

    >
    > >> click on the Baby X link.

    >
    > > A Git repository would have been nice. Or failing that, a tar.gz
    > > archive instead of a .zip.

    >
    > > Also, the PDF seems broken. Neither Ghostscript nor evince can
    > > display it.

    >
    >
    > So is the ZIP file.
    >


    I accidentally transferred the to the server using text mode.
    Try now.
    I've also added a .tar.gz
    Malcolm McLean, Aug 4, 2013
    #4
  5. >> Also, the PDF seems broken. Neither Ghostscript nor evince can
    >> display it.

    >
    >So is the ZIP file.


    I could open all three (.pdf, .tar.gz, .zip,) without any problem.
    (Using 7-Zip & SumatraPDF)
    --
    Roberto Waltman

    [ Please reply to the group,
    return address is invalid ]
    Roberto Waltman, Aug 4, 2013
    #5
  6. Malcolm McLean <> writes:
    > On Sunday, August 4, 2013 10:29:40 AM UTC+1, Bart wrote:
    >> "Jorgen Grahn" <> wrote in message
    >>
    >> news:...
    >>
    >> > On Sat, 2013-08-03, Malcolm McLean wrote:

    >>
    >> >> I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

    >>
    >>
    >>
    >> >> http://www.malcolmmclean.site11.com/www

    >>
    >> >> click on the Baby X link.

    >>
    >> > A Git repository would have been nice. Or failing that, a tar.gz
    >> > archive instead of a .zip.

    >>
    >> > Also, the PDF seems broken. Neither Ghostscript nor evince can
    >> > display it.

    >>
    >>
    >> So is the ZIP file.
    >>

    >
    > I accidentally transferred the to the server using text mode.
    > Try now.
    > I've also added a .tar.gz


    "compileme.txt" says to compile with

    gcc *.c -lX11

    which compiles with no warnings. But when I try:

    gcc -std=c99 -pedantic -Wall -Wextra -O3 *.c -lX11

    I get 552 lines of warnings. You might want to take a look at those.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 4, 2013
    #6
  7. Malcolm McLean

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Sunday, August 4, 2013 10:29:40 AM UTC+1, Bart wrote:
    >> "Jorgen Grahn" <> wrote in message
    >>
    >> news:...
    >>
    >>> On Sat, 2013-08-03, Malcolm McLean wrote:

    >>
    >>>> I proudly announce Baby X v0.0, the baby X windows toolkit. [...]

    >>
    >>
    >>
    >>>> http://www.malcolmmclean.site11.com/www

    >>
    >>>> click on the Baby X link.

    >>
    >>> A Git repository would have been nice. Or failing that, a tar.gz
    >>> archive instead of a .zip.

    >>
    >>> Also, the PDF seems broken. Neither Ghostscript nor evince can
    >>> display it.

    >>
    >>
    >> So is the ZIP file.
    >>

    >
    > I accidentally transferred the to the server using text mode.
    > Try now.
    > I've also added a .tar.gz


    You might want to fix up all of the signed/unsigned mismatches with your
    depth parameter.

    --
    Ian Collins
    Ian Collins, Aug 4, 2013
    #7
  8. On Sunday, August 4, 2013 10:34:47 PM UTC+1, Keith Thompson wrote:
    > Malcolm McLean <> writes:
    >
    >
    > "compileme.txt" says to compile with
    >
    > gcc *.c -lX11
    >
    >
    >
    > which compiles with no warnings. But when I try:
    >
    >
    >
    > gcc -std=c99 -pedantic -Wall -Wextra -O3 *.c -lX11
    >
    >
    >
    > I get 552 lines of warnings. You might want to take a look at those.
    >
    >

    A lot of those are caused by signed / unsigned mismatches. But putting in
    casts and unsigned types isn't really solving the problem, just replacing
    messy warnings with messy, more error-prone code. We need signed types
    for indices because -1 is often either used as a null value, or generated
    as a post value. Signed types are safer for size calculations because they
    can trap if the size overflows.
    But I'll certainly look and see what can be suppressed.
    Malcolm McLean, Aug 5, 2013
    #8
  9. Malcolm McLean <> writes:
    > On Sunday, August 4, 2013 10:34:47 PM UTC+1, Keith Thompson wrote:

    [...]
    >> I get 552 lines of warnings. You might want to take a look at those.
    >>
    >>

    > A lot of those are caused by signed / unsigned mismatches. But putting in
    > casts and unsigned types isn't really solving the problem, just replacing
    > messy warnings with messy, more error-prone code. We need signed types
    > for indices because -1 is often either used as a null value, or generated
    > as a post value. Signed types are safer for size calculations because they
    > can trap if the size overflows.
    > But I'll certainly look and see what can be suppressed.


    Signed types *can* trap on overflow, but in most implementations
    they don't; they just quietly wrap around. I suggest just using
    size_t for all sizes. If you need a special invalid size value,
    you can use (size_t)-1.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 5, 2013
    #9
  10. Malcolm McLean

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Sunday, August 4, 2013 10:34:47 PM UTC+1, Keith Thompson wrote:
    >> Malcolm McLean <> writes:
    >>
    >> "compileme.txt" says to compile with
    >>
    >> gcc *.c -lX11
    >>
    >> which compiles with no warnings. But when I try:
    >>
    >> gcc -std=c99 -pedantic -Wall -Wextra -O3 *.c -lX11
    >>
    >> I get 552 lines of warnings. You might want to take a look at those.
    >>
    >>

    > A lot of those are caused by signed / unsigned mismatches. But putting in
    > casts and unsigned types isn't really solving the problem, just replacing
    > messy warnings with messy, more error-prone code.


    Nonsense. Most of the warnings are down to you passing an int* to a
    depth return parameter. Depth in X can't be negative.

    > We need signed types
    > for indices because -1 is often either used as a null value, or generated
    > as a post value.


    Depth isn't an index.

    > Signed types are safer for size calculations because they
    > can trap if the size overflows.


    Tell that to the designers of the standard library (and X).

    > But I'll certainly look and see what can be suppressed.


    Just fix, there's no need to suppress valid warnings.

    --
    Ian Collins
    Ian Collins, Aug 5, 2013
    #10
  11. On Monday, August 5, 2013 9:25:31 PM UTC+1, Ian Collins wrote:
    > Malcolm McLean wrote:
    >
    > > Signed types are safer for size calculations because they
    > > can trap if the size overflows.

    >
    > Tell that to the designers of the standard library (and X).
    >

    Unfortunately, a reasonably intelligent programmer can think that "this
    quantity cannot be negative, therefore it ought to be unsigned". He's almost
    always wrong. For instance pixel indices can't be negative when drawing, so
    draw_pixel() can take unsigned x, y. But in fact most calling code is going to
    generate intermediate values which can be negative, so it's a nuisance. This
    example is too obvious for most people to fall into the trap. It's valid to
    subtract one depth from another to yield a depth difference, so depth should
    be signed. It's a little glitch on X, but we have to live with it. We can't
    change the interface now.
    size_t is a disaster for the C language, and I've spoken against it on many
    occasions. I won't rehash the arguments here.
    But gcc doesn't give a warning by default.
    >
    >
    > > But I'll certainly look and see what can be suppressed.

    >
    > Just fix, there's no need to suppress valid warnings.
    >

    Whilst the code compiles cleanly if compiled according to the instructions,
    I agree there's a case for supporting a clean compile under stricter warnings,
    so that people can choose to use them if they find them useful. The warnings
    aren't valid, however, and the code is correct. They're noise.
    Malcolm McLean, Aug 6, 2013
    #11
  12. Malcolm McLean

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Monday, August 5, 2013 9:25:31 PM UTC+1, Ian Collins wrote:
    >> Malcolm McLean wrote:
    >>
    >>> Signed types are safer for size calculations because they
    >>> can trap if the size overflows.

    >>
    >> Tell that to the designers of the standard library (and X).
    >>

    > Unfortunately, a reasonably intelligent programmer can think that "this
    > quantity cannot be negative, therefore it ought to be unsigned". He's almost
    > always wrong. For instance pixel indices can't be negative when drawing, so
    > draw_pixel() can take unsigned x, y. But in fact most calling code is going to
    > generate intermediate values which can be negative, so it's a nuisance. This
    > example is too obvious for most people to fall into the trap. It's valid to
    > subtract one depth from another to yield a depth difference, so depth should
    > be signed. It's a little glitch on X, but we have to live with it. We can't
    > change the interface now.


    No, you can't. So pass the correct types.

    > size_t is a disaster for the C language, and I've spoken against it on many
    > occasions. I won't rehash the arguments here.


    It's also irrelevant to this discussion.

    > But gcc doesn't give a warning by default.


    gcc isn't a conforming compiler by default.

    >>> But I'll certainly look and see what can be suppressed.

    >>
    >> Just fix, there's no need to suppress valid warnings.
    >>

    > Whilst the code compiles cleanly if compiled according to the instructions,
    > I agree there's a case for supporting a clean compile under stricter warnings,
    > so that people can choose to use them if they find them useful. The warnings
    > aren't valid, however, and the code is correct. They're noise.


    The warnings are valid and will be generated by any conforming compiler,
    which makes you code at best annoying and at worse useless to anyone
    using a decent compiler.

    --
    Ian Collins
    Ian Collins, Aug 6, 2013
    #12
  13. On Tuesday, August 6, 2013 8:19:00 PM UTC+1, Ian Collins wrote:
    > Malcolm McLean wrote:
    >
    >
    > The warnings are valid and will be generated by any conforming compiler,
    > which makes you code at best annoying and at worse useless to anyone
    > using a decent compiler.
    >

    If code has defined behaviour which is correct, then warnings are noise.
    If suppressing the warnings means putting in constructs which are likely
    to confuse, and to lead to incorrect behaviour (eg inappropriate use of
    unsigned types for values which might yield negative results intermediate
    calculations), then you've got a balanced judgement to make.

    The underlying problem can't be solved now, because it's too late.
    Fortunately gcc doesn't give these inappropriate warnings when invoked
    in default mode, which should be the mode you use except in special
    circumstances. These is a case for supporting people who don't want to
    compile Baby X according to the instructions, I agree, but "I didn't
    follow the instructions and it worked but gave funny messages" isn't
    an especially strong complaint.
    Malcolm McLean, Aug 6, 2013
    #13
  14. Malcolm McLean

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Tuesday, August 6, 2013 8:19:00 PM UTC+1, Ian Collins wrote:
    >> Malcolm McLean wrote:
    >>
    >>
    >> The warnings are valid and will be generated by any conforming compiler,
    >> which makes you code at best annoying and at worse useless to anyone
    >> using a decent compiler.
    >>

    > If code has defined behaviour which is correct, then warnings are noise.
    > If suppressing the warnings means putting in constructs which are likely
    > to confuse, and to lead to incorrect behaviour (eg inappropriate use of
    > unsigned types for values which might yield negative results intermediate
    > calculations), then you've got a balanced judgement to make.


    In all the cases I've seen, you don't use the depth parameter.

    > The underlying problem can't be solved now, because it's too late.
    > Fortunately gcc doesn't give these inappropriate warnings when invoked
    > in default mode, which should be the mode you use except in special
    > circumstances. These is a case for supporting people who don't want to
    > compile Baby X according to the instructions, I agree, but "I didn't
    > follow the instructions and it worked but gave funny messages" isn't
    > an especially strong complaint.


    One of the first rules of open source code is if you want people to use
    your code, make sure it compiles cleanly.

    --
    Ian Collins
    Ian Collins, Aug 6, 2013
    #14
  15. Malcolm McLean

    Ike Naar Guest

    On 2013-08-06, Malcolm McLean <> wrote:
    > Whilst the code compiles cleanly if compiled according to the instructions,
    > I agree there's a case for supporting a clean compile under stricter warnings,
    > so that people can choose to use them if they find them useful. The warnings
    > aren't valid, however, and the code is correct. They're noise.


    In addition to signed/unsigned warnings, there are other issues as well,
    e.g. calling functions without a prototype in scope (strcmp,
    XDestroyImage, etc.) (due to missing #include's),
    missing return statements in the body of functions
    returning non-void, etc.
    Ike Naar, Aug 6, 2013
    #15
  16. On Tuesday, August 6, 2013 10:00:18 PM UTC+1, Ike Naar wrote:
    > On 2013-08-06, Malcolm McLean <> wrote:
    >
    > In addition to signed/unsigned warnings, there are other issues as well,
    > e.g. calling functions without a prototype in scope (strcmp,
    > XDestroyImage, etc.) (due to missing #include's),
    > missing return statements in the body of functions
    > returning non-void, etc.
    >

    Some of those need fixing, yes.
    Malcolm McLean, Aug 6, 2013
    #16
  17. On Tuesday, August 6, 2013 8:49:58 PM UTC+1, Ian Collins wrote:
    > Malcolm McLean wrote:
    >
    >
    > In all the cases I've seen, you don't use the depth parameter.
    >

    Yes, it's a X nuisance function, which returns far too much information
    when usually you simply want the size. Then it doesn't check for null,
    so you have to pass dummy paramters for the unwanted values. I'm considering
    wrapping it in a bbx_getsize() and stripping all those calls out.
    >
    >
    > One of the first rules of open source code is if you want people to use
    > your code, make sure it compiles cleanly.
    >

    Most open source people will be using gcc, so I made it compile cleanly
    under gcc in default mode. That's central to the idea behind Baby X. I want
    to strip away all the funny flags and dependencies and configurations and
    pre-build steps.
    Malcolm McLean, Aug 6, 2013
    #17
  18. Malcolm McLean <> writes:

    > On Tuesday, August 6, 2013 8:49:58 PM UTC+1, Ian Collins wrote:

    <snip>
    >> One of the first rules of open source code is if you want people to use
    >> your code, make sure it compiles cleanly.
    >>

    > Most open source people will be using gcc, so I made it compile cleanly
    > under gcc in default mode. That's central to the idea behind Baby X. I want
    > to strip away all the funny flags and dependencies and configurations and
    > pre-build steps.


    If you fix the code to remove most, maybe all, the warnings it will
    still compile clean in gcc's default mode.

    As I understand it, your goal is for Baby X to be compiled along with
    the client code. If so, you should make some effort to accommodate as
    wide a variety of compile flags as you can. It's exactly when you do
    have a separate build step for the library that you can pick and choose
    exactly how it should be compiled (but I've not been following closely
    so I may not have picked up on what your main goals are).

    --
    Ben.
    Ben Bacarisse, Aug 7, 2013
    #18
  19. Malcolm McLean

    Ian Collins Guest

    Malcolm McLean wrote:
    > On Tuesday, August 6, 2013 8:49:58 PM UTC+1, Ian Collins wrote:
    >> Malcolm McLean wrote:
    >>
    >>
    >> In all the cases I've seen, you don't use the depth parameter.
    >>

    > Yes, it's a X nuisance function, which returns far too much information
    > when usually you simply want the size. Then it doesn't check for null,
    > so you have to pass dummy paramters for the unwanted values. I'm considering
    > wrapping it in a bbx_getsize() and stripping all those calls out.


    Why are you so obsessed with not passing the correct type? Is it a case
    of dogma vs correctness?

    >> One of the first rules of open source code is if you want people to use
    >> your code, make sure it compiles cleanly.
    >>

    > Most open source people will be using gcc, so I made it compile cleanly
    > under gcc in default mode. That's central to the idea behind Baby X. I want
    > to strip away all the funny flags and dependencies and configurations and
    > pre-build steps.


    Hardly anyone (who knows what they are doing) uses gcc in its default
    mode. The customer site I was working at this morning always uses
    -werreor for example. Event adding the slightest whiff of conformance
    spews the warnings.

    --
    Ian Collins
    Ian Collins, Aug 7, 2013
    #19
  20. On Wednesday, August 7, 2013 2:45:23 AM UTC+1, Ian Collins wrote:
    > Malcolm McLean wrote:
    >
    >
    > Why are you so obsessed with not passing the correct type? Is it a case
    > of dogma vs correctness?
    >

    It's a case of keeping clutter out of the Baby X code. Which keeping the
    types as simple as possible. Unsigned integers aren't wanted, they're
    just a nuisance, a source of confusion and complexity and bugs. However
    Baby X does have to call X, which sometimes uses them.
    It's not a case of obsession, just pointing out that the warnings are
    noise, and the roots of the issue lie elsewhere.
    >
    > > Most open source people will be using gcc, so I made it compile cleanly
    > > under gcc in default mode. That's central to the idea behind Baby X. I want
    > > to strip away all the funny flags and dependencies and configurations and
    > > pre-build steps.

    >
    >
    > Hardly anyone (who knows what they are doing) uses gcc in its default
    > mode. The customer site I was working at this morning always uses
    > -werreor for example. Event adding the slightest whiff of conformance
    > spews the warnings.
    >

    It's a baby toolkit, so it uses babytalk. Which is gcc in default mode. But
    supporting other modes which don't break default mode is largely harmless.
    The only danger is that someone might extend it by putting in some construct
    which relies on the non-default mode, which is unlikely.
    Most of the warnings can probably be suppressed without any real issues,
    so it's worth doing that. I don't see it as a serious matter, however.
    Malcolm McLean, Aug 7, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Owen

    Baby JavaScript question

    Jim Owen, Jul 23, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    325
    Vidar Petursson
    Jul 23, 2003
  2. Artemisio
    Replies:
    6
    Views:
    13,126
    Artemisio
    Aug 21, 2004
  3. Artemisio

    line shift? (baby steps 2)

    Artemisio, Aug 23, 2004, in forum: Python
    Replies:
    6
    Views:
    320
    Jeff Lindholm
    Aug 24, 2004
  4. Timothy Fitz
    Replies:
    0
    Views:
    478
    Timothy Fitz
    Oct 27, 2004
  5. Bulba!
    Replies:
    13
    Views:
    460
    M.E.Farmer
    Jan 1, 2005
Loading...

Share This Page