[9fans] Ogg/Vorbis ported

[9fans] Ogg/Vorbis ported

[Mathieu Lonjaret]

Hello all,

Subject says it all; as my first port I did libogg and libvorbis.

I did it mainly as a learning exercise, so it's far from perfect, but
both the libs compile as well as the simple encoder and decoder from
the 'examples' dir.
I have not tried the encoder, but the decoder seems to be running fine
like that:
cat somefile.ogg | ./decoder_example > /dev/audio

I did no try to rework things, like the types for example (as it was
done for libmad/mp3dec in rsc's contrib), I limited myself to fix
things the best I could until it built fine. So constructive
criticism, remarks, comments, are of course welcome please. In
particular, I'm not sure about these various things I did:
1) changed all the alloca calls to some malloc/free
2) added a rint function
3) commented out most of the #if defined ... (seemed safe since most
were gnuisms, gcc, or win32 specific).
4) the 'max' and 'min' vars seemed to pose a problem (although I
wasn't able to find them already defined on plan9), so renamed them to
things like local_max.
5) created some new headers and moved some code in there to make it cleaner.
6) the various locations I set in the mkfile to install things.
Also, the weirdest I think was these 3 extern funcs:  floor1_fit,
floor1_interpolate_fit, floor1_encode which were declared with a void
* as one of the args, but which were used with a struct * instead.
Seems like fixing the declarations and moving them to a header made
things build fine but I'm not sure of what was the initial intent
here.

They're hosted as indicated below at the moment, but if they're not
deemed worthless, could I have a contrib dir so they can be installed
with fgb's replica please?

http://www.ipgp.jussieu.fr/~lonjaret/libogg.tar.gz
http://www.ipgp.jussieu.fr/~lonjaret/libvorbis.tar.gz

Next should be a decent player, and other of the vorbis-tools, if I
can get around the ncurses dependency.

