From no_reply at codeplex.com Sun Dec 1 09:19:33 2013 From: no_reply at codeplex.com (CodePlex) Date: 1 Dec 2013 00:19:33 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 11/30/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] time.strftime returns incorrect date 2. [New comment] Trivial: datetime.date.strftime does not show good data 3. [New comment] strftime("%Y-%A-%B") returns unicode on non-English machine 4. [New comment] time.strptime works when it shouldn't 5. [New issue] System.Decimal string.format issue ---------------------------------------------- ISSUES 1. [New comment] time.strftime returns incorrect date http://ironpython.codeplex.com/workitem/19257 User paweljasinski has commented on the issue: "

can not reproduce in 2.7.4

"----------------- 2. [New comment] Trivial: datetime.date.strftime does not show good data http://ironpython.codeplex.com/workitem/23671 User paweljasinski has commented on the issue: "

can not reproduce in 2.7.4

"----------------- 3. [New comment] strftime("%Y-%A-%B") returns unicode on non-English machine http://ironpython.codeplex.com/workitem/23965 User paweljasinski has commented on the issue: "

I believe this is not a valid bug.
%a, %b, %A and %B are locale dependent and can produce unicode (http://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior).
Also in the second test case, I see no reason why time should be included neither understand why year should be reordered.

"----------------- 4. [New comment] time.strptime works when it shouldn't http://ironpython.codeplex.com/workitem/30047 User paweljasinski has commented on the issue: "

it looks like an easy fix, but I maybe missing something:
The offending code from time.cs:
```
if (!StringUtils.TryParseDateTimeExact(@string,
String.Join("", formats),
PythonLocale.GetLocaleInfo(context).Time.DateTimeFormat,
DateTimeStyles.AllowWhiteSpaces | DateTimeStyles.NoCurrentDateDefault,
out res)) {
// If TryParseExact fails, fall back to DateTime.Parse which does a better job in some cases...
res = DateTime.Parse(@string, PythonLocale.GetLocaleInfo(context).Time.DateTimeFormat);
}
```
If the exact parse fails, second attempt is made without(!) consulting any format string.
I think if exact parse fails, it should simply fail.

"----------------- 5. [New issue] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User davcar has proposed the issue: "When I run the following program, I cannot format a System.Decimal. I have an integration with a .NET library that returns a decimal type that I need to display in the ironpython script. import System f = 1.42742 d = System.Decimal(f) print "{}".format(d) # 1.42742 print "{:,.2f}".format(f) # 1.43 print "{:,.2f}".format(d * 1.0) # 1.43 print "{:,.2f}".format(d) # 12f WRONG " ---------------------------------------------- ---------------------------------------------- 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: From duane.mccollum at comcast.net Mon Dec 2 10:08:56 2013 From: duane.mccollum at comcast.net (duane.mccollum at comcast.net) Date: Mon, 2 Dec 2013 09:08:56 +0000 (UTC) Subject: [Ironpython-users] re(1); 04 Message-ID: <1656487300.5682523.1385975336154.JavaMail.root@comcast.net> referral http://topsupplementsmuscle.affiliate-marketing-online.net/honrekoq/winteroffers.php Sent: 12/2/2013 1:08:52 AM >From duane.mccollum From no_reply at codeplex.com Tue Dec 3 09:19:21 2013 From: no_reply at codeplex.com (CodePlex) Date: 3 Dec 2013 00:19:21 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/2/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [Status update] time.strftime returns incorrect date 2. [Status update] Trivial: datetime.date.strftime does not show good data 3. [Status update] strftime("%Y-%A-%B") returns unicode on non-English machine 4. [New comment] time.strptime works when it shouldn't 5. [New comment] struct doesn't support format string of type bytes 6. [New comment] Quoted IRONPYTHONPATH causes error with "import" 7. [New comment] Include some way to discover IronPython path 8. [New comment] System.Decimal string.format issue 9. [New comment] System.Decimal string.format issue 10. [New comment] System.Decimal string.format issue ---------------------------------------------- ISSUES 1. [Status update] time.strftime returns incorrect date http://ironpython.codeplex.com/workitem/19257 User jdhardy has updated the issue: Status has changed from Active to Closed. ----------------- 2. [Status update] Trivial: datetime.date.strftime does not show good data http://ironpython.codeplex.com/workitem/23671 User jdhardy has updated the issue: Status has changed from Active to Closed. ----------------- 3. [Status update] strftime("%Y-%A-%B") returns unicode on non-English machine http://ironpython.codeplex.com/workitem/23965 User jdhardy has updated the issue: Status has changed from Active to Closed. ----------------- 4. [New comment] time.strptime works when it shouldn't http://ironpython.codeplex.com/workitem/30047 User jdhardy has commented on the issue: "

Agreed, it should fail on exact parse.

"----------------- 5. [New comment] struct doesn't support format string of type bytes http://ironpython.codeplex.com/workitem/34682 User jdhardy has commented on the issue: "

I added a comment to your change; there's an easier way to do it.

Can you add a test under Languages/IronPython/Tests as well? You can use [Languages/IronPython/Tests/test_struct_threadsafe.py](https://github.com/IronLanguages/main/blob/master/Languages/IronPython/Tests/test_struct_threadsafe.py) as an example.

"----------------- 6. [New comment] Quoted IRONPYTHONPATH causes error with "import" http://ironpython.codeplex.com/workitem/34687 User jdhardy has commented on the issue: "

`import sys` loads a built-in module, so it never looks at IRONPYTHONPATH. Not accepting quotes is just a bug.

"----------------- 7. [New comment] Include some way to discover IronPython path http://ironpython.codeplex.com/workitem/34692 User jdhardy has commented on the issue: "

Check HKLM\SOFTWARE\IronPython\2.7\InstallPath; that should have what you need.

"----------------- 8. [New comment] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User jdhardy has commented on the issue: "

Can you try converting to a `decimal.Decimal` first?

d = decimal.Decimal(System.Decimal(f))

Handling System.Decimal directly is preferable but this might at least give you a workaround.

"----------------- 9. [New comment] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User davcar has commented on the issue: "

Converting it as you suggested works. However I am actually receiving a lot of .Net decimal types from a .Net method I am calling. I was hoping not to have to do any extra conversions for each. Currently to avoid that, I am doing the conversion to a double inside the .Net method which works but not really great for using as money.

"----------------- 10. [New comment] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User davcar has commented on the issue: "

By the way, I am using IronPython as a way to let the user store scripts in the database to do some simple summary reporting with.

Can do - updated IAW comments

https://github.com/jbester/main/compare/IronLanguages:master...master

"----------------- 2. [New comment] Quoted IRONPYTHONPATH causes error with "import" http://ironpython.codeplex.com/workitem/34687 User peterSchwalm has commented on the issue: "

Hello,
I am not sure if this is really a bug. IMHO quotes are only syntactic matter of the windows command line interpreter. They are used in .cmd- / .bat-files ore interactively and they serve as protection against splitting filenames containing spaces on a command line into multiple arguments. Normally command lines are splitted into arguments at space characters.

A program or script called by the command line

c:>progName my text.txt

would find ['progName', 'my', 'text.txt'] in sys.argv (or in how ever that would be named in a non-python language).

Surrounding the filename (my text.txt) with quotes as in

c:>progName "my text.txt"

simply prevents splitting between 'my' and 'text.txt'. So sys.argv would contain ['progName', 'my text.txt']. So during parsing the command line the quotes disappear and sys.argv will NOT contain ['progName', '"my text.txt"']

That means the filename itself and the internal presentation in the program does not contain the quotes.

The problem with the SET-command in cmd.exe is: the command line is not parsed as usually. Instead the
environment variable contains the rest of the line (except file redirection options). So after

c:>set x=a b c

the environment variable x contains 'a b c' and the protection against splitting is not necessary.

So I think the better solution would be: do not use quotes when assigning filenames to environment variables by the SET-command.

To strip already existing quotes from filenames in batch-files one can use the construct '%~0', '%~1' ... for batchparameters or '%%~f' in for loops. Unfortunately this does not work for environment variables. But one can misuse one-time-for-loops for this purpose.

For example after in a .bat-file

set x="a b c"

x contains '"a b c"'

To strip off the quotes one can write:

for %%f in (%x%) set x=%%~f

"----------------- 3. [New comment] Quoted IRONPYTHONPATH causes error with "import" http://ironpython.codeplex.com/workitem/34687 User peterSchwalm has commented on the issue: "

In my last comment I accidently "saved" to early.

The batch-file snippet is:

set x="a b c"
set x
rem x is '"a b c"'
rem remove quotes
for %%f in (%x%) do set x=%%~f
set x
rem x is 'a b c' now.

Sometimes cumbersome to handle. But I would prefer that to handling these batch-file oddities in ironPython.

Peter

"----------------- 4. [New comment] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User vernondcole has commented on the issue: "

Given that 'string'.format() is a function from the Python standard library, I would say that the chance of getting the worldwide Python community to embrace the extension you suggest for a foreign (dotNet) data type is practically nil -- especially since the option, converting to decimal.Decimal is both easy, and specially supported by the IronPython runtime for exactly this kind of situation. Conversion to Double could loose precision, direct conversion will not.

>>> from System import Decimal as SystemDecimal
>>> import decimal
>>> sd = SystemDecimal(1234567)
>>> thousand = SystemDecimal(1000)
>>> fract = sd / thousand
>>> dd = decimal.Decimal(fract)
>>> print('{:,.2f}'.format(dd))
1,234.57
>>>

Works just exactly like you want.

"----------------- 5. [New issue] io.StringIO always closed http://ironpython.codeplex.com/workitem/34713 User paweljasinski has proposed the issue: "c:\cygwin64\home\rejap>ipy IronPython 2.7.4 (2.7.0.40) on .NET 4.0.30319.18052 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> from io import StringIO >>> s=StringIO() >>> s.write('1') Traceback (most recent call last): File "", line 1, in ValueError: write to closed file >>> s=StringIO('1') Traceback (most recent call last): File "", line 1, in ValueError: write to closed file >>> " ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Thu Dec 5 09:22:20 2013 From: no_reply at codeplex.com (CodePlex) Date: 5 Dec 2013 00:22:20 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/4/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] struct doesn't support format string of type bytes 2. [New comment] StringIO read and writes fail with "ValueError: write to closed file" exception 3. [New comment] StringIO read and writes fail with "ValueError: write to closed file" exception 4. [New comment] Quoted IRONPYTHONPATH causes error with "import" 5. [New comment] System.Decimal string.format issue ---------------------------------------------- ISSUES 1. [New comment] struct doesn't support format string of type bytes http://ironpython.codeplex.com/workitem/34682 User jdhardy has commented on the issue: "

Can you submit a pull request? It would also help to use `git rebase -i HEAD~4` to collapse it to a single change.

"----------------- 2. [New comment] StringIO read and writes fail with "ValueError: write to closed file" exception http://ironpython.codeplex.com/workitem/34683 User jbester1 has commented on the issue: "

Looked into a bit - it looks the __init__ is never being called in BytesIO class used by StringIO as a backing store. Adding an BytesIO __init__ call (in the StringIO __init__) fixes both the read and write close errors. But only *really* fixes the read case not the write case. Rerunning the write case I now get the following:

----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\iron_python_bugs\stringio_tests.py", line 19, in test_write
output_file.write("hello world\n")
LookupError: unknown error handler name 'string'

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

"----------------- 3. [New comment] StringIO read and writes fail with "ValueError: write to closed file" exception http://ironpython.codeplex.com/workitem/34683 User jbester1 has commented on the issue: "

Possible Fix; also addresses 34713

https://github.com/jbester/main/compare/IronLanguages:master...jbester:stringio

"----------------- 4. [New comment] Quoted IRONPYTHONPATH causes error with "import" http://ironpython.codeplex.com/workitem/34687 User jdhardy has commented on the issue: "

Environment variables are special because you can also set them in the Windows "Environment Variables" dialog box, and people (i.e. me) have been known to use quotes there as well because they misunderstand how it works (it doesn't help that the Windows quoting rules are complicated and inconsistent).

IronPython is the program that's interpreting the environment variable, and I think removing quotes from the beginning & end of each path is a reasonable thing to do.

I also have a vague recollection of already having fixed this issue, so I'll to see what's going on here.

"----------------- 5. [New comment] System.Decimal string.format issue http://ironpython.codeplex.com/workitem/34710 User jdhardy has commented on the issue: "

The format protocol allows types to have a [__format__ method](http://www.python.org/dev/peps/pep-3101/) that lets them participate without chaning the built-in format function. There's an extension mechanism, also used for System.Double and System.Int32, that allows adding those special methods to .NET types so that they can interact with Python facilities.

We wouldn't need to get any other Python implementation to support System.Decimal; it's just a matter of adding the appropriate extension in IronPython. I'd have to dig into the code to remember exactly how to do it, but I know it's possible.

fixed in db4f89f1a0c638afb1f44076a308691d00ae5a87

"----------------- 2. [New comment] strftime does not format %f correctly http://ironpython.codeplex.com/workitem/32215 User paweljasinski has commented on the issue: "

fixed in db4f89f1a0c638afb1f44076a308691d00ae5a87

"----------------- 3. [New comment] ftplib.storbinary always timeout http://ironpython.codeplex.com/workitem/32770 User ssarabando has commented on the issue: "

Issue still occurs with v2.7.4 (Sep. 2013). It just hangs in storbinary.

"----------------- 4. [New comment] datetime.strptime with %f error http://ironpython.codeplex.com/workitem/34706 User paweljasinski has commented on the issue: "

fixed in db4f89f1a0c638afb1f44076a308691d00ae5a87

" ---------------------------------------------- ---------------------------------------------- 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: From learmeanu at gmail.com Sat Dec 7 11:29:27 2013 From: learmeanu at gmail.com (Lee Armeanu) Date: Sat, 7 Dec 2013 23:29:27 +1300 Subject: [Ironpython-users] description for a property Message-ID: Hi all, I am trying to populate a simple PropertyGrid, something in the lines: class Form1(System.Windows.Forms.Form): def __init__(self): self.PropertyGrid1 = System.Windows.Forms.PropertyGrid() ... ... self.Load += self.Form1_Load self.ResumeLayout(False) def Form1_Load(self, sender, event_args): self.PropertyGrid1.SelectedObject = Parrot() class Parrot(object): def __init__(self): self._voltage = 100000 @property def voltage(self): """Get the current voltage.""" return self._voltage I would expect that the description string """Get the current voltage.""" is shown below the grid section but only "voltage" is printed. Any suggestions? Thanks, Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rome at Wintellect.com Sun Dec 8 22:48:56 2013 From: rome at Wintellect.com (Keith Rome) Date: Sun, 8 Dec 2013 21:48:56 +0000 Subject: [Ironpython-users] description for a property In-Reply-To: References: Message-ID: <8E25B751-F796-4137-BE6B-582EC7C7BE49@Wintellect.com> I think that you are giving an instance of System.Type to the property grid where you really want to be giving it an instance of your class. So it sees your method member of the dynamic Type and shows it. All members of dynamic types are seen as properties from the perspective of PropertyGrid. Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | krome at wintellect.com www.wintellect.com > On Dec 8, 2013, at 4:44 PM, "Lee Armeanu" wrote: > > Hi all, > I am trying to populate a simple PropertyGrid, something in the lines: > class Form1(System.Windows.Forms.Form): > > def __init__(self): > self.PropertyGrid1 = System.Windows.Forms.PropertyGrid() > ... > > ... > self.Load += self.Form1_Load > self.ResumeLayout(False) > > > def Form1_Load(self, sender, event_args): > self.PropertyGrid1.SelectedObject = Parrot() > > class Parrot(object): > def __init__(self): > self._voltage = 100000 > > @property > def voltage(self): > """Get the current voltage.""" > return self._voltage > I would expect that the description string """Get the current voltage.""" is shown below the grid section but only "voltage" is printed. > Any suggestions? > > Thanks, > Lee > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > https://mail.python.org/mailman/listinfo/ironpython-users From ps at peter-schwalm.de Tue Dec 10 01:19:37 2013 From: ps at peter-schwalm.de (Peter Schwalm) Date: Tue, 10 Dec 2013 01:19:37 +0100 Subject: [Ironpython-users] memory fragmentation oder leak in ironpython program Message-ID: <52A65E19.7050403@peter-schwalm.de> Hello, I have an ipy script that manipulates several thousand .pdf documents in a single run via itextsharp. I observe that it is permanently getting slower. After starting the program it processes about 10 documents per second, after processing 5000 documents it does only process 3 oder 4 docs per second. I have already in .net GC garbage collection calls which made the situation something better (before that it was still worse). Does anyone know if this could a fragmention problem? And what I could against it? Another peculiarity: in sysinternals procexp I can see that the memory usage rises during the excecution, but - after I inserted the GC.Collect() calls - relative moderately. What rises constantly are the GC handles (about 170.000 after 8000 documents). If I read the docs it looks as if GCHandles are handles that make managed memory accessible for non-managed programs. Does anyone know where these GC handles come from, if they could be the cause of my problems and what I could do against them? Thanks in advance, Peter Schwalm From ps at peter-schwalm.de Tue Dec 10 05:29:05 2013 From: ps at peter-schwalm.de (Peter Schwalm) Date: Tue, 10 Dec 2013 05:29:05 +0100 Subject: [Ironpython-users] memory fragmentation oder leak in ironpython program / I apologize In-Reply-To: References: <52A65E19.7050403@peter-schwalm.de> Message-ID: <52A69891.8040805@peter-schwalm.de> Hallo Slide, thank you for your answer. I don't knwo if iTextSharp uses IDisposable. I admit, I use it as a block box, but at least I suppose it's well written, because I think it is a proven tool. ... and I apologize: I have found the mistake in my own code now. It was a list which - unnecessarily - grew with every document and which was worked upon rather costly. So I caused the problem myself. The program has a constant throughput, and for now I'm happy. But I still have no safe way to analyze such problems, and there are still questions which I don't have an answer for: Is ipy kosher in it's memory handling? Where does this ever growing number of GCHandles (shown by sysinternals procexp) come from? Can I simply ignore it? Is it good practice to use explicit GC.Collect()-calls? If anyone can share her/his experience in these fields, I would be happy. Thanks in advance Peter Schwalm Am 10.12.2013 02:19, schrieb Slide: > > Does itextsharp implement idisposable for any objects you are using? > > On Dec 9, 2013 5:19 PM, "Peter Schwalm" > wrote: > > Hello, > > I have an ipy script that manipulates several thousand .pdf > documents in a single run via itextsharp. I observe that it is > permanently getting slower. After starting the program it > processes about 10 documents per second, after processing 5000 > documents it does only process 3 oder 4 docs per second. > > I have already in .net GC garbage collection calls which made the > situation something better (before that it was still worse). > > Does anyone know if this could a fragmention problem? And what I > could against it? > > Another peculiarity: > > in sysinternals procexp I can see that the memory usage rises > during the excecution, but - after I inserted the GC.Collect() > calls - relative moderately. What rises constantly are the GC > handles (about 170.000 after 8000 documents). If I read the docs > it looks as if GCHandles are handles that make managed memory > accessible for non-managed programs. > > Does anyone know where these GC handles come from, if they could > be the cause of my problems and what I could do against them? > > Thanks in advance, > Peter Schwalm > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > https://mail.python.org/mailman/listinfo/ironpython-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Tue Dec 10 09:37:32 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Tue, 10 Dec 2013 08:37:32 +0000 Subject: [Ironpython-users] memory fragmentation oder leak in ironpython program / I apologize In-Reply-To: <52A69891.8040805@peter-schwalm.de> References: <52A65E19.7050403@peter-schwalm.de> <52A69891.8040805@peter-schwalm.de> Message-ID: <727D8E16AE957149B447FE368139F2B53858AFFA@SERVER10> Hi, Peter, There is at least one known memory leak problem with IronPython. However, it only affects the case when you run lots of python scripts within the same process, not when a single python script is running (as an application): http://ironpython.codeplex.com/workitem/31764 Recently, there was some progress in debugging of the problem, but it is not solved yet. Usually, it is not good practice to call GC.Collect() explicitly, except in cases when you certainly know that there is a huge amount of memory which is to be released now. There are certain knobs you can use to tweak the garbage collection algorithms. Especially the ServerGC setting brought a 200% speedup on a compute and memory allocation intense c# application (geodata processing) on a 64 Bit multi-CPU machine, on the cost of about 200MB more memory usage (of about 2.5G total). Google will give you many helpful links like http://msdn.microsoft.com/de-de/library/0xy59wtx%28v=vs.110%29.aspx http://msdn.microsoft.com/en-us/library/ms229357%28v=vs.110%29.aspx http://www.atalasoft.com/cs/blogs/rickm/archive/2008/08/20/changing-your-garbage-collector-settings-on-the-fly-net-memory-management-part-5.aspx http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions ________________________________ 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store: store.codesys.com CODESYS forum: forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org] Im Auftrag von Peter Schwalm Gesendet: Dienstag, 10. Dezember 2013 05:29 An: Slide Cc: ironpython mailList Betreff: Re: [Ironpython-users] memory fragmentation oder leak in ironpython program / I apologize Hallo Slide, thank you for your answer. I don't knwo if iTextSharp uses IDisposable. I admit, I use it as a block box, but at least I suppose it's well written, because I think it is a proven tool. ... and I apologize: I have found the mistake in my own code now. It was a list which - unnecessarily - grew with every document and which was worked upon rather costly. So I caused the problem myself. The program has a constant throughput, and for now I'm happy. But I still have no safe way to analyze such problems, and there are still questions which I don't have an answer for: Is ipy kosher in it's memory handling? Where does this ever growing number of GCHandles (shown by sysinternals procexp) come from? Can I simply ignore it? Is it good practice to use explicit GC.Collect()-calls? If anyone can share her/his experience in these fields, I would be happy. Thanks in advance Peter Schwalm Am 10.12.2013 02:19, schrieb Slide: Does itextsharp implement idisposable for any objects you are using? On Dec 9, 2013 5:19 PM, "Peter Schwalm" > wrote: Hello, I have an ipy script that manipulates several thousand .pdf documents in a single run via itextsharp. I observe that it is permanently getting slower. After starting the program it processes about 10 documents per second, after processing 5000 documents it does only process 3 oder 4 docs per second. I have already in .net GC garbage collection calls which made the situation something better (before that it was still worse). Does anyone know if this could a fragmention problem? And what I could against it? Another peculiarity: in sysinternals procexp I can see that the memory usage rises during the excecution, but - after I inserted the GC.Collect() calls - relative moderately. What rises constantly are the GC handles (about 170.000 after 8000 documents). If I read the docs it looks as if GCHandles are handles that make managed memory accessible for non-managed programs. Does anyone know where these GC handles come from, if they could be the cause of my problems and what I could do against them? Thanks in advance, Peter Schwalm _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org https://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Thu Dec 12 09:23:09 2013 From: no_reply at codeplex.com (CodePlex) Date: 12 Dec 2013 00:23:09 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/11/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] gc.collect non-deterministically hangs ---------------------------------------------- ISSUES 1. [New issue] gc.collect non-deterministically hangs http://ironpython.codeplex.com/workitem/34730 User paweljasinski has proposed the issue: "I experience gc.collect() occasionally to hang. Trying to narrow down the problem to single test case failed so far. Usually it hangs when run in a bigger context such as a test case suite. The same test, when run individually, will be ok. I can trigger it by adding a test case which is run after the gc.collect(). This looks to me like a race condition, where by changing a module content, import timing is changed. I also observed, that adding a print statement before/after causes hang." ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Fri Dec 13 09:22:59 2013 From: no_reply at codeplex.com (CodePlex) Date: 13 Dec 2013 00:22:59 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/12/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [Status update] gc.collect non-deterministically hangs ---------------------------------------------- ISSUES 1. [Status update] gc.collect non-deterministically hangs http://ironpython.codeplex.com/workitem/34730 User paweljasinski has updated the issue: Status has changed from Proposed to Closed with the following comment, "I should better watch what I have in del before complaining about gc.collect having a bug." ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Tue Dec 17 09:20:32 2013 From: no_reply at codeplex.com (CodePlex) Date: 17 Dec 2013 00:20:32 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/16/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] {}.update(b=1) -> TypeError ---------------------------------------------- ISSUES 1. [New issue] {}.update(b=1) -> TypeError http://ironpython.codeplex.com/workitem/34742 User pekkaklarck has proposed the issue: "It seems b is a somewhat special argument for dict.update: IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.18052 (32-bit) Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> d.update(a=1) >>> d.update(a=2, c=3) >>> d.update({}, a=3) >>> d {'c': 3, 'a': 3} >>> d.update(b=1) Traceback (most recent call last): File "", line 1, in TypeError: Multiple targets could match: update(object), update(object, dict), u pdate(dict) >>> d.update(a=1, b=2) Traceback (most recent call last): File "", line 1, in TypeError: expected dict, got int >>> d.update({}, b=1) Traceback (most recent call last): File "", line 1, in TypeError: update() takes at most 1 argument (2 given) Otherwise using b as a key isn't an issue: >>> d = dict(b=1) >>> d.update({'b': 2}) >>> d {'b': 2} " ---------------------------------------------- ---------------------------------------------- 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: From pawel.jasinski at gmail.com Wed Dec 18 12:41:08 2013 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Wed, 18 Dec 2013 12:41:08 +0100 Subject: [Ironpython-users] pyzmq can be used with ironpython Message-ID: hi, I have managed to get pyzmq to work under Ironpython. Anybody interested can take it from: https://github.com/paweljasinski/pyzmq/tree/iron https://github.com/paweljasinski/clrzmq/tree/iron It is usable ( From pawel.jasinski at gmail.com Wed Dec 18 12:49:22 2013 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Wed, 18 Dec 2013 12:49:22 +0100 Subject: [Ironpython-users] pyzmq can be used with ironpython In-Reply-To: References: Message-ID: hi, I have managed to get pyzmq to work under Ironpython. Anybody interested can take it from: https://github.com/paweljasinski/pyzmq/tree/iron https://github.com/paweljasinski/clrzmq/tree/iron It is usable, but not in the "push request" quality. I would appreciate feedback about a way clrzmq is integrated with ironpython. In order to keep structure of the pyzmq, native C# modules must reference things from python. The code works, but ... Thanks Pawel The previous post got out unfinished. On Wed, Dec 18, 2013 at 12:41 PM, Pawel Jasinski wrote: > hi, > > I have managed to get pyzmq to work under Ironpython. > Anybody interested can take it from: > https://github.com/paweljasinski/pyzmq/tree/iron > https://github.com/paweljasinski/clrzmq/tree/iron > > It is usable ( From no_reply at codeplex.com Thu Dec 19 09:28:31 2013 From: no_reply at codeplex.com (CodePlex) Date: 19 Dec 2013 00:28:31 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/18/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] Should subprocess Work On Mono? ---------------------------------------------- ISSUES 1. [New issue] Should subprocess Work On Mono? http://ironpython.codeplex.com/workitem/34751 User TeddyP has proposed the issue: "I've spent the last couple of days doing searches, digging through code, looking at old forum posts, looking at online documentation, and checking the mailing list. I'm still not sure so I'll throw it out there: Should I be able to import the subprocess module and use it on Mono (because I don't seem to be able to)? If I should, any ideas on what I'm doing wrong? If I shouldn't, is there: Intent to have it work in the future? If so, is there an issue # or something I could be tracking against? Any documentation that makes this clear? I'm using the following versions/systems: IronPython v2.7.3 Xubuntu 13.10 64-bit running Mono 2.10.8.1 (Debian 2.10.8.1-5ubuntu2) Windows 7 Enterprise 64-bit running .NET Framework 4.5.1 (and a few of the older .NET versions as well) Windows ...>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe" IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.18408 (64-bit) Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> I can proceed and do things like subprocess.call('') just fine. Linux ...$ mono ../IronPython/ipy64.exe IronPython 2.7.3 (2.7.0.40) on Mono 4.0.30319.1 (64-bit) Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess Traceback (most recent call last): File "", line 1, in File "../IronPython/Lib/subprocess.py", line 430, in ImportError: No module named fcntl >>> Some things I looked at when trying to figure this out: IronPython Work Item 15512: Seems to indicate subprocess was implemented and working as of 2.7B2 (other release notes and mailing list items seem to back this up). Not explicit if it was tested/supposed to be working on Mono or not, but it seems that by default the assumption should be yes unless it explicitly says otherwise. IronPython Work Item 23983: Similar to the other one. Also marked as closed out. IronPython FAQ: I didn't see anything about it in the FAQ IronPython Mailing List Archive: Didn't appear to be anything recent (lots of stuff back from pre-2.7B2 and then with the fix in 2.7B2) IronPython Cookbook: Launching Sub-Processes: Provides a workaround using System.Diagnostic.Processes instead of subprocess that still works. Has some links to a partial subprocess module implementation in C# written by jdhardy back in 2008 (who I see is still heavily involved and a coordinator in this project). Not sure if that was ever completed or integrated into IronPython (I don't see it in the source code package from 2.7.3 though). Other link is dead. The cookbook page says Because the select module is not available, you can't use the subprocess module in IronPython. I'm guessing that is somewhat outdated, as the select module doesn't seem to have anything to do with the current issue (possibly back in 2007 when it was written) and there haven't been any significant updates to that page since it was first written. Looking at the source code for subprocess.py, what appears to keep the module from being loaded (unknown if it would work even if you got it loading, but hey...) is listed below. Note that these assume the POSIX codepath is the one that should be taken (which is what currently is being taken; if ultimately the Windows codepath is what we are going for, a different set of changes would need to be made to subprocess.py). Missing fcntl module. This is a Unix specific module that is a built-in module provided by the Python interpreter itself on Linux. The IronPython interpreter does not have fcntl as a built-in. The uses of fcntl by subprocess are all fairly contained around safely/properly handling duplicated stdio handles when child processes are spawned. The particular symbols missing are the fcntl function itself, FD_CLOEXEC, F_GETFD, and F_SETFD. Missing certain members from the os module. In particular the WIFSIGNALED, WTERMSIG, WIFEXITED, WEXITSTATUS, and WNOHANG symbols. Even though they are from the os module, the os module actually gets them from the posix module on Linux. Now the posix module is present with IronPython but it doesn't have these symbols. All of the uses of these symbols in subprocess are fairly well contained as well and deal with properly waiting for and setting the return code for the exiting child process. Any thoughts?" ---------------------------------------------- ---------------------------------------------- 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: From jdhardy at gmail.com Fri Dec 20 07:12:24 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 19 Dec 2013 23:12:24 -0700 Subject: [Ironpython-users] pyzmq can be used with ironpython In-Reply-To: References:

Message-ID: On Wed, Dec 18, 2013 at 4:49 AM, Pawel Jasinski wrote: > hi, > > I have managed to get pyzmq to work under Ironpython. > Anybody interested can take it from: > https://github.com/paweljasinski/pyzmq/tree/iron > https://github.com/paweljasinski/clrzmq/tree/iron That's fantastic. I'm assuming this is for IPython Notebook? > It is usable, but not in the "push request" quality. > > I would appreciate feedback about a way clrzmq is integrated with ironpython. > In order to keep structure of the pyzmq, native C# modules must > reference things from python. I doubt adding IP-specific stuff to clrzmq will be acceptable upstream, so they'll have to be broken apart. Why can't ZeroMQ.Iron be a separate assembly? In particular, it would be nice if that assembly was not platform specific and could reference the various platform-specific clrzmq DLLs. It appears that clrzmq uses different DLLs for .NET and Mono, so choosing the right DLL to load automatically could be interesting. It may make sense to maintain a fork of pyzmq, but that depends on what upstream would be interested in supporting. This is a common problem (I would love to do the same for SQLite and expat) so it would be nice to have an idea of what works and what doesn't. - Jeff From no_reply at codeplex.com Fri Dec 20 09:23:43 2013 From: no_reply at codeplex.com (CodePlex) Date: 20 Dec 2013 00:23:43 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/19/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] {}.update(b=1) -> TypeError 2. [New comment] {}.update(b=1) -> TypeError 3. [New comment] Should subprocess Work On Mono? ---------------------------------------------- ISSUES 1. [New comment] {}.update(b=1) -> TypeError http://ironpython.codeplex.com/workitem/34742 User jdhardy has commented on the issue: "

`b` is the name of the argument to the C# [update function](https://github.com/IronLanguages/main/blob/master/Languages/IronPython/IronPython/Runtime/PythonDictionary.cs#L409), and this is confusing the named argument resolution.

"----------------- 2. [New comment] {}.update(b=1) -> TypeError http://ironpython.codeplex.com/workitem/34742 User jdhardy has commented on the issue: "

Fixed in 5337519/356b9e1. The trick is to give the parameters "unspeakable" names that make the source look ugly but make everything work from the Python side.

"----------------- 3. [New comment] Should subprocess Work On Mono? http://ironpython.codeplex.com/workitem/34751 User jdhardy has commented on the issue: "

First off, I appreciate your thoroughness. I'm not sure I've ever but this much detail into a bug report.

The short version is that no, it probably doesn't work, because I don't think it's ever been tested and then made to work. I would love for it to be supported on Mono, but I just don't have the time to do it right now myself. One area that may cause issues is the subprocess (and multiprocessing) might do things to the process state that Mono doesn't like (see [System.Unix.Native.Syscall.fork is commented out](http://mono.1490590.n4.nabble.com/System-Unix-Native-Syscall-fork-is-commented-out-td1535320.html), for example).

If you want to tackle it, [Mono.Unix.Native](http://docs.go-mono.com/?link=N%3aMono.Unix.Native) is probably going to be your friend to fill in IronPython's posix support. (Interestingly, IP doesn't have a real posix module right now; the 'nt' module is re-named to 'posix' when running on Unix...)

One thing to keep in mind is that the same DLLs have to work on both; happily, DLL imports are not resolved unless used, and I'm OK with it failing if someone tries to call a posix method on Windows (this is how the msvcrt module fails on non-Windows machines, for example). signal.cs is another example of how it can be handled, where the module needs to be implemented on both platforms. Finally, it's OK to use reflection to look for Mono.Posix.dll and pull the values at runtime, and just ignore them at compile time.

There doesn't seem to be issues open for fcntl or a real posix module, so feel free to open them if needed.

Message-ID: On Fri, Dec 20, 2013 at 7:12 AM, Jeff Hardy wrote: > On Wed, Dec 18, 2013 at 4:49 AM, Pawel Jasinski > wrote: >> hi, >> >> I have managed to get pyzmq to work under Ironpython. >> Anybody interested can take it from: >> https://github.com/paweljasinski/pyzmq/tree/iron >> https://github.com/paweljasinski/clrzmq/tree/iron > > That's fantastic. I'm assuming this is for IPython Notebook? actually I have tested it with ptvs and ipython. I was able to enable "ipython w/o pylab" and get a session going. It is not a touch-down. The guilty is ip unicode/byte/char system. The ipython types are python 3 compatible, but entire standard lib is typed in 2.x terms. This is a strong argument to move to 3. For the ipython itself, modifications are ugly (I will push it to my github repo today). Not all usage scenarios of ipython/zmq work. There are unittest in ipython/zmq which I simply gave up. > >> It is usable, but not in the "push request" quality. >> >> I would appreciate feedback about a way clrzmq is integrated with ironpython. >> In order to keep structure of the pyzmq, native C# modules must >> reference things from python. > > I doubt adding IP-specific stuff to clrzmq will be acceptable > upstream, so they'll have to be broken apart. Yes, particularly dependency on ironpython assembly is a no-go. I am using only very bottom of clrzmq (P/Invoke), so it will be trivial to separate it. zmq devels adviced me to check out pure .net zmq provided (NetMQ). I have to find out how it fits with pyzmq. > Why can't ZeroMQ.Iron be a separate assembly? it can be a separate assembly referencing platform/architecture specific libzmq > In particular, it would be nice if that assembly > was not platform specific and could reference the various > platform-specific clrzmq DLLs. It appears that clrzmq uses different > DLLs for .NET and Mono, so choosing the right DLL to load > automatically could be interesting. It may make sense to maintain a > fork of pyzmq, but that depends on what upstream would be interested > in supporting. I am in touch with zmq folks. > > This is a common problem (I would love to do the same for SQLite and > expat) so it would be nice to have an idea of what works and what > doesn't. > > - Jeff --pawel From pawel.jasinski at gmail.com Fri Dec 20 13:08:33 2013 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Fri, 20 Dec 2013 13:08:33 +0100 Subject: [Ironpython-users] Fwd: pyzmq can be used with ironpython Message-ID: > For the ipython itself, modifications are ugly (I will push it to my > github repo today). > Not all usage scenarios of ipython/zmq work. There are unittest in > ipython/zmq which I simply gave up. https://github.com/paweljasinski/ipython/tree/iron-wip --pawel From no_reply at codeplex.com Sat Dec 21 09:19:49 2013 From: no_reply at codeplex.com (CodePlex) Date: 21 Dec 2013 00:19:49 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/20/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] Should subprocess Work On Mono? 2. [New issue] StackOverflowException while parsing long expression script 3. [New issue] Huge memory consumption during ---------------------------------------------- ISSUES 1. [New comment] Should subprocess Work On Mono? http://ironpython.codeplex.com/workitem/34751 User TeddyP has commented on the issue: "

Thanks for the response. I probably won't be able to tackle it myself now either. This was a rabbit hole I went down trying to work around a limitation of another tool that uses IronPython to provide extensibility. I was trying to use subprocess as a workaround for that tool's limitation (the System.Diagnostics.Process workaround manages to get me the functionality I need in this particular case, but it seems to lack the elegance of using subprocess so I went digging).

I'm glad to have the question answered at least. Hopefully folks with the same question will stumble across this post without having to do all the digging around I did. Perhaps it will be a good starting point for whoever eventually decides to tackle it as well.

I wonder if it would be possible to have the subprocess module in IronPython throw an exception that clearly indicates it isn't currently supported on non-Windows platforms if it detects it isn't running on Windows? It looks like there is some customization of the subprocess module released with IronPython as compared to what comes with the corresponding version of Python (I diff'ed the 2.7.3 version of both and they were largely the same but did have a few differences), so this might be a quick, easy, and efficient way of conveying the information.

"----------------- 2. [New issue] StackOverflowException while parsing long expression script http://ironpython.codeplex.com/workitem/34760 User zocram15 has proposed the issue: "Trying to execute the attached script throws a StackOverflowException. I understand that that it not the best way of writing a sum but that's just an example that reproduces the issue I'm seeing."----------------- 3. [New issue] Huge memory consumption during http://ironpython.codeplex.com/workitem/34761 User zocram15 has proposed the issue: "I have a simple application that uses IronPython as a scripting language, we have noticed that when someone write big expressions the application uses a huge amount of memory for small period of time. If the expression is very huge the application consumes the whole system memory and hangs the machine. I've been able to reproduce the issue in the attached sample program. I've tried to disable AdaptiveCompilation and other options but the issue still remains. I've tested this on Windows 7 64 bit compiling the application both for .net 4 and .net 4.5. Let me know if more information are need, or if I can be of any help on finding fixing the issue." ---------------------------------------------- ---------------------------------------------- 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: From no_reply at codeplex.com Wed Dec 25 09:21:58 2013 From: no_reply at codeplex.com (CodePlex) Date: 25 Dec 2013 00:21:58 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/24/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] dict lookup of System.Int64 and long is not the same 2. [New issue] Add support for RIPEMD160 to hashlib ---------------------------------------------- ISSUES 1. [New issue] dict lookup of System.Int64 and long is not the same http://ironpython.codeplex.com/workitem/34770 User giltayar has proposed the issue: "To reproduce: >>> dct = {} >>> import System >>> dct[System.Int64(1110766100758387874)] = "FindMe?" >>> dct[System.Int64(1110766100758387874)] 'FindMe!' >>> dct[1110766100758387874] Traceback (most recent call last): File "", line 1, in KeyError: 1110766100758387874 Same for set: >>> s = set() >>> s.add(System.Int64(1110766100758387874)) >>> System.Int64(1110766100758387874) in s True >>> 1110766100758387874 in s False This happens to me because I use NHibernate, where the model class is a C# class with an Id of System.Int64. Whenever I use a dict, and the Id as a key, this happens because I sometimes look for the id as a regular python number. (I am confused as to whether to submit an issue in github or here, so I submitted in both! Please excuse my n00bness)"----------------- 2. [New issue] Add support for RIPEMD160 to hashlib http://ironpython.codeplex.com/workitem/34771 User adal has proposed the issue: "IronPython doesn't support the RIPEMD160 hashing algorithm. RIPEMD160 is used by Bitcoin, so this means that no Bitcoin software written in Python can run under IronPython. The following code works in CPython, but not in IronPython: import hashlib hash = hashlib.new("ripemd160") hash.update("test") print hash.hexdigest() .NET supports RIPEMD160 - http://msdn.microsoft.com/en-us/library/system.security.cryptography.ripemd160.aspx" ---------------------------------------------- ---------------------------------------------- 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: From pawel.jasinski at gmail.com Thu Dec 26 14:05:15 2013 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Thu, 26 Dec 2013 14:05:15 +0100 Subject: [Ironpython-users] pipe dup and dup2 Message-ID: hi, I have fixed pipe and added dup and dup2 to nt/os module. The results can be seen here: https://github.com/paweljasinski/IronLanguages/tree/tinker-with-file However, I am not 100% sure, that the way it is now is right. At the moment IP manages its own file descriptors available via nt/os module. On platforms, such mono/linux, it is probably redundant. Perfectly functioning posix layer with native file descriptors exist. I suspect there is a way to access it. On classic windows there is msvcrt which can be used, analog to the way cpython does. As far as I can tell IP targets other windows platforms without msvcrt support and I am not able to access situation there. Any ideas and comments are welcome. --pawel Ref: https://ironpython.codeplex.com/workitem/7267 From no_reply at codeplex.com Sun Dec 29 09:20:48 2013 From: no_reply at codeplex.com (CodePlex) Date: 29 Dec 2013 00:20:48 -0800 Subject: [Ironpython-users] IronPython, Daily Digest 12/28/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] str() or unicode() setting up unicode string, exception occurs. ---------------------------------------------- ISSUES 1. [New comment] str() or unicode() setting up unicode string, exception occurs. http://ironpython.codeplex.com/workitem/15372 User paweljasinski has commented on the issue: "

I think this is no longer an issue.
The following:
```
a='A'
print unicode(a)
print str(a)
print "-"*20

a=u'\uff21'
print unicode(a)
print str(a)
```
produces:
```
A
A
--------------------
A
Traceback (most recent call last):
File "test_cp15372.py", line 8, in <module>
UnicodeEncodeError: ('unknown', '\x00', 0, 1, '')
```

which is consistent with cpython.
I also think I have nailed the origin of the obfuscated message.