For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | Snaipe's commentsregister

This means that if you distribute your dissector, you have to make your sources available.

This is nothing new though: all wireshark plugins must be GPL, since the API itself they rely on is GPL.


v3 means that if it's used (even over a network) by somebody, they can request the code, versus GPLv2 (Wireshark license), which says if you distribute binaries of Wireshark or software based on it, you must provide the source. The difference is that you could theoretically provide a web interface to a GPLv2 project and not need to supply the source, but if you provide such an interface to GPLv3 software, you could receive a request for the code.

EDIT: I'm not entirely correct There are provisions for the network situation ("ASP (application service provider) loophole") I described, but I looks like it's not necessarily the default mode. See [0][1].

[0] https://en.wikipedia.org/wiki/GNU_General_Public_License

[1] https://en.wikipedia.org/wiki/Affero_General_Public_License


Nop The 'over the network' stuff is AGPL


The GNU GPL v3 does not contain such a provision. However, a different license, the GNU AGPL v3, does. Your post is entirely incorrect regarding the GPLv3.

As Wikipedia notes, some drafts of the GPLv3 contained such a provision, but this did not make it into the final version.


This is because wssdl is still within the boundaries of the lua grammar: the file you provide is still lua, so you have to abide by its rule.

I experimented with a key/value approach on the syntax itself (something like `{ src_port = u16 }` or `{ src_port = 16 }`), which was nicer, but the problem was that, in lua, table literals are unordered. The current approach uses the method syntax (`a:b()`) as a nice workaround, but this mandates the use of parenthesis after the type and other specifiers. This is fine though since a lot of the provided types are parameterized (e.g. `bytes(n)` which takes a number of octets)


Author here.

This software is still in alpha, and lacks in both handling some reST features and style extensibility, but is still pretty much functional.

I made this for another project of mine where I needed to render some document parts over the terminal, and decided to give reST a go.

As always, suggestions are welcome.


How does your project differ from rendering an rst document in to a manpage?


Man pages are their own thing -- although the end result could be the same with some aesthetic differences (man pages does not support colors per-se, though with a config you could style your titles or emphasis).

rst2ansi is a more generic document renderer, that may be used in another program to render document parts. It doesn't convert the document to an intermediate man page, nor specifically formats the document as, well, documentation.


The closest thing I think of given your example is how the --help flag in git displays the manpage instead of an option summary. Is that the sort of thing you have in mind?


I originally made this for an interactive index where you can query some document parts, and these parts are written in rst -- in essence, it's almost the same: rendering an arbitrary document into a string, that you may or may not manipulate later.


Author here. This was fun to make, although I'm sure this algorithm is absolutely nothing new.

An implementation of this for rendering tables as rst-style ascii is available here: https://github.com/Snaipe/table2ascii

As always, suggestions are welcome.


Great tutorial with pictures! I'd like to see the tutorial for ascii2table too.


Macros are used to handle platform specific details, for the most part. I don't think it's that opaque, but then again I might be biased.


By default, if the test raises any signal or exits with anything other than 0, the test fails.

Otherwise, you can't (yet!) test if the code exits with a specific value nor simply redirect input/output, but I'll be sure to take these suggestions into account, thanks!

Both will be implemented quite soon.


Developer here.

I made this unit testing framework out of frustrations I had (and still have) with other C frameworks like CUnit or Check.

I wanted to make something much more simple, yet as powerful, and I think (and hope) I nailed it pretty much after a few months of work.

If you have any questions or suggestions, feel free to ask :)


Why did you rule out using Google Test (https://code.google.com/p/googletest)?

(In case you mulled over using it.)


Google Test requires you to write your tests in C++ rather than C; so there was times I just could not use it.


I'm having a little trouble imagining a situation where unit tests for a C codebase are appropriate that would be stymied by having to write the tests in C++. (Maybe relying on struct layout?)


Because C hasn't been a subset of C++ since C99, there are plenty of case where trying to do C in C++ is awkward or just not possible with standard C++:

First, you'd have to wrap your header inclusions in `extern "C"` to disable mangling, then you would have to make sure you static_cast all your pointers where normally `void*` conversions would have done its job.

Furthermore, all interfaces relying on designated initializers and compound literals are broken unless you decide to compile in nonstandard GNU C++.

And there are more incompatibilities, such as using `static` or `const` in array parameter declarations or using VLA in macros which are not recognized by C++.

It's all about using the right tool for the right job, ultimately.


Did you check out Greg Banks' Novaprova?


Actually, I didn't know about it until now! The project uses a similar approach to mine, by parsing the DIE tree produced by dwarf, which means that it won't work if you're not compiling with -g.

It also uses some very platform specific stuff, so windows & os x are out, too.

Very well made nonetheless.


I think he's got OSX running now, but as you say -- it relies on some platform-specific stuff.

Good to see C test frameworks doing some innovative stuff!


Darwin support is functional today, I'm just waiting for the 3.11 Valgrind release, which fixes a bug which is a showstopper for NovaProva.


Developer here. If you have any suggestion/criticism on the project, I'd be happy to know.

What this brings on the table compared to other frameworks is a very simple way to write tests, while giving the programmer enough liberty to do what he wants.

Criterion achieves that by implementing a xUnit structure with automatic test registration using a declarative syntax -- which means you can be very expressive with the way you declare your tests and suite in a few lines of code. The rest is handled by criterion itself and the default main it provides.

Samples: https://github.com/Snaipe/Criterion/blob/bleeding/samples

Documentation: http://criterion.readthedocs.org/en/latest/


Developer here. I'll be happy to answer or listen to any question/criticism.

The library is currently supported on Linux and Mac OS X.


Developer here, I would be happy to answer any question that you have. If you have any suggestions/criticism, I would gladly hear it!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You