Right, the author mentioned configuration... but I felt like he kind of let that idea die off. I mean, when he's talking about the tree movement, he talks about trunks, then something like "if the processor can handle it" introduce branches and leaves, and then a third level of realism above that. I guess I felt that talking about configuration at that point would have been helpful.
Off topic, but I found the article a bit hard to follow since I had to click through all 7 pages - and clicking on "printable version" just showed one page at a time as well. Argh....
if (!((r <= w && (e < r || e >= w)) || (e < r && e >= w))) {
IPW2100_DEBUG_TX("exit - no processed packets ready to release.\n");
return 0;
}
Fortunately there's a little ASCII art right above it that helps explain what that if condition does:
/*
* Quick graphic to help you visualize the following
* if / else statement
*
* ===>| s---->|===============
* e>|
* | a | b | c | d | e | f | g | h | i | j | k | l
* r---->|
* w
*
* w - updated by driver
* r - updated by firmware
* s - start of oldest BD entry (txq->oldest)
* e - end of oldest BD entry
*
*/
Re:Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 1
Yup, sure, right on. And Ruby is written in C, after all, so if C dies Ruby won't be far behind.
I guess it's hard to say much about the future of languages... seems like they sort of get revived now and then... the ebb and flow, as 'twere. But anyhow, I plan on using Ruby for the foreseeable future:-)
Re:Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 1
> At least 50 people use Ruby
At least 50 people use C, too!:-)
> Which would you bet on sticking around?
Both.
> they both suffer the same fate
Nay, forsooth!
Re:Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 1
> the bottleneck will be the network, > not the application code
Right on. It's like working on a SOAP client - you can optimize the heck out of the client, but sending all that XML over the wire is where your performance hit is going to happen.
> we hold the individual responsible, > rather than the knife or gun
Not in all cases. Lots of hardware has failsafe mechanisms built into it.
For example, when I was in the Coast Guard, our ship had a 25mm gun on the bow. The gun had "stops" - that is, if you tried to swing it aft to point at the pilothouse, there were metal stanchions that kept it from going that far. So even if someone went nuts and tried to expend a couple of rounds at the bridge, he couldn't.
Not to mention that the GM1 would have thrown him over the side. But that's a given.
Re:Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 1
> Do a poll of every software developer > or programmer you know and ask them if > they have ever written or seen a program > written in Ruby
The 50 or so developers on my current project all find Ruby quite handy.
> same principles apply to Eiffel, et al
Yup, not much Eiffeling going on these days, to the best of my knowledge. I guess I feel that there's a bit of a difference btwn Ruby and say, Ada or Eiffel.
Maybe we're the last project in the world to use Ruby... but I doubt it....
Re:Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 0, Offtopic
> For what purpose?
Oh, the usual scripting language reasons: easier to program, easier to debug, reduces dangers of stack smashing and suchlike... all that.
> Ruby is an esoteric language that > hardly anyone uses and less people will > use as the years goes on
Ruby is a general purpose language that lots of people use and it will continue to grow in popularity.
There, now we've both made assertions. So where do we go from here?
Most implementations will be in written in C...
on
Implementing CIFS
·
· Score: 2, Insightful
...but is there any reason why a CIFS client (or server) couldn't be written in a higher level language like Ruby?
Obviously there'd be a speed hit, but it seems like it'd be a lot faster to develop in, and time-critical bits could be written in C and accessed via Ruby/DL or whatever.
Ditto for Python, of course... same sort of advantages/issues.
> What projects (software or otherwise) are > out there that would benefit from more > involvement if only they had the publicity?"
I think the problem is that projects that are useful and popular get as much developer help as they need, whereas those projects that aren't getting helped are usually in that situation for good reasons.
For example, I work on a clunky little DOOM map generator. I wrote it as a way to a) generate very simple maps and b) learn about bitpacking in Ruby. So the fact that it only gets 3 downloads a day is fine - it's serving its purpose.
If you want to help a popular open source project - Open Office or Mozilla or some such - a way to do it might be to download Valgrind and find a memory leak or two. Submit a couple of patches and you'll be doing lots of people a favor, and you'll probably get mad props from the project you're contributing to for getting some grunt work accomplished.
First, sorry about the delay in replying. I lost the original email from Slashdot and had to dig around a bit to locate this comment. Anyhow.
> Making direct, statements
Hm. That kind of makes sense... although such a statement provides a claim by which to analyze a given religion. If a religion claimed that all people were transported to earth by spaceships in 1900, it would be easy to disprove that religion.
> This is the domain of science
Right on, empirical data and all that.
There's a school of thought called scientism that more or less says that all truth worthy of the name must be empirically provable. So a statement like "My dad and I enjoyed the baseball game" wouldn't be "true" because there weren't any double-blind studies or statistics gathered to support that assertion. At the other end of the spectrum is subjectivism, which abandons the field and says that you can't know anything at all with any certainty, so why bother.
I'm not sure that's entirely relevant, but I'm listening to a book on tape on my commute to work that talks about that and it seemed interesting:-)
> Write a simple game on your own, > something a one-man shop could do. > Write another pac-man clone, or space > invaders, or asteroids. Polish it with > title screens showing points and credits, > and make it look like something from > an 80's arcade.
So true. This gave me an appreciation for how hard this stuff is. Just getting collision detection working in a Brickout clone was enough to send me back to my college math books, relearning basic trigonometry.
And reading books like "Game Programming Gems" gave me an appreciation for the same sort of thing. It's not just that there's an article on A*, it's that the first paragraph of the article summarizes A* and references three or four papers which have been written about various A* optimizations. Crikey.
Dude, there was this asteroid thing, and some dinosaurs, and, aw man, is that crazy or what?
> I'm reading an excerpt from the > BBC's online h2g2,
Cool. I wish I could find that series on books on tape... 'twould make my commute much nicer. It'd be quite a number of tapes, though... the weight would probably cut my gas mileage in half...
Yup, I'm not sure where we're going with this one. On the other hand, this discussion is allowing me to procrastinate on applying a large and complicated patch to a project I'm working on, which is nice.
> I'm not sure I caught the Simpsons reference
Regrettably, I couldn't come up with one, but I left the reference in there just as an initial break-the-ice sort of thing. A sort of Slashdotters greeting, if you will.
Slashdot Mirror
Right, certainly, there are conflicting forces here - ease of use vs configurability.
I guess I'd tend to err on the side of advanced users being able to configure things....
Right, the author mentioned configuration... but I felt like he kind of let that idea die off. I mean, when he's talking about the tree movement, he talks about trunks, then something like "if the processor can handle it" introduce branches and leaves, and then a third level of realism above that. I guess I felt that talking about configuration at that point would have been helpful.
Off topic, but I found the article a bit hard to follow since I had to click through all 7 pages - and clicking on "printable version" just showed one page at a time as well. Argh....
Instead of trying to do super-duper processor detection degradation stuff, let the player choose levels of detail and such-like.
That way he can choose whatever's important to him... if he's a big fan of realistic trees, let 'em have it at the cost of slower AI or whatever.
...also wrote The Unix Guide to Defenestration, which is an executive-level discussion of making a data center profitable.
He's been a Linux advocate for quite a while...
> the end of it is within the free
> space in the buffer after w and before r
Hm, nifty! Thanks!
Yup, sure, right on. And Ruby is written in C, after all, so if C dies Ruby won't be far behind.
:-)
I guess it's hard to say much about the future of languages... seems like they sort of get revived now and then... the ebb and flow, as 'twere. But anyhow, I plan on using Ruby for the foreseeable future
> At least 50 people use Ruby
:-)
At least 50 people use C, too!
> Which would you bet on sticking around?
Both.
> they both suffer the same fate
Nay, forsooth!
> the bottleneck will be the network,
> not the application code
Right on. It's like working on a SOAP client - you can optimize the heck out of the client, but sending all that XML over the wire is where your performance hit is going to happen.
> I pointed out that this is not
> always the case.
You're right, it's not.
> Given enough time, it might be possible
> to break or otherwise get around these stops
Sure, they could break out a torch and cut the stops off.
> we hold the individual responsible,
> rather than the knife or gun
Not in all cases. Lots of hardware has failsafe mechanisms built into it.
For example, when I was in the Coast Guard, our ship had a 25mm gun on the bow. The gun had "stops" - that is, if you tried to swing it aft to point at the pilothouse, there were metal stanchions that kept it from going that far. So even if someone went nuts and tried to expend a couple of rounds at the bridge, he couldn't.
Not to mention that the GM1 would have thrown him over the side. But that's a given.
> Do a poll of every software developer
> or programmer you know and ask them if
> they have ever written or seen a program
> written in Ruby
The 50 or so developers on my current project all find Ruby quite handy.
> same principles apply to Eiffel, et al
Yup, not much Eiffeling going on these days, to the best of my knowledge. I guess I feel that there's a bit of a difference btwn Ruby and say, Ada or Eiffel.
Maybe we're the last project in the world to use Ruby... but I doubt it....
> For what purpose?
Oh, the usual scripting language reasons: easier to program, easier to debug, reduces dangers of stack smashing and suchlike... all that.
> Ruby is an esoteric language that
> hardly anyone uses and less people will
> use as the years goes on
Ruby is a general purpose language that lots of people use and it will continue to grow in popularity.
There, now we've both made assertions. So where do we go from here?
...but is there any reason why a CIFS client (or server) couldn't be written in a higher level language like Ruby?
Obviously there'd be a speed hit, but it seems like it'd be a lot faster to develop in, and time-critical bits could be written in C and accessed via Ruby/DL or whatever.
Ditto for Python, of course... same sort of advantages/issues.
...is NOVALUG.
You can find many presentations and such-like from past meetings here.
This link's for you.
[tcopeland wishes email were a higher bandwidth medium, more capable of effectively communicating emotions/body language/nonverbal cues...]
> What projects (software or otherwise) are
> out there that would benefit from more
> involvement if only they had the publicity?"
I think the problem is that projects that are useful and popular get as much developer help as they need, whereas those projects that aren't getting helped are usually in that situation for good reasons.
For example, I work on a clunky little DOOM map generator. I wrote it as a way to a) generate very simple maps and b) learn about bitpacking in Ruby. So the fact that it only gets 3 downloads a day is fine - it's serving its purpose.
If you want to help a popular open source project - Open Office or Mozilla or some such - a way to do it might be to download Valgrind and find a memory leak or two. Submit a couple of patches and you'll be doing lots of people a favor, and you'll probably get mad props from the project you're contributing to for getting some grunt work accomplished.
> This is the domain of science
:-)
First, sorry about the delay in replying. I lost the original email from Slashdot and had to dig around a bit to locate this comment. Anyhow.
> Making direct, statements
Hm. That kind of makes sense... although such a statement provides a claim by which to analyze a given religion. If a religion claimed that all people were transported to earth by spaceships in 1900, it would be easy to disprove that religion.
> This is the domain of science
Right on, empirical data and all that.
There's a school of thought called scientism that more or less says that all truth worthy of the name must be empirically provable. So a statement like "My dad and I enjoyed the baseball game" wouldn't be "true" because there weren't any double-blind studies or statistics gathered to support that assertion. At the other end of the spectrum is subjectivism, which abandons the field and says that you can't know anything at all with any certainty, so why bother.
I'm not sure that's entirely relevant, but I'm listening to a book on tape on my commute to work that talks about that and it seemed interesting
> language could really improve my perl,
> python, or ruby.
Right on. Here's a quote from Yukihiro Matsumoto, creator of Ruby:
There's an Artima article where he gives some of his reasons for this idea. That whole series of interviews with him is pretty good.
> Write a simple game on your own,
> something a one-man shop could do.
> Write another pac-man clone, or space
> invaders, or asteroids. Polish it with
> title screens showing points and credits,
> and make it look like something from
> an 80's arcade.
So true. This gave me an appreciation for how hard this stuff is. Just getting collision detection working in a Brickout clone was enough to send me back to my college math books, relearning basic trigonometry.
And reading books like "Game Programming Gems" gave me an appreciation for the same sort of thing. It's not just that there's an article on A*, it's that the first paragraph of the article summarizes A* and references three or four papers which have been written about various A* optimizations. Crikey.
> Licensing may be as simple as PARC requiring
> some information about your anticipated use
> of the protocols.
True, you're right, maybe giving them the benefit of the doubt would be better....
> how about that asteroid
Dude, there was this asteroid thing, and some dinosaurs, and, aw man, is that crazy or what?
> I'm reading an excerpt from the
> BBC's online h2g2,
Cool. I wish I could find that series on books on tape... 'twould make my commute much nicer. It'd be quite a number of tapes, though... the weight would probably cut my gas mileage in half...
> super-nerd Magic: the Gathering type game
All we need now are some Hitchhiker's Guide references and it'll be complete.
> going off-topic
Hopefully everyone else has already moved on to the killer asteroid article...
> I've kind of lost track of myself
Yup, I'm not sure where we're going with this one. On the other hand, this discussion is allowing me to procrastinate on applying a large and complicated patch to a project I'm working on, which is nice.
> I'm not sure I caught the Simpsons reference
Regrettably, I couldn't come up with one, but I left the reference in there just as an initial break-the-ice sort of thing. A sort of Slashdotters greeting, if you will.