For those who don't follow this group regularly, Baby X is a miniature toolkit for X11 and Windows, and the Baby X resource compiler is the resource compiler for it. It outputs C source.

The last of the bugs reported by Ben has been fixed. The only problem remaining is that the MP3 decoder allocates global tables for pre-calculated results on first call, and never frees them. I decided to leave this behaviour in instead of mess with the code.

I've decided that version 1.2 will concentrate on the needs of Baby X programmers. I believe that the resource compiler is used by non-Baby X programmers, but it's hard to be sure as few people get back to me. But trying to make it more generally useful opens up a whole host of problems. So it's generally useful as a side effect, not as the main purpose of the program.

Features are frozen for v1.2, but I'm happy to consider suggestions for v1.3. Bug reports are of course vital at this stage. A very late bug manifested only on Windows. It was

(all values long)
Nout = (long) ((Nchannels * Nsamples * resamplerate + 1204.0)/samplerate);

The wiggle room was also meant to cast the expression to a double. resamplerate and samplerate are typically 44100 or so. Nsamples is samplerate * duration in seconds, so it can go very high. The expression is not cast to a double, and on Windows long is only 32 bits, and it overflows.

But now we have a release candidate for v1.2.
Any more bug reports very welcome.

The project is hosted at
https://github.com/MalcolmMcLean/babyxrc

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Any more bug reports very welcome.
>
> The project is hosted at
> https://github.com/MalcolmMcLean/babyxrc

I get compile errors again (the same ones) using cmake and make. That
was fixed a few days ago but it's back. I replaced the tree (in case
cmake it breaking things) and went to the src directory and tried the
direct compile command. Same result.

Also, these instructions

There is a CMake script. So if you have CMake, make a directory called
"build", navigate to it, then type

cmake ..
make

make no sense to me. Where (and why) must I have this directory called
"build"? cmake .. must be run where .. contains the right files.

What I did (when trying cmake) was untar the files, cd to the resulting
directory (babyxrc-1.1), and typed "cmake .; make".

--
Ben.

On Tuesday, 8 August 2023 at 17:04:16 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > Any more bug reports very welcome.
> >
> > The project is hosted at
> > https://github.com/MalcolmMcLean/babyxrc
> I get compile errors again (the same ones) using cmake and make. That
> was fixed a few days ago but it's back. I replaced the tree (in case
> cmake it breaking things) and went to the src directory and tried the
> direct compile command. Same result.
>
> Also, these instructions
>
> There is a CMake script. So if you have CMake, make a directory called
> "build", navigate to it, then type
>
> cmake ..
> make
>
> make no sense to me. Where (and why) must I have this directory called
> "build"? cmake .. must be run where .. contains the right files.
>
There's a .gitignore file which ignores "build". So if you want the CMake
products under the babyxrc root directory, which you probably do, and
you use the name "build", git won't pester you to add the CMkae products
to the repository.
>
> What I did (when trying cmake) was untar the files, cd to the resulting
> directory (babyxrc-1.1), and typed "cmake .; make".
>
I think what you've done is tried to compile release 1.1 It was a mistake
to make this release, but I wanted to get Sourceforge integration working,
and you need a release to pass to the system. But it was premature.

The release candidate for version 1.2 is at the head node of "master".
But there isn't a v1.2 yet. That onyl happens after the release candidate
is accepted and is no longer a candidate. I think it's bug free, which is why
it's a candidate. But the build instructions could maybe be a little clearer,
and that's just as serious as a bug in the code itself.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Tuesday, 8 August 2023 at 17:04:16 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > Any more bug reports very welcome.
>> >
>> > The project is hosted at
>> > https://github.com/MalcolmMcLean/babyxrc
>> I get compile errors again (the same ones) using cmake and make. That
>> was fixed a few days ago but it's back. I replaced the tree (in case
>> cmake it breaking things) and went to the src directory and tried the
>> direct compile command. Same result.
>>
>> Also, these instructions
>>
>> There is a CMake script. So if you have CMake, make a directory called
>> "build", navigate to it, then type
>>
>> cmake ..
>> make
>>
>> make no sense to me. Where (and why) must I have this directory called
>> "build"? cmake .. must be run where .. contains the right files.
>>
> There's a .gitignore file which ignores "build". So if you want the CMake
> products under the babyxrc root directory, which you probably do, and
> you use the name "build", git won't pester you to add the CMkae products
> to the repository.

Since I extracted from a tarball, I don't care about git. But OK, I
see the purpose.

