At the very least, using brackets to group instead of whitespace allows you to move through code much more easily. I use % dozens of times a day in vi (it bounces between paired brackets). It's so much easier than scrolling up and down through pages of code. Also, making blocks of code more than about 24 lines in Python is a readability nightmare, because the whitespace that defines the block can't be seen in its context without scrolling... and you don't have a nice editor shortcut to help you out.
They mean that the film has been adjusted to fit the aspect ratio of the transmission medium. TV has traditionally had a 4:3 aspect ratio, and movies generally have a much wider aspect ratio.
I don't know if it's a DC power converter. By Lenz's Law, the only way that you can get a magnetic field from electric current is to have a current input varying in the time domain (AC). You would then need an AC->DC converter on board the device you want to charge. It may very well be that the wallwart that you see is actually an AC-AC transformer. My BCD clock has one --- I think it uses the frequency of the AC signal as its time source.
We could give that text file a name... how about HOSTS? And it could be updated every once in a while when different computers are added to the network! And we can pretend we're still in the days of ARPANET! Yay!
Linear algebra is extremely useful in many engineering contexts. Circuit & structural analysis come to mind off the top of my head. While much of this just boils down to Gauss-Jordan elimination, you can sometimes save a lot of time or prove some things by using some of the more complex linear algebra topics.
Adding keys to your tables will really speed up read queries. Also, look at your most frequently used SQL queries, and time them with different data sets. Adjust the queries by adding keys to tables, especially in WHERE clauses. Also, you may want to look into completely revamping queries.
Multi-part queries involving lots of roundtrips between the script and the database are a no-no. Consider replacing these queries with SQL joins. Joins are relatively fast if done properly. Next, you may want to try to use subqueries (in recent MySQL versions) or temporary tables. GROUP BY can be your friend if used properly.
Finally, stored procedures can be used as a last-case option for dealing with horrendous queries that seem to absolutely require repetitive database round-trips. Stored procedures are most mature in databases like PostgreSQL and Oracle. Stored procedures may not help the fact that you still have to sift through a lot of data manually, but they can help you by not requiring you to pass that data back and forth several times.
Also, you may want to adjust your table structure. If you have tables with linked records, add an integer or bigint id column to each parent table, and use that to link your child entries. A primary key, auto-incremented, integer WHERE lookup is much faster than even a properly indexed single or multiple column WHERE in a SELECT.
PostgreSQL may be a better choice in your situation; it may be a good idea to benchmark it against MySQL. However, if your queries are not properly optimized, the cheapest way to improve performance would be to work at them. It might be wise to pick out a book on SQL to learn how to optimize your queries for more efficiency.
> In the past, these drivers has access to critical > sections of the kernel and so if for example, they > had a buffer overrun, it was possible that it > could write a critical section of the kernel > space, thus bringing down the machine. With > Vista, this is going to change.
Wait? Didn't they say that about Windows 95? And Windows NT 4? And Windows 2000? And Windows XP? I've had blue screens on all of those (except NT4, which I've never run).
You could try Xitel's Pro Hi-Fi Link. It's a bit pricey, but it connects via the standard USB Audio protocol to your computer. It also includes all the audio cables you need. I believe it supports passing through stuff like AC3.
At the very least, using brackets to group instead of whitespace allows you to move through code much more easily. I use % dozens of times a day in vi (it bounces between paired brackets). It's so much easier than scrolling up and down through pages of code. Also, making blocks of code more than about 24 lines in Python is a readability nightmare, because the whitespace that defines the block can't be seen in its context without scrolling... and you don't have a nice editor shortcut to help you out.
They mean that the film has been adjusted to fit the aspect ratio of the transmission medium. TV has traditionally had a 4:3 aspect ratio, and movies generally have a much wider aspect ratio.
SALSA has already been done ... it's essentially a distributed system framework for Java.
I don't know if it's a DC power converter. By Lenz's Law, the only way that you can get a magnetic field from electric current is to have a current input varying in the time domain (AC). You would then need an AC->DC converter on board the device you want to charge. It may very well be that the wallwart that you see is actually an AC-AC transformer. My BCD clock has one --- I think it uses the frequency of the AC signal as its time source.
We could give that text file a name... how about HOSTS? And it could be updated every once in a while when different computers are added to the network! And we can pretend we're still in the days of ARPANET! Yay!
Linear algebra is extremely useful in many engineering contexts. Circuit & structural analysis come to mind off the top of my head. While much of this just boils down to Gauss-Jordan elimination, you can sometimes save a lot of time or prove some things by using some of the more complex linear algebra topics.
Adding keys to your tables will really speed up read queries. Also, look at your most frequently used SQL queries, and time them with different data sets. Adjust the queries by adding keys to tables, especially in WHERE clauses. Also, you may want to look into completely revamping queries.
Multi-part queries involving lots of roundtrips between the script and the database are a no-no. Consider replacing these queries with SQL joins. Joins are relatively fast if done properly. Next, you may want to try to use subqueries (in recent MySQL versions) or temporary tables. GROUP BY can be your friend if used properly.
Finally, stored procedures can be used as a last-case option for dealing with horrendous queries that seem to absolutely require repetitive database round-trips. Stored procedures are most mature in databases like PostgreSQL and Oracle. Stored procedures may not help the fact that you still have to sift through a lot of data manually, but they can help you by not requiring you to pass that data back and forth several times.
Also, you may want to adjust your table structure. If you have tables with linked records, add an integer or bigint id column to each parent table, and use that to link your child entries. A primary key, auto-incremented, integer WHERE lookup is much faster than even a properly indexed single or multiple column WHERE in a SELECT.
PostgreSQL may be a better choice in your situation; it may be a good idea to benchmark it against MySQL. However, if your queries are not properly optimized, the cheapest way to improve performance would be to work at them. It might be wise to pick out a book on SQL to learn how to optimize your queries for more efficiency.
> In the past, these drivers has access to critical
> sections of the kernel and so if for example, they
> had a buffer overrun, it was possible that it
> could write a critical section of the kernel
> space, thus bringing down the machine. With
> Vista, this is going to change.
Wait? Didn't they say that about Windows 95? And Windows NT 4? And Windows 2000? And Windows XP? I've had blue screens on all of those (except NT4, which I've never run).
You could try Xitel's Pro Hi-Fi Link. It's a bit pricey, but it connects via the standard USB Audio protocol to your computer. It also includes all the audio cables you need. I believe it supports passing through stuff like AC3.