Multiple Python processes run and no workflow result

[obstschale]

Hi Guys,

 

I recently published my NSC workflow to convert numbers. But I have encountered a problem.

 

If I try to convert a number using convert it will run the following script using

 

 

python convertNumber.py {query} 2>&1 | tee nsc.log

 

The problem is sometimes the number gets converted and everything works fine and the sometimes it is not working. Either Alfred wants to search the given string in Google or the "Please Wait" subtext will be displayed. Anyhow, whenever it is not working several Python process will start and will occupy fully the CPU.

 

As you see above I already create a log file. If the script run perfectly the log file will contain the XML, thats fine. But if it isn't working there is no output.

 

Do you have any idea why it isn't working?

 

PS: All other script I use in this workflow are working just fine.

 

[jdfwarrior]

Hi Guys,

 

I recently published my NSC workflow to convert numbers. But I have encountered a problem.

 

If I try to convert a number using convert it will run the following script using

 

 

python convertNumber.py {query} 2>&1 | tee nsc.log

 

The problem is sometimes the number gets converted and everything works fine and the sometimes it is not working. Either Alfred wants to search the given string in Google or the "Please Wait" subtext will be displayed. Anyhow, whenever it is not working several Python process will start and will occupy fully the CPU.

 

As you see above I already create a log file. If the script run perfectly the log file will contain the XML, thats fine. But if it isn't working there is no output.

 

Do you have any idea why it isn't working?

 

PS: All other script I use in this workflow are working just fine.

 

Sounds as if you are using a script filter. Typically when you get this behavior from a script filter it's the result of the script either:

 

1. The script isn't finishing. From the sound of yours maxing the processor, something sounds like its going crazy in your code.

2. The is an error in the XML

3. There was some form of error, warning, or other text printed out with the XML. Since Alfred uses everything the script outputs to generate the feedback, anything additional to the XML will cause errors.

4. No output was provided.

[obstschale]

First of all thx for your help David,

 

a) I already assumed that my script is not finishing and that it has problems if not all 3 numbers were given. Therefore I check in my script if 3 parameters are given. If not I will output an valid XML error message which looks like this: http://d.pr/i/6np5

I checked my XML carefully and if I run it in the terminal the xml looks good and nothing is messed up.

c) I'm not sure about that that according to be, I tested it in the terminal and it looks good

d) yes, otherwise it would be in my log file, wouldn't it?

[jdfwarrior]

First of all thx for your help David,

 

a) I already assumed that my script is not finishing and that it has problems if not all 3 numbers were given. Therefore I check in my script if 3 parameters are given. If not I will output an valid XML error message which looks like this: http://d.pr/i/6np5

I checked my XML carefully and if I run it in the terminal the xml looks good and nothing is messed up.

c) I'm not sure about that that according to be, I tested it in the terminal and it looks good

d) yes, otherwise it would be in my log file, wouldn't it?

 

I would suggest passing your XML through a validator of some sorts to ensure that it is correct or, rather than using something like lxml, try using phyllissteins python workflow library, found here. He's got a lot of useful functionality already created that will make creating workflows and generating results much easier.

[obstschale]

I tried so many possibilities but I can not solve the problem. I use now alp to generate the xml statement but that wasn't the problem. But I figured out that  the workflow works fine as long as the base (third argument) is less than 10. As soon as the new base has two digits Alfred will call the python script but the process does not end. But if I kill the process the correct xml statement will be printed in my log file. Totally weird!

 

This is my python script and it works in the terminal but not with alfred. The process won't end if it tries to calculate the new number (lin 39). So think there is a problem in my int2base function. But why is it working in the terminal and with alfred upto number 9 as base?

 

#!/usr/bin/env python

""" Arguments
	sys.argv[0] = filename
	sys.argv[1] = number
	sys.argv[2] = source
	sys.argv[3] = destination
"""

import sys
import alp
import string
digs = string.digits + string.lowercase


def int2base(x, base):
  if x < 0: sign = -1
  elif x==0: return '0'
  else: sign = 1
  x *= sign
  digits = []
  while x:
    digits.append(digs[x % base])
    x /= base
  if sign < 0:
    digits.append('-')
  digits.reverse()
  return ''.join(digits)


if (len(sys.argv) == 4):
	# calculate integer first
	decimal = int(sys.argv[1], int(sys.argv[2]))
	# create dictionary to create xml from it
	decimalDic = dict(title=str(decimal), subtitle="Decimal", uid="decimal", valid=True, arg=str(decimal), icon="icons/decimal.png")
	d = alp.Item(**decimalDic)

	# calculate new number
	conv = int2base(decimal, int(sys.argv[3]))
	# create dictionary to create xml from it
	convertDic = dict(title=conv, subtitle="Number to base " + str(sys.argv[3]), uid="conv", valid=True, arg=conv)
	c = alp.Item(**convertDic)

	itemsList = [d, c]
	alp.feedback(itemsList)

else:
	errorDic = dict(title="Make sure to pass 3 numbers", subtitle="for help type \"nsc help\"", uid="error", valid=False, arg="error")
	error = alp.Item(**errorDic)
	alp.feedback(error)

 

I call the script in alfred like this:

python convertNumber.py {query} 2>&1 | tee nsc.log

 

 

[obstschale]

I got a tip on GitHub and could solve the problem.

 

 

NSC has a problem converting a number into base 1. That makes no sense and therefore NSC stucked in an infinite loop for all bases from 10 to 19.

 

I fixed it in v2.01

 

#close