>> What I did (when trying cmake) was untar the files, cd to the resulting
>> directory (babyxrc-1.1), and typed "cmake .; make".
>>
> I think what you've done is tried to compile release 1.1

Yes. You said you were working on 1.2. It made sense to me to compile
a release, not something you were working on which does not appear to be
ready yet. We were at cross purposes.

--
Ben.

On Tuesday, 8 August 2023 at 18:44:28 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Tuesday, 8 August 2023 at 17:04:16 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > Any more bug reports very welcome.
> >> >
> >> > The project is hosted at
> >> > https://github.com/MalcolmMcLean/babyxrc
> >> I get compile errors again (the same ones) using cmake and make. That
> >> was fixed a few days ago but it's back. I replaced the tree (in case
> >> cmake it breaking things) and went to the src directory and tried the
> >> direct compile command. Same result.
> >>
> >> Also, these instructions
> >>
> >> There is a CMake script. So if you have CMake, make a directory called
> >> "build", navigate to it, then type
> >>
> >> cmake ..
> >> make
> >>
> >> make no sense to me. Where (and why) must I have this directory called
> >> "build"? cmake .. must be run where .. contains the right files.
> >>
> > There's a .gitignore file which ignores "build". So if you want the CMake
> > products under the babyxrc root directory, which you probably do, and
> > you use the name "build", git won't pester you to add the CMkae products
> > to the repository.
> Since I extracted from a tarball, I don't care about git. But OK, I
> see the purpose.
> >> What I did (when trying cmake) was untar the files, cd to the resulting
> >> directory (babyxrc-1.1), and typed "cmake .; make".
> >>
> > I think what you've done is tried to compile release 1.1
> Yes. You said you were working on 1.2. It made sense to me to compile
> a release, not something you were working on which does not appear to be
> ready yet. We were at cross purposes.
>
In a better world, the release v1.1 should compile and work. In fact it only works
well on the Mac. It should have been far better tested earlier, but I needed something
to give to Sourceforge to get Sourceforge / git integration working. But it was
a mistake to release v1.1 prematurely. v1.2 is the fix.

Its currently a release candidate. A problem is that the resource compiler by its
nature is difficult to test. You can see that it is spitting out C source without
falling over, but the source also has to represent the data correctly. I've made
a start with a little test program to test the fonts.
The other problem is that the output files are so large that I don't like putting
them on github. If the resource compiler catches on then someone will have
to take a decison whether output files or script files shall be archived.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> But now we have a release candidate for v1.2.
> Any more bug reports very welcome.
>
> The project is hosted at
> https://github.com/MalcolmMcLean/babyxrc

The file README.md says "the code is all clean portable ANSI C".

The files in the src directory aren't even close to conforming
to ANSI C (aka C90) rules.

Almost all of the source compiles cleanly under C99 rules.

However, one file -- loadimage.c -- needs C11 features to
compile it. The problems originate in the header nanosvg.h,
around lines 124 and 363 (anonymous unions, introduced in C11).

On Tuesday, 8 August 2023 at 20:38:39 UTC+1, Tim Rentsch wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > But now we have a release candidate for v1.2.
> > Any more bug reports very welcome.
> >
> > The project is hosted at
> > https://github.com/MalcolmMcLean/babyxrc
> The file README.md says "the code is all clean portable ANSI C".
>
> The files in the src directory aren't even close to conforming
> to ANSI C (aka C90) rules.
>
> Almost all of the source compiles cleanly under C99 rules.
>
> However, one file -- loadimage.c -- needs C11 features to
> compile it. The problems originate in the header nanosvg.h,
> around lines 124 and 363 (anonymous unions, introduced in C11).
>
That's worth addressing to support C99.

On 2023-08-09, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Tuesday, 8 August 2023 at 20:38:39 UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > But now we have a release candidate for v1.2.
>> > Any more bug reports very welcome.
>> >
>> > The project is hosted at
>> > https://github.com/MalcolmMcLean/babyxrc
>> The file README.md says "the code is all clean portable ANSI C".
>>
>> The files in the src directory aren't even close to conforming
>> to ANSI C (aka C90) rules.
>>
>> Almost all of the source compiles cleanly under C99 rules.
>>
>> However, one file -- loadimage.c -- needs C11 features to
>> compile it. The problems originate in the header nanosvg.h,
>> around lines 124 and 363 (anonymous unions, introduced in C11).
>>
> That's worth addressing to support C99.

That still abandons the project goal of remaining in ANSI C.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca