| Re: MicroSnot just sneezed all over my PC [message #396579 is a reply to message #396578] |
Fri, 10 July 2020 12:29   |
|
|
Originally posted by: Gareth Evans
On 10/07/2020 16:32, Andreas Eder wrote:
> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> I used LaTeX for my slides at university. LaTeX is almost
>> infinitely superior to Word for any serious text, my only gripe
>> is figure placement. But LaTeX for slides... no.
>
> Have you looked at beamer? Yjay is far superior to powerpoint in my
> opinion. And far faster to write for me.
Is there a (Slacko) Linux package that will read (and maybe
write) .DOCX files (in order to circumvent MicroSnot forever
moving the goalposts as to what is the industry standard)?
I just remembered that I dual booted an old laptop 5 years
ago but not done anything with it since.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396584 is a reply to message #396579] |
Fri, 10 July 2020 16:28 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-07-10, Gareth Evans <headstone255@yahoo.com> wrote:
> On 10/07/2020 16:32, Andreas Eder wrote:
>
>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> I used LaTeX for my slides at university. LaTeX is almost
>>> infinitely superior to Word for any serious text, my only gripe
>>> is figure placement. But LaTeX for slides... no.
>>
>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>> opinion. And far faster to write for me.
>
> Is there a (Slacko) Linux package that will read (and maybe
> write) .DOCX files (in order to circumvent MicroSnot forever
> moving the goalposts as to what is the industry standard)?
Try LibreOffice.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396590 is a reply to message #396584] |
Fri, 10 July 2020 19:04 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-07-10, Gareth Evans <headstone255@yahoo.com> wrote:
>
>> On 10/07/2020 16:32, Andreas Eder wrote:
>>
>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>>> I used LaTeX for my slides at university. LaTeX is almost
>>>> infinitely superior to Word for any serious text, my only gripe
>>>> is figure placement. But LaTeX for slides... no.
>>>
>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>> opinion. And far faster to write for me.
>>
>> Is there a (Slacko) Linux package that will read (and maybe
>> write) .DOCX files (in order to circumvent MicroSnot forever
>> moving the goalposts as to what is the industry standard)?
>
> Try LibreOffice.
>
From what I read it’s a bit iffy, but I didn’t note the date of those
posts.
--
Pete
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396591 is a reply to message #396579] |
Fri, 10 July 2020 19:05 |
|
|
Originally posted by: J. Clarke
On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
<headstone255@yahoo.com> wrote:
> On 10/07/2020 16:32, Andreas Eder wrote:
>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> I used LaTeX for my slides at university. LaTeX is almost
>>> infinitely superior to Word for any serious text, my only gripe
>>> is figure placement. But LaTeX for slides... no.
>>
>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>> opinion. And far faster to write for me.
>
> Is there a (Slacko) Linux package that will read (and maybe
> write) .DOCX files (in order to circumvent MicroSnot forever
> moving the goalposts as to what is the industry standard)?
You do know that the document format used by Word is an ISO standard
do you not?
> I just remembered that I dual booted an old laptop 5 years
> ago but not done anything with it since.
>
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396592 is a reply to message #396591] |
Fri, 10 July 2020 20:30 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-07-10, J Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
> <headstone255@yahoo.com> wrote:
>
>> On 10/07/2020 16:32, Andreas Eder wrote:
>>
>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>>> I used LaTeX for my slides at university. LaTeX is almost
>>>> infinitely superior to Word for any serious text, my only gripe
>>>> is figure placement. But LaTeX for slides... no.
>>>
>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>> opinion. And far faster to write for me.
>>
>> Is there a (Slacko) Linux package that will read (and maybe
>> write) .DOCX files (in order to circumvent MicroSnot forever
>> moving the goalposts as to what is the industry standard)?
>
> You do know that the document format used by Word is an ISO standard
> do you not?
That's news to me. I remember the days when the .doc file format
was covered by an NDA - and that someone in this newsgroup signed
it and said we really didn't want to know what was inside.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396595 is a reply to message #396592] |
Fri, 10 July 2020 20:58 |
|
|
Originally posted by: J. Clarke
On 11 Jul 2020 00:30:32 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
> On 2020-07-10, J Clarke <jclarke.873638@gmail.com> wrote:
>
>> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
>> <headstone255@yahoo.com> wrote:
>>
>>> On 10/07/2020 16:32, Andreas Eder wrote:
>>>
>>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>
>>>> > I used LaTeX for my slides at university. LaTeX is almost
>>>> > infinitely superior to Word for any serious text, my only gripe
>>>> > is figure placement. But LaTeX for slides... no.
>>>>
>>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>>> opinion. And far faster to write for me.
>>>
>>> Is there a (Slacko) Linux package that will read (and maybe
>>> write) .DOCX files (in order to circumvent MicroSnot forever
>>> moving the goalposts as to what is the industry standard)?
>>
>> You do know that the document format used by Word is an ISO standard
>> do you not?
>
> That's news to me. I remember the days when the .doc file format
> was covered by an NDA - and that someone in this newsgroup signed
> it and said we really didn't want to know what was inside.
That was doc. docx is defined by ISO29500. So is xlsx. Change the
extension on either to .zip and double-click it (in Windows 10 anyway)
and it opens up into a set of xml files.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396601 is a reply to message #396590] |
Sat, 11 July 2020 05:42 |
Andy Leighton
Messages: 203
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 10 Jul 2020 16:04:50 -0700, Peter Flass <peter_flass@yahoo.com> wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2020-07-10, Gareth Evans <headstone255@yahoo.com> wrote:
>>
>>> On 10/07/2020 16:32, Andreas Eder wrote:
>>>
>>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>
>>>> > I used LaTeX for my slides at university. LaTeX is almost
>>>> > infinitely superior to Word for any serious text, my only gripe
>>>> > is figure placement. But LaTeX for slides... no.
>>>>
>>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>>> opinion. And far faster to write for me.
>>>
>>> Is there a (Slacko) Linux package that will read (and maybe
>>> write) .DOCX files (in order to circumvent MicroSnot forever
>>> moving the goalposts as to what is the industry standard)?
>>
>> Try LibreOffice.
>
> From what I read it’s a bit iffy, but I didn’t note the date of those
> posts.
Not really. I use LibreOffice and never had any problems with my own
documents or the stuff I get given that has come from MS Office.
Not it is possible to create stuff in Microsoft Office that isn't going
to work very well in LibreOffice (and probably vice-versa) but they
aren't you typical work documents.
--
Andy Leighton => andyl@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396604 is a reply to message #396591] |
Sat, 11 July 2020 08:56 |
|
|
Originally posted by: Gareth Evans
On 11/07/2020 00:05, J. Clarke wrote:
> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
> <headstone255@yahoo.com> wrote:
>
>> On 10/07/2020 16:32, Andreas Eder wrote:
>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>>> I used LaTeX for my slides at university. LaTeX is almost
>>>> infinitely superior to Word for any serious text, my only gripe
>>>> is figure placement. But LaTeX for slides... no.
>>>
>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>> opinion. And far faster to write for me.
>>
>> Is there a (Slacko) Linux package that will read (and maybe
>> write) .DOCX files (in order to circumvent MicroSnot forever
>> moving the goalposts as to what is the industry standard)?
>
> You do know that the document format used by Word is an ISO standard
> do you not?
No, I did not, but I had in mind MicroSnot's EEE policy;
Embrace, Extend, Exterminate.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396606 is a reply to message #396591] |
Sat, 11 July 2020 12:07 |
|
|
Originally posted by: Jim Jackson
On 2020-07-10, J Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
>> Is there a (Slacko) Linux package that will read (and maybe
>> write) .DOCX files (in order to circumvent MicroSnot forever
>> moving the goalposts as to what is the industry standard)?
>
> You do know that the document format used by Word is an ISO standard
> do you not?
Oh memories memories. Microsoft strong-armed it's new docx xml based
format through the standardisation process in the early noughties.
Wikipedia https://en.wikipedia.org/wiki/Office_Open_XML has some
comments on it (3rd paragraph under the Standardisation Process
heading).
They were shamed into doing something because a lot of big organisations
were getting jittery about format lock-in (doc being proprietary), and
there was already an Internation Standard, Open Document, which they
were not going t osupport because they didn't invent it. Microsoft at
the time was aggressively trying to protect it's dominant position.
Interestingly they seem to have changed a lot in the intervening years.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396611 is a reply to message #396606] |
Sat, 11 July 2020 12:56 |
|
|
Originally posted by: J. Clarke
On Sat, 11 Jul 2020 16:07:27 -0000 (UTC), Jim Jackson
<jj@iridium.wf32df> wrote:
> On 2020-07-10, J Clarke <jclarke.873638@gmail.com> wrote:
>> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
>>> Is there a (Slacko) Linux package that will read (and maybe
>>> write) .DOCX files (in order to circumvent MicroSnot forever
>>> moving the goalposts as to what is the industry standard)?
>>
>> You do know that the document format used by Word is an ISO standard
>> do you not?
>
> Oh memories memories. Microsoft strong-armed it's new docx xml based
> format through the standardisation process in the early noughties.
> Wikipedia https://en.wikipedia.org/wiki/Office_Open_XML has some
> comments on it (3rd paragraph under the Standardisation Process
> heading).
>
> They were shamed into doing something because a lot of big organisations
> were getting jittery about format lock-in (doc being proprietary), and
> there was already an Internation Standard, Open Document, which they
> were not going t osupport because they didn't invent it. Microsoft at
> the time was aggressively trying to protect it's dominant position.
> Interestingly they seem to have changed a lot in the intervening years.
They found other ways. One big one is providing the average user
quite remarkably capable development capability that is locked into a
Microsoft interprocess communication protocol that has wide third
party support. If we had to go to LibreOffice our productivity would
tank until we recreated most of our automation code--no, it does not
run in LibreOffice and can't be easily ported.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396612 is a reply to message #396611] |
Sat, 11 July 2020 13:34 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 11 Jul 2020 12:56:57 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:
> They found other ways. One big one is providing the average user
> quite remarkably capable development capability that is locked into a
> Microsoft interprocess communication protocol that has wide third
> party support. If we had to go to LibreOffice our productivity would
> tank until we recreated most of our automation code--no, it does not
> run in LibreOffice and can't be easily ported.
I still find the idea of using an office suite for process
automation bizarre.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396613 is a reply to message #396595] |
Sat, 11 July 2020 14:21 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-07-11, J Clarke <jclarke.873638@gmail.com> wrote:
> On 11 Jul 2020 00:30:32 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> On 2020-07-10, J Clarke <jclarke.873638@gmail.com> wrote:
>>
>>> You do know that the document format used by Word is an ISO standard
>>> do you not?
>>
>> That's news to me. I remember the days when the .doc file format
>> was covered by an NDA - and that someone in this newsgroup signed
>> it and said we really didn't want to know what was inside.
>
> That was doc. docx is defined by ISO29500. So is xlsx. Change the
> extension on either to .zip and double-click it (in Windows 10 anyway)
> and it opens up into a set of xml files.
I did discover that much. (Although in Linux it was much easier -
hexdump revealed the PK magic bytes, and unzip unpacked it without
having to rename it.) I suppose it adds a lot of flexibility, but
for simple documents it looks like gratuitous complexity. Hopefully
with ISO behind it there won't be any proprietary gotchas.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396614 is a reply to message #396612] |
Sat, 11 July 2020 14:24 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-07-11, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Sat, 11 Jul 2020 12:56:57 -0400
> J. Clarke <jclarke.873638@gmail.com> wrote:
>
>> They found other ways. One big one is providing the average user
>> quite remarkably capable development capability that is locked into a
>> Microsoft interprocess communication protocol that has wide third
>> party support. If we had to go to LibreOffice our productivity would
>> tank until we recreated most of our automation code--no, it does not
>> run in LibreOffice and can't be easily ported.
>
> I still find the idea of using an office suite for process
> automation bizarre.
Perhaps, but look at some of the things that are being done by
people who live in spreadsheet land.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396616 is a reply to message #396591] |
Sat, 11 July 2020 15:20 |
|
|
Originally posted by: drb
> You do know that the document format used by Word is an ISO standard
> do you not?
It's probably more correct to say that at one point ISO wrote
down what M$ products were doing, and that M$ has been diverging
from there ever since.
De
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396617 is a reply to message #396614] |
Sat, 11 July 2020 15:38 |
|
|
Originally posted by: J. Clarke
On 11 Jul 2020 18:24:47 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
> On 2020-07-11, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On Sat, 11 Jul 2020 12:56:57 -0400
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>
>>> They found other ways. One big one is providing the average user
>>> quite remarkably capable development capability that is locked into a
>>> Microsoft interprocess communication protocol that has wide third
>>> party support. If we had to go to LibreOffice our productivity would
>>> tank until we recreated most of our automation code--no, it does not
>>> run in LibreOffice and can't be easily ported.
>>
>> I still find the idea of using an office suite for process
>> automation bizarre.
>
> Perhaps, but look at some of the things that are being done by
> people who live in spreadsheet land.
Look at it from a different perspective.
Microsoft Visual Basic for Applications is a programming environment
that includes libraries that provide the functionality of a full
featured office suite including a spreadsheet, word processor,
database manager, and slideshow presenter and is in addition supported
by a wide variety of third party libraries.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396618 is a reply to message #396616] |
Sat, 11 July 2020 15:54 |
|
|
Originally posted by: J. Clarke
On Sat, 11 Jul 2020 14:20:10 -0500, drb@ihatespam.msu.edu (Dennis
Boone) wrote:
>> You do know that the document format used by Word is an ISO standard
>> do you not?
>
> It's probably more correct to say that at one point ISO wrote
> down what M$ products were doing, and that M$ has been diverging
> from there ever since.
No, Microsoft wrote down what their products were doing and crammed it
down ISO's throat whether ISO liked it or not.
Do you have evidence that the current Microsoft products are not
compliant with ISO29500?
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396619 is a reply to message #396614] |
Sat, 11 July 2020 15:38 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 11 Jul 2020 18:24:47 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-07-11, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On Sat, 11 Jul 2020 12:56:57 -0400
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>
>>> They found other ways. One big one is providing the average user
>>> quite remarkably capable development capability that is locked into a
>>> Microsoft interprocess communication protocol that has wide third
>>> party support. If we had to go to LibreOffice our productivity would
>>> tank until we recreated most of our automation code--no, it does not
>>> run in LibreOffice and can't be easily ported.
>>
>> I still find the idea of using an office suite for process
>> automation bizarre.
>
> Perhaps, but look at some of the things that are being done by
> people who live in spreadsheet land.
I have seen, I find it bizarre.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396621 is a reply to message #396617] |
Sat, 11 July 2020 17:35 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 11 Jul 2020 15:38:12 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:
> On 11 Jul 2020 18:24:47 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> On 2020-07-11, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>
>>> I still find the idea of using an office suite for process
>>> automation bizarre.
>>
>> Perhaps, but look at some of the things that are being done by
>> people who live in spreadsheet land.
>
> Look at it from a different perspective.
>
> Microsoft Visual Basic for Applications is a programming environment
> that includes libraries that provide the functionality of a full
> featured office suite including a spreadsheet, word processor,
> database manager, and slideshow presenter and is in addition supported
> by a wide variety of third party libraries.
I see your point, I've always thought of it as a scripting language
bolted onto a bunch of office applications and I think it started that way
before it became what you describe.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396638 is a reply to message #396612] |
Sun, 12 July 2020 02:55 |
|
|
Originally posted by: maus
On 2020-07-11, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Sat, 11 Jul 2020 12:56:57 -0400
> J. Clarke <jclarke.873638@gmail.com> wrote:
>
>> They found other ways. One big one is providing the average user
>> quite remarkably capable development capability that is locked into a
>> Microsoft interprocess communication protocol that has wide third
>> party support. If we had to go to LibreOffice our productivity would
>> tank until we recreated most of our automation code--no, it does not
>> run in LibreOffice and can't be easily ported.
>
> I still find the idea of using an office suite for process
> automation bizarre.
>
I haave long since given up trying to communicate via email with
government. print it out, and post it.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396649 is a reply to message #396591] |
Sun, 12 July 2020 15:00 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Fri, 10 Jul 2020 17:29:54 +0100, Gareth Evans
> <headstone255@yahoo.com> wrote:
>
>> On 10/07/2020 16:32, Andreas Eder wrote:
>>> On Fr 26 Jun 2020 at 16:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>>> I used LaTeX for my slides at university. LaTeX is almost
>>>> infinitely superior to Word for any serious text, my only gripe
>>>> is figure placement. But LaTeX for slides... no.
>>>
>>> Have you looked at beamer? Yjay is far superior to powerpoint in my
>>> opinion. And far faster to write for me.
>>
>> Is there a (Slacko) Linux package that will read (and maybe
>> write) .DOCX files (in order to circumvent MicroSnot forever
>> moving the goalposts as to what is the industry standard)?
>
> You do know that the document format used by Word is an ISO standard
> do you not?
There was a bit of controversy about that when it was submitted
to ISO, as it is not all-inclusive and was not generally embraced
by the open source community.
https://www.wired.com/2007/08/microsoft-allegedly-bullies-an d-bribes-to-make-office-an-international-standard/
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396825 is a reply to message #396201] |
Sun, 19 July 2020 23:36 |
|
|
Originally posted by: J. Clarke
On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>
>>>
>>> I've never done it but I believe LibreOffice can be scripted similar to
>>> MS Office.
>>
>> That's not the problem. You have a GNU APL workspace. You need to
>> set some parameters in the workspace, start it running, detect when it
>> has finished, grab some data out of it, save it to a new location, and
>> if it crashes you have to recognize that it crashed and log the crash.
>>
>> It isn't just scripting the office application, it is using the office
>> application to control another program provided by a different vendor.
>>
>>
>
> Isn't that what shell scripts are designed for? Use the right tool
> for the job.
OK, so tell us how to, from a shell script, display the list of jobs
you can run, quickly select the ones you want, start one less than the
number of cores in the machine of them, monitor their operation, when
one completes start another, display all of this in the user-friendly
interface, and if one crashes detect that it has crashed and display
appropriate messages.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396826 is a reply to message #396212] |
Sun, 19 July 2020 23:48 |
|
|
Originally posted by: J. Clarke
On Fri, 26 Jun 2020 09:58:16 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>
>>>>
>>>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> MS Office.
>>>
>>> That's not the problem. You have a GNU APL workspace. You need to
>>> set some parameters in the workspace, start it running, detect when it
>>> has finished, grab some data out of it, save it to a new location, and
>>> if it crashes you have to recognize that it crashed and log the crash.
>>>
>>> It isn't just scripting the office application, it is using the office
>>> application to control another program provided by a different vendor.
>>>
>>>
>>
>> Isn't that what shell scripts are designed for? Use the right tool
>> for the job.
>>
>
> It’s probably a piece of Topsy software, it “just growed.” I would imagine
> somebody tried it as a one-shot and it went from there. I would also
> imagine it would be a horror to rewrite it to do it right. It’s certainly
> possible to do COM stuff from a program, or probably even a script.
It didn't "just grow", it was designed to do what it does and it took
a lot of research and experimentation to figure out how to do it. If
I was doing it now I would have done some things differently and
eventually it may get a rewrite, but it's hardly a "horror".
As for shell scripts, this is a Windows shop. And before you say
"well change that", it's a Fortune 100 company, and I'm not the head
of IT.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396827 is a reply to message #396200] |
Sun, 19 July 2020 23:51 |
|
|
Originally posted by: J. Clarke
On Fri, 26 Jun 2020 14:20:24 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>> On 25 Jun 2020 06:11:44 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>> wrote:
>>
>
>> So what's an actually better and not just different office suite? And
>> don't say "Open Office" until you can demonstrate Open Office managing
>> 60 APL workspaces each executing on a different core.
>
>
> Of course 99.9999999999999% of office users (MS or Open/Libre office)
> don't need office to manage any APL workspaces. What a silly requirement.
I don't care what 99.99999999% need. This is what _I_ need.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396833 is a reply to message #396827] |
Mon, 20 July 2020 04:06 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 19 Jul 2020 23:51:20 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Fri, 26 Jun 2020 14:20:24 GMT, scott@slp53.sl.home (Scott Lurndal)
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>> On 25 Jun 2020 06:11:44 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>> wrote:
>>>
>>
>>> So what's an actually better and not just different office suite? And
>>> don't say "Open Office" until you can demonstrate Open Office managing
>>> 60 APL workspaces each executing on a different core.
>>
>>
>> Of course 99.9999999999999% of office users (MS or Open/Libre office)
>> don't need office to manage any APL workspaces. What a silly
>> requirement.
>
> I don't care what 99.99999999% need. This is what _I_ need.
Sure but what you need is a process control system not an office
suite. It is impressive that you can use an office suite for the purpose
but it is certainly possible to imagine a far better office suite than
either MS or Libre with no ability to manage APL workspaces at all.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396836 is a reply to message #396825] |
Mon, 20 July 2020 08:47 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>
>>>>
>>>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> MS Office.
>>>
>>> That's not the problem. You have a GNU APL workspace. You need to
>>> set some parameters in the workspace, start it running, detect when it
>>> has finished, grab some data out of it, save it to a new location, and
>>> if it crashes you have to recognize that it crashed and log the crash.
>>>
>>> It isn't just scripting the office application, it is using the office
>>> application to control another program provided by a different vendor.
>>>
>>>
>>
>> Isn't that what shell scripts are designed for? Use the right tool
>> for the job.
>
> OK, so tell us how to, from a shell script, display the list of jobs
> you can run, quickly select the ones you want, start one less than the
> number of cores in the machine of them, monitor their operation, when
> one completes start another, display all of this in the user-friendly
> interface, and if one crashes detect that it has crashed and display
> appropriate messages.
I don't mean to question your requirements or implementation,
I'm sure it took a lot of work to accomplish what you have.
Just curious about some of these things.
The number of CPUs seems trivial, at least on Linux:
home> lscpu | grep '^CPU(s):'
CPU(s): 4
I'm not sure what monitoring would entail, but it's pretty easy to
tell if something is running, capture it's PID and use "ps".
Crashes seem easy to detect and analyze using "abrt".
The go to tool for Linux always seems to be a shell script.
I think that's a mistake, sooner or later as the application
grows, shell scripts are going to come up short. Much better
to start out with a real scripting language like Perl or even
better, Python.
Python and Qt (PyQt) can produce some very attractive GUIs.
(Works on Windows too.)
--
Dan Espen
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396837 is a reply to message #396836] |
Mon, 20 July 2020 09:34 |
|
|
Originally posted by: J. Clarke
On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>
>>>> >
>>>> >I've never done it but I believe LibreOffice can be scripted similar to
>>>> >MS Office.
>>>>
>>>> That's not the problem. You have a GNU APL workspace. You need to
>>>> set some parameters in the workspace, start it running, detect when it
>>>> has finished, grab some data out of it, save it to a new location, and
>>>> if it crashes you have to recognize that it crashed and log the crash.
>>>>
>>>> It isn't just scripting the office application, it is using the office
>>>> application to control another program provided by a different vendor.
>>>>
>>>>
>>>
>>> Isn't that what shell scripts are designed for? Use the right tool
>>> for the job.
>>
>> OK, so tell us how to, from a shell script, display the list of jobs
>> you can run, quickly select the ones you want, start one less than the
>> number of cores in the machine of them, monitor their operation, when
>> one completes start another, display all of this in the user-friendly
>> interface, and if one crashes detect that it has crashed and display
>> appropriate messages.
>
> I don't mean to question your requirements or implementation,
> I'm sure it took a lot of work to accomplish what you have.
> Just curious about some of these things.
>
> The number of CPUs seems trivial, at least on Linux:
>
> home> lscpu | grep '^CPU(s):'
> CPU(s): 4
That's not the problem. The problem is having it keep track of the
number of sessions it has started and that have completed.
> I'm not sure what monitoring would entail, but it's pretty easy to
> tell if something is running, capture it's PID and use "ps".
Knowing that something is running doesn't help. We know it's running
because we started it. We need to know when it has completed. APL is
an environment, you don't do "APL X" and have X run. You do APL, then
)LOAD X, then Y to start a process, possibly after setting variables
A, B, and C to control that process, and then it runs until it
completes or crashes, then it sits there either with an error message
showing or the cursor sitting there flashing at you. And once the
process is completed, then we have other steps that need to be
performed.
> Crashes seem easy to detect and analyze using "abrt".
APL doesn't crash. The program running in APL crashes. APL duly
reports it to the user and remains open. While there are probably
ways to make the interpreter itself crash that would come under the
heading of an "exploit", not something that happens in normal
programming.
> The go to tool for Linux always seems to be a shell script.
> I think that's a mistake, sooner or later as the application
> grows, shell scripts are going to come up short. Much better
> to start out with a real scripting language like Perl or even
> better, Python.
>
> Python and Qt (PyQt) can produce some very attractive GUIs.
> (Works on Windows too.)
For certain values of "attractive" and it's a lot more work than
displaying the information in an Excel workbook.
And at the time Python was not available to us.
Further, I'm still not sure that I can make Python do what VBA is
doing.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396838 is a reply to message #396836] |
Mon, 20 July 2020 09:42 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>
>>>> >
>>>> > I've never done it but I believe LibreOffice can be scripted similar to
>>>> > MS Office.
>>>>
>>>> That's not the problem. You have a GNU APL workspace. You need to
>>>> set some parameters in the workspace, start it running, detect when it
>>>> has finished, grab some data out of it, save it to a new location, and
>>>> if it crashes you have to recognize that it crashed and log the crash.
>>>>
>>>> It isn't just scripting the office application, it is using the office
>>>> application to control another program provided by a different vendor.
>>>>
>>>>
>>>
>>> Isn't that what shell scripts are designed for? Use the right tool
>>> for the job.
>>
>> OK, so tell us how to, from a shell script, display the list of jobs
>> you can run, quickly select the ones you want, start one less than the
>> number of cores in the machine of them, monitor their operation, when
>> one completes start another, display all of this in the user-friendly
>> interface, and if one crashes detect that it has crashed and display
>> appropriate messages.
>
> I don't mean to question your requirements or implementation,
> I'm sure it took a lot of work to accomplish what you have.
> Just curious about some of these things.
>
> The number of CPUs seems trivial, at least on Linux:
>
>> lscpu | grep '^CPU(s):'
> CPU(s): 4
>
> I'm not sure what monitoring would entail, but it's pretty easy to
> tell if something is running, capture it's PID and use "ps".
>
> Crashes seem easy to detect and analyze using "abrt".
>
> The go to tool for Linux always seems to be a shell script.
> I think that's a mistake, sooner or later as the application
> grows, shell scripts are going to come up short. Much better
> to start out with a real scripting language like Perl or even
> better, Python.
>
> Python and Qt (PyQt) can produce some very attractive GUIs.
> (Works on Windows too.)
>
>
Or Rexx
--
Pete
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396839 is a reply to message #396837] |
Mon, 20 July 2020 09:42 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> > On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> > wrote:
>>>> >
>>>>
>>>> >>
>>>> >> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >> MS Office.
>>>> >
>>>> > That's not the problem. You have a GNU APL workspace. You need to
>>>> > set some parameters in the workspace, start it running, detect when it
>>>> > has finished, grab some data out of it, save it to a new location, and
>>>> > if it crashes you have to recognize that it crashed and log the crash.
>>>> >
>>>> > It isn't just scripting the office application, it is using the office
>>>> > application to control another program provided by a different vendor.
>>>> >
>>>> >
>>>>
>>>> Isn't that what shell scripts are designed for? Use the right tool
>>>> for the job.
>>>
>>> OK, so tell us how to, from a shell script, display the list of jobs
>>> you can run, quickly select the ones you want, start one less than the
>>> number of cores in the machine of them, monitor their operation, when
>>> one completes start another, display all of this in the user-friendly
>>> interface, and if one crashes detect that it has crashed and display
>>> appropriate messages.
>>
>> I don't mean to question your requirements or implementation,
>> I'm sure it took a lot of work to accomplish what you have.
>> Just curious about some of these things.
>>
>> The number of CPUs seems trivial, at least on Linux:
>>
>>> lscpu | grep '^CPU(s):'
>> CPU(s): 4
>
> That's not the problem. The problem is having it keep track of the
> number of sessions it has started and that have completed.
>
>> I'm not sure what monitoring would entail, but it's pretty easy to
>> tell if something is running, capture it's PID and use "ps".
>
> Knowing that something is running doesn't help. We know it's running
> because we started it. We need to know when it has completed. APL is
> an environment, you don't do "APL X" and have X run. You do APL, then
> )LOAD X, then Y to start a process, possibly after setting variables
> A, B, and C to control that process, and then it runs until it
> completes or crashes, then it sits there either with an error message
> showing or the cursor sitting there flashing at you. And once the
> process is completed, then we have other steps that need to be
> performed.
>
>> Crashes seem easy to detect and analyze using "abrt".
>
> APL doesn't crash. The program running in APL crashes. APL duly
> reports it to the user and remains open. While there are probably
> ways to make the interpreter itself crash that would come under the
> heading of an "exploit", not something that happens in normal
> programming.
>
>> The go to tool for Linux always seems to be a shell script.
>> I think that's a mistake, sooner or later as the application
>> grows, shell scripts are going to come up short. Much better
>> to start out with a real scripting language like Perl or even
>> better, Python.
>>
>> Python and Qt (PyQt) can produce some very attractive GUIs.
>> (Works on Windows too.)
>
> For certain values of "attractive" and it's a lot more work than
> displaying the information in an Excel workbook.
>
> And at the time Python was not available to us.
>
> Further, I'm still not sure that I can make Python do what VBA is
> doing.
>
To each his own, or, if the only tool you have is a hammer, everything
looks like a nail,
--
Pete
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396843 is a reply to message #396839] |
Mon, 20 July 2020 10:31 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>> wrote:
>>>>
>>>> > J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >
>>>> >>>
>>>> >>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >>> MS Office.
>>>> >>
>>>> >> That's not the problem. You have a GNU APL workspace. You need to
>>>> >> set some parameters in the workspace, start it running, detect when it
>>>> >> has finished, grab some data out of it, save it to a new location, and
>>>> >> if it crashes you have to recognize that it crashed and log the crash.
>>>> >>
>>>> >> It isn't just scripting the office application, it is using the office
>>>> >> application to control another program provided by a different vendor.
>>>> >>
>>>> >>
>>>> >
>>>> > Isn't that what shell scripts are designed for? Use the right tool
>>>> > for the job.
>>>>
>>>> OK, so tell us how to, from a shell script, display the list of jobs
>>>> you can run, quickly select the ones you want, start one less than the
>>>> number of cores in the machine of them, monitor their operation, when
>>>> one completes start another, display all of this in the user-friendly
>>>> interface, and if one crashes detect that it has crashed and display
>>>> appropriate messages.
>>>
>>> I don't mean to question your requirements or implementation,
>>> I'm sure it took a lot of work to accomplish what you have.
>>> Just curious about some of these things.
>>>
>>> The number of CPUs seems trivial, at least on Linux:
>>>
>>>> lscpu | grep '^CPU(s):'
>>> CPU(s): 4
>>
>> That's not the problem. The problem is having it keep track of the
>> number of sessions it has started and that have completed.
>>
>>> I'm not sure what monitoring would entail, but it's pretty easy to
>>> tell if something is running, capture it's PID and use "ps".
>>
>> Knowing that something is running doesn't help. We know it's running
>> because we started it. We need to know when it has completed. APL is
>> an environment, you don't do "APL X" and have X run. You do APL, then
>> )LOAD X, then Y to start a process, possibly after setting variables
>> A, B, and C to control that process, and then it runs until it
>> completes or crashes, then it sits there either with an error message
>> showing or the cursor sitting there flashing at you. And once the
>> process is completed, then we have other steps that need to be
>> performed.
>>
>>> Crashes seem easy to detect and analyze using "abrt".
>>
>> APL doesn't crash. The program running in APL crashes. APL duly
>> reports it to the user and remains open. While there are probably
>> ways to make the interpreter itself crash that would come under the
>> heading of an "exploit", not something that happens in normal
>> programming.
>>
>>> The go to tool for Linux always seems to be a shell script.
>>> I think that's a mistake, sooner or later as the application
>>> grows, shell scripts are going to come up short. Much better
>>> to start out with a real scripting language like Perl or even
>>> better, Python.
>>>
>>> Python and Qt (PyQt) can produce some very attractive GUIs.
>>> (Works on Windows too.)
>>
>> For certain values of "attractive" and it's a lot more work than
>> displaying the information in an Excel workbook.
>>
>> And at the time Python was not available to us.
>>
>> Further, I'm still not sure that I can make Python do what VBA is
>> doing.
>
> To each his own, or, if the only tool you have is a hammer, everything
> looks like a nail,
Well, I think he's working with something pretty complex.
I think they used what they had and now they're in pretty deep.
I never liked being tied to one vendors whims, but sometimes it's
hard to avoid.
In this case, I'd try to keep current on what alternatives I might have.
--
Dan Espen
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396844 is a reply to message #396838] |
Mon, 20 July 2020 10:46 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Dan Espen <dan1espen@gmail.com> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> > On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> > wrote:
>>>> >
>>>>
>>>> >>
>>>> >> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >> MS Office.
>>>> >
>>>> > That's not the problem. You have a GNU APL workspace. You need to
>>>> > set some parameters in the workspace, start it running, detect when it
>>>> > has finished, grab some data out of it, save it to a new location, and
>>>> > if it crashes you have to recognize that it crashed and log the crash.
>>>> >
>>>> > It isn't just scripting the office application, it is using the office
>>>> > application to control another program provided by a different vendor.
>>>> >
>>>> >
>>>>
>>>> Isn't that what shell scripts are designed for? Use the right tool
>>>> for the job.
>>>
>>> OK, so tell us how to, from a shell script, display the list of jobs
>>> you can run, quickly select the ones you want, start one less than the
>>> number of cores in the machine of them, monitor their operation, when
>>> one completes start another, display all of this in the user-friendly
>>> interface, and if one crashes detect that it has crashed and display
>>> appropriate messages.
>>
>> I don't mean to question your requirements or implementation,
>> I'm sure it took a lot of work to accomplish what you have.
>> Just curious about some of these things.
>>
>> The number of CPUs seems trivial, at least on Linux:
>>
>>> lscpu | grep '^CPU(s):'
>> CPU(s): 4
>>
>> I'm not sure what monitoring would entail, but it's pretty easy to
>> tell if something is running, capture it's PID and use "ps".
>>
>> Crashes seem easy to detect and analyze using "abrt".
>>
>> The go to tool for Linux always seems to be a shell script.
>> I think that's a mistake, sooner or later as the application
>> grows, shell scripts are going to come up short. Much better
>> to start out with a real scripting language like Perl or even
>> better, Python.
>>
>> Python and Qt (PyQt) can produce some very attractive GUIs.
>> (Works on Windows too.)
>
> Or Rexx
Just checked. The GUI packages for REXX are ActiveTcl and
RexxTK. The both appear to be TK based. I looked at
TCL/TK. What I saw was pretty ugly. Maybe it's better now,
I don't know.
What I liked about Qt was that it looks like a native application,
the same code looks different on Unix/Windows/MacOS. It also has
a huge selection of widgets.
Looks like TCL/TK is portable too.
REXX is pretty nice to code in, I've used it extensively,
but I'd still prefer Python. It hasn't let me down.
When I need to parse JSON, Html, email, there are good packages
available.
--
Dan Espen
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396850 is a reply to message #396843] |
Mon, 20 July 2020 16:58 |
|
|
Originally posted by: J. Clarke
On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>>
>>>> > On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>> > wrote:
>>>> >
>>>> >> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> >>> wrote:
>>>> >>>
>>>> >>
>>>> >>>>
>>>> >>>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >>>> MS Office.
>>>> >>>
>>>> >>> That's not the problem. You have a GNU APL workspace. You need to
>>>> >>> set some parameters in the workspace, start it running, detect when it
>>>> >>> has finished, grab some data out of it, save it to a new location, and
>>>> >>> if it crashes you have to recognize that it crashed and log the crash.
>>>> >>>
>>>> >>> It isn't just scripting the office application, it is using the office
>>>> >>> application to control another program provided by a different vendor.
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> Isn't that what shell scripts are designed for? Use the right tool
>>>> >> for the job.
>>>> >
>>>> > OK, so tell us how to, from a shell script, display the list of jobs
>>>> > you can run, quickly select the ones you want, start one less than the
>>>> > number of cores in the machine of them, monitor their operation, when
>>>> > one completes start another, display all of this in the user-friendly
>>>> > interface, and if one crashes detect that it has crashed and display
>>>> > appropriate messages.
>>>>
>>>> I don't mean to question your requirements or implementation,
>>>> I'm sure it took a lot of work to accomplish what you have.
>>>> Just curious about some of these things.
>>>>
>>>> The number of CPUs seems trivial, at least on Linux:
>>>>
>>>> > lscpu | grep '^CPU(s):'
>>>> CPU(s): 4
>>>
>>> That's not the problem. The problem is having it keep track of the
>>> number of sessions it has started and that have completed.
>>>
>>>> I'm not sure what monitoring would entail, but it's pretty easy to
>>>> tell if something is running, capture it's PID and use "ps".
>>>
>>> Knowing that something is running doesn't help. We know it's running
>>> because we started it. We need to know when it has completed. APL is
>>> an environment, you don't do "APL X" and have X run. You do APL, then
>>> )LOAD X, then Y to start a process, possibly after setting variables
>>> A, B, and C to control that process, and then it runs until it
>>> completes or crashes, then it sits there either with an error message
>>> showing or the cursor sitting there flashing at you. And once the
>>> process is completed, then we have other steps that need to be
>>> performed.
>>>
>>>> Crashes seem easy to detect and analyze using "abrt".
>>>
>>> APL doesn't crash. The program running in APL crashes. APL duly
>>> reports it to the user and remains open. While there are probably
>>> ways to make the interpreter itself crash that would come under the
>>> heading of an "exploit", not something that happens in normal
>>> programming.
>>>
>>>> The go to tool for Linux always seems to be a shell script.
>>>> I think that's a mistake, sooner or later as the application
>>>> grows, shell scripts are going to come up short. Much better
>>>> to start out with a real scripting language like Perl or even
>>>> better, Python.
>>>>
>>>> Python and Qt (PyQt) can produce some very attractive GUIs.
>>>> (Works on Windows too.)
>>>
>>> For certain values of "attractive" and it's a lot more work than
>>> displaying the information in an Excel workbook.
>>>
>>> And at the time Python was not available to us.
>>>
>>> Further, I'm still not sure that I can make Python do what VBA is
>>> doing.
>>
>> To each his own, or, if the only tool you have is a hammer, everything
>> looks like a nail,
>
> Well, I think he's working with something pretty complex.
> I think they used what they had and now they're in pretty deep.
> I never liked being tied to one vendors whims, but sometimes it's
> hard to avoid.
>
> In this case, I'd try to keep current on what alternatives I might have.
Our Powers That Be are committed to Microsoft, and at this point we're
damned glad that we were. On Thursday the CEO decreed "everybody but
security, landscaping, and building maintenance will be working from
home starting Monday". So on Monday we were working from home with
damned few hitches, and mostly because the Microsoft ecosystem has all
the tools we needed built into it.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396851 is a reply to message #396850] |
Mon, 20 July 2020 17:42 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>>
>> In this case, I'd try to keep current on what alternatives I might have.
>
> Our Powers That Be are committed to Microsoft, and at this point we're
> damned glad that we were. On Thursday the CEO decreed "everybody but
> security, landscaping, and building maintenance will be working from
> home starting Monday". So on Monday we were working from home with
> damned few hitches, and mostly because the Microsoft ecosystem has all
> the tools we needed built into it.
We've been working from home (the entire company, several thousand)
since the second day of march. And the only MS stuff we use is office360
and a mix of windows, macos and linux from the OS perspective. Most of
use remote into various linux systems to do real work (high-end processor
design). The rest is various source code control systems, wiki's and
web-based bug, document and task tracking - none of which is MS.
We've had no hitches, and have taped out a half dozen chips since.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396854 is a reply to message #396851] |
Mon, 20 July 2020 18:40 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>
>>>
>>> In this case, I'd try to keep current on what alternatives I might have.
>>
>> Our Powers That Be are committed to Microsoft, and at this point we're
>> damned glad that we were. On Thursday the CEO decreed "everybody but
>> security, landscaping, and building maintenance will be working from
>> home starting Monday". So on Monday we were working from home with
>> damned few hitches, and mostly because the Microsoft ecosystem has all
>> the tools we needed built into it.
>
> We've been working from home (the entire company, several thousand)
> since the second day of march. And the only MS stuff we use is office360
> and a mix of windows, macos and linux from the OS perspective. Most of
> use remote into various linux systems to do real work (high-end processor
> design). The rest is various source code control systems, wiki's and
> web-based bug, document and task tracking - none of which is MS.
>
> We've had no hitches, and have taped out a half dozen chips since.
>
I don’t think either of you is going to convince the other.
--
Pete
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396860 is a reply to message #396854] |
Mon, 20 July 2020 20:45 |
|
|
Originally posted by: J. Clarke
On Mon, 20 Jul 2020 15:40:42 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>
>>>>
>>>> In this case, I'd try to keep current on what alternatives I might have.
>>>
>>> Our Powers That Be are committed to Microsoft, and at this point we're
>>> damned glad that we were. On Thursday the CEO decreed "everybody but
>>> security, landscaping, and building maintenance will be working from
>>> home starting Monday". So on Monday we were working from home with
>>> damned few hitches, and mostly because the Microsoft ecosystem has all
>>> the tools we needed built into it.
>>
>> We've been working from home (the entire company, several thousand)
>> since the second day of march. And the only MS stuff we use is office360
>> and a mix of windows, macos and linux from the OS perspective. Most of
>> use remote into various linux systems to do real work (high-end processor
>> design). The rest is various source code control systems, wiki's and
>> web-based bug, document and task tracking - none of which is MS.
>>
>> We've had no hitches, and have taped out a half dozen chips since.
>>
>
> I don’t think either of you is going to convince the other.
There's no convincing needed. We use Windows and Z/OS. He uses
Windows, Linux, and MacOS. Same difference, however he doesn't want
to admit that Windows has been very helpful in the current situation
and I'm happy to do so.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396861 is a reply to message #396850] |
Mon, 20 July 2020 20:45 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>> > J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >
>>>> >> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>> >> wrote:
>>>> >>
>>>> >>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>
>>>> >>>>>
>>>> >>>>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >>>>> MS Office.
>>>> >>>>
>>>> >>>> That's not the problem. You have a GNU APL workspace. You need to
>>>> >>>> set some parameters in the workspace, start it running, detect when it
>>>> >>>> has finished, grab some data out of it, save it to a new location, and
>>>> >>>> if it crashes you have to recognize that it crashed and log the crash.
>>>> >>>>
>>>> >>>> It isn't just scripting the office application, it is using the office
>>>> >>>> application to control another program provided by a different vendor.
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>> Isn't that what shell scripts are designed for? Use the right tool
>>>> >>> for the job.
>>>> >>
>>>> >> OK, so tell us how to, from a shell script, display the list of jobs
>>>> >> you can run, quickly select the ones you want, start one less than the
>>>> >> number of cores in the machine of them, monitor their operation, when
>>>> >> one completes start another, display all of this in the user-friendly
>>>> >> interface, and if one crashes detect that it has crashed and display
>>>> >> appropriate messages.
>>>> >
>>>> > I don't mean to question your requirements or implementation,
>>>> > I'm sure it took a lot of work to accomplish what you have.
>>>> > Just curious about some of these things.
>>>> >
>>>> > The number of CPUs seems trivial, at least on Linux:
>>>> >
>>>> >> lscpu | grep '^CPU(s):'
>>>> > CPU(s): 4
>>>>
>>>> That's not the problem. The problem is having it keep track of the
>>>> number of sessions it has started and that have completed.
>>>>
>>>> > I'm not sure what monitoring would entail, but it's pretty easy to
>>>> > tell if something is running, capture it's PID and use "ps".
>>>>
>>>> Knowing that something is running doesn't help. We know it's running
>>>> because we started it. We need to know when it has completed. APL is
>>>> an environment, you don't do "APL X" and have X run. You do APL, then
>>>> )LOAD X, then Y to start a process, possibly after setting variables
>>>> A, B, and C to control that process, and then it runs until it
>>>> completes or crashes, then it sits there either with an error message
>>>> showing or the cursor sitting there flashing at you. And once the
>>>> process is completed, then we have other steps that need to be
>>>> performed.
>>>>
>>>> > Crashes seem easy to detect and analyze using "abrt".
>>>>
>>>> APL doesn't crash. The program running in APL crashes. APL duly
>>>> reports it to the user and remains open. While there are probably
>>>> ways to make the interpreter itself crash that would come under the
>>>> heading of an "exploit", not something that happens in normal
>>>> programming.
>>>>
>>>> > The go to tool for Linux always seems to be a shell script.
>>>> > I think that's a mistake, sooner or later as the application
>>>> > grows, shell scripts are going to come up short. Much better
>>>> > to start out with a real scripting language like Perl or even
>>>> > better, Python.
>>>> >
>>>> > Python and Qt (PyQt) can produce some very attractive GUIs.
>>>> > (Works on Windows too.)
>>>>
>>>> For certain values of "attractive" and it's a lot more work than
>>>> displaying the information in an Excel workbook.
>>>>
>>>> And at the time Python was not available to us.
>>>>
>>>> Further, I'm still not sure that I can make Python do what VBA is
>>>> doing.
>>>
>>> To each his own, or, if the only tool you have is a hammer, everything
>>> looks like a nail,
>>
>> Well, I think he's working with something pretty complex.
>> I think they used what they had and now they're in pretty deep.
>> I never liked being tied to one vendors whims, but sometimes it's
>> hard to avoid.
>>
>> In this case, I'd try to keep current on what alternatives I might have.
>
> Our Powers That Be are committed to Microsoft, and at this point we're
> damned glad that we were. On Thursday the CEO decreed "everybody but
> security, landscaping, and building maintenance will be working from
> home starting Monday". So on Monday we were working from home with
> damned few hitches, and mostly because the Microsoft ecosystem has all
> the tools we needed built into it.
Just chiming in. You don't need MSFT to use a VPN.
Some things actually work better without MSFT.
I saw lots of people using remote desktops to do their work.
With X windows, you don't need to remote the whole desktop, just
the applications you want to run. You do something like "ssh" to
your desktop at work, then start the application you want to use and
your work desktop opens a window on your home machine.
It can be really cool. At work I might have 5 or 6 files open
with Emacs edits in progress. I go home then ssh, then tell the
running Emacs to create a frame on my home machine. From that
"frame" I can access the same 5 or 6 files as though I never left.
--
Dan Espen
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396862 is a reply to message #396861] |
Mon, 20 July 2020 20:56 |
|
|
Originally posted by: J. Clarke
On Mon, 20 Jul 2020 20:45:46 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> > On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen <dan1espen@gmail.com>
>>>> > wrote:
>>>> >
>>>> >> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>
>>>> >>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>> >>> wrote:
>>>> >>>
>>>> >>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen <dan1espen@gmail.com>
>>>> >>>>> wrote:
>>>> >>>>>
>>>> >>>>
>>>> >>>>>>
>>>> >>>>>> I've never done it but I believe LibreOffice can be scripted similar to
>>>> >>>>>> MS Office.
>>>> >>>>>
>>>> >>>>> That's not the problem. You have a GNU APL workspace. You need to
>>>> >>>>> set some parameters in the workspace, start it running, detect when it
>>>> >>>>> has finished, grab some data out of it, save it to a new location, and
>>>> >>>>> if it crashes you have to recognize that it crashed and log the crash.
>>>> >>>>>
>>>> >>>>> It isn't just scripting the office application, it is using the office
>>>> >>>>> application to control another program provided by a different vendor.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>> Isn't that what shell scripts are designed for? Use the right tool
>>>> >>>> for the job.
>>>> >>>
>>>> >>> OK, so tell us how to, from a shell script, display the list of jobs
>>>> >>> you can run, quickly select the ones you want, start one less than the
>>>> >>> number of cores in the machine of them, monitor their operation, when
>>>> >>> one completes start another, display all of this in the user-friendly
>>>> >>> interface, and if one crashes detect that it has crashed and display
>>>> >>> appropriate messages.
>>>> >>
>>>> >> I don't mean to question your requirements or implementation,
>>>> >> I'm sure it took a lot of work to accomplish what you have.
>>>> >> Just curious about some of these things.
>>>> >>
>>>> >> The number of CPUs seems trivial, at least on Linux:
>>>> >>
>>>> >>> lscpu | grep '^CPU(s):'
>>>> >> CPU(s): 4
>>>> >
>>>> > That's not the problem. The problem is having it keep track of the
>>>> > number of sessions it has started and that have completed.
>>>> >
>>>> >> I'm not sure what monitoring would entail, but it's pretty easy to
>>>> >> tell if something is running, capture it's PID and use "ps".
>>>> >
>>>> > Knowing that something is running doesn't help. We know it's running
>>>> > because we started it. We need to know when it has completed. APL is
>>>> > an environment, you don't do "APL X" and have X run. You do APL, then
>>>> > )LOAD X, then Y to start a process, possibly after setting variables
>>>> > A, B, and C to control that process, and then it runs until it
>>>> > completes or crashes, then it sits there either with an error message
>>>> > showing or the cursor sitting there flashing at you. And once the
>>>> > process is completed, then we have other steps that need to be
>>>> > performed.
>>>> >
>>>> >> Crashes seem easy to detect and analyze using "abrt".
>>>> >
>>>> > APL doesn't crash. The program running in APL crashes. APL duly
>>>> > reports it to the user and remains open. While there are probably
>>>> > ways to make the interpreter itself crash that would come under the
>>>> > heading of an "exploit", not something that happens in normal
>>>> > programming.
>>>> >
>>>> >> The go to tool for Linux always seems to be a shell script.
>>>> >> I think that's a mistake, sooner or later as the application
>>>> >> grows, shell scripts are going to come up short. Much better
>>>> >> to start out with a real scripting language like Perl or even
>>>> >> better, Python.
>>>> >>
>>>> >> Python and Qt (PyQt) can produce some very attractive GUIs.
>>>> >> (Works on Windows too.)
>>>> >
>>>> > For certain values of "attractive" and it's a lot more work than
>>>> > displaying the information in an Excel workbook.
>>>> >
>>>> > And at the time Python was not available to us.
>>>> >
>>>> > Further, I'm still not sure that I can make Python do what VBA is
>>>> > doing.
>>>>
>>>> To each his own, or, if the only tool you have is a hammer, everything
>>>> looks like a nail,
>>>
>>> Well, I think he's working with something pretty complex.
>>> I think they used what they had and now they're in pretty deep.
>>> I never liked being tied to one vendors whims, but sometimes it's
>>> hard to avoid.
>>>
>>> In this case, I'd try to keep current on what alternatives I might have.
>>
>> Our Powers That Be are committed to Microsoft, and at this point we're
>> damned glad that we were. On Thursday the CEO decreed "everybody but
>> security, landscaping, and building maintenance will be working from
>> home starting Monday". So on Monday we were working from home with
>> damned few hitches, and mostly because the Microsoft ecosystem has all
>> the tools we needed built into it.
>
> Just chiming in. You don't need MSFT to use a VPN.
> Some things actually work better without MSFT.
Who said anything about a VPN? You really should find out what other
people are doing before you tell them how to do it better. In point
of fact our VPN is provided by Cisco.
> I saw lots of people using remote desktops to do their work.
> With X windows, you don't need to remote the whole desktop, just
> the applications you want to run. You do something like "ssh" to
> your desktop at work, then start the application you want to use and
> your work desktop opens a window on your home machine.
Same with RDP except no SSH needed. But who needs remote desktops?
> It can be really cool. At work I might have 5 or 6 files open
> with Emacs edits in progress. I go home then ssh, then tell the
> running Emacs to create a frame on my home machine. From that
> "frame" I can access the same 5 or 6 files as though I never left.
I bring my work computer home. But RDP does that just fine without
being dependent on Emacs. And I don't have to tell the remote machine
to "create a frame".
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396864 is a reply to message #396862] |
Mon, 20 July 2020 23:09 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Mon, 20 Jul 2020 20:45:46 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> J. Clarke <jclarke.873638@gmail.com> writes:
>>
>>> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
>>> wrote:
>>>
>>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>>
>>>> > J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> >> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen
>>>> >> <dan1espen@gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>
>>>> >>>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott
>>>> >>>> Lurndal)
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen
>>>> >>>>>> <dan1espen@gmail.com>
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>>>>
>>>> >>>>>>> I've never done it but I believe LibreOffice can be scripted
>>>> >>>>>>> similar to MS Office.
>>>> >>>>>>
>>>> >>>>>> That's not the problem. You have a GNU APL workspace. You
>>>> >>>>>> need to set some parameters in the workspace, start it
>>>> >>>>>> running, detect when it has finished, grab some data out of
>>>> >>>>>> it, save it to a new location, and if it crashes you have to
>>>> >>>>>> recognize that it crashed and log the crash.
>>>> >>>>>>
>>>> >>>>>> It isn't just scripting the office application, it is using
>>>> >>>>>> the office application to control another program provided by
>>>> >>>>>> a different vendor.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> Isn't that what shell scripts are designed for? Use the right
>>>> >>>>> tool for the job.
>>>> >>>>
>>>> >>>> OK, so tell us how to, from a shell script, display the list of
>>>> >>>> jobs you can run, quickly select the ones you want, start one
>>>> >>>> less than the number of cores in the machine of them, monitor
>>>> >>>> their operation, when one completes start another, display all
>>>> >>>> of this in the user-friendly interface, and if one crashes
>>>> >>>> detect that it has crashed and display appropriate messages.
>>>> >>>
>>>> >>> I don't mean to question your requirements or implementation,
>>>> >>> I'm sure it took a lot of work to accomplish what you have.
>>>> >>> Just curious about some of these things.
>>>> >>>
>>>> >>> The number of CPUs seems trivial, at least on Linux:
>>>> >>>
>>>> >>> lscpu | grep '^CPU(s):'
>>>> >>> CPU(s): 4
>>>> >>
>>>> >> That's not the problem. The problem is having it keep track of
>>>> >> the number of sessions it has started and that have completed.
>>>> >>
>>>> >>> I'm not sure what monitoring would entail, but it's pretty easy
>>>> >>> to tell if something is running, capture it's PID and use "ps".
>>>> >>
>>>> >> Knowing that something is running doesn't help. We know it's
>>>> >> running because we started it. We need to know when it has
>>>> >> completed. APL is an environment, you don't do "APL X" and have
>>>> >> X run. You do APL, then )LOAD X, then Y to start a process,
>>>> >> possibly after setting variables A, B, and C to control that
>>>> >> process, and then it runs until it completes or crashes, then it
>>>> >> sits there either with an error message showing or the cursor
>>>> >> sitting there flashing at you. And once the process is
>>>> >> completed, then we have other steps that need to be performed.
>>>> >>
>>>> >>> Crashes seem easy to detect and analyze using "abrt".
>>>> >>
>>>> >> APL doesn't crash. The program running in APL crashes. APL duly
>>>> >> reports it to the user and remains open. While there are
>>>> >> probably ways to make the interpreter itself crash that would
>>>> >> come under the heading of an "exploit", not something that
>>>> >> happens in normal programming.
>>>> >>
>>>> >>> The go to tool for Linux always seems to be a shell script. I
>>>> >>> think that's a mistake, sooner or later as the application
>>>> >>> grows, shell scripts are going to come up short. Much better to
>>>> >>> start out with a real scripting language like Perl or even
>>>> >>> better, Python.
>>>> >>>
>>>> >>> Python and Qt (PyQt) can produce some very attractive GUIs.
>>>> >>> (Works on Windows too.)
>>>> >>
>>>> >> For certain values of "attractive" and it's a lot more work than
>>>> >> displaying the information in an Excel workbook.
>>>> >>
>>>> >> And at the time Python was not available to us.
>>>> >>
>>>> >> Further, I'm still not sure that I can make Python do what VBA is
>>>> >> doing.
>>>> >
>>>> > To each his own, or, if the only tool you have is a hammer,
>>>> > everything looks like a nail,
>>>>
>>>> Well, I think he's working with something pretty complex. I think
>>>> they used what they had and now they're in pretty deep. I never
>>>> liked being tied to one vendors whims, but sometimes it's hard to
>>>> avoid.
>>>>
>>>> In this case, I'd try to keep current on what alternatives I might
>>>> have.
>>>
>>> Our Powers That Be are committed to Microsoft, and at this point
>>> we're damned glad that we were. On Thursday the CEO decreed
>>> "everybody but security, landscaping, and building maintenance will
>>> be working from home starting Monday". So on Monday we were working
>>> from home with damned few hitches, and mostly because the Microsoft
>>> ecosystem has all the tools we needed built into it.
>>
>> Just chiming in. You don't need MSFT to use a VPN. Some things
>> actually work better without MSFT.
>
> Who said anything about a VPN? You really should find out what other
> people are doing before you tell them how to do it better. In point
> of fact our VPN is provided by Cisco.
Well, I'm confused. You talked about working from home. I assumed you
meant the VPN. Aha, I think you were talking about RDP.
X windows is always a network type protocol so all I needed to work
remote was the VPN. At work we were always connecting to other machines
and running stuff there using X Windows.
I had no idea that RDP let you redirect individual windows to another
desktop. RDP stands for "Remote Desktop Protocol'.
I've never used RDP. For a while I had to use Citrix to get get a
windows desktop on a server to do a time sheet. I think RDP did the
same thing at one time.
Okay, just read a bit about RDP. It looks like MSFT added "Seamless
Windows" in 2006:
Seamless Windows: remote applications can run on a client machine that
is served by a Remote Desktop connection.
I just read the Wikipedia page on RDP. That's pretty cool software. It
even includes audio redirection, file sharing and USB redirection.
There are also RDP clients for Linux.
>> I saw lots of people using remote desktops to do their work. With X
>> windows, you don't need to remote the whole desktop, just the
>> applications you want to run. You do something like "ssh" to your
>> desktop at work, then start the application you want to use and your
>> work desktop opens a window on your home machine.
>
> Same with RDP except no SSH needed. But who needs remote desktops?
I think you misunderstood what I meant when I described ssh and then
creating a frame. In fact I created an Emacs window on my home machine
by hitting a single key. Scripts did all the dirty work.
It was pretty cool to connect to my existing edit sessions. More than
once I noticed I hadn't saved my latest changes before leaving work.
>> It can be really cool. At work I might have 5 or 6 files open with
>> Emacs edits in progress. I go home then ssh, then tell the running
>> Emacs to create a frame on my home machine. From that "frame" I can
>> access the same 5 or 6 files as though I never left.
>
> I bring my work computer home. But RDP does that just fine without
> being dependent on Emacs. And I don't have to tell the remote machine
> to "create a frame".
Emacs just happens to be the tool I was using. I could have been using
any editor or a terminal.
Eventually they forced me to work on a Windows machine so I had a laptop
to take home. i bought a KVM switch so I could continue to use my
mechanical keyboard and large monitor.
--
Dan Espen
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396866 is a reply to message #396864] |
Tue, 21 July 2020 00:15 |
|
|
Originally posted by: J. Clarke
On Mon, 20 Jul 2020 23:09:24 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Mon, 20 Jul 2020 20:45:46 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>
>>>> On Mon, 20 Jul 2020 10:31:30 -0400, Dan Espen <dan1espen@gmail.com>
>>>> wrote:
>>>>
>>>> >Peter Flass <peter_flass@yahoo.com> writes:
>>>> >
>>>> >> J. Clarke <jclarke.873638@gmail.com> wrote:
>>>> >>> On Mon, 20 Jul 2020 08:47:44 -0400, Dan Espen
>>>> >>> <dan1espen@gmail.com>
>>>> >>> wrote:
>>>> >>>
>>>> >>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>>
>>>> >>>>> On Fri, 26 Jun 2020 14:22:12 GMT, scott@slp53.sl.home (Scott
>>>> >>>>> Lurndal)
>>>> >>>>> wrote:
>>>> >>>>>
>>>> >>>>>> J. Clarke <jclarke.873638@gmail.com> writes:
>>>> >>>>>>> On Thu, 25 Jun 2020 20:02:00 -0400, Dan Espen
>>>> >>>>>>> <dan1espen@gmail.com>
>>>> >>>>>>> wrote:
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>> I've never done it but I believe LibreOffice can be scripted
>>>> >>>>>>>> similar to MS Office.
>>>> >>>>>>>
>>>> >>>>>>> That's not the problem. You have a GNU APL workspace. You
>>>> >>>>>>> need to set some parameters in the workspace, start it
>>>> >>>>>>> running, detect when it has finished, grab some data out of
>>>> >>>>>>> it, save it to a new location, and if it crashes you have to
>>>> >>>>>>> recognize that it crashed and log the crash.
>>>> >>>>>>>
>>>> >>>>>>> It isn't just scripting the office application, it is using
>>>> >>>>>>> the office application to control another program provided by
>>>> >>>>>>> a different vendor.
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>> Isn't that what shell scripts are designed for? Use the right
>>>> >>>>>> tool for the job.
>>>> >>>>>
>>>> >>>>> OK, so tell us how to, from a shell script, display the list of
>>>> >>>>> jobs you can run, quickly select the ones you want, start one
>>>> >>>>> less than the number of cores in the machine of them, monitor
>>>> >>>>> their operation, when one completes start another, display all
>>>> >>>>> of this in the user-friendly interface, and if one crashes
>>>> >>>>> detect that it has crashed and display appropriate messages.
>>>> >>>>
>>>> >>>> I don't mean to question your requirements or implementation,
>>>> >>>> I'm sure it took a lot of work to accomplish what you have.
>>>> >>>> Just curious about some of these things.
>>>> >>>>
>>>> >>>> The number of CPUs seems trivial, at least on Linux:
>>>> >>>>
>>>> >>>> lscpu | grep '^CPU(s):'
>>>> >>>> CPU(s): 4
>>>> >>>
>>>> >>> That's not the problem. The problem is having it keep track of
>>>> >>> the number of sessions it has started and that have completed.
>>>> >>>
>>>> >>>> I'm not sure what monitoring would entail, but it's pretty easy
>>>> >>>> to tell if something is running, capture it's PID and use "ps".
>>>> >>>
>>>> >>> Knowing that something is running doesn't help. We know it's
>>>> >>> running because we started it. We need to know when it has
>>>> >>> completed. APL is an environment, you don't do "APL X" and have
>>>> >>> X run. You do APL, then )LOAD X, then Y to start a process,
>>>> >>> possibly after setting variables A, B, and C to control that
>>>> >>> process, and then it runs until it completes or crashes, then it
>>>> >>> sits there either with an error message showing or the cursor
>>>> >>> sitting there flashing at you. And once the process is
>>>> >>> completed, then we have other steps that need to be performed.
>>>> >>>
>>>> >>>> Crashes seem easy to detect and analyze using "abrt".
>>>> >>>
>>>> >>> APL doesn't crash. The program running in APL crashes. APL duly
>>>> >>> reports it to the user and remains open. While there are
>>>> >>> probably ways to make the interpreter itself crash that would
>>>> >>> come under the heading of an "exploit", not something that
>>>> >>> happens in normal programming.
>>>> >>>
>>>> >>>> The go to tool for Linux always seems to be a shell script. I
>>>> >>>> think that's a mistake, sooner or later as the application
>>>> >>>> grows, shell scripts are going to come up short. Much better to
>>>> >>>> start out with a real scripting language like Perl or even
>>>> >>>> better, Python.
>>>> >>>>
>>>> >>>> Python and Qt (PyQt) can produce some very attractive GUIs.
>>>> >>>> (Works on Windows too.)
>>>> >>>
>>>> >>> For certain values of "attractive" and it's a lot more work than
>>>> >>> displaying the information in an Excel workbook.
>>>> >>>
>>>> >>> And at the time Python was not available to us.
>>>> >>>
>>>> >>> Further, I'm still not sure that I can make Python do what VBA is
>>>> >>> doing.
>>>> >>
>>>> >> To each his own, or, if the only tool you have is a hammer,
>>>> >> everything looks like a nail,
>>>> >
>>>> >Well, I think he's working with something pretty complex. I think
>>>> >they used what they had and now they're in pretty deep. I never
>>>> >liked being tied to one vendors whims, but sometimes it's hard to
>>>> >avoid.
>>>> >
>>>> >In this case, I'd try to keep current on what alternatives I might
>>>> >have.
>>>>
>>>> Our Powers That Be are committed to Microsoft, and at this point
>>>> we're damned glad that we were. On Thursday the CEO decreed
>>>> "everybody but security, landscaping, and building maintenance will
>>>> be working from home starting Monday". So on Monday we were working
>>>> from home with damned few hitches, and mostly because the Microsoft
>>>> ecosystem has all the tools we needed built into it.
>>>
>>> Just chiming in. You don't need MSFT to use a VPN. Some things
>>> actually work better without MSFT.
>>
>> Who said anything about a VPN? You really should find out what other
>> people are doing before you tell them how to do it better. In point
>> of fact our VPN is provided by Cisco.
>
> Well, I'm confused. You talked about working from home. I assumed you
> meant the VPN. Aha, I think you were talking about RDP.
Wasn't talking about that either.
> X windows is always a network type protocol so all I needed to work
> remote was the VPN. At work we were always connecting to other machines
> and running stuff there using X Windows.
>
> I had no idea that RDP let you redirect individual windows to another
> desktop. RDP stands for "Remote Desktop Protocol'.
>
> I've never used RDP. For a while I had to use Citrix to get get a
> windows desktop on a server to do a time sheet. I think RDP did the
> same thing at one time.
>
> Okay, just read a bit about RDP. It looks like MSFT added "Seamless
> Windows" in 2006:
>
> Seamless Windows: remote applications can run on a client machine that
> is served by a Remote Desktop connection.
>
> I just read the Wikipedia page on RDP. That's pretty cool software. It
> even includes audio redirection, file sharing and USB redirection.
> There are also RDP clients for Linux.
Yep, but wasn't what I was talking about. We mainly use it if we're
doing something that involves large files on network shares, where
transfer via the Internet is slow.
>>> I saw lots of people using remote desktops to do their work. With X
>>> windows, you don't need to remote the whole desktop, just the
>>> applications you want to run. You do something like "ssh" to your
>>> desktop at work, then start the application you want to use and your
>>> work desktop opens a window on your home machine.
>>
>> Same with RDP except no SSH needed. But who needs remote desktops?
>
> I think you misunderstood what I meant when I described ssh and then
> creating a frame. In fact I created an Emacs window on my home machine
> by hitting a single key. Scripts did all the dirty work.
>
> It was pretty cool to connect to my existing edit sessions. More than
> once I noticed I hadn't saved my latest changes before leaving work.
I still don't get the point. I don't normally log into a machine at
work from home, I have my work machine at home. When I close the lid,
the next time I open it everything is exactly as it was when I closed
the lid, unless the IT department forced a reboot in the interim.
But if I am logged into a work machine, if I disconnect, the next time
I reconnect the screen is exactly as I left it, again unless IT
rebooted it or someone else logged into it and forced my session to
close.
>>> It can be really cool. At work I might have 5 or 6 files open with
>>> Emacs edits in progress. I go home then ssh, then tell the running
>>> Emacs to create a frame on my home machine. From that "frame" I can
>>> access the same 5 or 6 files as though I never left.
>>
>> I bring my work computer home. But RDP does that just fine without
>> being dependent on Emacs. And I don't have to tell the remote machine
>> to "create a frame".
>
> Emacs just happens to be the tool I was using. I could have been using
> any editor or a terminal.
Remote access isn't a function of an editor or terminal for us.
> Eventually they forced me to work on a Windows machine so I had a laptop
> to take home. i bought a KVM switch so I could continue to use my
> mechanical keyboard and large monitor.
My monitor is 49 inches and 4K, one cable moves the keyboard and mouse
and two clicks on the remote move the screen.
For us the laptop is a third screen most of the time.
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396870 is a reply to message #396836] |
Tue, 21 July 2020 04:15 |
Jorgen Grahn
Messages: 606
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 2020-07-20, Dan Espen wrote:
....
> The go to tool for Linux always seems to be a shell script.
> I think that's a mistake, sooner or later as the application
> grows, shell scripts are going to come up short. Much better
> to start out with a real scripting language like Perl or even
> better, Python.
I disagree -- many tasks are solved elegantly in shell scripts (bash
at least) but only clumsily in Python. (For other tasks it's the other
way around of course, but I prefer the shell for handling files, and
streams of data between external commands.)
My bosses tend to agree with you though, so I've often done typical
shell tasks in Python. (Perl is not an option for them.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
|
|
|
| Re: MicroSnot just sneezed all over my PC [message #396874 is a reply to message #396870] |
Tue, 21 July 2020 09:23 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Mon, 2020-07-20, Dan Espen wrote:
> ...
>> The go to tool for Linux always seems to be a shell script.
>> I think that's a mistake, sooner or later as the application
>> grows, shell scripts are going to come up short. Much better
>> to start out with a real scripting language like Perl or even
>> better, Python.
>
> I disagree -- many tasks are solved elegantly in shell scripts (bash
> at least) but only clumsily in Python. (For other tasks it's the other
> way around of course, but I prefer the shell for handling files, and
> streams of data between external commands.)
>
> My bosses tend to agree with you though, so I've often done typical
> shell tasks in Python. (Perl is not an option for them.)
I agree that shell often provides a nice simple solution for small
problems.
What I found is that simple solutions have a way of growing to larger
and larger solutions. Then shell scripting becomes harder and harder
to manage.
Once was given dozens of awk files and shell scripts that no one else
could find their way through. Converted it all to one Perl script
and the mess became manageable.
When I coded in Perl I used constructs that made it look very much
like C.
Of course, in today's world, I'd use Python.
--
Dan Espen
|
|
|
|
Members
Search
Help
Register
Login
Home
