search

Qucs / qucs

Qucs Project official mirror
http://qucs.sourceforge.net/
GNU General Public License v2.0
1.16k stars 213 forks source link

qucs#936 bug corrected, tested with python3 #971

Closed oxmon-2500 closed 4 years ago

oxmon-2500 commented 4 years ago

python_01 python_03

in3otd commented 4 years ago

could you please check if this is related to this post; - see fix at the end of the thread . I forgot about opening an issue/PR about that... IIRC, there the issue was that shape should be an int or a list of int but it was actually an ndarray.

oxmon-2500 commented 4 years ago

could you please check if this is related to this post; - see fix at the end of the thread . I forgot about opening an issue/PR about that... IIRC, there the issue was that shape should be an int or a list of int but it was actually an ndarray.

The fix at the end of the thread was already implemented. I inserted the fix proposed in qucs#936 and make python3 migration. I tested it only with the files from the same directory which was OK.

in3otd commented 4 years ago

um, it seems to me that the fix in that thread is not in here, line 31 was not changed. The fix done here in the end is similar, as it makes sure that shape contains only int but I don't see why it has to be a numpy array instead of a list.

I see that after restarting Travis is passing now, no idea where the problem seen before came from.

oxmon-2500 commented 4 years ago

I thought the prefix np. is the change, it was to quick conclusion - tnx for accurate review. But I tried 

 shape.append(int(g[2]))

and it produces on other place:

shape = shape[::-1].astype('int')
AttributeError: 'list' object has no attribute 'astype'

In the current version it works fine with the python3 and produces a nice chart. Probably it lies on the newly version of numpy .

Regarding Travis, its probably somewhere a non-multithread-able procedure and it may come again