Thanks to rsc for 9vx (haven't tested on native plan9 btw), and to
sqweek and quintile for their advices.

Cheers,
Mathieu

--
GPG key on subkeys.pgp.net:

KeyID:   | Fingerprint:
683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3

Re: [9fans] Ogg/Vorbis ported

[hiro]

That's great.
There's also the celt codec, which has low delay and a quality which
is pretty much from outer space...
I thought about it, but can't port it.

On Wed, Jan 28, 2009 at 6:53 PM, Mathieu Lonjaret <lejatorn@gmail.com> wrote:
> Hello all,
>
> Subject says it all; as my first port I did libogg and libvorbis.
>
> I did it mainly as a learning exercise, so it's far from perfect, but
> both the libs compile as well as the simple encoder and decoder from
> the 'examples' dir.
> I have not tried the encoder, but the decoder seems to be running fine
> like that:
> cat somefile.ogg | ./decoder_example > /dev/audio
>
> I did no try to rework things, like the types for example (as it was
> done for libmad/mp3dec in rsc's contrib), I limited myself to fix
> things the best I could until it built fine. So constructive
> criticism, remarks, comments, are of course welcome please. In
> particular, I'm not sure about these various things I did:
> 1) changed all the alloca calls to some malloc/free
> 2) added a rint function
> 3) commented out most of the #if defined ... (seemed safe since most
> were gnuisms, gcc, or win32 specific).
> 4) the 'max' and 'min' vars seemed to pose a problem (although I
> wasn't able to find them already defined on plan9), so renamed them to
> things like local_max.
> 5) created some new headers and moved some code in there to make it cleaner.
> 6) the various locations I set in the mkfile to install things.
> Also, the weirdest I think was these 3 extern funcs:  floor1_fit,
> floor1_interpolate_fit, floor1_encode which were declared with a void
> * as one of the args, but which were used with a struct * instead.
> Seems like fixing the declarations and moving them to a header made
> things build fine but I'm not sure of what was the initial intent
> here.
>
> They're hosted as indicated below at the moment, but if they're not
> deemed worthless, could I have a contrib dir so they can be installed
> with fgb's replica please?
>
> http://www.ipgp.jussieu.fr/~lonjaret/libogg.tar.gz
> http://www.ipgp.jussieu.fr/~lonjaret/libvorbis.tar.gz
>
> Next should be a decent player, and other of the vorbis-tools, if I
> can get around the ncurses dependency.
>
> Thanks to rsc for 9vx (haven't tested on native plan9 btw), and to
> sqweek and quintile for their advices.
>
> Cheers,
> Mathieu
>
> --
> GPG key on subkeys.pgp.net:
>
> KeyID:   | Fingerprint:
> 683DE5F3 | 4324 5818 39AA 9545 95C6 09AF B0A4 DFEA 683D E5F3
>
>

Re: [9fans] Ogg/Vorbis ported

[ron minnich]

>From what you learned, are there some nice general scripts that could
be used to automate some of this for the next hunk of gnu-like code
that comes along?

Thanks for the port ...

ron

[9fans] porting GNU code

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

> ..are there some nice general scripts that could
> be used to automate some of this for the next hunk of gnu-like code
> that comes along?

I wrote a tool to help me port some ANSI C code from the net. It
autogenerates mkfiles based on analysis of the source and headers.

Importantly the porting effort can be coded into an rc(1) script, this
means new releases of your GNU (for example) package can be built with
relative ease.

manpage attached, sourcecode and examples in the contrib package steve/mkmk

-Steve

[-- Attachment #2.1: Type: text/plain, Size: 310 bytes --]

from postmaster@felix:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/troff
	Content-Disposition: attachment; filename=mkmk
	Content-Transfer-Encoding: base64

[-- Attachment #2.2: mkmk.suspect --]
[-- Type: application/octet-stream, Size: 5448 bytes --]

.TH MKMK 1
.SH NAME
mkmk \- create a mkfile for foreign software
.SH SYNOPSIS
.B mkmk
[
.B -aSA
] [
.B -S
.I file
] [
.B -I
.I incdir
] [
.B -L
.I libdir
] [
.B -D
.I name
[
.I =value
]] [
.B -U
.I name
] [
.B -w
.I column
] [
.B -C
.I cflags
] [
.B -x
.I exclude
] [
.I file...
]
.SH DESCRIPTION
.I mkmk
attempts to generate a correct mkfile for
.I mk(1)
based on the files given, or if none, those found in the current directory,
it writes the generated mkfile to its standard output.
.P
Though 
.I mkmk(1)
makes strenuous attempts to identify the dependency tree and required
macro definitions it will make mistakes. It is expected that
.I mkmk(1)
will usually be invoked from an
.I rc(1) script, 
.IR 9port ,
which will use the various command options to modify the generated mkfile.
In extreme cases it may even have to use other tools such as
.I sed(1)
and
.I awk(1)
to massage the generated script.
One of these scripts would be needed for each package ported using
.IR mkmk(1) .
.LP
Using a script is preferable to hand editing
the generated mkfile as it allows updates of the package to be
installed by simply re-running the 
.I 9port
script.
There are a number of options:
.TP
.B -o target
.TP
.B -m
.TP
.B -l target
.TP
.B -s target
.br
.I mkmk(1)
is able to generate the four standard mkfile types:
.B -o
a single executable file target,
.B -m
multiple targets, one per source file,
.B -l
a user library, and
.B -s
a system library. In each case where a single target is required it's name
must follow the option letter. If none of these options is specified
it is assumed the the mkfile is a top level driver and exists only to recursively call
.I mk(1)
in subdirectories.
.TP
.B -A
.br
Autoconf mode, most defines are written to the file
.I config.h
in the current directory (provided it doesn't exist), and heuristics
are used parse Autoconf feature tests and provide correct answers to them.
.TP
.B  -a
.br
APE mode, target libraries will be placed in /$objtype/lib/ape, binaries in
/$objtype/bin/ape, manuals in /sys/lib/Xape (where X is the manual section number).
This infers that the target application or library will only be used from within
the APE environment.
.TP
.B  -S
.br
.I mkmk(1)
normally reads each header file only once, however strange preprocessor
code can mean a single header file will compile differently depending
on which source file inludes it. The
.B -S
option, (slow but accurate), disables this optimisation at the expense
of much longer runtimes. 
.TP
.B  -I incdir
.br
Aditional include directories to be searched by the compiler
may be given, these are also added to
the
.I CFLAGS=
macro in the generated mkfile. This option make be repeated as required.
.TP
.B  -w width
.br
text in the generated mkfile is word wrapped, at column 78 by default giving
wide but short output.
this column number may be controlled by this
option; a value of zero will give one object per line style \- narrow but tall
files, preferred by some users.
.TP
.B -D name[=value]
.br
C preprocessor macros may be defined using the same syntax as the
C preprocessor. This option may be repeated as often as required.
.TP
.B -U name
.br
C preprocessor macros may be undefined using the same syntax as the
C preprocessor. This option may be repeated as often as required.
.TP
.B -B
This is shorthand for
.B "-c -B"
which turns off the warnings about function calls in the absence of prototypes.
Sadly it owes its existence to the frequency that it is needed.
.TP
.B -c flags
.br
Arbitary C compiler flags can be added to the CFLAGS variable in
the generated mkfile using this option, it make be repeated as required.
.TP
-a
.br
APE mode, controls the installation directories for target files. Libraries are installed
to /$objtype/lib/ape rather than /$objtype/lib,
executables to /$objtype/bin/ape rather than /$objtype/bin and manuals to
/sys/man/apeX rather than /sys/man/X.
.TP
-x file
.br
Exclude file from processing.
.I Mkmk(1)
parses all the files in the current directory, except those specified with
the
.B -x
option. This option can appear as often as necessary.
.TP
.B -h flags
.br
Aditional libker flags make be specified, these are appended to the LDFLAGS
variable in the generate mkfile. This option can appear as often as necessary.
.TP
.B -H libs
.br
User libraries required may be specified, these are appended to
the LIBS variable in the generate mkfile. System libraries need not be
listed as
.B pcc(1)
knows how to find them.
.TP
.B -C file
Files to be deleted by the
.I clean
.B mk(1)
target may be specified, these are
appended to the CLEANFILES variable in the generate mkfile.
This option can appear as often as necessary.
.SH AUTOCONF
In autoconf mode
.I mkmk(1)
attempts to autodetect features requested in the source code by
examining the symbols in the plan9 libraries, and by infering which
plan9 sourcecode control defines are required. A small number of specific
preprocessor macros are also defined automaticially when they are tested;
these relate to features that Plan9 has but which automated testing is
too painful.
.SH BUGS
.I mkmk(1)
needs to have a much better understanding of the APE subsystem.
It should be able to extract the  prototypes defined in the APE headers and what
preprocessor macros they are controlled by. Currently this information is compiled
into the source.
.SH SOURCE
.B /sys/src/cmd/mkmk
.br
.B /sys/src/cmd/mkmk/9port - example 9port scripts
.SH SEE ALSO
.IR mk (1)

Re: [9fans] porting GNU code

[erik quanstrom]

> Importantly the porting effort can be coded into an rc(1) script, this
> means new releases of your GNU (for example) package can be built with
> relative ease.

optomist!

- erik

Re: [9fans] porting GNU code

[Steve Simon]

> optomist!

Yes I am.

However, I did say ``built with relative ease'',
I did not say ``built easily''

☺

-Steve

Re: [9fans] Ogg/Vorbis ported

[Mathieu]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Well, a few trivial tasks could probably be automated. What comes
first to my mind is the removal of the common includes for the non plan
9 headers/libs, namely string.h, stdlib.h, math.h, and stdio.h. I know
this last one is in plan 9 but most of the time the plan 9 one was not
the one needed as the function used were in plan 9's libc, not in stdio.
I did not have to add libc.h and u.h that often, so it wouldn't have
been worth being automated imho.

Then I guess replacing the alloca() calls with malloc() could be done
automatically but one still has to do some carefull searching to place
the free()s, so I'm not sure one would gain much time with this.

As with exit(), it can be replaced automatically with exits() but you
still have to figure out what message you want in your exits().

Honestly, it took me more time to figure out what was wrong and how to
fix it, than to actually do it. Once you have some sort of workflow set
up in your mind, a few Edit lines in a guide file make the repetitive
tasks go much faster. For example, since my sam-foo is weak, it took
me a while to devise that: 'Edit line1,line2x/.*\n/ g/return/p', which
would give me how many return there are in the function I am looking at,
hence helping me not to miss any of the free() to place (without having
to go through all the code).

Cheers,
Mathieu

[-- Attachment #2: Type: message/rfc822, Size: 4246 bytes --]

From: ron minnich <rminnich@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Ogg/Vorbis ported
Date: Thu, 29 Jan 2009 08:27:42 -0800
Message-ID: <13426df10901290827k581268e6i43b213df72b666a4@mail.gmail.com>

>From what you learned, are there some nice general scripts that could
be used to automate some of this for the next hunk of gnu-like code
that comes along?

Thanks for the port ...

ron

Re: [9fans] Ogg/Vorbis ported

[lucio]

> As with exit(), it can be replaced automatically with exits() but you
> still have to figure out what message you want in your exits().

If anyone is interested, this is what I used as a compatibility shim:

#include <u.h>
#include <libc.h>

void
exit (int code) {
	switch (code) {
		case -1:
			exits("FAILURE");
		case 0:
			exits(0);
		default:
			exits("Unknown condition");
	}
}

One could instead print("%d", code), or print("FAILURE: %d", code).

Two cents, please!

++L

PS: I have a small compatibility library I seldom use.  It has been
useful at times.  The version on sources
(contrib/lucio/sys/src/pub/compat) looks a bit skinny, I may have lost
something along the way.

Re: [9fans] Ogg/Vorbis ported

[erik quanstrom]

>> As with exit(), it can be replaced automatically with exits() but you
>> still have to figure out what message you want in your exits().
>
> If anyone is interested, this is what I used as a compatibility shim:
>
> #include <u.h>
> #include <libc.h>
>
> void
> exit (int code) {
> 	switch (code) {
> 		case -1:
> 			exits("FAILURE");
> 		case 0:
> 			exits(0);
> 		default:
> 			exits("Unknown condition");
> 	}
> }
>
> One could instead print("%d", code), or print("FAILURE: %d", code).
>
> Two cents, please!

printing would not make sense.  neither unix nor plan 9
print exit codes.

this seems to me too complicated and not complicated enough.
on the not-complicated-enough side, to get every last program,
you would need to make exit do something like

int
exit(int r)
{
	static char buf[16];

	if(r == 0)
		exits(0);
	snprint(buf, sizeof buf, "%d", r);
	exits(buf);
}

and you would need to rewrite wait to atoi(w->msg).
this would catch programs like postfix that don't treat
exit status as a boolean.  (as god intended.)

but once you've done this, you're going half-way down
the ape path.

otoh, if you design in unix/plan 9 portability, it's too
much.

int
exits(char *s)
{
	/* missing atexits */
	exit(s && *s);
}

porting is rancid, isn't it?

- erik

Re: [9fans] Ogg/Vorbis ported

[lejatorn]

For the record, libogg and libvorbis are now hosted in anothy's
contrib as well.
/n/sources/contrib/anothy/ufo/

Thanks anothy.

Mathieu