"Additionally, the sense circuitry 704 can be connected to a power source 706, such as a battery, built in the stylus. In another embodiment, power can be supplied from a power source in another electronic device, such as a touch sensing device, via a cable connecting the stylus to the device, or via inductive coupling.".
In British usage is the word usually attached to services from a utility or public service related company or would the charges listed on a restaurant menu technically be "tariffs?"
The first meaning only, so utilities and public services such as water, gas, electricity and phone have tariffs. The figures shown on a restaurant menu are merely prices, taxes and surcharges.
I'm British. I understand "tariff" to mean a system of charges. I think that the most commonly encountered use here of the word "tariff" will be in relation to mobile phones. I had never thought of "tariff" as being a government related word until now. But perhaps, the language of government has persisted from when the government owned everything. From what I understand of the word, the modern British usage is correct although unfamilar to an American. The American usage seems rather alien to me. Isn't that fair?
Even on slightly fancier processors you can have limited JTAG debugging support. Severe limitations on the number of instruction breakpoints and data breakpoints can limit the usefulness of the debugger for everyday work. Even in not-particularly-time-critical software single-stepping through the code can be impossible - either the bug is time dependant (e.g. errors in hardware drivers or race conditions) or normal execution relies on timing (e.g. communications). The debugger is useful only for a very narrowly defined set of bugs.
When the debug-with-printf approach is used the program speed can be badly affected. Changes in program speed can affect the occurance of the bug being investigated. Output may be going to a serial UART running at no more than 115200 baud. Even the GPIO toggling method can have this problem; the processor we use has the GPIO in a separate clock domain that runs several times slower than the instruction clock. One workaround for this is to write to RAM (if available) or to additional hardware connected to the external memory bus. At worst you're reduced to paper debugging.
The Logic Sniffer is a cheap 16 channel Logic Analyser, which while no where near as good as a commercial unit comes in at 1/100th of the cost as well.
I've used an inexpensive commerical PC-based logic analyser. It had a combination of terrible software and frustrating hardware limitations (e.g. only being able to set the timebase in powers of two and a very limited number of samples).
This particular logic analyser can only make a limited number of samples. A limitation like this can make some debugging problems harder. E.g. I2C/SPI serial data where it may be impossible to trigger at the required moment. A cheap logic analyser may make sense for a private individual but in a commerical setting they are a false economy.
The limitations of compiled executables are becoming more apparent with today's diverse hardware. One generation of mobile device may not use the same instruction architecture (processor type) as the next generation of mobile device. And the other devices connected to the processor change frequently. A new executable would have to be compiled for every major variant of the device. With something like Java bytecode the program can be one-time optimised when the program is loaded onto the device, which is a good comprise between efficiency and portability.
I program in C. In C there is normally a good correspondence between C code and machine code. But there are many ways that C is less efficient compared to more modern languages, especially when writing well structured code.
Virtually every device has substantial amounts of code written in C or C++. Javascript would be useless on the microcontroller I write C code for. If C and C++ were to vanish overnight we'd be back in the stone age. I won't comment on whether C and C++ belong in the stone age, but it's great that many programmers don't have to think at the lower levels of machine abstraction.
An even better solution would be a physical recorder on the aircraft and transmission of that data from the aircraft. In this way the information will be protected from either loss of the physical recorder, problems that affect the transmission equipment (e.g. aircraft damage in the region of the antenna) or problems with the ground stations. Also, the volume of data that could be logged on a physical recorder could exceed what could be reasonably transmitted continuously (because it might not possible to transmit anything after the fact).
I believe that it says more about politics than innovation that few engineers and scientists choose to enter politics. Perhaps engineers and scientists feel that they can't succeed with a well researched fact-based viewpoint against the slippery populist rhetoric of typical politicians. It's either that, or politicians have provided the ideal environment for engineers and scientists such that they feel there is no need to effect change through politics.
The "kill-switch" is intended for businesses and governments - the cost of a computer is negligible compared to the potential cost of a data breach. Encryption should be standard for these organisations. If the encryption is done properly then it should be tied to both the hardware and the user, so that data can only be accessed on authorised computer systems. Hence the "kill-switch" which will prevent data from being decrypted (by denying access to the hardware) even if the user's passwords are known. This is far more security than the average person wants or needs.
Discrete tracking may allow equipment to be recovered. But just like anti-theft ID chips in Caravans etc. it isn't necessarily the thief that is out of pocket when the equipment is recovered.
Perl 6 has guillemets in its standard syntax (equivalent to "<<" and ">>"). These are non-ASCII symbols. It will also be possible to declare new operators using whatever character you want (e.g. a snowman operator, see: http://perl6advent.wordpress.com/2009/12/17/day-17-making-snowmen/).
One reason is the lack of sounds in Japanese resulting in huge numbers of homophones. Both Katakana and Hiragana encode each of the homophones in a fixed way unlike in English (e.g. in English "One" vs "Won"). The use of Kanji reduces the amount of ambiguity in the written language. The Chinese characters were used first anyway.
Driving in the direction you are looking is a terrible idea.
Here in the UK you don't pass a driving test without using your rear view mirror, your side mirrors; and looking when appropriate through the side or rear windows. Just because you are looking for potential dangers doesn't mean you want to steer into them (e.g. a car overtaking you). Applying makeup etc. or tuning the radio would be unusually lethal.
256MB isn't nearly as pitiful as you make it out to be
I program for an embedded system with 64K of on-chip RAM and 256K of external RAM. There is less than 256MB of RAM shipped per 3 months of sales. There is also FLASH memory in our system but only a few megabytes.
The great thing about more RAM is that programming gets much easier. But many, many things are still possible with tiny amounts of it. At the lowest end of microcontrollers is the likes of the PIC10F200, which has just 375 bytes of program memory and 16 bytes of data memory. Real multi-tasking isn't possible at that level but a few orders of magnitude above it is often not just desirable to have real multi-tasking but necessary.
Apple must trade off the hardware cost vs. the development cost. For them each cent trimmed off the hardware cost is enough to hire a few more software developers to work-around the limitations imposed.
Otherwise 80 columns is more than enough space for anyone.
I wrap as much of my code to 80 columns as possible but I may be doing the wrong thing.
The main problem is that 80 columns can be a fight between meaningful variable/function names and actually getting anything done on a line of code. Just changing a variable name can mean spending time getting everything back under the 80 column self-imposed limit. And that's a problem if you've done A=B+C and can't do much more to shorten the line without using +=. Rigid use of a small column limit may lead to less readable code.
The diff tool is another battle ground: shorter lines help when differencing files (e.g. 3 files side by side) but at the same time a shorter column limit often means more changed lines.
I think that the goal in programming is to write obviously correct code. Whatever achieves this is the right approach. Which is why programmers often can't agree on anything because there isn't one correct approach (except their own!).
Yes, Perl is still relevant to a number of software developers and systems administrators.
It is an ideal language for software developers who want to use metaprogramming techniques (code generation; domain specific languages), text processing or data conversion, or automation of software development process. Perl 6 will have a full grammar engine (for parsing - like having YACC/BISON built in) which will make text processing even easier than before. The use of a scripting language for these tasks leaves the source code more accessible than compiled languages, which is an advantage to software developers who can adapt the code more readily than a compiled project.
Whether Perl 6 will be used much for primary software development I don't know. My day job is C programming for embedded systems where Perl is not suitable. Desktop programming is more likely to be in C++ or C# where the standard libraries are huge and the software development ecosystem is more developed.
The primary audience for new Perl, in my opinion, is expert software developers who need a powerful/succinct language to implement solutions to problems in the manner they think. Perl 6 therefore supports just about every programming paradigm known to mankind. What makes Perl great for software gurus is what makes it an awful language for programming newbies.
I will be learning Perl 6, not because I will use it much, but because I will discover new ways to think about problems. Oh, and it'll be fun.
So all the binary data etc. that is required to build an application should
be managed seperately? Our GUI code is generated by a third party tool which
stores its information (e.g. fonts) as part of a binary database. This belongs
with the source code because the code needs to be modified in step with it. Having
the log message is very helpful as it would take hours to work out the changes
made between two of these files, because diff isn't useful. The files
are 15MB in size.
SVN may not be the best choice for binary data but at least it is
possible to put binary data into it. I would rather endure SVN's slowness
than have to manually manage binary files. I believe that revision control could be better supported by operating systems. Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved (if the working file referenced the base file until the working file needs to be changed). The SVN tools would then be able to work much faster because the need for file comparison would be less common.
Unless the revision control system's performance is dreadful I think that all files should be in revision control.
In fact there is a way to kill Guybrush Threapwood. A few times during the game he says he can hold his breath underwater for ten minutes. And if you keep him underwater for that long he will die. I doubt many people accidentally killed Guybrush this way.
I would drop unimportant items from my inventory on the floor as I go from room to room. I would not assume that the maze layout made any sense whatsoever. And I would pay careful attention to any variances in the textual descriptions.
As for the punch-cards the sieve of Erastothenes method sounds like a great way to solve the problem. Do I get a hole-punch? A computer? Or the bits to make my own computer? Since those are the items YOU have could I not just write a short program on my RPN calculator instead?
Given that I'm only two and a half decades old either: (a) these screening questions aren't hard enough; or (b) I know more than the average for my age.
If I was interviewing I would want to know that the person understands version control. I would expect them to demonstrate that they could understand the user's needs (e.g. interface design). And I would want to know that they weren't hostile to development processes (e.g. code reviews).
Slashdot Mirror
The pen for Wacom tablets is powered from the tablet itself. This is how pressure detection and buttons can work on the pen.
http://en.wikipedia.org/wiki/Wacom#Technology
The Apple patent states:
"Additionally, the sense circuitry 704 can be connected to a power source 706, such as a battery, built in the stylus. In another embodiment, power can be supplied from a power source in another electronic device, such as a touch sensing device, via a cable connecting the stylus to the device, or via inductive coupling.".
In British usage is the word usually attached to services from a utility or public service related company or would the charges listed on a restaurant menu technically be "tariffs?"
The first meaning only, so utilities and public services such as water, gas, electricity and phone have tariffs. The figures shown on a restaurant menu are merely prices, taxes and surcharges.
I'm British. I understand "tariff" to mean a system of charges. I think that the most commonly encountered use here of the word "tariff" will be in relation to mobile phones. I had never thought of "tariff" as being a government related word until now. But perhaps, the language of government has persisted from when the government owned everything. From what I understand of the word, the modern British usage is correct although unfamilar to an American. The American usage seems rather alien to me. Isn't that fair?
Even on slightly fancier processors you can have limited JTAG debugging support. Severe limitations on the number of instruction breakpoints and data breakpoints can limit the usefulness of the debugger for everyday work. Even in not-particularly-time-critical software single-stepping through the code can be impossible - either the bug is time dependant (e.g. errors in hardware drivers or race conditions) or normal execution relies on timing (e.g. communications). The debugger is useful only for a very narrowly defined set of bugs.
When the debug-with-printf approach is used the program speed can be badly affected. Changes in program speed can affect the occurance of the bug being investigated. Output may be going to a serial UART running at no more than 115200 baud. Even the GPIO toggling method can have this problem; the processor we use has the GPIO in a separate clock domain that runs several times slower than the instruction clock. One workaround for this is to write to RAM (if available) or to additional hardware connected to the external memory bus. At worst you're reduced to paper debugging.
The Logic Sniffer is a cheap 16 channel Logic Analyser, which while no where near as good as a commercial unit comes in at 1/100th of the cost as well.
I've used an inexpensive commerical PC-based logic analyser. It had a combination of terrible software and frustrating hardware limitations (e.g. only being able to set the timebase in powers of two and a very limited number of samples).
This particular logic analyser can only make a limited number of samples. A limitation like this can make some debugging problems harder. E.g. I2C/SPI serial data where it may be impossible to trigger at the required moment. A cheap logic analyser may make sense for a private individual but in a commerical setting they are a false economy.
The limitations of compiled executables are becoming more apparent with today's diverse hardware. One generation of mobile device may not use the same instruction architecture (processor type) as the next generation of mobile device. And the other devices connected to the processor change frequently. A new executable would have to be compiled for every major variant of the device. With something like Java bytecode the program can be one-time optimised when the program is loaded onto the device, which is a good comprise between efficiency and portability.
I program in C. In C there is normally a good correspondence between C code and machine code. But there are many ways that C is less efficient compared to more modern languages, especially when writing well structured code.
Virtually every device has substantial amounts of code written in C or C++. Javascript would be useless on the microcontroller I write C code for. If C and C++ were to vanish overnight we'd be back in the stone age. I won't comment on whether C and C++ belong in the stone age, but it's great that many programmers don't have to think at the lower levels of machine abstraction.
An even better solution would be a physical recorder on the aircraft and transmission of that data from the aircraft. In this way the information will be protected from either loss of the physical recorder, problems that affect the transmission equipment (e.g. aircraft damage in the region of the antenna) or problems with the ground stations. Also, the volume of data that could be logged on a physical recorder could exceed what could be reasonably transmitted continuously (because it might not possible to transmit anything after the fact).
I believe that it says more about politics than innovation that few engineers and scientists choose to enter politics. Perhaps engineers and scientists feel that they can't succeed with a well researched fact-based viewpoint against the slippery populist rhetoric of typical politicians. It's either that, or politicians have provided the ideal environment for engineers and scientists such that they feel there is no need to effect change through politics.
Recursive use of the trademark symbol could make things a little interesting.
The "kill-switch" is intended for businesses and governments - the cost of a computer is negligible compared to the potential cost of a data breach. Encryption should be standard for these organisations. If the encryption is done properly then it should be tied to both the hardware and the user, so that data can only be accessed on authorised computer systems. Hence the "kill-switch" which will prevent data from being decrypted (by denying access to the hardware) even if the user's passwords are known. This is far more security than the average person wants or needs.
Discrete tracking may allow equipment to be recovered. But just like anti-theft ID chips in Caravans etc. it isn't necessarily the thief that is out of pocket when the equipment is recovered.
Perl 6 has guillemets in its standard syntax (equivalent to "<<" and ">>"). These are non-ASCII symbols. It will also be possible to declare new operators using whatever character you want (e.g. a snowman operator, see: http://perl6advent.wordpress.com/2009/12/17/day-17-making-snowmen/).
One reason is the lack of sounds in Japanese resulting in huge numbers of homophones. Both Katakana and Hiragana encode each of the homophones in a fixed way unlike in English (e.g. in English "One" vs "Won"). The use of Kanji reduces the amount of ambiguity in the written language. The Chinese characters were used first anyway.
Disclaimer: I don't speak Japanese, yet.
The current generation has put aside plenty for the archaeologists. But they will need to reinvent the digger in order to shift through it all.
Jonathan Paton
Driving in the direction you are looking is a terrible idea.
Here in the UK you don't pass a driving test without using your rear view mirror, your side mirrors; and looking when appropriate through the side or rear windows. Just because you are looking for potential dangers doesn't mean you want to steer into them (e.g. a car overtaking you). Applying makeup etc. or tuning the radio would be unusually lethal.
Jonathan Paton
256MB isn't nearly as pitiful as you make it out to be
I program for an embedded system with 64K of on-chip RAM and 256K of external RAM. There is less than 256MB of RAM shipped per 3 months of sales. There is also FLASH memory in our system but only a few megabytes.
The great thing about more RAM is that programming gets much easier. But many, many things are still possible with tiny amounts of it. At the lowest end of microcontrollers is the likes of the PIC10F200, which has just 375 bytes of program memory and 16 bytes of data memory. Real multi-tasking isn't possible at that level but a few orders of magnitude above it is often not just desirable to have real multi-tasking but necessary.
Apple must trade off the hardware cost vs. the development cost. For them each cent trimmed off the hardware cost is enough to hire a few more software developers to work-around the limitations imposed.
Jonathan Paton
Otherwise 80 columns is more than enough space for anyone.
I wrap as much of my code to 80 columns as possible but I may be doing the wrong thing.
The main problem is that 80 columns can be a fight between meaningful variable/function names and actually getting anything done on a line of code. Just changing a variable name can mean spending time getting everything back under the 80 column self-imposed limit. And that's a problem if you've done A=B+C and can't do much more to shorten the line without using +=. Rigid use of a small column limit may lead to less readable code.
The diff tool is another battle ground: shorter lines help when differencing files (e.g. 3 files side by side) but at the same time a shorter column limit often means more changed lines.
I think that the goal in programming is to write obviously correct code. Whatever achieves this is the right approach. Which is why programmers often can't agree on anything because there isn't one correct approach (except their own!).
Yes, Perl is still relevant to a number of software developers and systems administrators.
It is an ideal language for software developers who want to use metaprogramming techniques (code generation; domain specific languages), text processing or data conversion, or automation of software development process. Perl 6 will have a full grammar engine (for parsing - like having YACC/BISON built in) which will make text processing even easier than before. The use of a scripting language for these tasks leaves the source code more accessible than compiled languages, which is an advantage to software developers who can adapt the code more readily than a compiled project.
Whether Perl 6 will be used much for primary software development I don't know. My day job is C programming for embedded systems where Perl is not suitable. Desktop programming is more likely to be in C++ or C# where the standard libraries are huge and the software development ecosystem is more developed.
The primary audience for new Perl, in my opinion, is expert software developers who need a powerful/succinct language to implement solutions to problems in the manner they think. Perl 6 therefore supports just about every programming paradigm known to mankind. What makes Perl great for software gurus is what makes it an awful language for programming newbies.
I will be learning Perl 6, not because I will use it much, but because I will discover new ways to think about problems. Oh, and it'll be fun.
Jonathan Paton
You shouldn't put in the things you can't diff.
So all the binary data etc. that is required to build an application should be managed seperately? Our GUI code is generated by a third party tool which stores its information (e.g. fonts) as part of a binary database. This belongs with the source code because the code needs to be modified in step with it. Having the log message is very helpful as it would take hours to work out the changes made between two of these files, because diff isn't useful. The files are 15MB in size.
SVN may not be the best choice for binary data but at least it is possible to put binary data into it. I would rather endure SVN's slowness than have to manually manage binary files. I believe that revision control could be better supported by operating systems. Two copies of every file are managed by a SVN checkout - the base file and the working file. If the filesystem could store these together then the cost would be halved (if the working file referenced the base file until the working file needs to be changed). The SVN tools would then be able to work much faster because the need for file comparison would be less common.
Unless the revision control system's performance is dreadful I think that all files should be in revision control.
In fact there is a way to kill Guybrush Threapwood. A few times during the game he says he can hold his breath underwater for ten minutes. And if you keep him underwater for that long he will die. I doubt many people accidentally killed Guybrush this way.
I would drop unimportant items from my inventory on the floor as I go from room to room. I would not assume that the maze layout made any sense whatsoever. And I would pay careful attention to any variances in the textual descriptions.
As for the punch-cards the sieve of Erastothenes method sounds like a great way to solve the problem. Do I get a hole-punch? A computer? Or the bits to make my own computer? Since those are the items YOU have could I not just write a short program on my RPN calculator instead?
Given that I'm only two and a half decades old either: (a) these screening questions aren't hard enough; or (b) I know more than the average for my age.
If I was interviewing I would want to know that the person understands version control. I would expect them to demonstrate that they could understand the user's needs (e.g. interface design). And I would want to know that they weren't hostile to development processes (e.g. code reviews).
One problem - it's non tactile. But with some further programming the system could be operated like a joystick.
The recently released Subversion 1.5.0 includes many improvements. Merge tracking is one of the improvements.
<<
:)
""
"dneirf olleH"
while
dup size
repeat
dup head swap tail rot rot swap + swap
end
drop
msgbox
>>
Perhaps I should stick to Perl
The article makes absolutely no mention of glitter, only sand. Did you expect the summary to be accurate, even today?