[Ironpython-users] IronPython, Daily Digest 1/10/2013

[no_reply at codeplex.com]

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] GetEncodings called in StringOps.cs fails using Mono
2. [New issue] DAQMX Code which works fine with "Python 2.7.3" giving issue with IRONPYTHON
3. [New issue] DAQmxCreateDOChan() code which works in python does not works with ironpython
4. [New issue] Importing & reloading module leaks memory

----------------------------------------------

ISSUES

1. [New comment] GetEncodings called in StringOps.cs fails using Mono
http://ironpython.codeplex.com/workitem/33646
User jdhardy has commented on the issue:

"If you do get it working, a github pull request or a patch on here is the easiest way for me to incorporate the fix."-----------------

2. [New issue] DAQMX Code which works fine with "Python 2.7.3" giving issue with IRONPYTHON
http://ironpython.codeplex.com/workitem/33648
User suma_putani has proposed the issue:

"Hello,

We are using National Instruments (NI) Driver 6501 for switch Testing. Below is the code which is written in Python 2.7.3. The same code does not work with Iron Python. 


import ctypes
import numpy
import sys
import os 
import time

#------------- Functions ------------------------------------------

# Error Writing module.
def WriteError(ErrorCode):
	if ErrorCode < 0:
		BufSize = 1000
		Buf = ctypes.create_string_buffer('\000' * BufSize)
		nidaq.DAQmxGetErrorString(ErrorCode, ctypes.byref(Buf), BufSize)
		raise RuntimeError('nidaq call failed with error %d: %s'%(ErrorCode,repr(Buf.value)))
	return ErrorCode

#------------- Functions ------------------------------

int32 = ctypes.c_long
uint8 = ctypes.c_uint8
uInt32 = ctypes.c_ulong
uInt64 = ctypes.c_ulonglong
float64 = ctypes.c_double
TaskHandle = uInt32
Port = uInt32
ChannelValue = Port(0x77)

# load DLL
nidaq = ctypes.windll.nicaiu

DAQmx_Val_GroupByChannel = 0
DAQmx_Val_ChanForAllLines = 1

taskHandle0 = TaskHandle(0)
CreateChan = "Dev5/port0/line7:0"

Data = numpy.zeros((8,),dtype=numpy.uint8)
nidaq.DAQmxCreateTask("",ctypes.byref(taskHandle0))
Result = WriteError(nidaq.DAQmxCreateDOChan(taskHandle0,CreateChan,"", DAQmx_Val_ChanForAllLines))
Result = WriteError(nidaq.DAQmxWriteDigitalU32(taskHandle0,1,1,float64(10.0),DAQmx_Val_GroupByChannel, ctypes.byref(ChannelValue),None,None))
Result = WriteError(nidaq.DAQmxReadDigitalLines(taskHandle0,-1,float64(10.0),DAQmx_Val_GroupByChannel,Data.ctypes.data, 8,None,None,None))

print Data
str1 = Data[0:8]
str2 = ""
for i in str1:
        str2 = str2+str(i)
print hex(int(str2,2))

#time.sleep(10)
nidaq.DAQmxStopTask(taskHandle0)
nidaq.DAQmxClearTask(taskHandle0)

---------------------------------------------------------------------------------------
Output in Python 2.7.3 :
[0 1 1 1 0 1 1 1]
0x77

Output in IronPython 2.7.3 :

C:\IronPython 2.7>IPY read.py

Traceback (most recent call last):
  File "read.py", line 33, in 
  File "read.py", line 12, in WriteError
RuntimeError: nidaq call failed with error -200170: 'Physical channel specified
does not exist on this device.\n\nRefer to the documentation for channels availa
ble on this device.'
	
I don't think it is something to do with Physical Channel as the same code works fine for Python 2.7.3. 
Let me know if this is a Iron Python Issue. If so how to resolve it.

Or If I need to refer to Ctypes variable in a different way."-----------------

3. [New issue] DAQmxCreateDOChan() code which works in python does not works with ironpython
http://ironpython.codeplex.com/workitem/33649
User jayprakash has proposed the issue:

"My this line of code works well when i execute it in python:
nidaq.DAQmxCreateDOChan(taskHandle0,CreateChan,"", DAQmx_Val_ChanForAllLines)

But when i execute the same come in ironpython i get an error code -200170(physical channel specified does not exist on this device)

I am clueless about how to solve this issue."-----------------

4. [New issue] Importing & reloading module leaks memory
http://ironpython.codeplex.com/workitem/33650
User ripedbone has proposed the issue:

"When I'm importing a module with __import__ and then reloading it with reload, it seems to leave the whole module into memory.

Here's a simple example code how to reproduce this. It's just importing and reloading a module which has two classes and the other one has a long list of methods just to get the module size bigger.

Garbage collection doesn't do anything with the memory until memory usage is ~600 Mb, which is quite strange. Furthermore, this maximum memory size is directly linked to the size of the imported module. Does anyone have an idea why? Or should I do the importing and reloading differently?

Just run attached import_test.py to reproduce the problem."
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20130111/ae25d6b9/attachment.html>