-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I try to write a Windows Bitmap File using Data.Binary, but I have some trouble. For example, the internet states, that the magic number, that puts 'BM' in the first two bytes of the file is 19778. But when I
put (19778::Word16)
I get 'MB' instead. I read on the german Wikipedia, that bmp uses little endian encoding, but Data.Binary uses big endian. Obviously this can't work. Is there a way to switch endianness? Or at least a function that converts between the two? I looked at the Data.Binary Haddock documentation, but found nothing like that. Thanks in advance, Adrian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG5Q1Z11V8mqIQMRsRA/V6AJoC/R2k5rz0LjQI4iGoi79zLYZmgwCdEx/g cZOR5jseUcQnc6+I09N+xj8= =K5ww -----END PGP SIGNATURE-----
Adrian Neumann wrote:
For example, the internet states, that the magic number, that puts 'BM' in the first two bytes of the file is 19778. But when I
put (19778::Word16)
I get 'MB' instead. I read on the german Wikipedia, that bmp uses little endian encoding, but Data.Binary uses big endian. Obviously this can't work.
Data.Binary is two different things. This is not as well explained as it could be. It is (a) a binary read/write layer for haskell types, which uses its own formats you have no right to complain about (b) a simple efficient binary bitstream layer You don't want to use (a), which takes great care to use compatible endianness to make sure its output can be read on other architectures. (b) however lets you choose your endianness. http://www.cse.unsw.edu.au/~dons/binary/Data-Binary-Put.html The docs are not as well interlinked as you might hope. Jules
Thomas Schilling wrote:
On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote:
The docs are not as well interlinked as you might hope.
In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds.
On the documentation page: http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message. Jules
On Monday 10 September 2007 17:17, Jules Bean wrote:
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html [...]
Just a small hint: That page seems to be out of date compared to: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3 The library looks quite nice, but I'm missing support for reading/writing Int{8,16,32,64} and Float/Double (in IEEE format, currently *the* binary representation in most formats I know) in LE/BE/host byte order. Have I overlooked something? Using unsafeCoerce# and friend there are probably workarounds for this, but having it in the "official" API would be quite helpful for I/O of real-world formats. Cheers, S.
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote:
On Monday 10 September 2007 17:17, Jules Bean wrote:
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html [...]
Just a small hint: That page seems to be out of date compared to:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3
The library looks quite nice, but I'm missing support for reading/writing Int{8,16,32,64}
maybe this? http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary-... Also note that many Haskell standard types are instances of the Binary class. I might have misunderstood what you're asking for, though...
and Float/Double (in IEEE format, currently *the* binary representation in most formats I know) in LE/BE/host byte order. Have I overlooked something? Using unsafeCoerce# and friend there are probably workarounds for this, but having it in the "official" API would be quite helpful for I/O of real-world formats.
Cheers, S.
On Monday 10 September 2007 18:21, Thomas Schilling wrote:
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote: [...]
The library looks quite nice, but I'm missing support for reading/writing Int{8,16,32,64}
maybe this?
http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary -Get.html#v%3AgetWord8
Of course I can *implement* everything on top of this, but this is not the point. The binary library should have builtin support for more data types, and this is probably not hard to implement.
Also note that many Haskell standard types are instances of the Binary class. I might have misunderstood what you're asking for, though...
Again a confusion of the 2 things the binary package offers (I was confused initially as well): The Binary class is totally useless for reading/writing existing formats, simply because that's not its task. To read/write an existing format (BMP, MP3, WAV, Quake BSP, etc.) you have to use the getFoo/readFoo functions. So what I was asking for is: getInt32be, putIEEEFloatLe, getIEEEDoubleHost, ... Type classes might be used to get a slightly smaller API, but I am unsure about the performance impact and how much this would really buy us in terms of the ease of use of the API. Cheers, S.
sven.panne:
On Monday 10 September 2007 18:21, Thomas Schilling wrote:
On Mon, 2007-09-10 at 18:11 +0200, Sven Panne wrote: [...]
The library looks quite nice, but I'm missing support for reading/writing Int{8,16,32,64}
maybe this?
http://hackage.haskell.org/packages/archive/binary/0.3/doc/html/Data-Binary -Get.html#v%3AgetWord8
Of course I can *implement* everything on top of this, but this is not the point. The binary library should have builtin support for more data types, and this is probably not hard to implement.
Yeah, just send patches against the darcs repo for either Binary instances for more basic types, or primops if necessary (e.g. for Float)
Also note that many Haskell standard types are instances of the Binary class. I might have misunderstood what you're asking for, though...
Again a confusion of the 2 things the binary package offers (I was confused initially as well): The Binary class is totally useless for reading/writing existing formats, simply because that's not its task. To read/write an existing format (BMP, MP3, WAV, Quake BSP, etc.) you have to use the getFoo/readFoo functions. So what I was asking for is:
getInt32be, putIEEEFloatLe, getIEEEDoubleHost, ...
Right.
Type classes might be used to get a slightly smaller API, but I am unsure about the performance impact and how much this would really buy us in terms of the ease of use of the API.
Yeah, performance is the big thing here: we spent weeks cranking it up to hundred+ M/sec throughput. I'd hate to lose that, and the API is pretty simple anyway. -- Don
Don Stewart wrote:
sven.panne:
Of course I can *implement* everything on top of this, but this is not the point. The binary library should have builtin support for more data types, and this is probably not hard to implement.
Yeah, just send patches against the darcs repo for either Binary instances for more basic types, or primops if necessary (e.g. for Float)
Ah, the famous "open source process" we all hear so much hype about... This is probably the first time I've actually seen it in action though. Refreshing. :-)
On Mon, 2007-09-10 at 18:40 +0200, Sven Panne wrote:
Type classes might be used to get a slightly smaller API, but I am unsure about the performance impact and how much this would really buy us in terms of the ease of use of the API.
There shouldn't be any problem w.r.t. performance, the compiler can specialize and inline. What's the problem with reading custom data? data MP3 = MP3 { ... } instance Binary MP3 where get = MP3 <$> getHeader <*> getData -- [*] where getHeader = do magic <- getWord32le case magic of ... ... put = ... to read a (IEEE) double you use do x <- (get :: Double); ... but most of the time the right type will be inferred from the context. If there are serious performance problems it'd could probably be attacked using some more use of inline declarations or maybe use of compiler rewrite rules (in the library). I don't expect things to work as smoothly as they maybe could (the package is in version 0.3), but so far things don't seem too bad. Did you do any benchmarks? / Thomas [*] .. note that <$> .. <*> is just a more convenient way of writing: do hdr <- getHeader dat <- getData return (MP3 hdr dat) Those operators live in Control.Applicative and are included in recent versions of the 'base' package. (
On Monday 10 September 2007 19:50, Thomas Schilling wrote:
[...] instance Binary MP3 where get = MP3 <$> getHeader <*> getData -- [*] where getHeader = do magic <- getWord32le case magic of ...
Of course this works in the sense that "it compiles", but Binary is conceptually the wrong class to use.
to read a (IEEE) double you use
do x <- (get :: Double); ...
:Where is "IEEE" mentioned in the docs? Does it use LE/BE/host order? Plain get/put on Float/Double are useless for reading IEEE floating numbers. Cheers, S.
sven.panne:
On Monday 10 September 2007 19:50, Thomas Schilling wrote:
[...] instance Binary MP3 where get = MP3 <$> getHeader <*> getData -- [*] where getHeader = do magic <- getWord32le case magic of ...
Of course this works in the sense that "it compiles", but Binary is conceptually the wrong class to use.
I wouldn't go as far as saying `wrong', for protocol-specific data types it seems reasonable for the Haskell serialisation to use an agreed-upon external format, via a Binary instance. It's cute, anyway. -- Don
On Tuesday 11 September 2007 08:14, Don Stewart wrote:
sven.panne:
On Monday 10 September 2007 19:50, Thomas Schilling wrote:
[...] instance Binary MP3 where get = MP3 <$> getHeader <*> getData -- [*] where getHeader = do magic <- getWord32le case magic of ...
Of course this works in the sense that "it compiles", but Binary is conceptually the wrong class to use.
I wouldn't go as far as saying `wrong', for protocol-specific data types it seems reasonable for the Haskell serialisation to use an agreed-upon external format, via a Binary instance.
The question is: What is the *human reader* suggested when he sees a signature like "foo :: Binary a => ... -> a -> ..."? This should probably mean "foo is using some portable (de-)serialization, but doesn't care about the actual representation", at least this is how I understand Binary's contract from the Haddock docs. The example above means something completely different, so I propose to add another class (e.g. "ExternalBinary", better name needed) to the binary package for such uses. This class wouldn't have any instances in the package itself, but at least it would set a standard, so things are crystal clear when one sees a signature like "blah :: ExternalBinary a => ... -> a -> ...". This situation is very similar to the OO-world, where class inheritance is often overused, just because it looks so handy when written initially and delegation/aggregation/... would be the conceptually right way (i.e. implementation hierarchy vs. interface hierarchy). Cheers, S.
On Tue, 2007-09-11 at 09:10 +0200, Sven Panne wrote:
foo :: Binary a => ... -> a -> ..."? This should probably mean "foo is using some portable (de-)serialization, but doesn't care about the actual representation",
I'm probably missing something, but: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? -k
Ketil Malde wrote:
On Tue, 2007-09-11 at 09:10 +0200, Sven Panne wrote:
foo :: Binary a => ... -> a -> ..."? This should probably mean "foo is using some portable (de-)serialization, but doesn't care about the actual representation",
I'm probably missing something, but:
How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats?
It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here. The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes. For these reasons, although it is very cool, I don't think it can be recommended as a basis for long-term file format definitions. (All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.) Jules
On Tue, 2007-09-11 at 12:01 +0100, Jules Bean wrote:
How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats?
It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here.
Okay. Data.Binary is not for persistence, then (since the format may change between versions of the library, and presumably between different compilers/RTS), but merely for transient serializing, as over a network connection. This isn't so obvious from the documentation (I myself have blatantly used it for persistence and for reading in externally specified data), and the functions involving FilePaths also tend confusing the issue here. Perhaps it could be made clearer? Another way to avoid abuse of Data.Binary would be to add a unique magic number to each stream, and throw an exception when a mismatching magic number is encountered. -k
Ketil Malde wrote:
On Tue, 2007-09-11 at 12:01 +0100, Jules Bean wrote:
How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats?
It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here.
Okay. Data.Binary is not for persistence, then (since the format may change between versions of the library, and presumably between different compilers/RTS), but merely for transient serializing, as over a network connection.
I probably came over stronger than I intended. It is intended for persistence, too. My point is that, should a bug be discovered in Data.Binary, the maintainers may be forced to change the format and there is no mechanism in place for coping with that.
On Sep 11, 2007, at 7:01 , Jules Bean wrote:
The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes.
I will just point out that, while this is one extreme, the other extreme is ASN.1. I think we want to walk the middle path instead.... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
So the answer for persistence is Data.Binary -> ASN.1 converter that
can be used in extrema?
On 11/09/2007, Brandon S. Allbery KF8NH
On Sep 11, 2007, at 7:01 , Jules Bean wrote:
The actual format used by Data.Binary is not explicitly described in any standard (although in most cases it's moderately obvious, and anyone can read the code), and it's not formally guaranteed that it will never change in a later version (although the maintainers will no doubt try very hard to ensure it doesn't); nor does it contain any automatic support for version-stamping to ensure backwards compatibility in the face of later unlooked-for format changes.
I will just point out that, while this is one extreme, the other extreme is ASN.1. I think we want to walk the middle path instead....
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Jules Bean wrote:
For these reasons, although it is very cool, I don't think it can be recommended as a basis for long-term file format definitions.
Indeed, the authors have never claimed that this is what it's for. Unfortunately, because the authors haven't *disclaimed* this as a purpose, people have fairly reasonably assumed that this *is* the intent of the package. In conversations with Don and Duncan, they've always been quite clear that Data.Binary is intended to shovel bits rapidly and with a reasonable interface. All of the things of which you speak, and more useful ones such as RTTI and representation of cyclic data, ought to live in a higher-level library. Said library merely hasn't been written yet.
(All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.)
Data.Binary *is* the low-level Data.Binary :-)
Bryan O'Sullivan wrote:
(All of the above speaks of the 'high-level' Data.Binary not the 'low-level'.)
Data.Binary *is* the low-level Data.Binary :-)
I was distinguishing between these two levels: (1) High-level = Binary typeclass. Contains instances for many, many useful common types, the internals of which you don't need to understand to use them. But then you wont' understand the format used. Which doesn't matter if all you want to do is pipe stuff around. (2) Low-level = Get and Put typeclasses. Allow you to shovel bytes as you wish, including bundling them up into words of various sizes with explicit endian-ness control. You can sensibly use this to define file formats precisely with some reasonable expectation of speed. You could for example write a TIFF reader (and writer [*]) using these primitives. Jules [*] - exercise for the reader: Can you write a TIFF reader and writer simultaneously, in the sense that you define the file format once and get Get and Put instances for free?
Hello Sven, Tuesday, September 11, 2007, 11:10:17 AM, you wrote:
Haddock docs. The example above means something completely different, so I propose to add another class (e.g. "ExternalBinary", better name needed) to
this looks correct form theoretical POV but don't forget that then you will need to redefine each and every function working on Binary instances -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Sven Panne wrote:
So what I was asking for is:
getInt32be, putIEEEFloatLe, getIEEEDoubleHost, ...
Type classes might be used to get a slightly smaller API, but I am unsure about the performance impact and how much this would really buy us in terms of the ease of use of the API.
It's not that related, but I just got struck by an obvious idea, namely to put the endianness in an extra parameter data Endianness = Little | Big | Host putInt32 :: Endianness -> Int -> Put in order to avoid three functions for every data type. I don't know whether this makes performance a bit worse, but if it does, phantom types or similar are an option to encode endianness, too. data LE = LE data BE = BE data Host = Host class Put a endian where put :: endian -> a -> Put instance Put Int32 LE where ... instance Put Int32 BE where ... instance Put Int32 Host where ... Oh, and the 8,16,32 and 64 are good candidates for phantom type/associated data types, too. Regards, apfelmus
On Monday 10 September 2007 21:02, apfelmus wrote:
[...] class Put a endian where put :: endian -> a -> Put [...] Oh, and the 8,16,32 and 64 are good candidates for phantom type/associated data types, too.
I think that using any non-H98 feature like MPTC or associated data types for such a generally useful and basic package would be a *big* mistake. Let's follow the "KISS" principle here. Everybody is free to make a nicer, but non-portable wrapper... Cheers, S.
* apfelmus wrote:
It's not that related, but I just got struck by an obvious idea, namely to put the endianness in an extra parameter
data Endianness = Little | Big | Host putInt32 :: Endianness -> Int -> Put
Please add the endianess to the state of the monad "Put". setendianess :: Endianness -> Put And for convinience please add the "Network" constructor to the type "Endianness". ,-)
On Mon, 2007-09-10 at 16:17 +0100, Jules Bean wrote:
Thomas Schilling wrote:
On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote:
The docs are not as well interlinked as you might hope.
In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds.
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html
I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message.
Jules
No offence was intended. I was simply mentioning a feature that might be overlooked by many. If you look at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3 You can find links to the various modules provided by that package and will notice that links to parts exported by other packages work nicely. (In this case it is only base-2.0, I think.) Your clarification is probably worth including into the package documentation, but I think you have to talk to dons for that to happen. / Thomas
nominolo:
On Mon, 2007-09-10 at 16:17 +0100, Jules Bean wrote:
Thomas Schilling wrote:
On Mon, 2007-09-10 at 11:10 +0100, Jules Bean wrote:
The docs are not as well interlinked as you might hope.
In fact, the docs on hackage are interlinked nicely. That is, for packages for which the documentation builds.
On the documentation page:
http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html
I see no links to Data.Binary.Put, nor anything to make me even suspect that there is another page I should be reading. Nor anythign to suggest that Data.Binary is split into two levels in the way I outlined in my earlier message.
Jules
No offence was intended. I was simply mentioning a feature that might be overlooked by many. If you look at
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.3
You can find links to the various modules provided by that package and will notice that links to parts exported by other packages work nicely. (In this case it is only base-2.0, I think.)
Your clarification is probably worth including into the package documentation, but I think you have to talk to dons for that to happen.
Yep, just send a patch. Or suggest what needs to happen. -- Don
On Monday 10 September 2007 19:26, Don Stewart wrote:
Yep, just send a patch. Or suggest what needs to happen.
OK, I'll see what I can do next weekend, currently I'm busy with packaging/fixing GHC. I have similar code lying around in various places, and it would be nice if there was a more officially sanctioned place to put this. Cheers, S.
sven.panne:
On Monday 10 September 2007 19:26, Don Stewart wrote:
Yep, just send a patch. Or suggest what needs to happen.
OK, I'll see what I can do next weekend, currently I'm busy with packaging/fixing GHC. I have similar code lying around in various places, and it would be nice if there was a more officially sanctioned place to put this.
Just in case people didn't see, the `binary' package lives on http://darcs.haskell.org/binary/ However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review. -- Don
Don Stewart wrote:
Just in case people didn't see, the `binary' package lives on
http://darcs.haskell.org/binary/
However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review.
Right. And this is the "real" binary package then? (I've seen references to seemingly half a dozen "binary" packages, some obsolete, some not... It's rather confusing out there!)
andrewcoppin:
Don Stewart wrote:
Just in case people didn't see, the `binary' package lives on
http://darcs.haskell.org/binary/
However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review.
Right. And this is the "real" binary package then? (I've seen references to seemingly half a dozen "binary" packages, some obsolete, some not... It's rather confusing out there!)
Yep. Look on hackage to get a sense of what is current. -- Don
On Tuesday 11 September 2007 09:17, Don Stewart wrote:
Just in case people didn't see, the `binary' package lives on
http://darcs.haskell.org/binary/
However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review.
Is there any deep reason why "binary" is not below "packages" like almost all other packages? The toplevel directory is already a complete mess, so a little bit more structure would be good. So I propose the following: Move "binary" to "packages/binary", update any references to the old URL and use a symlink on darcs.haskell.org for backwards compatibility (this should be nuked in a few months or so). Cheers, S.
On Sat, Sep 15, 2007 at 01:20:57PM +0200, Sven Panne wrote:
On Tuesday 11 September 2007 09:17, Don Stewart wrote:
Just in case people didn't see, the `binary' package lives on
http://darcs.haskell.org/binary/
However, Lennart Kolmodin, Duncan and I are actively maintaining and reviewing patches, so send them to one (or all) of us for review.
Is there any deep reason why "binary" is not below "packages" like almost all other packages? The toplevel directory is already a complete mess, so a little bit more structure would be good. So I propose the following: Move "binary" to "packages/binary", update any references to the old URL and use a symlink on darcs.haskell.org for backwards compatibility (this should be nuked in a few months or so).
"packages" is only for those libraries that are shipped with GHC. Stefan
On Saturday 15 September 2007 20:09, Stefan O'Rear wrote:
"packages" is only for those libraries that are shipped with GHC.
First of all, this fact would be new to me, furthermore this would be a highly volatile categorization. Should URLs change when a package suddenly gets into or was thrown out of boot-/extra-packages? I don't think so. The fact what is shipped and what not is explicit in the ghc/libraries/{boot,extra}-libraries, not in the structure of darcs.haskell.org. Packages which are hosted there should be below, well, "packages". The toplevel directory is currently a bit crowded and unstructured... Cheers, S.
Stefan O'Rear wrote:
"packages" is only for those libraries that are shipped with GHC.
It is? This is news to me. An obvious counter example seems to be the collections package which has been put here. This is not shipped with ghc and I'm not aware of any plans to do this. Perhaps if this is the intention it would be better to call it "ghc-packages". But darcs.haskell.org does seem to be a real mess and I do have a hard time figuring out what's what here and how it's organised (or even if it is organised :-) Regards -- Adrian Hey
Adrian Neumann wrote:
For example, the internet states, that the magic number, that puts 'BM' in the first two bytes of the file is 19778. But when I
put (19778::Word16)
I get 'MB' instead.
Just use putWord16le instead. There exist endian-specific versions of
all of the word-level get and put functions.
participants (15)
-
Adrian Hey -
Adrian Neumann -
Andrew Coppin -
apfelmus -
Brandon S. Allbery KF8NH -
Bryan O'Sullivan -
Bulat Ziganshin -
Don Stewart -
Jules Bean -
Ketil Malde -
Lutz Donnerhacke -
Neil Davies -
Stefan O'Rear -
Sven Panne -
Thomas Schilling