Re: Python 3.6 causes error, python 3.5 does not.

2018-05-21 Thread Jim

On 05/20/2018 02:03 PM, Jim wrote:

Mint 18
Libreoffice 5.1.6.2
Python 3.6.5 in one virtual environment
Python 3.5.2 in another

I am writing a script that uses pyautogui to get some data and paste it 
into a Libreoffice calc file, there by bypassing the complexity of uno.


The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
opens the calc file then pops up a dialog saying "std::bad_alloc". There 
are no relevant errors in the terminal. At this point I must reload the 
file and let calc recover it. I googled "std::bad_alloc" but didn'


This is the portion of the code that causes the error:

import pyautogui
import subprocess
import threading
import time

LONG_ENOUGH = 5

class LO():
     '''Manipulate libreoffice not using UNO'''
     def __init__(self):
     self.filename = 
'/home/jfb/Documents/Financial/Investing/Stocks.ods'
     opener = threading.Thread(target=self.open_it, 
args=(self.filename,))

     opener.start()
     time.sleep(5) #LONG_ENOUGH)
     #self.manipulate_LO()

     #Open and work with libreoffice
     def open_it(self, filename):
     #subprocess.call(["libreoffice", filename])
     subprocess.run(["libreoffice", filename])

lo = LO()

To complicate matters not all .ods files show this problem. I ran some 
tests. Two of my .ods files are effected but a couple of others are not. 
A new test file I created is not effected.


I don't know if I have a Libreoffice problem, file corruption or a 
Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
reason I decided to ask here first.


Regards,  Jim



To follow up. I just discovered the error only happens if I start the 
script from inside the 3.6 virtual environment. If I start it from 
another terminal with the full path to the 3.6 VE and the script it runs 
without error.


Regards,  Jim

--
https://mail.python.org/mailman/listinfo/python-list


Re: Python 3.6 causes error, python 3.5 does not.

2018-05-21 Thread dieter
Jim  writes:
> ...
> The problem is it runs fine if I use python 3.5. If I use python 3.6
> it opens the calc file then pops up a dialog saying
> "std::bad_alloc".

This looks like a C++ error message -- maybe from "calc".

It also looks quite severe (some memory allocation problem).
Therefore, it does not look likely that we can help you via this list.
I would use a C/C++ level debugger, to find out whether the message
come from the Python side (quite unlikely in my opinion) or from
"libreoffice".

-- 
https://mail.python.org/mailman/listinfo/python-list


Python 3.6 causes error, python 3.5 does not.

2018-05-20 Thread Jim

Mint 18
Libreoffice 5.1.6.2
Python 3.6.5 in one virtual environment
Python 3.5.2 in another

I am writing a script that uses pyautogui to get some data and paste it 
into a Libreoffice calc file, there by bypassing the complexity of uno.


The problem is it runs fine if I use python 3.5. If I use python 3.6 it 
opens the calc file then pops up a dialog saying "std::bad_alloc". There 
are no relevant errors in the terminal. At this point I must reload the 
file and let calc recover it. I googled "std::bad_alloc" but didn'


This is the portion of the code that causes the error:

import pyautogui
import subprocess
import threading
import time

LONG_ENOUGH = 5

class LO():
'''Manipulate libreoffice not using UNO'''
def __init__(self):
self.filename = 
'/home/jfb/Documents/Financial/Investing/Stocks.ods'
opener = threading.Thread(target=self.open_it, 
args=(self.filename,))

opener.start()
time.sleep(5) #LONG_ENOUGH)
#self.manipulate_LO()

#Open and work with libreoffice
def open_it(self, filename):
#subprocess.call(["libreoffice", filename])
subprocess.run(["libreoffice", filename])

lo = LO()

To complicate matters not all .ods files show this problem. I ran some 
tests. Two of my .ods files are effected but a couple of others are not. 
A new test file I created is not effected.


I don't know if I have a Libreoffice problem, file corruption or a 
Python problem. The fact that 3.6 gives an error but 3.5 does not is the 
reason I decided to ask here first.


Regards,  Jim

--
https://mail.python.org/mailman/listinfo/python-list