There is a solution: offer the d/l only as a.torrent at first, until popularity wanes. Then switch over to HTTP.
Re:Flash Player is not Mozilla.org's product
on
Rob Pike Responds
·
· Score: 1
Perhaps the best approach is a combined one.
I seem to remember seeing that at some point as well - (was that IE? Don't use Windows anymore...) browser launching an external app but still using the brower shell window (aka chrome).
If both solutions are provided, plug-in developers can use the separate process in development and for early beta releases, and switch to in-process when the tool is stable.
Thanks for this bit of inspiration; it's worthy of consideration!
The concept of IDL does not rely on object-orientation in any form. I could write an IDL and a small component architecture for a procedural language within a couple days using a Bison/Flex grammar were I so inclined. If I based it on XML instead, I could write it even faster.
The point is this: you specify the interface to your functions (or methods) in a public, well-known way. Whether the target language is OO is irrelevant, unless the IDL specifically forces an OO approach, in which case you should look for a different solution that supports procedural languages, or write one yourself.
Not in all cases. It's often easier for a program to contain a misbehaving component if the component runs in a separate process. For instance, if a web browser plug-in segfaults, do you want it to destroy the data you've entered into a form on another page?
In reality, both major browsers (IE, Moz) use component architectures, not separate processes, so I'm not sure your example is truely relevant.
Also, a formalized interface means two things that help stabalize components:
Scripts. Components with an IDL can easily be accessed through scripts, and smart applications put most of an applicaitons (non speed critical) functionality there. Scripts are 1000x easier to debug than native C code.
Formal interfaces also provide a clean entry-point for build-time regression testing. Of course this type of testing is possible without IDL, but IDL spells out the methods that need testing. Also, re point #1 above, tests can be written in script.
Testing your product thoroughly and having clean interfaces is a much better way to guarantee stability than simply containing segfaults.
Re:#8 One tool for one job?
on
Rob Pike Responds
·
· Score: 2, Insightful
OK I have to agree with you.
My first response was a bit over-emotional.
I simply meant this: his answer seemes very glib to me. It would simply be nice if he had elaborated a bit:/
#8 One tool for one job?
on
Rob Pike Responds
·
· Score: 4, Interesting
I modded this question up in the question round because I wanted a real answer, damnit.
I sincerely believe that "one tool for one job" isn't dead, the landscape has simply changed.
Yesteryear, the only way software tools worked together was via stdin/out over the command line.
Nowadays, we have brought the concept into application space through component architectures and IDLs (COM/XPCOM/JavaBeans to name 3). These new tools allow for that clean separation. Plug-ins or components are free to concentrate on doing one thing very well.
The change, IMO, is a good one. Formalized interfaces are good, and components are better optimized than launching a whole separate process.
Re:Why I dislike Halo (and all modern console game
on
Halo 2 Goes Gold
·
· Score: 2, Insightful
That's 2 comments comparing it to watching TV, which is just wrongheaded.
There's a major difference. When watching TV, one focuses on the picture as a whole and every frame is not important. If I blink for an extra sec or rub my eyes, I don't miss anything.
In a game, one has to pay close attention to small subsections of the screen, focusing on individual sprites which may not be bigger than a few pixels if the object is far away. Blinking at the wrong moment or for a slightly extended period can be fatal.
In other words a much higher concentration level is required to play games. The easier it is on my eyes, the better. I spend 12+ hours per day in front of a monitor - my eyes don't need additional stress.
Re:Why I dislike Halo (and all modern console game
on
Halo 2 Goes Gold
·
· Score: 1
I agree with you 100%.
I'd just like to add one more reason PC games are superior: graphics. 1024x768 @ 76Hz on a 20 inch monitor beats the pants off of a (non-high definition) TV any day. That makes me wonder - anyone know if the current consoles support HTDV?
I swear, if I stare at a console game for longer than 15 minutes, my eyes start watering from the low refresh rate...
Amen, brother! I'm getting in on the discussion a bit late, but WTF.
I've been thinking about this recently too. It requires an interesting mix of screen-scraping techniques and RAD GUI development. Mozilla's XUL engine is perfect for this.
Most/. readers have probably noticed that many sites offer an RSS (or other RDF format) feed. This is a good start, because it allows a desktop app to get at the structured data without knowing how to parse HTML.
There is a major problem with this, however. Take a look at slashdot's feed. Interesting, yes, but limited. About all it lets you do is create a simple launcher that would link to the details / comments page. You couldn't, for example, put user comments into a tree-like widget very easily. Since/. doesn't provide comments in RSS the app would be very limited.
I've been thinking about solutions for this problem for a long time now. Mozilla is by far the most interesting solution to date. My solution uses XSLT and RDF and only requires a couple hundred lines of script code. The basic flow looks like this:
start with a plain-old URL, e.g: http://slashdot.org/article.pl?sid=04/10/08/143520 1&tid=154&tid=113&tid=114
Transform the page into a custom RDF/XML format, using XSLT. This simplifies transformation and makes it easy to track HTML updates on the host site.
Create a 'rdf:xxx' in-memory datasource from the loaded RDF.
Attach templated components to it, which are notified and refreshed when the datasource is re-read.
This class is implemented in less than 300 lines of Javascript code.
The XUL template system hooks into this perfectly. For example, I was able to write a menu which contains the front-page slashdot stories in about 5 lines of XUL code and about 30 lines of XSLT.
In short, if you haven't already, check out Mozilla as an application development platform. You won't regret it!
I'm definitely interested in scoring some zero-G space nooky. My mom did say that I should wait and make sure my first time is special.
And, hopefully there will be room for two in that capsule, so that it can be even MORE special!
Apparently, the consolation prize for admitting you're a virgin on slashdot is a +5 funny karma bonus;)
Re:python's list processing rules
on
Dive Into Python
·
· Score: 0
Yeah, I never said it was the *best* list processor. LISP (the List Processor) is of course great at processing lists.
But do you know what it sucks at? Everything else:P Anyone who's been lost in stupid parenthesis knows what I mean.
Python is a very nice language because it combines great ideas from both functional and procedural languages.
python's list processing rules
on
Dive Into Python
·
· Score: 4, Informative
For those who haven't tinkered yet, or are just getting started with Python, I've found one of it's greatest strengths is it's ability to munge lists.
e.g, look at this super-terse, but still legible, sub-array code:
l = l[1:]
List comprehensions are another great feature:
l = [ do_something(x) for x in l ]
This is so amazingly compact when compared with list processing in Java or C++.
Anyhow, hats off to Guido Van Rossum for such a great language. I'll have to check this book out... I've been using the python cookbook (OReilly) and the documentation on the site almost exclusively...
First, the researchers divided the simulated cube into several billion smaller volumes. During the gravitational calculations, points within one of these volumes are lumped together--their masses are summed. ... a tree algorithm to simplify and speed up the calculations for this realm of short-distance interactions. Think of all 10 billion points as the leaves of a tree. Eight of these leaves attach to a stem, eight stems attach to a branch, and so on, until all the points are connected to the trunk. To evaluate the force on a given point, the program climbs up the tree from the root, adding the contributions from branches and stems found along the way until it encounters individual leaves
Wow. What did the threads look like in this app?! The article describes it as a 'simple program', but concurrency over these data structures is very impressive:)
instead of giving them your wallet you'd just pull out your money clip of fake US twenties
OK, so instead of stealing from you, the mugger ends up stealing from someone else when he spends your fake cash. In the end, someone ends up holding the bag and losing out.
If there is any karma in this world, you'll get it as change from that half-calf latte, you insensitive clod!
If it's a pair of cores on a single piece of silicon, it seems it would take the same silicon as two separate cpus, so where's the benefit?
That's just it - it doesn't. Most of the physical space on a chip is taken up by the local cache. If 2 cores can share the same cache, but keep their state separated, voila, price/performance sweet spot... aka $avings.
I bet we even see processors with more than 2 cores in the near future.
if this thing has any binary-only drivers, or if the *whole distribution* is GPLd. If there's binaries, and I can't use them in Debian, what's the point? I'd rather just check the Debian hardware compatability list and build or buy a model with full support.
Care to comment, Bruce Perens? Do you still work for HP?
Also, any code that contains a smiley gets like 50000 bonus points:) I myself like this bit of code which has a winky:
for(Iterator i = l.iterate(); i.hasNext();) {... }
You, my friend, have won the prize for most useful and beautiful shell snippet ever posted to/. Unfortunatly, the thread is now so old the mods are long gone:/
Wrapping the function into an interface is laughable and not desired, interfaces are always public.
And I'm an idiot?!:)
Here's a non-public interface (or the functional equivelant):
public class SomeOuterClass {
class NonPublicInterface {
public abstract void myMethod();
}
class NonPublicImplementation extends NonPublicInterface {
public void myMethod() {
System.out.println("My Method!");
}
} }
Because of inner-classes, you can define them right inline with your invoking class, if you so desire.
That you cannot use dynamic functions.
WTF do you mean 'dynamic functions'? If you implement the above interface 5 different ways, it's functionally equivelant to writing 5 functions and passing them. Plus, it's much more explicit and like I said before, gives you a place to write documentation.
OK I was wrong about upcast / downcast. I looked it up and the other posters are correct. That meaning is strange to me, because I envision the class hierarchy upside-down apparently:/
As far as templates are concerned - gimme a break everyone. They are simply syntactic sugar - a macro language that is preprocessed before compiling to binary. So even though you didn't have to deal with the cast, it still exists. Sorry if it was too much for your mind to handle before templates came along.
Re: the specific case of STL that has been mentioned here - the no-casting is a *side effect* of the template implentation of STL, not the goal. The goal is to allow differently sized structures as data on the list instead of e.g. requiring that only pointers are put there. The templating system plops the explicit type names into the generated code.
Templates may sheild you from writing casts, but that doesn't mean they aren't there!
Note: I tried to use miniver's version that uses 'while read x...', but it doesn't work. The variables inside the loop are in a sub-shell and are not exported back out to the script-executing shell.
This slightly reorganized version lets you create a list of directories that you want to behave as we've discussed.
First off, create your conf file in/etc/java.conf:
/usr/local/java/lib/ $HOME/classes
Then this code will do the trick:
#!/bin/bash
unset CLASSPATH for d in `cat/etc/java.conf`; do
for x in `find $d -name '*.jar'`; do
export CLASSPATH="$CLASSPATH:$x"
done done export CLASSPATH
You could wrap java's executable with this bit of script and it would behave as you want (at least on *nix platforms).
Slashdot Mirror
- Judging Amy
- Gillmore Girls
- Everybody Loves Raymond
With this new gadget, I could consign her to watching these terrible shows on her Mac, preferably with headphones on and a small tent around her desk.Damn, who am I kidding? I'll be the one in the tent watching 12 hours of LoTR
Sweet! All I need for my self-powered computer is a fan mount! Cools my processor and powers it at the same time ;)
Perhaps the best approach is a combined one.
I seem to remember seeing that at some point as well - (was that IE? Don't use Windows anymore...) browser launching an external app but still using the brower shell window (aka chrome).
If both solutions are provided, plug-in developers can use the separate process in development and for early beta releases, and switch to in-process when the tool is stable.
Thanks for this bit of inspiration; it's worthy of consideration!
The concept of IDL does not rely on object-orientation in any form. I could write an IDL and a small component architecture for a procedural language within a couple days using a Bison/Flex grammar were I so inclined. If I based it on XML instead, I could write it even faster.
The point is this: you specify the interface to your functions (or methods) in a public, well-known way. Whether the target language is OO is irrelevant, unless the IDL specifically forces an OO approach, in which case you should look for a different solution that supports procedural languages, or write one yourself.
Also, a formalized interface means two things that help stabalize components:
Testing your product thoroughly and having clean interfaces is a much better way to guarantee stability than simply containing segfaults.
OK I have to agree with you.
:/
My first response was a bit over-emotional.
I simply meant this: his answer seemes very glib to me. It would simply be nice if he had elaborated a bit
I modded this question up in the question round because I wanted a real answer, damnit.
I sincerely believe that "one tool for one job" isn't dead, the landscape has simply changed.
Yesteryear, the only way software tools worked together was via stdin/out over the command line.
Nowadays, we have brought the concept into application space through component architectures and IDLs (COM/XPCOM/JavaBeans to name 3). These new tools allow for that clean separation. Plug-ins or components are free to concentrate on doing one thing very well.
The change, IMO, is a good one. Formalized interfaces are good, and components are better optimized than launching a whole separate process.
That's 2 comments comparing it to watching TV, which is just wrongheaded.
There's a major difference. When watching TV, one focuses on the picture as a whole and every frame is not important. If I blink for an extra sec or rub my eyes, I don't miss anything.
In a game, one has to pay close attention to small subsections of the screen, focusing on individual sprites which may not be bigger than a few pixels if the object is far away. Blinking at the wrong moment or for a slightly extended period can be fatal.
In other words a much higher concentration level is required to play games. The easier it is on my eyes, the better. I spend 12+ hours per day in front of a monitor - my eyes don't need additional stress.
I agree with you 100%.
I'd just like to add one more reason PC games are superior: graphics. 1024x768 @ 76Hz on a 20 inch monitor beats the pants off of a (non-high definition) TV any day. That makes me wonder - anyone know if the current consoles support HTDV?
I swear, if I stare at a console game for longer than 15 minutes, my eyes start watering from the low refresh rate...
I've been thinking about this recently too. It requires an interesting mix of screen-scraping techniques and RAD GUI development. Mozilla's XUL engine is perfect for this.
Most
There is a major problem with this, however. Take a look at slashdot's feed. Interesting, yes, but limited. About all it lets you do is create a simple launcher that would link to the details / comments page. You couldn't, for example, put user comments into a tree-like widget very easily. Since
I've been thinking about solutions for this problem for a long time now. Mozilla is by far the most interesting solution to date. My solution uses XSLT and RDF and only requires a couple hundred lines of script code. The basic flow looks like this:
- start with a plain-old URL, e.g: http://slashdot.org/article.pl?sid=04/10/08/14352
0 1&tid=154&tid=113&tid=114 - Transform the page into a custom RDF/XML format, using XSLT. This simplifies transformation and makes it easy to track HTML updates on the host site.
- Create a 'rdf:xxx' in-memory datasource from the loaded RDF.
- Attach templated components to it, which are notified and refreshed when the datasource is re-read.
This class is implemented in less than 300 lines of Javascript code.The XUL template system hooks into this perfectly. For example, I was able to write a menu which contains the front-page slashdot stories in about 5 lines of XUL code and about 30 lines of XSLT.
In short, if you haven't already, check out Mozilla as an application development platform. You won't regret it!
Yeah, I never said it was the *best* list processor. LISP (the List Processor) is of course great at processing lists.
:P Anyone who's been lost in stupid parenthesis knows what I mean.
But do you know what it sucks at? Everything else
Python is a very nice language because it combines great ideas from both functional and procedural languages.
e.g, look at this super-terse, but still legible, sub-array code:List comprehensions are another great feature:This is so amazingly compact when compared with list processing in Java or C++.
Anyhow, hats off to Guido Van Rossum for such a great language. I'll have to check this book out... I've been using the python cookbook (OReilly) and the documentation on the site almost exclusively...
Wow. What did the threads look like in this app?! The article describes it as a 'simple program', but concurrency over these data structures is very impressive
Also, I wonder if they used GMP for their math?
If there is any karma in this world, you'll get it as change from that half-calf latte, you insensitive clod!
I bet we even see processors with more than 2 cores in the near future.
if this thing has any binary-only drivers, or if the *whole distribution* is GPLd. If there's binaries, and I can't use them in Debian, what's the point? I'd rather just check the Debian hardware compatability list and build or buy a model with full support.
Care to comment, Bruce Perens? Do you still work for HP?
Lister: Can't you check the black-box recording?
Holly: Yeah, hang on [dissapears from screen]
Holly: [reappears] Oi! It's been half-inched!
It's so terse, almost to the point of being glib!
Also, any code that contains a smiley gets like 50000 bonus points
YES!!
.bat wiz would come along and show the light! Cheers!
I was hoping a
Here's a non-public interface (or the functional equivelant):Because of inner-classes, you can define them right inline with your invoking class, if you so desire.
WTF do you mean 'dynamic functions'? If you implement the above interface 5 different ways, it's functionally equivelant to writing 5 functions and passing them. Plus, it's much more explicit and like I said before, gives you a place to write documentation.
OK I was wrong about upcast / downcast. I looked it up and the other posters are correct. That meaning is strange to me, because I envision the class hierarchy upside-down apparently :/
As far as templates are concerned - gimme a break everyone. They are simply syntactic sugar - a macro language that is preprocessed before compiling to binary. So even though you didn't have to deal with the cast, it still exists. Sorry if it was too much for your mind to handle before templates came along.
Re: the specific case of STL that has been mentioned here - the no-casting is a *side effect* of the template implentation of STL, not the goal. The goal is to allow differently sized structures as data on the list instead of e.g. requiring that only pointers are put there. The templating system plops the explicit type names into the generated code.
Templates may sheild you from writing casts, but that doesn't mean they aren't there!
This slightly reorganized version lets you create a list of directories that you want to behave as we've discussed.
First off, create your conf file in
Sweet! Didn't know while could take stdin.
:)
You learn something new every day, huh?
Thanks,
--g