Re: [volt-nuts] do you like Labview in your labs?
Openoffice.org is free, and will open all of the older versions
of word files.
-Chuck Harris
Charles P. Steinmetz wrote:
John wrote:
10 year old Office stuff still works fine and has far more features
than I'll ever need.
True enough, I much prefer older versions of the Office apps. That was
true even before the hateful "ribbon" interface. BUT. The current
versions of the Office apps won't open old files anymore, so if you send
what you create to someone with the current version, you're SOL. I have
thousands of old Word files that I can't open, except in a text editor.
I have an old version of Word, but MS doesn't seem to allow one to have
both versions installed.
(If someone knows of a good solution to this, I'm all ears. And no, the
Open Office word mangler won't open them, either.)
Best regards,
Charles
volt-nuts mailing list -- volt-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.
Chuck wrote:
Openoffice.org is free, and will open all of the older versions of word files.
Not so. At least, my copy won't (see the last paragraph of my
previous message, below). Or rather, it will open at least some of
them, but in unformatted text mode, not with their Word formatting --
much like opening them in a text editor. Useless for old article
manuscripts, for example, which have lots of formatting, paragraph
and text styles, formulas with symbols, headers and footers, multiple
sections, etc., etc.
Best regards,
Charles
True enough, I much prefer older versions of the Office apps. That was
true even before the hateful "ribbon" interface. BUT. The current
versions of the Office apps won't open old files anymore, so if you send
what you create to someone with the current version, you're SOL. I have
thousands of old Word files that I can't open, except in a text editor.
I have an old version of Word, but MS doesn't seem to allow one to have
both versions installed.
(If someone knows of a good solution to this, I'm all ears. And no, the
Open Office word mangler won't open them, either.)
Best regards,
Charles
That's the locally famous former Wanamaker organ and store, now
Macys. It works because folks are there to lollygag and shop, open
to suggestion, and its a known location for live classical organ
music for over a century.
If you are open to something, your sense of value will strike as soon
as something of value fell on your lap, software included.
I have strongest doubts on spontaneity just as the Bell subway
example was already biased for being suboptimal; 650 choir members
meeting in a lobby on Saturday can't be there to just shop; Macys
exists in so many more accessible suburbs; Philadelphia is notorious
for parking issues. The video quality is too good compared to
"spontaneous" ones via cellphone video, to suggest that was planned
from the start; aka, marketing. 5,000,000 views is ~ a number
watching wrestling on TV and running a paid spot for Macys.
http://www.usatoday.com/life/television/news/nielsens-charts.htm
I think something that is less intellectual will stop a crowd: If
Starbucks set up a booth with free food, coffee, during morning rush
hour, will almost certainly create a stir than Mr. Bell.
Likewise in software, for users, neither open source or closed source
matters, what matters is it works and its easier to maintain over
time, if needed.
At 11:28 PM 12/6/2010, J. Forster wrote:
Charles,
You make a good point. People are busy with their own stuff. I would have
walked right by the guy too. I always got annoyed with panhandlers. Even
remarkable things like in this YouTube link get old very quickly, IMO.
http://www.youtube.com/watch?v=wp_RHnQ-jgU
FWIW,
-John
If Word or Open office won't work then try Window's built in Wordpad,
or opensource AbiWord, they all have a realm of converters.
At 02:08 AM 12/7/2010, Charles P. Steinmetz wrote:
Chuck wrote:
Openoffice.org is free, and will open all of the older versions of
word files.
Not so. At least, my copy won't (see the last paragraph of my
previous message, below). Or rather, it will open at least some of
them, but in unformatted text mode, not with their Word formatting
-- much like opening them in a text editor. Useless for old article
manuscripts, for example, which have lots of formatting, paragraph
and text styles, formulas with symbols, headers and footers,
multiple sections, etc., etc.
Best regards,
Charles
True enough, I much prefer older versions of the Office apps. That was
true even before the hateful "ribbon" interface. BUT. The current
versions of the Office apps won't open old files anymore, so if you send
what you create to someone with the current version, you're SOL. I have
thousands of old Word files that I can't open, except in a text editor.
I have an old version of Word, but MS doesn't seem to allow one to have
both versions installed.
(If someone knows of a good solution to this, I'm all ears. And no, the
Open Office word mangler won't open them, either.)
Best regards,
Charles
volt-nuts mailing list -- volt-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.
Sincerely,
Marv Gozum
Philadelphia, PA
Hi Chuck,
Thanks for the clarification. Since the 3478A is a popular DVM in
the secondary market, this is good to know and for the archives of
volt-nuts to log your Prologix experience; I see the initial
struggles over at time-nuts archive.
Thanks for the Python code! I like its look, but the simplicity of
device interfacing begs the question, why Python over competitors,
not just Labview, why not C or Pascal or Basic etc., for writing
support code for instruments?
Doesn't seem like the fastest out there and these benchmarks do not
measure code size either.
http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php
I don't know the answer. Right now, I just use what I have.
But it seems overall being aware or knowing the commands of GPIB and
Prologix and establishing a connection to these devices through a
minimalist way: serial port/USB/dll layer is a stable floor, it made
your Python code very readable; if I simply let any app interface
automatically, should things malfunction, I'd have to trace the fault
from some established working floor.
I don't think I'd be able to do this if I obtained an interface
library in any language or Labview and relied on its abstraction to
keep my instruments together without knowing how its done.
If I write it myself, it seems it doesn't matter what the language
is, unless it offered some value in maintenance, speed or code size.
At 08:42 PM 12/6/2010, Chuck Harris wrote:
Marvin E. Gozum wrote:
Chuck, on the side, did your issues with Prologix GPIB adapter resolve
using Linux?
Marvin,
..---------------------------------------------------
Modify it to your hearts content.
-Chuck Harris
OBTW, Prologix is a great company, I cannot recommend them enough!
Sincerely,
Marv Gozum
Philadelphia, PA
Hi Marvin,
Python is appealing for a number of reasons. First, it is an
interpreted scripting language. You can make changes on the
fly and instantly see their effect. Second, it is a very highly
structured object oriented language. Third, it is available on
virtually all operating systems, and runs on virtually all processors.
Fourth, it has thousands of library functions available. Chances are
that anything you want to do, library wise, has already been done, and
is waiting for you... python and graphs, python and surfaces, python
and audio, python and Octave, python and C++, python and burning DVD's,
python and well, visa compliant GPIB drivers...
Because it is scripted, Python is never going to be the fastest running
solution, but how fast do you need your GPIB code to be? The libraries
are typically written in C++, and are blindingly quick. The ease with
which you can make small changes and test them makes quick utilities
easy to put together. The easy integration with packages like wxPython
makes building beautiful integrated graphical applications easy to toss
together.... and wxPython builds GUI's anywhere python runs... including
windows.
Perl would work too, but unless you are very disciplined, perl scripts
end up being write only... totally unintelligible when you come back
later to make changes... sometimes even the next day...
I like C a lot; however, it takes a serious amount of setting up
to make the compiler not barf with lots of undefined references.
Python shares a characteristic with BASIC in that using a variable
will cause it to be created, of the right type, and properly initialized.
And, unlike Labview, python will survive the NI's eventual bankruptcy, or
sale. Python is heavily used in Linux, BSD unix, and even windows. It
will be here for a long while.
-Chuck Harris
Marvin E. Gozum wrote:
Hi Chuck,
Thanks for the clarification. Since the 3478A is a popular DVM in the
secondary market, this is good to know and for the archives of volt-nuts
to log your Prologix experience; I see the initial struggles over at
time-nuts archive.
Thanks for the Python code! I like its look, but the simplicity of
device interfacing begs the question, why Python over competitors, not
just Labview, why not C or Pascal or Basic etc., for writing support
code for instruments?
Doesn't seem like the fastest out there and these benchmarks do not
measure code size either.
http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php
I don't know the answer. Right now, I just use what I have.
But it seems overall being aware or knowing the commands of GPIB and
Prologix and establishing a connection to these devices through a
minimalist way: serial port/USB/dll layer is a stable floor, it made
your Python code very readable; if I simply let any app interface
automatically, should things malfunction, I'd have to trace the fault
from some established working floor.
I don't think I'd be able to do this if I obtained an interface library
in any language or Labview and relied on its abstraction to keep my
instruments together without knowing how its done.
If I write it myself, it seems it doesn't matter what the language is,
unless it offered some value in maintenance, speed or code size.
That's the locally famous former Wanamaker organ and store, now
Macys. It works because folks are there to lollygag and shop, open
to suggestion, and its a known location for live classical organ
music for over a century.
If you are open to something, your sense of value will strike as soon
as something of value fell on your lap, software included.
I have strongest doubts on spontaneity just as the Bell subway
example was already biased for being suboptimal; 650 choir members
meeting in a lobby on Saturday can't be there to just shop;
The event was certainly not happenstance. It must have been carefully
planned. The only ones surprised were those not in on the prank, as
always.
Macys
exists in so many more accessible suburbs; Philadelphia is notorious
for parking issues. The video quality is too good compared to
"spontaneous" ones via cellphone video, to suggest that was planned
from the start; aka, marketing. 5,000,000 views is ~ a number
watching wrestling on TV and running a paid spot for Macys.
Macys probably paid all the costs of the hack. It's since been done in a
bunch of other places. Once ius a showstopper. Done too often, it's a
PITA.
http://www.usatoday.com/life/television/news/nielsens-charts.htm
I think something that is less intellectual will stop a crowd: If
Starbucks set up a booth with free food, coffee, during morning rush
hour, will almost certainly create a stir than Mr. Bell.
Anything free draws a crowd, at least for a few seconds. Anything.
As to the violin at the subway, I don't know what he was playing, but a
long piece would certainly have drawn fewer stoppers than something short.
FWIW,
-John
===================
Likewise in software, for users, neither open source or closed source
matters, what matters is it works and its easier to maintain over
time, if needed.
Many thanks again Chuck. Beyond the facts, your passion for Python
says a lot. I will take the time to dig into it. I like interpreted
for onthefly results, I want easy set up, and flexibility in many
things particularly managing variables ala BASIC is always welcome; I
had something like it in Turbo Pascal and Delphi despite being
compiled. I share your misgiving with C, just not good when you are
splitting time between hardware and software and want fast results.
I was going to give Free Pascal a whirl, but sound like Python may be enough.
At 11:23 AM 12/7/2010, Chuck Harris wrote:
Hi Marvin,
Python is appealing for a number of reasons. First, it is an
interpreted scripting language. You can make changes on the
fly and instantly see their effect. Second, it is a very highly
structured object oriented language. Third, it is available on
virtually all operating systems, and runs on virtually all processors.
Fourth, it has thousands of library functions available. Chances are
that anything you want to do, library wise, has already been done, and
is waiting for you... python and graphs, python and surfaces, python
and audio, python and Octave, python and C++, python and burning DVD's,
python and well, visa compliant GPIB drivers...
Because it is scripted, Python is never going to be the fastest running
solution, but how fast do you need your GPIB code to be? The libraries
are typically written in C++, and are blindingly quick. The ease with
which you can make small changes and test them makes quick utilities
easy to put together. The easy integration with packages like wxPython
makes building beautiful integrated graphical applications easy to toss
together.... and wxPython builds GUI's anywhere python runs... including
windows.
Perl would work too, but unless you are very disciplined, perl scripts
end up being write only... totally unintelligible when you come back
later to make changes... sometimes even the next day...
I like C a lot; however, it takes a serious amount of setting up
to make the compiler not barf with lots of undefined references.
Python shares a characteristic with BASIC in that using a variable
will cause it to be created, of the right type, and properly initialized.
And, unlike Labview, python will survive the NI's eventual bankruptcy, or
sale. Python is heavily used in Linux, BSD unix, and even windows. It
will be here for a long while.
-Chuck Harris
Best Wishes,
Marv Gozum
Philadelphia
FWIW, the little I've done in Python has been positive. It's capable of
a lot -- the whole Gnuradio interface is built in python.
Personally, I've used perl under Linux for most of my GPIB stuff. Since
perl is good at string handling, it works well for grabbing data from
the instrument, munging it a bit, then writing it to a log file -- which
is most of what I do.
John
On 12/7/2010 2:28 PM, Marv Gozum @ JHN wrote:
Many thanks again Chuck. Beyond the facts, your passion for Python says
a lot. I will take the time to dig into it. I like interpreted for
onthefly results, I want easy set up, and flexibility in many things
particularly managing variables ala BASIC is always welcome; I had
something like it in Turbo Pascal and Delphi despite being compiled. I
share your misgiving with C, just not good when you are splitting time
between hardware and software and want fast results.
I was going to give Free Pascal a whirl, but sound like Python may be
enough.
At 11:23 AM 12/7/2010, Chuck Harris wrote:
Hi Marvin,
Python is appealing for a number of reasons. First, it is an
interpreted scripting language. You can make changes on the
fly and instantly see their effect. Second, it is a very highly
structured object oriented language. Third, it is available on
virtually all operating systems, and runs on virtually all processors.
Fourth, it has thousands of library functions available. Chances are
that anything you want to do, library wise, has already been done, and
is waiting for you... python and graphs, python and surfaces, python
and audio, python and Octave, python and C++, python and burning DVD's,
python and well, visa compliant GPIB drivers...
Because it is scripted, Python is never going to be the fastest running
solution, but how fast do you need your GPIB code to be? The libraries
are typically written in C++, and are blindingly quick. The ease with
which you can make small changes and test them makes quick utilities
easy to put together. The easy integration with packages like wxPython
makes building beautiful integrated graphical applications easy to toss
together.... and wxPython builds GUI's anywhere python runs... including
windows.
Perl would work too, but unless you are very disciplined, perl scripts
end up being write only... totally unintelligible when you come back
later to make changes... sometimes even the next day...
I like C a lot; however, it takes a serious amount of setting up
to make the compiler not barf with lots of undefined references.
Python shares a characteristic with BASIC in that using a variable
will cause it to be created, of the right type, and properly initialized.
And, unlike Labview, python will survive the NI's eventual bankruptcy, or
sale. Python is heavily used in Linux, BSD unix, and even windows. It
will be here for a long while.
-Chuck Harris
Best Wishes,
Marv Gozum
Philadelphia
volt-nuts mailing list -- volt-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.
In message 4CFE8D43.8030409@febo.com, John Ackermann N8UR writes:
FWIW, the little I've done in Python has been positive. It's capable of
a lot -- the whole Gnuradio interface is built in python.
Python seems destined to become the new FORTRAN: It is the default language
in a lot of scientific areas, including for instance genomics.
In addition to my HPIB hackery, I have written a generic disassembler
in python which so far have a M68K backend and a MC6800 backend
which have disassembled the HP3458A and HP5370B respectively.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.