Interesting. Do you have a web reference with a how to or example? I like the idea of using python to generate code; I have done it in the past to generate a multi-thousand line shell script (actually an xjobs script, but whatever) to generate animated movie frames.
This. I use python usually when I need the language features (libs etc), and C for my embedded stuff. I don't bother with C++; I find C to be more than adequate for my needs. Most of the "C++" I've seen written in the small embedded space is basically C with a bit of C++ syntactic sugar (Arduino, I'm looking at you). Why not just use C??
I like linux, I run linux exclusively at home, but I don't believe that this could be purely Windows' fault. If the computers truly are identical, swap hard drives and see if the 'good' computer now suddenly develops faults while running windows, or if it's a hardware problem.
1. I had to fix a script to unattended write a CD of data every day. The script was being run on a computer literally in the middle of a gold mine in Papua New Guinea. I wrote the script in the same location, which was a small (1mx2m) hut plonked right in the middle of the gold mine, with the acquisition system and 2x computers (one linux file server, one MS-DOS acquisition controller) running off a generator. This was for a system designed mid-late 90's and deployed in this instance in 2004.
2. We had borrowed a different acquisition system to acquire some data for a research project in an underground coal mine in NSW, Australia. We had some of the data in the supplied format we'd taken that day, I gave it to my boss and he then started to convert it into the format he could use for analysis. However, it was taking a minute to process each file using the supplied dos-based utility to convert the data, but each conversion needed a user to type the input file name, output file name, file type etc. Then wait for the conversion to run. Note that we had in the hundreds of files, so it would have taken hours to convert the data manually. I wrote a bash script to generate a keystroke-input file which I fed into a keyboard simulator running under dosbox to convert the files in one process. It worked first time, so instead of sitting there feeding the conversion program with input, my boss was able to go out to dinner instead...
3&4. Probably not so unusual, but the above was a strange combination: writing a bash script under linux to write a program to run under a keyboard-emulator in dosbox.
It's often more telling what is not on the reference than what is on there. Similarly, it's often more pertinent what is omitted in a reference than what is actually said.
You enjoy pumping out those getters/setters, writing that boilerplate main class rubbish, etc... then? These things simply are not needed, and can be avoided by giving the programmer the right language features.
I don't write java, but I have a standard set of bash scripts I use to generate boilerplate for a new set of c,h files from a template. Writing boilerplate in any language is just plain dumb, if it can be scripted (it often can IME).
By lengthening the round trip time from coding to compiling you're decreasing the rate of repetition (and success).
I would argue that by lengthening the round trip time you're encouraging them to think about what they're doing rather than just try random things and see if it works.
"IT'S AN ARM-KILLING TABLET WITH 1 MIPS PROCESSOR!!1!1!one!!"
Some more text to get over Slashdot lameness filter for all caps. That was kind of the point, and now the joke's been ruined.
Somewhat perversely, my linux experience goes something like red hat -> mandrake (big mistake!) -> slackware -> gentoo (another mistake) -> slackware -> ubuntu. Thinking about going back to slackware; loved the init scripts and the way I could hold (most of) the system in my head at once. Still use slackware whenever I have to build a 'small' system, mostly because it's easy to remove what I don't want.
Have you looked at Reach LCDs? Not sure if they are to your budget, but they have nicely housed touch-screen LCDs driven by an allegedly simple serial protocol.
http://reachtech.com/
No, it still doesn'e make sense. The outcome may be the same, but the terminology used is incorrect. From the summary:
"Today, mobile devices use low-power DDR (LPDDR) memory, the current iteration of which uses 1.2v of power. While the next generation of mobile memory, LPDDR3, will further reduce that power consumption (probably by 35% to 40%)"
Which would be much better stated as:
"Today, mobile devices use low-power DDR (LPDDR) memory, the current iteration of which runs at 1.2V. The next generation of mobile memory, LPDDR3, will reduce the operating voltage, and hence the power used by up to 35 to 40%."
Interesting. Do you have a web reference with a how to or example? I like the idea of using python to generate code; I have done it in the past to generate a multi-thousand line shell script (actually an xjobs script, but whatever) to generate animated movie frames.
This. I use python usually when I need the language features (libs etc), and C for my embedded stuff. I don't bother with C++; I find C to be more than adequate for my needs. Most of the "C++" I've seen written in the small embedded space is basically C with a bit of C++ syntactic sugar (Arduino, I'm looking at you). Why not just use C??
What's sold as 'alternative medicine' is a more worrying instance.
Do you know what they call 'alternative medicine' that's been proven to work?
Medicine.
FPGA programming. Altera and Xilinx both have tools that run on Linux but not OSX.
At least Linux has a decent terminal emulator. Also linux is better for embedded development.
I like linux, I run linux exclusively at home, but I don't believe that this could be purely Windows' fault. If the computers truly are identical, swap hard drives and see if the 'good' computer now suddenly develops faults while running windows, or if it's a hardware problem.
1. I had to fix a script to unattended write a CD of data every day. The script was being run on a computer literally in the middle of a gold mine in Papua New Guinea. I wrote the script in the same location, which was a small (1mx2m) hut plonked right in the middle of the gold mine, with the acquisition system and 2x computers (one linux file server, one MS-DOS acquisition controller) running off a generator. This was for a system designed mid-late 90's and deployed in this instance in 2004.
2. We had borrowed a different acquisition system to acquire some data for a research project in an underground coal mine in NSW, Australia. We had some of the data in the supplied format we'd taken that day, I gave it to my boss and he then started to convert it into the format he could use for analysis. However, it was taking a minute to process each file using the supplied dos-based utility to convert the data, but each conversion needed a user to type the input file name, output file name, file type etc. Then wait for the conversion to run. Note that we had in the hundreds of files, so it would have taken hours to convert the data manually. I wrote a bash script to generate a keystroke-input file which I fed into a keyboard simulator running under dosbox to convert the files in one process. It worked first time, so instead of sitting there feeding the conversion program with input, my boss was able to go out to dinner instead...
3&4. Probably not so unusual, but the above was a strange combination: writing a bash script under linux to write a program to run under a keyboard-emulator in dosbox.
If a car (or worse airplane) suddenly died because it was 5 years old, the manufacturer would be out of business in a week.
Well, technically out of business in a week plus five years, but I get your point.
Medicine.
Have you looked into a serial-to-ethernet converter, like the ones made by Moxa?
alternative medicine for medicine etc.
Reminds me of the Tim Minchin line: "You know what they call alternative medicine that's been proven to work? Medicine."
OTOH, exactly how many hands do you have??
In Soviet Russia, first post gets you.
It's often more telling what is not on the reference than what is on there. Similarly, it's often more pertinent what is omitted in a reference than what is actually said.
You enjoy pumping out those getters/setters, writing that boilerplate main class rubbish, etc... then? These things simply are not needed, and can be avoided by giving the programmer the right language features.
I don't write java, but I have a standard set of bash scripts I use to generate boilerplate for a new set of c,h files from a template. Writing boilerplate in any language is just plain dumb, if it can be scripted (it often can IME).
By lengthening the round trip time from coding to compiling you're decreasing the rate of repetition (and success).
I would argue that by lengthening the round trip time you're encouraging them to think about what they're doing rather than just try random things and see if it works.
Falling back to windows textual find tools is a bit painful.
That's where cygwin is useful. find, grep, sed, awk all there on your windows box - makes navigating projects or library codebases much easier.
Sure he does. Nearly as much as Bill Gates, I hear.
"IT'S AN ARM-KILLING TABLET WITH 1 MIPS PROCESSOR!!1!1!one!!" Some more text to get over Slashdot lameness filter for all caps. That was kind of the point, and now the joke's been ruined.
Somewhat perversely, my linux experience goes something like red hat -> mandrake (big mistake!) -> slackware -> gentoo (another mistake) -> slackware -> ubuntu. Thinking about going back to slackware; loved the init scripts and the way I could hold (most of) the system in my head at once. Still use slackware whenever I have to build a 'small' system, mostly because it's easy to remove what I don't want.
Have you looked at Reach LCDs? Not sure if they are to your budget, but they have nicely housed touch-screen LCDs driven by an allegedly simple serial protocol. http://reachtech.com/
No, it still doesn'e make sense. The outcome may be the same, but the terminology used is incorrect. From the summary:
"Today, mobile devices use low-power DDR (LPDDR) memory, the current iteration of which uses 1.2v of power. While the next generation of mobile memory, LPDDR3, will further reduce that power consumption (probably by 35% to 40%)"
Which would be much better stated as:
"Today, mobile devices use low-power DDR (LPDDR) memory, the current iteration of which runs at 1.2V. The next generation of mobile memory, LPDDR3, will reduce the operating voltage, and hence the power used by up to 35 to 40%."
That is all true, but the units for power are "watts", not "volts". You wouldn't say your car goes 33mpg fast, would you?
1.2V of power??!! This is supposed to be news for nerds. Nerds should know the difference between voltage and power.
Just ignore that post of mine; I clearly can't read. Those limits apply to Excel 2003. Excel 2010 does indeed have 16384 columns.