ANTLR sucks...

ANTLR sucks... - The Desian Universe — LiveJournal

Links Home / GitHub

January 2017


	1


	2


	3


	4


	5


	6


	7


	8


	9


	10


	11


	12


	13


	14


	15


	16


	17


	18


	19


	20


	21


	22


	23


	24


	25


	26


	27


	28


	29


	30


	31

deskitty

Des

	Tue, Jan. 18th, 2005 11:25 pm

ANTLR sucks...

...but it's also much more flexible/full-featured/easier-once-you-get-the-hang-of-it than bison/flex. I just wish it wouldn't be so damn finicky. Good documentation would help too. The ANTLR documentation is (a) ambiguous, (b) incomplete, and (c) sometimes just plain wrong. I regularly had to go digging through the ANTLR headers/source to figure out why things weren't working.

So I have a love/hate relationship with it. Yay compilers class ...

(23:03:01) CondorDes: huh. I suck at estimating times. :)
(23:03:05) CondorDes: Which is probably a good thing.
(23:03:27) Rob: what kind of time?
(23:04:00) CondorDes: I had two tasks today; first was finish the type checking part of the compiler and make it produce reasonable error messages, and second was to do return checking (i.e. make sure all paths through a function return a value)
(23:04:15) CondorDes: I figured the first would take an hour or two, max ... and I ended up spending most of the day on it.
(23:04:38) CondorDes: I figured the second would take at least several hours, and I just did it in about 20 minutes. ;P

>>> MetaFS

Making slow progress on MetaFS. I'm slowly transitioning it over to a more flexible VFS/plugin design (which is also more complex and thus somewhat slower, but that's life ... ::sigh::). Once that's done, I'm going to write an MP3/Ogg plugin (because new user-visible features are a good thing) and push 0.1.2. I'm guessing that won't happen for a good week or two though.

0.1.3 is going to be a bit more ambiguous, though. I'm seriously thinking about scrapping BerkeleyDB in favor of SQLite ... but I have a sneaking suspicion that SQLite is the reason amaroK runs so slowly. Such a tradeoff ... nice and fast (with a custom query engine, ugh) or slow and easy (just generate SQL queries)? Hmmmm. [Before any of you suggest it, a full-fledged RDBMS like PostgreSQL or -- $DEITY forbid -- MySQL is right out. This needs to be usable on desktop systems, which means easy to setup...]

In any case, I'm shooting for at least rudimentary indexing and searching in 0.1.3. But I guess we'll see ...

>>>

I'm turning into a regular socialite, which scares me. I have regularly-scheduled things Fri, Sat and Sun nights ... and this week I have stuff on Wed and Thurs, too. All of these involve eating out, for one reason or another ... I can hear my poor wallet screaming now ...

-- Des

Current Mood: awake

awake
Current Music: Various Artists - Star Trek Series - The Healing Process

robbat2

Robbat2

	Thu, Jan. 20th, 2005 12:48 am (UTC)

SQLite can be fast, it's just easy to write slow code with it. At one stage I wrote a prototype backend for Portage using SQLite, and found it to be only fractionally slower than the normal AnyDBM we use (but at a larger memory overhead).

One danger found in all file-based DBMS is that multipler writers (without corrupting the file) is very hard to do. SQLite is the only one that I am aware of that makes it possible to actually do this presently. Even so, SQLite is DB-level locking, not table or row level.

deskitty

Des

	Thu, Jan. 20th, 2005 06:36 am (UTC)

OK, that actually makes me feel better about SQLite. The DB-level locking thing concerns me a little bit from a performance standpoint (since the daemon is multithreaded, and multiple threads may potentially be writing at once), but there are probably ways to minimize the impact there.

I guess we'll see. That's the easiest/fastest way for me to implement it at this point ... so it makes the most sense. Then if it turns out to be a performance bottleneck later, I suppose it can be replaced.

robbat2

Robbat2

	Thu, Jan. 20th, 2005 08:07 am (UTC)

It's only locked during writes.
Reads are completely concurrent.
One thing I read about it, is the interesting locking model that is used.

Read locks exist, but they are just to stop the writer starting up while readers are still busy.
All transactions start as read locks, the moment you do an write (insert/update), they get a write lock instead.
Due to this design, it's best to keep all writes at the end of transactions, and avoid a read-write-read sequence in the transaction.

My girlfriend likes your kitten picture.

Log in