Slashdot Mirror

I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).

The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.

Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.

Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.

You can also check out:
- the current draft of the manual, which will give you a better idea of the specifics of where I'm going with this.
- a graphical dump of the grammar for JSON, which the current development code is capable of generating.

I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).

The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.

Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.

Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.

You can also check out:
- the current draft of the manual, which will give you a better idea of the specifics of where I'm going with this.
- a graphical dump of the grammar for JSON, which the current development code is capable of generating.

I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).

The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.

Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.

Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.

You can also check out:
- the current draft of the manual, which will give you a better idea of the specifics of where I'm going with this.
- a graphical dump of the grammar for JSON, which the current development code is capable of generating.

I would encourage anyone who is interested in parsing or ANTLR to follow my project Gazelle. It is intended to be a next-gen parsing framework that builds on the ideas set forth in ANTLR but packages them in a significantly different way, which offers a lot of benefits (which I list in detail on the website).

The primary thing I am trying to deliver is reusability of parsers. The open-source community should be able to cooperate to write canonical parsers for all popular languages, but this goal is hampered by the fact that almost all parsing tools (ANTLR included) encourages you to write non-reusable grammars by virtue of the fact that you embed actions into the grammar.

Gazelle also takes a interpreter+JIT approach instead of emitting code in an imperative language. So for example, if you want a really fast HTTP parser from Ruby (which is precisely the raison d'etre for Mongrel), you can use the HTTP Gazelle parser from Ruby, but since the parsing is actually performed by the interpreter+JIT (written in C), you get extremely fast parsing without writing a line of C.

Gazelle is still very immature and not ready for people to try out, but I would encourage anyone who's interested to follow the Gazelle category on my blog.

You can also check out:
- the current draft of the manual, which will give you a better idea of the specifics of where I'm going with this.
- a graphical dump of the grammar for JSON, which the current development code is capable of generating.

My resume says right at the top that I'm not currently looking for work. Still I get a steady flow of emails soliciting me for Rails jobs.

Also, I was a full-time rails developer for nine months.

I'm in the position of designing a JIT for my latest project (well not quite yet, but soon), and while I'm considering LLVM, I'm leaning towards DynASM. Why? DynASM is 27kb of source compressed and builds in zero time (it's just a few header files) whereas LLVM is a 4.8MB download and takes something like 15 minutes to build.

I love the goals and scope of the LLVM project, I just wish it were a bit lighter-weight.

DJB makes an unusual and somewhat extreme claim in this paper: he says that the Principle of least privilege is "fundamentally wrong." I thought this was a strange thing for a security person to say, and I wrote a blog entry explaining why I think he's overreacting.

• capability-based security, from the ground up
• Microkernel architecture, which brings tons of benefits (principally modularity and isolation). Yes, microkernels have a bad name, but I'm building on L4, a practical, Open Source microkernel that got it right
• extensive support for low-latency and real-time applications (there is no reason that media players on today's hardware should ever glitch)

• capability-based security, from the ground up
• Microkernel architecture, which brings tons of benefits (principally modularity and isolation). Yes, microkernels have a bad name, but I'm building on L4, a practical, Open Source microkernel that got it right
• extensive support for low-latency and real-time applications (there is no reason that media players on today's hardware should ever glitch)

Audacity does not work well at 24 bit. It lacks multiple levels of undo

Huh? Audacity supports as much undo as you have space for. I wrote a "History" dialog that lets you jump to any previous state (which happens almost instantly). Here's a screenshot.

If you really like doing this, take a look at mine.

I have a picture, but if the discrimination thing is real I'll remove it.

It's also on a domain that has other stuff about it, but nothing that I wouldn't mind a potential employer reading (I intentionally keep public information about myself tame in general).

• Hacks such as cleaning up after Microsoft's broken DAV implementation in Windows XP. If a Windows XP client types in a username and password to authenticate against a DAV share, Windows will prepend SOMEDOMAIN\ to the username. This screws up authentication on the server. However you can write a mod_perl handler that intercepts the request in its early stages and rewrites the authentication header to strip SOMEDOMAIN\. Here's the script I wrote to do this
• Authorize users by arbitrary criteria. I wrote an authorization handler that will allow users to DAV into any URL of the form /theirusername/*.

Written like a true poseur!! Tell me, kid, do you know how to write software?

Yep. I've written a significant amount of code for Audacity and PortAudio, and plenty more small patches for other projects along the way. I'm also in the process of writing this introduction to the ALSA API, filling a void where little good documentation exists. Not to mention that I'm working in the software department of a successful computer company.

Listen , I am a professional person and I expec to be paid for my work.

That's wonderful. I am a programmer and I expect free access and distribution rights to the source code of any software I use on a regular basis. There's enough good free software around that I can require this of the software I use and still find programs to do everything I need.

Not that I'm opposed to you being paid for your work, but I'm not going to be the one paying you, especially since paying for proprietary software gets me a worse deal (no source code, no redistribution rights) than downloading free software for free.

This is an authoring error, pure and simple.

Looking at the second testcase now.

Since you're in the know, could you explain this to me while you're at it? It validates as XHTML 1.0 strict, but its behavior doesn't make sense to me.

Many systems have files readable by other students by default, and students don't bother to read-protect their files.

I would fit that description. In fact, I keep my assignments in a public CVS repository as I'm writing them, and many of my classmates know this. I have absolutely no problem with this, just as I have no problem discussing an assignment with my classmates or helping them out on their programs. I'm also fairly certain that cheating is quite rare (and since about half my class did all their work in the computer lab, it would be hard to cover up if it were happenning).

So what's the problem?