> it would be better to pick > good examples, not crappy ones
Unfortunately, I don't know the language, so I can't discriminate between good and bad examples.
> Don't bash a language that > you don't understand.
Hm... I guess my intent was just to support the original poster's note that the code is a bit hard to follow. 'i $l(exec,"""") k=$p(exc,"""",2)' still looks pretty hard to follow to me...
I guess it just looks a little odd... I'd expect to see them broken out into a directory hierarchy that mirrors a package or module structure. But perhaps M doesn't have a concept of such a thing?
> The biggest knock on Vista is that > its written in MUMPS, a rather > obscure programming language
Wow, so true. From gtm_V5.0-000/_RSEL.m:
f s d=$o(d("D",d)) q:d="" i $p=$p(d("D",d)," ") s d=d("D",d),ctrap=$p($p(d,"CTRA=",2)," "),exc=$p(d,"EXCE=",2) q
e s (ctrap,exc)="" ; should never happen
s k=$l(exc,"""")
s k=$l(exc) i $e(exc,1,1)="""",$e(exc,k,k)="""" s exc=$e(exc,2,k-1)
if ctrap'="" s exc="s ctrap="_ctrap x exc
k d
s (cnt,rd)=0,out=1,(last,r(0))=$c(255)
i '$l($zro) s d=1,d(1)="" q
s d=0
> An empty catch block? Useful for > ignoring non-critical errors.
Yup, true.
> Empty If statements? Sometimes [...]
Occasionally but rarely true. But I'd venture to say that the vast majority of empty if blocks are either bugs or just sloppy coding and should be cleaned up.
So yes, you're right, sometimes the warnings can be ignored. But in many cases, they are legitimate.
...since the download for OpenVista is 177 MB. Hideous packaging, too - here's the contents of that file:
$ ls -l total 1132 drwxr-xr-x 2 tom tom 4096 Jul 22 12:44 g drwxr-xr-x 2 tom tom 581632 Jun 28 11:32 o drwxr-xr-x 2 tom tom 561152 Jun 21 18:23 r -rwxr-xr-x 1 tom tom 3576 Jun 21 18:37 vista
The "o" and "r" directories have 23K files each in them. Bizarre.
Because modern software corporations know how to align the interests of the people. They know how to motivate people. They know how to sustain themselves over a long period of time, whereas I'm suspicious about the motivational structure of an open-source community and wonder whether it's sustainable.
That's an understandable suspicion. On the other hand, if you're using an open source product to help build your company, it's in your best interests to take some interest in that product and to help it develop. Then you're part of the community and you know how things are going.
select count(*), browser from activity_log group by browser; count | browser --------+---------
278 | OPERA 239072 | OTHER 499518 | MOZILLA 102863 | IE
It's a hosting site for open source Ruby projects, so it's a different user profile than most sites. But still, word.
Replying to myself... I guess there's two ways to approach it. You can parse the source code (like PMD), or parse the bytecode (like FindBugs).
Parsing the source code might be a bit tricky since you'll need to check for semantic problems which have already been fixed by the time the bytecode has been generated. Parsing the bytecode might have the additional benefit of being able to do some peephole optimization and such; you could write a static analysis tool that also does some work to reduce bytecode size.
Slashdot Mirror
> 60 lines per month.
Really! Jeepers. That seems a bit on the low side. I mean, a month? That's only three or four lines a day... gack.
...although simpler, I think. Apache 2 comes in at a half million dollars, Tomcat weighs in at $250K.
> it would be better to pick
> good examples, not crappy ones
Unfortunately, I don't know the language, so I can't discriminate between good and bad examples.
> Don't bash a language that
> you don't understand.
Hm... I guess my intent was just to support the original poster's note that the code is a bit hard to follow. 'i $l(exec,"""") k=$p(exc,"""",2)' still looks pretty hard to follow to me...
> About half of the files in that list
> are from Apache
Touche!
Yup, it's a bunch of binaries:I guess it just looks a little odd... I'd expect to see them broken out into a directory hierarchy that mirrors a package or module structure. But perhaps M doesn't have a concept of such a thing?
> its written in MUMPS, a rather
> obscure programming language
Wow, so true. From gtm_V5.0-000/_RSEL.m:Laws-a-mercy!
> there are some perfectly valid reasons
Yup, true.
> An empty catch block? Useful for
> ignoring non-critical errors.
Yup, true.
> Empty If statements? Sometimes [...]
Occasionally but rarely true. But I'd venture to say that the vast majority of empty if blocks are either bugs or just sloppy coding and should be cleaned up.
So yes, you're right, sometimes the warnings can be ignored. But in many cases, they are legitimate.
...will help prevent code like this, too. Removing useless code can't help but improve performance, not to mention readability...
[plug]
Support your local open source static code analysis utility!
[/plug]
I'll pass that on to the GForge fellas... thanks much!
Here's how GForge collects this info:It's all in www/include/browser.php...
> What makes up the "other"?
Googlebots mostly, I think...
> Don't you mean "But still, OO.o writer"?
Oh, I was using "word" as an abbreviation for "Abiword", of course! And when I say "I", I mean "GNU/I".
Yup, good stuff, just seems like the open source pickings are a little slim...
...had a sound track performed by the Moscow Symphony. Pretty impressive...
Here's the Wikipedia entry, and here's a code example:
> FxCop
Yup, but is it open source?
Nifty - bytecode analysis, hm, and open source, too. Looks cool, thanks!
Yup, saw that (see here), looks handy. But is it open source?
> FxCop. www.gotdotnet.com/team/fxcop/
Very nice, looks like the message board for that project is hopping, too.
But is it open source? This is the EULA; and I don't see a source download... maybe I'm just missing it...
Replying to myself... I guess there's two ways to approach it. You can parse the source code (like PMD), or parse the bytecode (like FindBugs).
Parsing the source code might be a bit tricky since you'll need to check for semantic problems which have already been fixed by the time the bytecode has been generated. Parsing the bytecode might have the additional benefit of being able to do some peephole optimization and such; you could write a static analysis tool that also does some work to reduce bytecode size.