From eliswilson at hushmail.com Wed May 1 00:19:35 2013 From: eliswilson at hushmail.com (eliswilson at hushmail.com) Date: Tue, 30 Apr 2013 18:19:35 -0400 Subject: [Ironpython-users] Biggest Fake Conference in Computer Science Message-ID: <20130430221935.4C50214DBDE@smtp.hushmail.com> Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world?s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP?s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP?s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia?s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP?13 because of the fears of their image being tarnished due to WORLDCOMP?s fraudulent activities. That is why WORLDCOMP?13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP?s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet?s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From no_reply at codeplex.com Wed May 1 09:17:52 2013 From: no_reply at codeplex.com (CodePlex) Date: 1 May 2013 00:17:52 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 4/30/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] IronPython: Python.CreateEngine blocking on Windows 8 2. [New comment] IronPython: Python.CreateEngine blocking on Windows 8 ---------------------------------------------- ISSUES 1. [New issue] IronPython: Python.CreateEngine blocking on Windows 8 http://ironpython.codeplex.com/workitem/34020 User Loupi has proposed the issue: "I have an application that relies on IronPython 2.7.3. I just switched to a new developement workstation with Windows 8. Using VS2010 debugger, I clearly see that the function Python.CreateEngine never returns. Anybody else experiencing this issue with Window 8 and IronPython?"----------------- 2. [New comment] IronPython: Python.CreateEngine blocking on Windows 8 http://ironpython.codeplex.com/workitem/34020 User Loupi has commented on the issue: "

I did a bit more debugging, and foudn out that the blocking occurs in PythonFile.CreateConsole internals From no_reply at codeplex.com Thu May 2 09:19:14 2013 From: no_reply at codeplex.com (CodePlex) Date: 2 May 2013 00:19:14 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/1/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] hashlib update really slow 2. [New issue] Memory leak - if script imports library ---------------------------------------------- ISSUES 1. [New issue] hashlib update really slow http://ironpython.codeplex.com/workitem/34022 User pingy has proposed the issue: "Compared to c python, its really slow for a big file Code: import hashlib hashmethod = hashlib.md5() fobj = open('BIGFILE', 'rUb') #a hefty 100MB will do chunk = 8192 #tried smaller and larger chunk, still slow readchunk = lambda: fobj.read(chunk) for chunk in iter(readchunk, b''): hashmethod.update(chunk) fobj.close() Version: IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.17929 (32-bit) Thanks"----------------- 2. [New issue] Memory leak - if script imports library http://ironpython.codeplex.com/workitem/34023 User Roman456 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. Also is happend when unloading script, if he imported any modules with import. Just importing * from System.Windows.Forms and then re-loading script causes huge memory leak. Script i tried doesn't do anything except importing clr types. GC does not help anything, even if i call Collect() with Forced option between loading and reloading script. Check this: http://ironpython.codeplex.com/workitem/33650. This problem is still actual. Will it be fixed?" ---------------------------------------------- ---------------------------------------------- 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 May 3 09:17:28 2013 From: no_reply at codeplex.com (CodePlex) Date: 3 May 2013 00:17:28 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/2/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] CreateEngine never returns ---------------------------------------------- ISSUES 1. [New issue] CreateEngine never returns http://ironpython.codeplex.com/workitem/34024 User joao3000 has proposed the issue: "I'm using a Desktop application on Windows 8, with some python scripts. When I try to call CreateEngine, this method never returns. If I use the code bellow, it starts working in debug mode, but if a create a build, with obfuscator code, it stops again. AppDomain sandbox = AppDomain.CreateDomain("sandbox"); scriptEngine = Python.CreateEngine(sandbox); Could you please give some solution. Thanks." ---------------------------------------------- ---------------------------------------------- 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 Petra.Chong at uk.bp.com Tue May 7 18:34:02 2013 From: Petra.Chong at uk.bp.com (Chong, Petra (HARVEY NASH)) Date: Tue, 7 May 2013 17:34:02 +0100 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe Message-ID: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> (I also asked this on StackOverflow - http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit- mode-on-64bit-machine-even-when-running-ipy64-exe - have copy pasted from there). I am sure I am missing something simple but unfortunately a lot of searching hasn't thrown up what it is.. I am running Windows 7 64-bit (I verified this by looking at Control Panel > All Control Panel Items > System and seeing that it says 64-bit Operating System). I have IronPython 2.7.3 installed from here (http://ironpython.codeplex.com/downloads/get/423690 ) This has created the following shortcut (with no corresponding shortcut in C:\Program Files\IronPython 2.7...): "C:\Program Files (x86)\IronPython 2.7\ipy64.exe" If I run this, I get this prompt: "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe" IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit) The docs from an older version of IronPython (2.6) athttp://ironpython.codeplex.com/releases/view/27350 say that: "A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes." >From this, I infer that ipy64 should have started as a 64 bit process, but that's not what shows in the prompt. Any ideas what I am doing wrong? Thanks in advance.. Edited to add: I have also tried running the following in the IronPython shell, which I found from another question on this site, to check whether the OS is 64 bit >>> import System >>> System.Environment.Is64BitOperatingSystem True ... but then I ran the following which indicates that IronPython really is running in 32 bit mode. >>> import System >>> System.IntPtr.Size 4 I have tested that I have 64-bit .NET installed by creating a console application in Visual Studio with the line Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". Thanks, PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue May 7 18:46:28 2013 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 7 May 2013 09:46:28 -0700 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe In-Reply-To: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> References: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> Message-ID: Can you use corflags.exe to confirm that your ipy64.exe is actually not marked for 32-bit execution? Your output should look like this: PS D:\Program Files\Sho\bin> corflags .\ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Version : v2.0.50727 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 On Tue, May 7, 2013 at 9:34 AM, Chong, Petra (HARVEY NASH) < Petra.Chong at uk.bp.com> wrote: > (I also asked this on StackOverflow - > http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit-mode-on-64bit-machine-even-when-running-ipy64-exe- have copy pasted from there). > **** > > ** ** > > I am sure I am missing something simple but unfortunately a lot of > searching hasn't thrown up what it is..**** > > I am running Windows 7 64-bit (I verified this by looking at Control Panel > > All Control Panel Items > System and seeing that it says 64-bit Operating > System).**** > > I have IronPython 2.7.3 installed from here ( > http://ironpython.codeplex.com/downloads/get/423690)**** > > This has created the following shortcut (with no corresponding shortcut in > C:\Program Files\IronPython 2.7...):**** > > "C:\Program Files (x86)\IronPython 2.7\ipy64.exe"**** > > If I run this, I get this prompt:**** > > "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe"**** > > IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit)**** > > The docs from an older version of IronPython (2.6) at > http://ironpython.codeplex.com/releases/view/27350 say that:**** > > "A very visible new feature added to this release is that ipy.exe is now > strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR > process on both x86 and x64 operating systems. ipy64.exe, despite what its > name might imply, is a platform agnostic assembly matching the old behavior > of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit > OSes and 64-bit on 64-bit OSes."**** > > From this, I infer that ipy64 should have started as a 64 bit process, but > that's not what shows in the prompt.**** > > Any ideas what I am doing wrong? Thanks in advance..**** > > Edited to add: I have also tried running the following in the IronPython > shell, which I found from another question on this site, to check whether > the OS is 64 bit**** > > >>> import System**** > > >>> System.Environment.Is64BitOperatingSystem**** > > True**** > > ... but then I ran the following which indicates that IronPython really is > running in 32 bit mode.**** > > >>> import System**** > > >>> System.IntPtr.Size**** > > 4**** > > ** ** > > I have tested that I have 64-bit .NET installed by creating a console > application in Visual Studio with the line > Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". > **** > > ** ** > > Thanks,**** > > ** ** > > PC**** > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Wed May 8 09:17:41 2013 From: no_reply at codeplex.com (CodePlex) Date: 8 May 2013 00:17:41 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/7/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] f_locals in sys.exc_info() ---------------------------------------------- ISSUES 1. [New issue] f_locals in sys.exc_info() http://ironpython.codeplex.com/workitem/34029 User ericreynolds has proposed the issue: "The following code gives different results in Python compared with IronPython because sys.exc_info().tb_frame.f_locals seems to be the locals dictionary of the current frame rather than the frame where the exception was thrown. import sys def f(): a = 1 b = 2 1/0 try: f() except: exc_type, exc_value, tb = sys.exc_info() if tb is not None: prev = tb curr = tb.tb_next while curr is not None: prev = curr curr = curr.tb_next print prev.tb_frame.f_locals In Python: {'a': 1, 'b': 2} In IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit): {'__name__': '__main__', '__file__': 'ExcTest.py', '__doc__': None, '__builtins__': , 'sys': , 'f': , 'exc_type': , 'exc_value': ZeroDivisionError('Att empted to divide by zero.',), 'tb': , 'prev': , 'curr': None } " ---------------------------------------------- ---------------------------------------------- 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 Petra.Chong at uk.bp.com Wed May 8 09:14:54 2013 From: Petra.Chong at uk.bp.com (Chong, Petra (HARVEY NASH)) Date: Wed, 8 May 2013 08:14:54 +0100 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe In-Reply-To: References: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> Message-ID: <8C7A86EEE05F15469A5C1F5D2B49D316014FFEB9@BP1XEUEX056-C.bp1.ad.bp.com> I do indeed get output that looks like yours - c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 And if I then run this: c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 11 ILONLY : 1 32BIT : 1 Signed : 1 Thanks, PC From: Curt Hagenlocher [mailto:curt at hagenlocher.org] Sent: 07 May 2013 17:46 To: Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Subject: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe Can you use corflags.exe to confirm that your ipy64.exe is actually not marked for 32-bit execution? Your output should look like this: PS D:\Program Files\Sho\bin> corflags .\ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Version : v2.0.50727 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 On Tue, May 7, 2013 at 9:34 AM, Chong, Petra (HARVEY NASH) wrote: (I also asked this on StackOverflow - http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit- mode-on-64bit-machine-even-when-running-ipy64-exe - have copy pasted from there). I am sure I am missing something simple but unfortunately a lot of searching hasn't thrown up what it is.. I am running Windows 7 64-bit (I verified this by looking at Control Panel > All Control Panel Items > System and seeing that it says 64-bit Operating System). I have IronPython 2.7.3 installed from here (http://ironpython.codeplex.com/downloads/get/423690 ) This has created the following shortcut (with no corresponding shortcut in C:\Program Files\IronPython 2.7...): "C:\Program Files (x86)\IronPython 2.7\ipy64.exe" If I run this, I get this prompt: "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe" IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit) The docs from an older version of IronPython (2.6) athttp://ironpython.codeplex.com/releases/view/27350 say that: "A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes." >From this, I infer that ipy64 should have started as a 64 bit process, but that's not what shows in the prompt. Any ideas what I am doing wrong? Thanks in advance.. Edited to add: I have also tried running the following in the IronPython shell, which I found from another question on this site, to check whether the OS is 64 bit >>> import System >>> System.Environment.Is64BitOperatingSystem True ... but then I ran the following which indicates that IronPython really is running in 32 bit mode. >>> import System >>> System.IntPtr.Size 4 I have tested that I have 64-bit .NET installed by creating a console application in Visual Studio with the line Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". Thanks, PC _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Wed May 8 11:20:11 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Wed, 8 May 2013 10:20:11 +0100 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe In-Reply-To: <8C7A86EEE05F15469A5C1F5D2B49D316014FFEB9@BP1XEUEX056-C.bp1.ad.bp.com> References: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> <8C7A86EEE05F15469A5C1F5D2B49D316014FFEB9@BP1XEUEX056-C.bp1.ad.bp.com> Message-ID: I find that the following works (on all versions I have tested, including Jython): > import sys def Python_is_64bit(): > if sys.platform == 'cli': #IronPython > import System > return System.IntPtr.Size == 8 > else: > try: > return sys.maxsize > 2147483647 > except AttributeError: > return sys.maxint > 2147483647 > -- Vernon Cole On Wed, May 8, 2013 at 8:14 AM, Chong, Petra (HARVEY NASH) < Petra.Chong at uk.bp.com> wrote: > I do indeed get output that looks like yours - **** > > ** ** > > c:\Program Files (x86)\IronPython > 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy64.exe**** > > Microsoft (R) .NET Framework CorFlags Conversion Tool. Version > 2.0.50727.42**** > > Copyright (c) Microsoft Corporation. All rights reserved.**** > > ** ** > > Version : v4.0.30319**** > > CLR Header: 2.5**** > > PE : PE32**** > > CorFlags : 9**** > > ILONLY : 1**** > > 32BIT : 0**** > > Signed : 1**** > > ** ** > > And if I then run this:**** > > ** ** > > c:\Program Files (x86)\IronPython > 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy.exe**** > > Microsoft (R) .NET Framework CorFlags Conversion Tool. Version > 2.0.50727.42**** > > Copyright (c) Microsoft Corporation. All rights reserved.**** > > ** ** > > Version : v4.0.30319**** > > CLR Header: 2.5**** > > PE : PE32**** > > CorFlags : 11**** > > ILONLY : 1**** > > 32BIT : 1**** > > Signed : 1**** > > ** ** > > Thanks,**** > > ** ** > > PC**** > > ** ** > > ** ** > > *From:* Curt Hagenlocher [mailto:curt at hagenlocher.org] > *Sent:* 07 May 2013 17:46 > *To:* Chong, Petra (HARVEY NASH) > *Cc:* ironpython-users at python.org > *Subject:* Re: [Ironpython-users] IronPython always in 32-bit mode on > 64bit machine even when running ipy64.exe**** > > ** ** > > Can you use corflags.exe to confirm that your ipy64.exe is actually not > marked for 32-bit execution? Your output should look like this:**** > > **** > > PS D:\Program Files\Sho\bin> corflags .\ipy64.exe > Microsoft (R) .NET Framework CorFlags Conversion Tool. Version > 3.5.30729.1 > Copyright (c) Microsoft Corporation. All rights reserved.**** > > Version : v2.0.50727 > CLR Header: 2.5 > PE : PE32 > CorFlags : 9 > ILONLY : 1 > 32BIT : 0 > Signed : 1**** > > **** > > ** ** > > On Tue, May 7, 2013 at 9:34 AM, Chong, Petra (HARVEY NASH) < > Petra.Chong at uk.bp.com> wrote:**** > > (I also asked this on StackOverflow - > http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit-mode-on-64bit-machine-even-when-running-ipy64-exe- have copy pasted from there). > **** > > **** > > I am sure I am missing something simple but unfortunately a lot of > searching hasn't thrown up what it is..**** > > I am running Windows 7 64-bit (I verified this by looking at Control Panel > > All Control Panel Items > System and seeing that it says 64-bit Operating > System).**** > > I have IronPython 2.7.3 installed from here ( > http://ironpython.codeplex.com/downloads/get/423690)**** > > This has created the following shortcut (with no corresponding shortcut in > C:\Program Files\IronPython 2.7...):**** > > "C:\Program Files (x86)\IronPython 2.7\ipy64.exe"**** > > If I run this, I get this prompt:**** > > "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe"**** > > IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit)**** > > The docs from an older version of IronPython (2.6) at > http://ironpython.codeplex.com/releases/view/27350 say that:**** > > "A very visible new feature added to this release is that ipy.exe is now > strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR > process on both x86 and x64 operating systems. ipy64.exe, despite what its > name might imply, is a platform agnostic assembly matching the old behavior > of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit > OSes and 64-bit on 64-bit OSes."**** > > From this, I infer that ipy64 should have started as a 64 bit process, but > that's not what shows in the prompt.**** > > Any ideas what I am doing wrong? Thanks in advance..**** > > Edited to add: I have also tried running the following in the IronPython > shell, which I found from another question on this site, to check whether > the OS is 64 bit**** > > >>> import System**** > > >>> System.Environment.Is64BitOperatingSystem**** > > True**** > > ... but then I ran the following which indicates that IronPython really is > running in 32 bit mode.**** > > >>> import System**** > > >>> System.IntPtr.Size**** > > 4**** > > **** > > I have tested that I have 64-bit .NET installed by creating a console > application in Visual Studio with the line > Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". > **** > > **** > > Thanks,**** > > **** > > PC**** > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users**** > > ** ** > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Wed May 8 11:55:17 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 8 May 2013 09:55:17 +0000 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe In-Reply-To: References: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> <8C7A86EEE05F15469A5C1F5D2B49D316014FFEB9@BP1XEUEX056-C.bp1.ad.bp.com> Message-ID: <727D8E16AE957149B447FE368139F2B51A2DB6EF@SERVER10> Hi, Just as a side note: It seems that sys.float_info.min and epsilon are not correct in IronPython. Activestate Python 2.7.2: >>> sys.float_info.min 2.2250738585072014e-308 >>> sys.float_info.epsilon 2.220446049250313e-16 IronPython 2.7.3: >>> sys.float_info.min -1.7976931348623157e+308 >>> sys.float_info.epsilon 4.9406564584124654e-324 The python documentation says: min DBL_MIN minimum positive normalized float epsilon DBL_EPSILON difference between 1 and the least value greater than 1 that is representable as a float For epsilon, it might be different in .NET compared to C, but the given value is rather optimistic given that the mantissa only has 15 digits / 53 bits. :) So, it seems both values are incorrect for IronPython. 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 Vernon D. Cole Gesendet: Mittwoch, 8. Mai 2013 11:20 An: Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe I find that the following works (on all versions I have tested, including Jython): import sys def Python_is_64bit(): if sys.platform == 'cli': #IronPython import System return System.IntPtr.Size == 8 else: try: return sys.maxsize > 2147483647 except AttributeError: return sys.maxint > 2147483647 -- Vernon Cole On Wed, May 8, 2013 at 8:14 AM, Chong, Petra (HARVEY NASH) > wrote: I do indeed get output that looks like yours - c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 And if I then run this: c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 11 ILONLY : 1 32BIT : 1 Signed : 1 Thanks, PC From: Curt Hagenlocher [mailto:curt at hagenlocher.org] Sent: 07 May 2013 17:46 To: Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Subject: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe Can you use corflags.exe to confirm that your ipy64.exe is actually not marked for 32-bit execution? Your output should look like this: PS D:\Program Files\Sho\bin> corflags .\ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Version : v2.0.50727 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 On Tue, May 7, 2013 at 9:34 AM, Chong, Petra (HARVEY NASH) > wrote: (I also asked this on StackOverflow - http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit-mode-on-64bit-machine-even-when-running-ipy64-exe - have copy pasted from there). I am sure I am missing something simple but unfortunately a lot of searching hasn't thrown up what it is.. I am running Windows 7 64-bit (I verified this by looking at Control Panel > All Control Panel Items > System and seeing that it says 64-bit Operating System). I have IronPython 2.7.3 installed from here (http://ironpython.codeplex.com/downloads/get/423690) This has created the following shortcut (with no corresponding shortcut in C:\Program Files\IronPython 2.7...): "C:\Program Files (x86)\IronPython 2.7\ipy64.exe" If I run this, I get this prompt: "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe" IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit) The docs from an older version of IronPython (2.6) athttp://ironpython.codeplex.com/releases/view/27350 say that: "A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes." >From this, I infer that ipy64 should have started as a 64 bit process, but that's not what shows in the prompt. Any ideas what I am doing wrong? Thanks in advance.. Edited to add: I have also tried running the following in the IronPython shell, which I found from another question on this site, to check whether the OS is 64 bit >>> import System >>> System.Environment.Is64BitOperatingSystem True ... but then I ran the following which indicates that IronPython really is running in 32 bit mode. >>> import System >>> System.IntPtr.Size 4 I have tested that I have 64-bit .NET installed by creating a console application in Visual Studio with the line Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". Thanks, PC _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Wed May 8 13:07:36 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 8 May 2013 11:07:36 +0000 Subject: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe In-Reply-To: <727D8E16AE957149B447FE368139F2B51A2DB6EF@SERVER10> References: <8C7A86EEE05F15469A5C1F5D2B49D316014FFD40@BP1XEUEX056-C.bp1.ad.bp.com> <8C7A86EEE05F15469A5C1F5D2B49D316014FFEB9@BP1XEUEX056-C.bp1.ad.bp.com> <727D8E16AE957149B447FE368139F2B51A2DB6EF@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B51A2DB748@SERVER10> Hi, http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the problem: The double.MinValue and double.Epsilon in C# have different meanings thant DBL_MIN and DBL_EPSILON in C. I'm looking for a way how to get the wanted values... :) 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 Markus Schaber Gesendet: Mittwoch, 8. Mai 2013 11:55 An: Vernon D. Cole; Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe Hi, Just as a side note: It seems that sys.float_info.min and epsilon are not correct in IronPython. Activestate Python 2.7.2: >>> sys.float_info.min 2.2250738585072014e-308 >>> sys.float_info.epsilon 2.220446049250313e-16 IronPython 2.7.3: >>> sys.float_info.min -1.7976931348623157e+308 >>> sys.float_info.epsilon 4.9406564584124654e-324 The python documentation says: min DBL_MIN minimum positive normalized float epsilon DBL_EPSILON difference between 1 and the least value greater than 1 that is representable as a float For epsilon, it might be different in .NET compared to C, but the given value is rather optimistic given that the mantissa only has 15 digits / 53 bits. :) So, it seems both values are incorrect for IronPython. 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 Vernon D. Cole Gesendet: Mittwoch, 8. Mai 2013 11:20 An: Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe I find that the following works (on all versions I have tested, including Jython): import sys def Python_is_64bit(): if sys.platform == 'cli': #IronPython import System return System.IntPtr.Size == 8 else: try: return sys.maxsize > 2147483647 except AttributeError: return sys.maxint > 2147483647 -- Vernon Cole On Wed, May 8, 2013 at 8:14 AM, Chong, Petra (HARVEY NASH) > wrote: I do indeed get output that looks like yours - c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 And if I then run this: c:\Program Files (x86)\IronPython 2.7>c:\users\xxxxx\Downloads\corflags.exe ipy.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. Version : v4.0.30319 CLR Header: 2.5 PE : PE32 CorFlags : 11 ILONLY : 1 32BIT : 1 Signed : 1 Thanks, PC From: Curt Hagenlocher [mailto:curt at hagenlocher.org] Sent: 07 May 2013 17:46 To: Chong, Petra (HARVEY NASH) Cc: ironpython-users at python.org Subject: Re: [Ironpython-users] IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe Can you use corflags.exe to confirm that your ipy64.exe is actually not marked for 32-bit execution? Your output should look like this: PS D:\Program Files\Sho\bin> corflags .\ipy64.exe Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Version : v2.0.50727 CLR Header: 2.5 PE : PE32 CorFlags : 9 ILONLY : 1 32BIT : 0 Signed : 1 On Tue, May 7, 2013 at 9:34 AM, Chong, Petra (HARVEY NASH) > wrote: (I also asked this on StackOverflow - http://stackoverflow.com/questions/16422812/ironpython-always-in-32-bit-mode-on-64bit-machine-even-when-running-ipy64-exe - have copy pasted from there). I am sure I am missing something simple but unfortunately a lot of searching hasn't thrown up what it is.. I am running Windows 7 64-bit (I verified this by looking at Control Panel > All Control Panel Items > System and seeing that it says 64-bit Operating System). I have IronPython 2.7.3 installed from here (http://ironpython.codeplex.com/downloads/get/423690) This has created the following shortcut (with no corresponding shortcut in C:\Program Files\IronPython 2.7...): "C:\Program Files (x86)\IronPython 2.7\ipy64.exe" If I run this, I get this prompt: "c:\Projects>"C:\Program Files (x86)\IronPython 2.7\ipy64.exe" IronPython 2.7.3 (2.7.0.40) on .NET 4.0.30319.296 (32-bit) The docs from an older version of IronPython (2.6) athttp://ironpython.codeplex.com/releases/view/27350 say that: "A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes." >From this, I infer that ipy64 should have started as a 64 bit process, but that's not what shows in the prompt. Any ideas what I am doing wrong? Thanks in advance.. Edited to add: I have also tried running the following in the IronPython shell, which I found from another question on this site, to check whether the OS is 64 bit >>> import System >>> System.Environment.Is64BitOperatingSystem True ... but then I ran the following which indicates that IronPython really is running in 32 bit mode. >>> import System >>> System.IntPtr.Size 4 I have tested that I have 64-bit .NET installed by creating a console application in Visual Studio with the line Console.WriteLn(System.IntPtr.Size) and verifying that the output is "8". Thanks, PC _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Wed May 8 17:10:50 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 8 May 2013 08:10:50 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) Message-ID: On Wed, May 8, 2013 at 4:07 AM, Markus Schaber wrote: > Hi,**** > > ** ** > > http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the > problem: The double.MinValue and double.Epsilon in C# have different > meanings thant DBL_MIN and DBL_EPSILON in C.**** > > ** ** > > I'm looking for a way how to get the wanted values? J > So am I! .NET does not provide them as constants as far as I can tell. I'm pretty sure .NET requires the use of IEEE-854 floats so they could probably just be hardcoded to match the C constants but ... ick. Maybe there's a way to calculate the C versions from what .NET provides? The relevant issue is https://ironpython.codeplex.com/workitem/27840. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Wed May 8 17:33:57 2013 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 8 May 2013 08:33:57 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: Message-ID: You can get precise values of these without depending on the compiler's ability to convert text to floating point values by saying sys.float_info.min = System.BitConverter.Int64BitsToDouble(0x0010000000000000) # i.e. 2^-1023 sys.float_info.epsilon = System.BitConverter.Int64BitsToDouble(0x3cb0000000000000) # i.e. 2^-53 On Wed, May 8, 2013 at 8:10 AM, Jeff Hardy wrote: > On Wed, May 8, 2013 at 4:07 AM, Markus Schaber wrote: > >> Hi,**** >> >> ** ** >> >> http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the >> problem: The double.MinValue and double.Epsilon in C# have different >> meanings thant DBL_MIN and DBL_EPSILON in C.**** >> >> ** ** >> >> I'm looking for a way how to get the wanted values? J >> > > So am I! .NET does not provide them as constants as far as I can tell. I'm > pretty sure .NET requires the use of IEEE-854 floats so they could probably > just be hardcoded to match the C constants but ... ick. Maybe there's a way > to calculate the C versions from what .NET provides? > > The relevant issue is https://ironpython.codeplex.com/workitem/27840. > > - Jeff > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Wed May 8 18:06:10 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 8 May 2013 16:06:10 +0000 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: Message-ID: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> Hi, I tried to find a way to calculate it reliably, but did not find an easy, nice and fast way. I guess setting the IEC bits directly is the best way for now, together with a comment why we don't use the false friends provided by .NET. However, as far as I read the docs of DoubleToInt64Bits() and Int64BitsToDouble(), the conversion may be subject to endianess issues... 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: Curt Hagenlocher [mailto:curt at hagenlocher.org] Gesendet: Mittwoch, 8. Mai 2013 17:34 An: Jeff Hardy Cc: Markus Schaber; ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) You can get precise values of these without depending on the compiler's ability to convert text to floating point values by saying sys.float_info.min = System.BitConverter.Int64BitsToDouble(0x0010000000000000) # i.e. 2^-1023 sys.float_info.epsilon = System.BitConverter.Int64BitsToDouble(0x3cb0000000000000) # i.e. 2^-53 On Wed, May 8, 2013 at 8:10 AM, Jeff Hardy > wrote: On Wed, May 8, 2013 at 4:07 AM, Markus Schaber > wrote: Hi, http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the problem: The double.MinValue and double.Epsilon in C# have different meanings thant DBL_MIN and DBL_EPSILON in C. I'm looking for a way how to get the wanted values... :) So am I! .NET does not provide them as constants as far as I can tell. I'm pretty sure .NET requires the use of IEEE-854 floats so they could probably just be hardcoded to match the C constants but ... ick. Maybe there's a way to calculate the C versions from what .NET provides? The relevant issue is https://ironpython.codeplex.com/workitem/27840. - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Wed May 8 18:09:02 2013 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 8 May 2013 09:09:02 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> Message-ID: You may be able to avoid endian-ness issues by using BitConverter.ToDouble with a byte array instead. (I'm never sure how endian-ness and IEEE-754 interact.) On Wed, May 8, 2013 at 9:06 AM, Markus Schaber wrote: > Hi,**** > > ** ** > > I tried to find a way to calculate it reliably, but did not find an easy, > nice and fast way.**** > > ** ** > > I guess setting the IEC bits directly is the best way for now, together > with a comment why we don't use the false friends provided by .NET.**** > > ** ** > > However, as far as I read the docs of DoubleToInt64Bits() and > Int64BitsToDouble(), the conversion may be subject to endianess issues?*** > * > > ** ** > > Best regards > > Markus Schaber > > *CODESYS?* 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:* Curt Hagenlocher [mailto:curt at hagenlocher.org] > *Gesendet:* Mittwoch, 8. Mai 2013 17:34 > *An:* Jeff Hardy > *Cc:* Markus Schaber; ironpython-users at python.org > *Betreff:* Re: [Ironpython-users] IronPython float_info values (was: > IronPython always in 32-bit mode on 64bit machine even when running > ipy64.exe)**** > > ** ** > > You can get precise values of these without depending on the compiler's > ability to convert text to floating point values by saying**** > > **** > > sys.float_info.min = > System.BitConverter.Int64BitsToDouble(0x0010000000000000) # i.e. 2^-1023* > *** > > sys.float_info.epsilon = > System.BitConverter.Int64BitsToDouble(0x3cb0000000000000) # i.e. 2^-53**** > > **** > > ** ** > > On Wed, May 8, 2013 at 8:10 AM, Jeff Hardy wrote:**** > > On Wed, May 8, 2013 at 4:07 AM, Markus Schaber > wrote:**** > > Hi,**** > > **** > > http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the > problem: The double.MinValue and double.Epsilon in C# have different > meanings thant DBL_MIN and DBL_EPSILON in C.**** > > **** > > I'm looking for a way how to get the wanted values? J**** > > ** ** > > So am I! .NET does not provide them as constants as far as I can tell. I'm > pretty sure .NET requires the use of IEEE-854 floats so they could probably > just be hardcoded to match the C constants but ... ick. Maybe there's a way > to calculate the C versions from what .NET provides?**** > > ** ** > > The relevant issue is https://ironpython.codeplex.com/workitem/27840. **** > > ** ** > > - Jeff**** > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Wed May 8 18:15:06 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Wed, 8 May 2013 16:15:06 +0000 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> Hi, The main problem for now is that I can't test whatever solution we find, because I don't have access to any hardware with non-intel Byte Order and a Microsoft .NET. (I don't want to rely on Mono for this test...) 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: Curt Hagenlocher [mailto:curt at hagenlocher.org] Gesendet: Mittwoch, 8. Mai 2013 18:09 An: Markus Schaber Cc: Jeff Hardy; ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) You may be able to avoid endian-ness issues by using BitConverter.ToDouble with a byte array instead. (I'm never sure how endian-ness and IEEE-754 interact.) On Wed, May 8, 2013 at 9:06 AM, Markus Schaber > wrote: Hi, I tried to find a way to calculate it reliably, but did not find an easy, nice and fast way. I guess setting the IEC bits directly is the best way for now, together with a comment why we don't use the false friends provided by .NET. However, as far as I read the docs of DoubleToInt64Bits() and Int64BitsToDouble(), the conversion may be subject to endianess issues... 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: Curt Hagenlocher [mailto:curt at hagenlocher.org] Gesendet: Mittwoch, 8. Mai 2013 17:34 An: Jeff Hardy Cc: Markus Schaber; ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) You can get precise values of these without depending on the compiler's ability to convert text to floating point values by saying sys.float_info.min = System.BitConverter.Int64BitsToDouble(0x0010000000000000) # i.e. 2^-1023 sys.float_info.epsilon = System.BitConverter.Int64BitsToDouble(0x3cb0000000000000) # i.e. 2^-53 On Wed, May 8, 2013 at 8:10 AM, Jeff Hardy > wrote: On Wed, May 8, 2013 at 4:07 AM, Markus Schaber > wrote: Hi, http://www.johndcook.com/blog/2010/06/08/c-math-gotchas/ explains the problem: The double.MinValue and double.Epsilon in C# have different meanings thant DBL_MIN and DBL_EPSILON in C. I'm looking for a way how to get the wanted values... :) So am I! .NET does not provide them as constants as far as I can tell. I'm pretty sure .NET requires the use of IEEE-854 floats so they could probably just be hardcoded to match the C constants but ... ick. Maybe there's a way to calculate the C versions from what .NET provides? The relevant issue is https://ironpython.codeplex.com/workitem/27840. - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users at python.org http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Wed May 8 21:54:07 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 8 May 2013 12:54:07 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> Message-ID: On Wed, May 8, 2013 at 9:15 AM, Markus Schaber wrote: > Hi, > > > > The main problem for now is that I can't test whatever solution we find, > because I don't have access to any hardware with non-intel Byte Order and a > Microsoft .NET. (I don't want to rely on Mono for this test?) Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) or Windows Phone should do. Heck, even the emulator might do. It shouldn't be too hard to whip up an app that prints those two values, and I think Alex has a Windows Phone if he'd be willing to test it. If ARM is little-endian (or Windows/ARM runs in little-endian mode) then I don't think it matters; we'd have to try Mono on a PowerPC or something like that. - Jeff From slide.o.mix at gmail.com Wed May 8 22:44:18 2013 From: slide.o.mix at gmail.com (Slide) Date: Wed, 8 May 2013 13:44:18 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> Message-ID: Unless Microsoft really wants pain and anguish, they are likely running in little endian mode. I've never run across an ARM setup that actually runs in big endian (nor do I want to), so I'm pretty sure its little endian. I'd be more than willing to test an app on my phone since Windows Phone is crap anyway, so you couldn't damage it any worse than it is now :-) Alex On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy wrote: > On Wed, May 8, 2013 at 9:15 AM, Markus Schaber > wrote: > > Hi, > > > > > > > > The main problem for now is that I can't test whatever solution we find, > > because I don't have access to any hardware with non-intel Byte Order > and a > > Microsoft .NET. (I don't want to rely on Mono for this test?) > > Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) > or Windows Phone should do. Heck, even the emulator might do. It > shouldn't be too hard to whip up an app that prints those two values, > and I think Alex has a Windows Phone if he'd be willing to test it. > > If ARM is little-endian (or Windows/ARM runs in little-endian mode) > then I don't think it matters; we'd have to try Mono on a PowerPC or > something like that. > > - Jeff > -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hfoffani at gmail.com Wed May 8 23:09:19 2013 From: hfoffani at gmail.com (=?utf-8?Q? Hern=C3=A1n_M._F. ?=) Date: Wed, 8 May 2013 23:09:19 +0200 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> Message-ID: <126B8B65-9025-493D-94D0-985C53C96A49@gmail.com> ARM, the architecture, is endianess agnostic. But AFAIT all major OS run over little-endian processors, including all Windows flavors. Hern?n MF S El 08/05/2013, a las 22:44, Slide escribi?: > Unless Microsoft really wants pain and anguish, they are likely running in little endian mode. I've never run across an ARM setup that actually runs in big endian (nor do I want to), so I'm pretty sure its little endian. I'd be more than willing to test an app on my phone since Windows Phone is crap anyway, so you couldn't damage it any worse than it is now :-) > > Alex > > > On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy wrote: >> On Wed, May 8, 2013 at 9:15 AM, Markus Schaber wrote: >> > Hi, >> > >> > >> > >> > The main problem for now is that I can't test whatever solution we find, >> > because I don't have access to any hardware with non-intel Byte Order and a >> > Microsoft .NET. (I don't want to rely on Mono for this test?) >> >> Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) >> or Windows Phone should do. Heck, even the emulator might do. It >> shouldn't be too hard to whip up an app that prints those two values, >> and I think Alex has a Windows Phone if he'd be willing to test it. >> >> If ARM is little-endian (or Windows/ARM runs in little-endian mode) >> then I don't think it matters; we'd have to try Mono on a PowerPC or >> something like that. >> >> - Jeff > > > > -- > Website: http://earl-of-code.com > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Fri May 10 08:24:25 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 9 May 2013 23:24:25 -0700 Subject: [Ironpython-users] Conversions from pure-Python types to .NET types Message-ID: There a few cases - decimal.Decimal, uuid.UUID - where there is a type implemented in Python with a corresponding type in .NET, and right now there's no way that I know of to allow for an implicit conversion from the Python type to the .NET type when calling a .NET API. I've been pondering this a bit and I think I have a reasonable solution: class MyDecimal(object): def __clr_convert__(self, to): if to is System.Decimal: return System.Decimal(self.get_bits()) return NotImplemented NotImplemented is a standard Python value that is used to signal when comparison operators are not implemented for certain types; reusing it here seems totally natural. It can't use None because None is potentially a valid result, depending on the type. I haven't completely thought through the impact on overload resolution so this could be too naive to work, but it's worth a try at least. The issue is the cost of doing a conversion only to throw it away, but ideally implicit conversions are cheap anyway. An alternative would be similar, but with an additional hook (i.e. __clr_conversions__) that is/returns a tuple of all types that it can be converted to, so that the actual conversion isn't necessary. For motivation and some more use cases, see https://ironpython.codeplex.com/workitem/14453 and https://ironpython.codeplex.com/workitem/33830. Are there an suggestions of how else this could be handled, or any concerns with the design? If all goes well I should be able to get this into 2.7.4 (Coming Soon, I swear!), but if it's too complex I might push it to 3.0. - Jeff From vernondcole at gmail.com Fri May 10 10:10:22 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Fri, 10 May 2013 02:10:22 -0600 Subject: [Ironpython-users] Conversions from pure-Python types to .NET types In-Reply-To: References: Message-ID: Sounds simple, clean, and gives an expected result. I like the idea of using "NotImplemented". I almost like the idea of raising NotImplementedError better (it would be a noisier failure) but the documentation might lead the unwary away from the problem (a failed implicit conversion) rather than toward it, so the returned value is probably better. On Fri, May 10, 2013 at 12:24 AM, Jeff Hardy wrote: > There a few cases - decimal.Decimal, uuid.UUID - where there is a type > implemented in Python with a corresponding type in .NET, and right now > there's no way that I know of to allow for an implicit conversion from > the Python type to the .NET type when calling a .NET API. > > I've been pondering this a bit and I think I have a reasonable solution: > > class MyDecimal(object): > def __clr_convert__(self, to): > if to is System.Decimal: > return System.Decimal(self.get_bits()) > return NotImplemented > > NotImplemented is a standard Python value that is used to signal when > comparison operators are not implemented for certain types; reusing it > here seems totally natural. It can't use None because None is > potentially a valid result, depending on the type. > > I haven't completely thought through the impact on overload resolution > so this could be too naive to work, but it's worth a try at least. The > issue is the cost of doing a conversion only to throw it away, but > ideally implicit conversions are cheap anyway. An alternative would be > similar, but with an additional hook (i.e. __clr_conversions__) that > is/returns a tuple of all types that it can be converted to, so that > the actual conversion isn't necessary. > > For motivation and some more use cases, see > https://ironpython.codeplex.com/workitem/14453 > and https://ironpython.codeplex.com/workitem/33830. > > Are there an suggestions of how else this could be handled, or any > concerns with the design? If all goes well I should be able to get > this into 2.7.4 (Coming Soon, I swear!), but if it's too complex I > might push it to 3.0. > > - Jeff > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Fri May 10 10:41:07 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Fri, 10 May 2013 08:41:07 +0000 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B51A2DB9CA@SERVER10> Hi, Maybe we'd use some conditional initializiation, checking for the properties of the number, like the following: // The definition of Epsion and MinValue differ between .NET and Python/C, // so we need to define our own values. // Approx. -2.2204460492503131e-16 - the byte order reversed value is approx. // 2.2290265677773679e-319, so this code delivers the correct value independently // of the byte order of the machine. private static readonly double EPSILON = Math.Max( System.BitConverter.Int64BitsToDouble(0x3cb0000000000000), System.BitConverter.Int64BitsToDouble(0x000000000000b03c)); // Approx. 2.2250738585072014e-308 - the byte-order reversed value is approx. // 2.0236928853657458e-320, so this code delviers the correct value independently // of the byte order of the machine. private static readonly double MIN = Math.Max( System.BitConverter.Int64BitsToDouble(0x0010000000000000), System.BitConverter.Int64BitsToDouble(0x0000000000001000)); public static floatinfo float_info = new floatinfo(Double.MaxValue, 1024, 308, MIN, -1021, -307, 15, 53, EPSILON, 2, 1); This trick relies on the fact that for the given values, the reversed byte order produces an zero-Exponent, which are denormalized numbers, and in both cases, the wanted number is a normalized one which (by definition) is larger than the denormalized one. This code is as elegant as checking for the endianness explicitly, and we are even safe for machines where the integer and float endianness are different (see https://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness - although I doubt that those hardware is relevant for our user base...) :) 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: Slide [mailto:slide.o.mix at gmail.com] Gesendet: Mittwoch, 8. Mai 2013 22:44 An: Jeff Hardy Cc: Markus Schaber; Curt Hagenlocher; ironpython-users at python.org Betreff: Re: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) Unless Microsoft really wants pain and anguish, they are likely running in little endian mode. I've never run across an ARM setup that actually runs in big endian (nor do I want to), so I'm pretty sure its little endian. I'd be more than willing to test an app on my phone since Windows Phone is crap anyway, so you couldn't damage it any worse than it is now :-) Alex On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy > wrote: On Wed, May 8, 2013 at 9:15 AM, Markus Schaber > wrote: > Hi, > > > > The main problem for now is that I can't test whatever solution we find, > because I don't have access to any hardware with non-intel Byte Order and a > Microsoft .NET. (I don't want to rely on Mono for this test...) Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) or Windows Phone should do. Heck, even the emulator might do. It shouldn't be too hard to whip up an app that prints those two values, and I think Alex has a Windows Phone if he'd be willing to test it. If ARM is little-endian (or Windows/ARM runs in little-endian mode) then I don't think it matters; we'd have to try Mono on a PowerPC or something like that. - Jeff -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Fri May 10 18:14:43 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Fri, 10 May 2013 09:14:43 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: <727D8E16AE957149B447FE368139F2B51A2DB9CA@SERVER10> References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB9CA@SERVER10> Message-ID: For me, using BitConverter.IsLittleEndian is clearer: private static readonly double EPSILON = System.BitConverter.Int64BitsToDouble( System.BitConverter.IsLittleEndian ? 0x3cb0000000000000 : 0x000000000000b03c); private static readonly double MIN = System.BitConverter.Int64BitsToDouble( System.BitConverter.IsLittleEndian ? 0x0010000000000000 : 0x0000000000001000); I don't think half-endian machines are worth worrying about. :) - Jeff On Fri, May 10, 2013 at 1:41 AM, Markus Schaber wrote: > Hi, > > > > Maybe we'd use some conditional initializiation, checking for the properties > of the number, like the following: > > > > // The definition of Epsion and MinValue differ between .NET and > Python/C, > > // so we need to define our own values. > > // Approx. -2.2204460492503131e-16 - the byte order reversed value > is approx. > > // 2.2290265677773679e-319, so this code delivers the correct value > independently > > // of the byte order of the machine. > > private static readonly double EPSILON = Math.Max( > > System.BitConverter.Int64BitsToDouble(0x3cb0000000000000), > > System.BitConverter.Int64BitsToDouble(0x000000000000b03c)); > > // Approx. 2.2250738585072014e-308 - the byte-order reversed value > is approx. > > // 2.0236928853657458e-320, so this code delviers the correct value > independently > > // of the byte order of the machine. > > private static readonly double MIN = Math.Max( > > System.BitConverter.Int64BitsToDouble(0x0010000000000000), > > System.BitConverter.Int64BitsToDouble(0x0000000000001000)); > > > > public static floatinfo float_info = new floatinfo(Double.MaxValue, > 1024, 308, MIN, -1021, -307, 15, 53, EPSILON, 2, 1); > > > > This trick relies on the fact that for the given values, the reversed byte > order produces an zero-Exponent, which are denormalized numbers, and in both > cases, the wanted number is a normalized one which (by definition) is larger > than the denormalized one. > > > > This code is as elegant as checking for the endianness explicitly, and we > are even safe for machines where the integer and float endianness are > different (see > https://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness ? > although I doubt that those hardware is relevant for our user base?) J > > > > > > > > Best regards > > Markus Schaber > > CODESYS? 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: Slide [mailto:slide.o.mix at gmail.com] > Gesendet: Mittwoch, 8. Mai 2013 22:44 > An: Jeff Hardy > Cc: Markus Schaber; Curt Hagenlocher; ironpython-users at python.org > > > Betreff: Re: [Ironpython-users] IronPython float_info values (was: > IronPython always in 32-bit mode on 64bit machine even when running > ipy64.exe) > > > > Unless Microsoft really wants pain and anguish, they are likely running in > little endian mode. I've never run across an ARM setup that actually runs in > big endian (nor do I want to), so I'm pretty sure its little endian. I'd be > more than willing to test an app on my phone since Windows Phone is crap > anyway, so you couldn't damage it any worse than it is now :-) > > > > Alex > > > > On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy wrote: > > On Wed, May 8, 2013 at 9:15 AM, Markus Schaber > wrote: >> Hi, >> >> >> > >> The main problem for now is that I can't test whatever solution we find, >> because I don't have access to any hardware with non-intel Byte Order and >> a >> Microsoft .NET. (I don't want to rely on Mono for this test?) > > Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) > or Windows Phone should do. Heck, even the emulator might do. It > shouldn't be too hard to whip up an app that prints those two values, > and I think Alex has a Windows Phone if he'd be willing to test it. > > If ARM is little-endian (or Windows/ARM runs in little-endian mode) > then I don't think it matters; we'd have to try Mono on a PowerPC or > something like that. > > - Jeff > > > > > > -- > Website: http://earl-of-code.com > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > From notifications at codeplex.com Sat May 11 08:30:57 2013 From: notifications at codeplex.com (CodePlex) Date: 10 May 2013 23:30:57 -0700 Subject: [Ironpython-users] User added as Contributor to your CodePlex project, ironpython Message-ID: An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Sat May 11 08:39:11 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Fri, 10 May 2013 23:39:11 -0700 Subject: [Ironpython-users] Conversions from pure-Python types to .NET types In-Reply-To: References: Message-ID: On Fri, May 10, 2013 at 1:10 AM, Vernon D. Cole wrote: > Sounds simple, clean, and gives an expected result. I like the idea of > using "NotImplemented". > I almost like the idea of raising NotImplementedError better (it would be > a noisier failure) but the documentation might lead the unwary away from the > problem (a failed implicit conversion) rather than toward it, so the > returned value is probably better. Well, failure is going to be pretty common, so I don't want it to be too noisy. I haven't completely figured out the proper conversion order but I think __clr_convert__ will have to first, and then __int__, __str__, etc. In addition, using the same idiom as __lt__ et al. should make it at least familiar. - Jeff From jdhardy at gmail.com Sat May 11 08:58:35 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Fri, 10 May 2013 23:58:35 -0700 Subject: [Ironpython-users] Announcing IronPython 2.7.4 Alpha 1! Message-ID: On behalf of the IronPython team, I'm happy to announce the first alpha release of IronPython 2.7.4. This release includes everything from IronPython 2.7.3 and earlier. Like all IronPython 2.7-series releases, .NET 4 is required to install it. Installing this release will replace any existing IronPython 2.7-series installation. Improvements in IronPython 2.7.4 are mainly a collection of bug fixes, many of which are directed at getting IPython working, although it's not there yet. Android and Silverlight 4 assemblies have been dropped from this version. The Android assemblies need some more work to be usable with Xamarin.Android, ans Silverlight 4 is just plain dead. For Visual Studio integration, check out Python Tools for Visual Studio which has support for IronPython as well as CPython, and many other fantastic features. IronPython 2.7.3 is also available for embedding via NuGet. The main package is IronPython, and the standard library is in IronPython.StdLib. Because this is a prerelease package, you must use -IncludePrerelease on the command line or select "Include Prerelease" from the package drop-down menu. A huge thanks goes out to Pawel Jasinski, Michael van der Kolff, and Aleksander Heintz, who contributed most of the packages for this release. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Sat May 11 09:01:38 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Sat, 11 May 2013 00:01:38 -0700 Subject: [Ironpython-users] Announcing IronPython 2.7.4 Alpha 1! In-Reply-To: References: Message-ID: Also, there's a few other things I'd like to do before 2.7.4 final - mainly, once and for all, get packaging (distribute/pip/etc.) to work. Also, virtualenv and full IPython support would be nice. Better Mono support would help a lot of people. The test suite is still much less reliable than I would like. There's a lot of options, and as always, I'm willing to help anyone that wants to volunteer; a lot of this stuff doesn't require digging into the real guts of IronPython. There's also some housekeeping tasks - the IronPython domains are now maintained by the Python Software Foundation, and I'd like to get the website off of MS infrastructure and onto GitHub pages or similar. Finally, my long dormant docs project should come back to life. Right now, it's quite possible that 2.7.4 will be the last 2.7 release; I've been looking at Python 3 features, and I want them badly for something I'm working on, so this summer and fall I'm going to focus on Python 3 (as much as possible, at least, during the few good months of weather that Seattle gets). Anyway, download the alpha, see what works and what breaks, and let me know so that we can get it fixed. - Jeff On Fri, May 10, 2013 at 11:58 PM, Jeff Hardy wrote: > On behalf of the IronPython team, I'm happy to announce the first alpha > release of IronPython 2.7.4. > This release includes everything from IronPython 2.7.3 and > earlier. Like all IronPython 2.7-series releases, .NET 4 is required to > install it. Installing this release will replace any existing IronPython > 2.7-series installation. > > Improvements in IronPython 2.7.4 are mainly a collection of bug fixes, > many of which are directed at getting IPython working, > although it's not there yet. > > Android and Silverlight 4 assemblies have been dropped from this version. > The Android assemblies need some more work to be usable with > Xamarin.Android, ans Silverlight 4 is just plain dead. > > For Visual Studio integration, check out Python Tools for Visual Studio which > has support for IronPython as well as CPython, and many other fantastic > features. > > IronPython 2.7.3 is also available for embedding via NuGet. > The main package is IronPython, and the standard library is in > IronPython.StdLib. Because this is a prerelease package, you must use > -IncludePrerelease on the command line or select "Include Prerelease" > from the package drop-down menu. > > A huge thanks goes out to Pawel Jasinski, Michael van der Kolff, and > Aleksander Heintz, who contributed most of the packages for this release. > > - Jeff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Sat May 11 09:18:02 2013 From: no_reply at codeplex.com (CodePlex) Date: 11 May 2013 00:18:02 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/10/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] sys.stdout.isatty() always returns True 2. [New comment] Lower casing non-ASCII characters does not work 3. [New comment] introduce support for readline module (raw input) 4. [New comment] match cpython behaviour - types.ModuleType() 5. [New comment] locale.setlocale does not detect/set default user locale 6. [New comment] TypeError: instancemethod.__cmp__(x,y) requires y to be a 'instancemethod', not a ... 7. [New comment] struct.pack not threadsafe 8. [New comment] IronPython: Python.CreateEngine blocking on Windows 8 ---------------------------------------------- ISSUES 1. [New comment] sys.stdout.isatty() always returns True http://ironpython.codeplex.com/workitem/33123 User jdhardy has commented on the issue: "

Fixed in c02becc.Fixed in c02becc.Fixed in dbfd060.Fixed in ab42602.Fixed in 2371b5d.Fixed in 1f4c7ee.Fixed in 86a3f79.Ok,

Here is some sample code that isolate and reproduce both the problem and the workaround.
It is composed of 3 projects:
CmdLineService (used to host the service in a command line, very handy for debugging)
IronPythonServiceHost (The Windows Service. Look at IronPythonServiceHost.cs to reproduce the problem)
IronPythonWcfServiceLibrary (A naive WCF service implementation used to reproduce the problem)

What's not inside:
IronPython assemblies. You'll have to add references for these in IronPythonWcfServiceLibrary.

To run it:
You must run Visual Studio with admin privileges.
Set IronPythonServiceHost as a startup project. Then go into it's poject properties. In the debug tab,
add /c as a command line argument.
From slide.o.mix at gmail.com Sun May 12 23:41:54 2013 From: slide.o.mix at gmail.com (Slide) Date: Sun, 12 May 2013 14:41:54 -0700 Subject: [Ironpython-users] Announcing IronPython 2.7.4 Alpha 1! In-Reply-To: References: Message-ID: Jeff, What is your timeline for moving to Github pages and issues? I still have the cp2gh script lying around, it may need some updates if there have been changes to CodePlex or the GH API. Alex On Sat, May 11, 2013 at 12:01 AM, Jeff Hardy wrote: > Also, there's a few other things I'd like to do before 2.7.4 final - > mainly, once and for all, get packaging (distribute/pip/etc.) to work. > Also, virtualenv and full IPython support would be nice. Better Mono > support would help a lot of people. The test suite is still much less > reliable than I would like. There's a lot of options, and as always, I'm > willing to help anyone that wants to volunteer; a lot of this stuff doesn't > require digging into the real guts of IronPython. > > There's also some housekeeping tasks - the IronPython domains are now > maintained by the Python Software Foundation, and I'd like to get the > website off of MS infrastructure and onto GitHub pages or similar. Finally, > my long dormant docs project should come back to life. > > Right now, it's quite possible that 2.7.4 will be the last 2.7 release; > I've been looking at Python 3 features, and I want them badly for something > I'm working on, so this summer and fall I'm going to focus on Python 3 (as > much as possible, at least, during the few good months of weather that > Seattle gets). > > Anyway, download the alpha, see what works and what breaks, and let me > know so that we can get it fixed. > > - Jeff > > > On Fri, May 10, 2013 at 11:58 PM, Jeff Hardy wrote: > >> On behalf of the IronPython team, I'm happy to announce the first alpha >> release of IronPython 2.7.4. >> This release includes everything from IronPython 2.7.3 and >> earlier. Like all IronPython 2.7-series releases, .NET 4 is required to >> install it. Installing this release will replace any existing IronPython >> 2.7-series installation. >> >> Improvements in IronPython 2.7.4 are mainly a collection of bug fixes, >> many of which are directed at getting IPython working, >> although it's not there yet. >> >> Android and Silverlight 4 assemblies have been dropped from this version. >> The Android assemblies need some more work to be usable with >> Xamarin.Android, ans Silverlight 4 is just plain dead. >> >> For Visual Studio integration, check out Python Tools for Visual Studio which >> has support for IronPython as well as CPython, and many other fantastic >> features. >> >> IronPython 2.7.3 is also available for embedding via NuGet. >> The main package is IronPython, and the standard library is in >> IronPython.StdLib. Because this is a prerelease package, you must use >> -IncludePrerelease on the command line or select "Include Prerelease" >> from the package drop-down menu. >> >> A huge thanks goes out to Pawel Jasinski, Michael van der Kolff, and >> Aleksander Heintz, who contributed most of the packages for this release. >> >> - Jeff >> > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Mon May 13 16:16:54 2013 From: m.schaber at codesys.com (Markus Schaber) Date: Mon, 13 May 2013 14:16:54 +0000 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB9CA@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B51A2DD142@SERVER10> Hi, Is anyone with commit access willing to commit the fix? And possibly include it in the upcoming 2.7.4? :-) Thanks :-) 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: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 > Von: Jeff Hardy [mailto:jdhardy at gmail.com] > Gesendet: Freitag, 10. Mai 2013 18:15 > An: Markus Schaber > Cc: ironpython-users at python.org > Betreff: Re: [Ironpython-users] IronPython float_info values (was: > IronPython always in 32-bit mode on 64bit machine even when running > ipy64.exe) > > For me, using BitConverter.IsLittleEndian is clearer: > > private static readonly double EPSILON = > System.BitConverter.Int64BitsToDouble( > System.BitConverter.IsLittleEndian ? 0x3cb0000000000000 : > 0x000000000000b03c); > > private static readonly double MIN = > System.BitConverter.Int64BitsToDouble( > System.BitConverter.IsLittleEndian ? 0x0010000000000000 : > 0x0000000000001000); > > I don't think half-endian machines are worth worrying about. :) > > - Jeff > > > On Fri, May 10, 2013 at 1:41 AM, Markus Schaber > wrote: > > Hi, > > > > > > > > Maybe we'd use some conditional initializiation, checking for the > > properties of the number, like the following: > > > > > > > > // The definition of Epsion and MinValue differ > between .NET > > and Python/C, > > > > // so we need to define our own values. > > > > // Approx. -2.2204460492503131e-16 - the byte order > reversed > > value is approx. > > > > // 2.2290265677773679e-319, so this code delivers the > correct > > value independently > > > > // of the byte order of the machine. > > > > private static readonly double EPSILON = Math.Max( > > > > > System.BitConverter.Int64BitsToDouble(0x3cb0000000000000), > > > > > > System.BitConverter.Int64BitsToDouble(0x000000000000b03c)); > > > > // Approx. 2.2250738585072014e-308 - the byte-order > reversed > > value is approx. > > > > // 2.0236928853657458e-320, so this code delviers the > correct > > value independently > > > > // of the byte order of the machine. > > > > private static readonly double MIN = Math.Max( > > > > > System.BitConverter.Int64BitsToDouble(0x0010000000000000), > > > > > > System.BitConverter.Int64BitsToDouble(0x0000000000001000)); > > > > > > > > public static floatinfo float_info = new > > floatinfo(Double.MaxValue, 1024, 308, MIN, -1021, -307, 15, 53, > > EPSILON, 2, 1); > > > > > > > > This trick relies on the fact that for the given values, the > reversed > > byte order produces an zero-Exponent, which are denormalized > numbers, > > and in both cases, the wanted number is a normalized one which (by > > definition) is larger than the denormalized one. > > > > > > > > This code is as elegant as checking for the endianness explicitly, > and > > we are even safe for machines where the integer and float > endianness > > are different (see > > https://en.wikipedia.org/wiki/Endianness#Floating- > point_and_endianness > > - although I doubt that those hardware is relevant for our user > base...) > > J > > > > > > > > > > > > > > > > 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: Slide [mailto:slide.o.mix at gmail.com] > > Gesendet: Mittwoch, 8. Mai 2013 22:44 > > An: Jeff Hardy > > Cc: Markus Schaber; Curt Hagenlocher; ironpython-users at python.org > > > > > > Betreff: Re: [Ironpython-users] IronPython float_info values (was: > > IronPython always in 32-bit mode on 64bit machine even when running > > ipy64.exe) > > > > > > > > Unless Microsoft really wants pain and anguish, they are likely > > running in little endian mode. I've never run across an ARM setup > that > > actually runs in big endian (nor do I want to), so I'm pretty sure > its > > little endian. I'd be more than willing to test an app on my phone > > since Windows Phone is crap anyway, so you couldn't damage it any > > worse than it is now :-) > > > > > > > > Alex > > > > > > > > On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy > wrote: > > > > On Wed, May 8, 2013 at 9:15 AM, Markus Schaber > > > wrote: > >> Hi, > >> > >> > >> > > > >> The main problem for now is that I can't test whatever solution we > >> find, because I don't have access to any hardware with non-intel > Byte > >> Order and a Microsoft .NET. (I don't want to rely on Mono for this > >> test...) > > > > Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) > > or Windows Phone should do. Heck, even the emulator might do. It > > shouldn't be too hard to whip up an app that prints those two > values, > > and I think Alex has a Windows Phone if he'd be willing to test it. > > > > If ARM is little-endian (or Windows/ARM runs in little-endian mode) > > then I don't think it matters; we'd have to try Mono on a PowerPC > or > > something like that. > > > > - Jeff > > > > > > > > > > > > -- > > Website: http://earl-of-code.com > > > > > > _______________________________________________ > > Ironpython-users mailing list > > Ironpython-users at python.org > > http://mail.python.org/mailman/listinfo/ironpython-users > > From slide.o.mix at gmail.com Mon May 13 16:29:02 2013 From: slide.o.mix at gmail.com (Slide) Date: Mon, 13 May 2013 07:29:02 -0700 Subject: [Ironpython-users] IronPython float_info values (was: IronPython always in 32-bit mode on 64bit machine even when running ipy64.exe) In-Reply-To: <727D8E16AE957149B447FE368139F2B51A2DD142@SERVER10> References: <727D8E16AE957149B447FE368139F2B51A2DB85E@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB877@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DB9CA@SERVER10> <727D8E16AE957149B447FE368139F2B51A2DD142@SERVER10> Message-ID: Pull requests are always welcome :-) On Mon, May 13, 2013 at 7:16 AM, Markus Schaber wrote: > Hi, > > Is anyone with commit access willing to commit the fix? And possibly > include it in the upcoming 2.7.4? :-) > > Thanks :-) > > 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: http://www.codesys.com | CODESYS > store: http://store.codesys.com > CODESYS forum: http://forum.codesys.com > > Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | > Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 > > Von: Jeff Hardy [mailto:jdhardy at gmail.com] > > Gesendet: Freitag, 10. Mai 2013 18:15 > > An: Markus Schaber > > Cc: ironpython-users at python.org > > Betreff: Re: [Ironpython-users] IronPython float_info values (was: > > IronPython always in 32-bit mode on 64bit machine even when running > > ipy64.exe) > > > > For me, using BitConverter.IsLittleEndian is clearer: > > > > private static readonly double EPSILON = > > System.BitConverter.Int64BitsToDouble( > > System.BitConverter.IsLittleEndian ? 0x3cb0000000000000 : > > 0x000000000000b03c); > > > > private static readonly double MIN = > > System.BitConverter.Int64BitsToDouble( > > System.BitConverter.IsLittleEndian ? 0x0010000000000000 : > > 0x0000000000001000); > > > > I don't think half-endian machines are worth worrying about. :) > > > > - Jeff > > > > > > On Fri, May 10, 2013 at 1:41 AM, Markus Schaber > > wrote: > > > Hi, > > > > > > > > > > > > Maybe we'd use some conditional initializiation, checking for the > > > properties of the number, like the following: > > > > > > > > > > > > // The definition of Epsion and MinValue differ > > between .NET > > > and Python/C, > > > > > > // so we need to define our own values. > > > > > > // Approx. -2.2204460492503131e-16 - the byte order > > reversed > > > value is approx. > > > > > > // 2.2290265677773679e-319, so this code delivers the > > correct > > > value independently > > > > > > // of the byte order of the machine. > > > > > > private static readonly double EPSILON = Math.Max( > > > > > > > > System.BitConverter.Int64BitsToDouble(0x3cb0000000000000), > > > > > > > > > System.BitConverter.Int64BitsToDouble(0x000000000000b03c)); > > > > > > // Approx. 2.2250738585072014e-308 - the byte-order > > reversed > > > value is approx. > > > > > > // 2.0236928853657458e-320, so this code delviers the > > correct > > > value independently > > > > > > // of the byte order of the machine. > > > > > > private static readonly double MIN = Math.Max( > > > > > > > > System.BitConverter.Int64BitsToDouble(0x0010000000000000), > > > > > > > > > System.BitConverter.Int64BitsToDouble(0x0000000000001000)); > > > > > > > > > > > > public static floatinfo float_info = new > > > floatinfo(Double.MaxValue, 1024, 308, MIN, -1021, -307, 15, 53, > > > EPSILON, 2, 1); > > > > > > > > > > > > This trick relies on the fact that for the given values, the > > reversed > > > byte order produces an zero-Exponent, which are denormalized > > numbers, > > > and in both cases, the wanted number is a normalized one which (by > > > definition) is larger than the denormalized one. > > > > > > > > > > > > This code is as elegant as checking for the endianness explicitly, > > and > > > we are even safe for machines where the integer and float > > endianness > > > are different (see > > > https://en.wikipedia.org/wiki/Endianness#Floating- > > point_and_endianness > > > - although I doubt that those hardware is relevant for our user > > base...) > > > J > > > > > > > > > > > > > > > > > > > > > > > > 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: Slide [mailto:slide.o.mix at gmail.com] > > > Gesendet: Mittwoch, 8. Mai 2013 22:44 > > > An: Jeff Hardy > > > Cc: Markus Schaber; Curt Hagenlocher; ironpython-users at python.org > > > > > > > > > Betreff: Re: [Ironpython-users] IronPython float_info values (was: > > > IronPython always in 32-bit mode on 64bit machine even when running > > > ipy64.exe) > > > > > > > > > > > > Unless Microsoft really wants pain and anguish, they are likely > > > running in little endian mode. I've never run across an ARM setup > > that > > > actually runs in big endian (nor do I want to), so I'm pretty sure > > its > > > little endian. I'd be more than willing to test an app on my phone > > > since Windows Phone is crap anyway, so you couldn't damage it any > > > worse than it is now :-) > > > > > > > > > > > > Alex > > > > > > > > > > > > On Wed, May 8, 2013 at 12:54 PM, Jeff Hardy > > wrote: > > > > > > On Wed, May 8, 2013 at 9:15 AM, Markus Schaber > > > > > wrote: > > >> Hi, > > >> > > >> > > >> > > > > > >> The main problem for now is that I can't test whatever solution we > > >> find, because I don't have access to any hardware with non-intel > > Byte > > >> Order and a Microsoft .NET. (I don't want to rely on Mono for this > > >> test...) > > > > > > Is ARM big-endian? If so, any Windows 8 ARM tablet (i.e. Surface RT) > > > or Windows Phone should do. Heck, even the emulator might do. It > > > shouldn't be too hard to whip up an app that prints those two > > values, > > > and I think Alex has a Windows Phone if he'd be willing to test it. > > > > > > If ARM is little-endian (or Windows/ARM runs in little-endian mode) > > > then I don't think it matters; we'd have to try Mono on a PowerPC > > or > > > something like that. > > > > > > - Jeff > > > > > > > > > > > > > > > > > > -- > > > Website: http://earl-of-code.com > > > > > > > > > _______________________________________________ > > > Ironpython-users mailing list > > > Ironpython-users at python.org > > > http://mail.python.org/mailman/listinfo/ironpython-users > > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Mon May 13 17:28:54 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 13 May 2013 08:28:54 -0700 Subject: [Ironpython-users] Announcing IronPython 2.7.4 Alpha 1! In-Reply-To: References: Message-ID: On Sun, May 12, 2013 at 2:41 PM, Slide wrote: > Jeff, > > What is your timeline for moving to Github pages and issues? I still have > the cp2gh script lying around, it may need some updates if there have been > changes to CodePlex or the GH API. > I've been trying to decide whether to do it before or after 2.7.4; right now I'm leaning towards before, in the next couple of weeks. How long does it take to run the script? - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Mon May 13 17:33:44 2013 From: slide.o.mix at gmail.com (Slide) Date: Mon, 13 May 2013 08:33:44 -0700 Subject: [Ironpython-users] Announcing IronPython 2.7.4 Alpha 1! In-Reply-To: References: Message-ID: Not that long, an hour or two at most I think. Alex On Mon, May 13, 2013 at 8:28 AM, Jeff Hardy wrote: > On Sun, May 12, 2013 at 2:41 PM, Slide wrote: > >> Jeff, >> >> What is your timeline for moving to Github pages and issues? I still have >> the cp2gh script lying around, it may need some updates if there have been >> changes to CodePlex or the GH API. >> > > I've been trying to decide whether to do it before or after 2.7.4; right > now I'm leaning towards before, in the next couple of weeks. How long does > it take to run the script? > > - Jeff > > -- Website: http://earl-of-code.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Fri May 17 10:06:46 2013 From: no_reply at codeplex.com (CodePlex) Date: 17 May 2013 01:06:46 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/16/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [Status update] Trivial: Light Grey Text in ipy when running on Linux or Solaris 2. [Status update] Source code encoding is not working correctly 3. [Status update] Cleanup "Windows Form Tutorial"; making it more Pythonic 4. [Status update] Still doesn't recognise *valid* PEP0263 codings in source files 5. [Status update] Create a FULLY StandAlone ".exe" binary? 6. [Status update] Incompat: Cannot use re module on bytearray objects 7. [Status update] Implement _bisect module 8. [Status update] Implement winsound module 9. [Status update] Implement bz2 module 10. [Status update] Trivial: isdigit() return "False" in IronPython with unicode object from u'\u2460' to u'\u2468' 11. [Status update] AttributeError: 'struct_time' object has no attribute 'n_fields' 12. [Status update] _ssl.RAND_add(x, y) should throw TypeError when x=None 13. [Status update] Exception().__doc__ different from CPython 14. [Status update] Pyc.py and FolderBrowserDialog 15. [Status update] Hashing objects can not be created from bytearrays with 2.7 16. [Status update] StackOverflowException when subclassing dict.add and dict.__setitem__ 17. [Status update] Compatibility: IronPython does not allow space before coding declaration 18. [Status update] sys.args[0] dissapears in ipy-script compiled with pyc.py 19. [Status update] [2.7 Beta 2] deepcopy(time(9, 0)) != time(9, 0) 20. [Status update] NullReference bug report 21. [Status update] zlib fails to compress an empty string 22. [Status update] zipimport adding an extra newline to the end of every line of imported source on windows 23. [Status update] Patch for pyc.py 24. [Status update] ast module is broken - TypeError: object.__new__() takes no parameters 25. [Status update] 2.7.2.1: ast.py fails on Lib/subprocess.py 26. [Status update] 2.7.2.1 "load language" problem 27. [Status update] compile does not accept AST object 28. [Status update] Duplicate key in dict 29. [Status update] IronPython engine fails to load under Silverlight (MethodAccessException) 30. [Status update] Occasional build error for Silverlight targets 31. [Status update] signal module does not work on non-Windows machines 32. [Status update] Add AssemblyFoldersEx paths for other platforms 33. [Status update] PEP 421 -- Adding sys.implementation 34. [Status update] IronPython coding obeys PEP0263, inconsistent with Emacs 35. [Status update] SQLite: InterfaceError: Unable to bind parameter 1 - unsupported type 36. [Status update] sys.stdout.isatty() always returns True 37. [Status update] Lower casing non-ASCII characters does not work 38. [Status update] introduce support for readline module (raw input) 39. [Status update] match cpython behaviour - types.ModuleType() 40. [Status update] locale.setlocale does not detect/set default user locale 41. [Status update] TypeError: instancemethod.__cmp__(x,y) requires y to be a 'instancemethod', not a ... 42. [Status update] super() does not preserve class 43. [Status update] struct.pack not threadsafe 44. [Status update] ast: elif is missing lineno and col_offset attributes 45. [Status update] PythonDictionary.Contains(KeyValuePair) doesn't check value 46. [New comment] CreateEngine never returns 47. [New issue] CPython in IronPython 48. [Status update] CPython in IronPython ---------------------------------------------- ISSUES 1. [Status update] Trivial: Light Grey Text in ipy when running on Linux or Solaris http://ironpython.codeplex.com/workitem/3825 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 2. [Status update] Source code encoding is not working correctly http://ironpython.codeplex.com/workitem/18637 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 3. [Status update] Cleanup "Windows Form Tutorial"; making it more Pythonic http://ironpython.codeplex.com/workitem/19488 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 4. [Status update] Still doesn't recognise *valid* PEP0263 codings in source files http://ironpython.codeplex.com/workitem/19861 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 5. [Status update] Create a FULLY StandAlone ".exe" binary? http://ironpython.codeplex.com/workitem/20621 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 6. [Status update] Incompat: Cannot use re module on bytearray objects http://ironpython.codeplex.com/workitem/21362 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 7. [Status update] Implement _bisect module http://ironpython.codeplex.com/workitem/21392 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 8. [Status update] Implement winsound module http://ironpython.codeplex.com/workitem/21405 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 9. [Status update] Implement bz2 module http://ironpython.codeplex.com/workitem/21412 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 10. [Status update] Trivial: isdigit() return "False" in IronPython with unicode object from u'\u2460' to u'\u2468' http://ironpython.codeplex.com/workitem/23855 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 11. [Status update] AttributeError: 'struct_time' object has no attribute 'n_fields' http://ironpython.codeplex.com/workitem/23861 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 12. [Status update] _ssl.RAND_add(x, y) should throw TypeError when x=None http://ironpython.codeplex.com/workitem/24276 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 13. [Status update] Exception().__doc__ different from CPython http://ironpython.codeplex.com/workitem/25155 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 14. [Status update] Pyc.py and FolderBrowserDialog http://ironpython.codeplex.com/workitem/27118 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 15. [Status update] Hashing objects can not be created from bytearrays with 2.7 http://ironpython.codeplex.com/workitem/27903 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 16. [Status update] StackOverflowException when subclassing dict.add and dict.__setitem__ http://ironpython.codeplex.com/workitem/28084 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 17. [Status update] Compatibility: IronPython does not allow space before coding declaration http://ironpython.codeplex.com/workitem/29193 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 18. [Status update] sys.args[0] dissapears in ipy-script compiled with pyc.py http://ironpython.codeplex.com/workitem/30263 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 19. [Status update] [2.7 Beta 2] deepcopy(time(9, 0)) != time(9, 0) http://ironpython.codeplex.com/workitem/30274 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 20. [Status update] NullReference bug report http://ironpython.codeplex.com/workitem/31621 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 21. [Status update] zlib fails to compress an empty string http://ironpython.codeplex.com/workitem/31976 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 22. [Status update] zipimport adding an extra newline to the end of every line of imported source on windows http://ironpython.codeplex.com/workitem/32335 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 23. [Status update] Patch for pyc.py http://ironpython.codeplex.com/workitem/32372 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 24. [Status update] ast module is broken - TypeError: object.__new__() takes no parameters http://ironpython.codeplex.com/workitem/32408 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 25. [Status update] 2.7.2.1: ast.py fails on Lib/subprocess.py http://ironpython.codeplex.com/workitem/32446 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 26. [Status update] 2.7.2.1 "load language" problem http://ironpython.codeplex.com/workitem/32452 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 27. [Status update] compile does not accept AST object http://ironpython.codeplex.com/workitem/32526 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 28. [Status update] Duplicate key in dict http://ironpython.codeplex.com/workitem/32527 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 29. [Status update] IronPython engine fails to load under Silverlight (MethodAccessException) http://ironpython.codeplex.com/workitem/32596 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 30. [Status update] Occasional build error for Silverlight targets http://ironpython.codeplex.com/workitem/32602 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 31. [Status update] signal module does not work on non-Windows machines http://ironpython.codeplex.com/workitem/32627 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 32. [Status update] Add AssemblyFoldersEx paths for other platforms http://ironpython.codeplex.com/workitem/32749 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 33. [Status update] PEP 421 -- Adding sys.implementation http://ironpython.codeplex.com/workitem/32786 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 34. [Status update] IronPython coding obeys PEP0263, inconsistent with Emacs http://ironpython.codeplex.com/workitem/32856 User slide_o_mix has updated the issue: Status has changed from Fixed to Closed. ----------------- 35. [Status update] SQLite: InterfaceError: Unable to bind parameter 1 - unsupported type http://ironpython.codeplex.com/workitem/32884 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 36. [Status update] sys.stdout.isatty() always returns True http://ironpython.codeplex.com/workitem/33123 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 37. [Status update] Lower casing non-ASCII characters does not work http://ironpython.codeplex.com/workitem/33133 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 38. [Status update] introduce support for readline module (raw input) http://ironpython.codeplex.com/workitem/33164 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 39. [Status update] match cpython behaviour - types.ModuleType() http://ironpython.codeplex.com/workitem/33173 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 40. [Status update] locale.setlocale does not detect/set default user locale http://ironpython.codeplex.com/workitem/33220 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 41. [Status update] TypeError: instancemethod.__cmp__(x,y) requires y to be a 'instancemethod', not a ... http://ironpython.codeplex.com/workitem/33622 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 42. [Status update] super() does not preserve class http://ironpython.codeplex.com/workitem/33663 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 43. [Status update] struct.pack not threadsafe http://ironpython.codeplex.com/workitem/33720 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 44. [Status update] ast: elif is missing lineno and col_offset attributes http://ironpython.codeplex.com/workitem/33725 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 45. [Status update] PythonDictionary.Contains(KeyValuePair) doesn't check value http://ironpython.codeplex.com/workitem/33904 User jdhardy has updated the issue: Status has changed from Fixed to Closed. ----------------- 46. [New comment] CreateEngine never returns http://ironpython.codeplex.com/workitem/34024 User jdhardy has commented on the issue: "

This might be related to https://ironpython.codeplex.com/workitem/34020. Can you provide a complete example and what version of Visual Studio you're using? From no_reply at codeplex.com Sat May 18 09:18:40 2013 From: no_reply at codeplex.com (CodePlex) Date: 18 May 2013 00:18:40 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/17/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New issue] IronPython pyc.py -> .exe : How to compile programs using external dlls ---------------------------------------------- ISSUES 1. [New issue] IronPython pyc.py -> .exe : How to compile programs using external dlls http://ironpython.codeplex.com/workitem/34064 User 27Sergio27 has proposed the issue: "Hello, I am starting to use the pyc.py file to create a .exe file of my IronPython project. It seems that pyc.py cannot deal with programs that use external dlls. To be clear here are examples of something that worked and something that didn't: program1.py : print 'hello world' raw_input('--->') I managed to make a .exe file of program1.py which worked by using the following command: ipy pyc.py /main:program1.py /target:exe Now here is program2.py : from clr import AddReferenceToFile AddReferenceToFile ('myExternalDllForProgram2.dll') raw_input('--->') I managed to make a .exe file of program2.py using the same command that for program1.py. Problem is, the .exe file does not work (the result box writes a lot of things and fails at some point). Of course, myExternalDllForProgram2.dll was put in the folder with the .exe file and its dll (and with these dlls as well: IronPython.dll, IronPython.Modules.dll, Microsoft.Scripting.Metadata.dll, Microsoft.Scripting.dll, Microsoft.Dynamic.dll) Does any one have an idea of what could have gone 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 no_reply at codeplex.com Sun May 19 09:17:45 2013 From: no_reply at codeplex.com (CodePlex) Date: 19 May 2013 00:17:45 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/18/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] IronPython pyc.py -> .exe : How to compile programs using external dlls ---------------------------------------------- ISSUES 1. [New comment] IronPython pyc.py -> .exe : How to compile programs using external dlls http://ironpython.codeplex.com/workitem/34064 User slide_o_mix has commented on the issue: "

Please use the mailing list for questions. From jdhardy at gmail.com Thu May 23 17:30:20 2013 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 23 May 2013 08:30:20 -0700 Subject: [Ironpython-users] Easy IronPython contribution opportunity Message-ID: I've had a couple of people ask me recently the easiest way to get involved with IronPython, and I didn't have a concrete answer. However, I found one this morning: fixing https://ironpython.codeplex.com/workitem/7267. The nt module is incomplete, and CPython provides all of the missing functions on Windows, so IronPython should too. The only tricky part is that it may require some p/invoking, but since nt is Windows-only it should be straightforward. As always, I'm willing to help anyone who wants to get started. - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Sat May 25 09:16:48 2013 From: no_reply at codeplex.com (CodePlex) Date: 25 May 2013 00:16:48 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/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] sys.platform under Silverlight returns wrong value ---------------------------------------------- ISSUES 1. [New issue] sys.platform under Silverlight returns wrong value http://ironpython.codeplex.com/workitem/34085 User alesprimozic has proposed the issue: "sys.platform in version 2.7.3 of IronPython running in Silverlight application returns a wrong value. In 2.7.1 sys.platform would return "silverlight". In 2.7.3 "cli" is returned." ---------------------------------------------- ---------------------------------------------- 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 notifications at codeplex.com Sun May 26 19:17:22 2013 From: notifications at codeplex.com (CodePlex) Date: 26 May 2013 10:17:22 -0700 Subject: [Ironpython-users] User added as Contributor to your CodePlex project, ironpython Message-ID: An HTML attachment was scrubbed... URL: From no_reply at codeplex.com Mon May 27 09:16:41 2013 From: no_reply at codeplex.com (CodePlex) Date: 27 May 2013 00:16:41 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/26/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] os: missing dup() and fdopen() functions, nt.dup, nt.dup2, nt.execv,nt.execve 2. [New comment] version() shows only version number when running pyc-compiled .exe 3. [New comment] sys.version is incomplete in user created engine, creating problems in platform.py 4. [New comment] Discrepancy in dict __delitem__ vs CPython ---------------------------------------------- ISSUES 1. [New comment] os: missing dup() and fdopen() functions, nt.dup, nt.dup2, nt.execv,nt.execve http://ironpython.codeplex.com/workitem/7267 User paweljasinski has commented on the issue: "

I have looked at dup and dup2. Here is what I have found:

From what I can tell ip builds its own layer to emulate file descriptors. That wouldn't be so bad, but it also mixes in fd from crt:

>>> import os
>>> os.pipe()
(3, 4)
>>> f=file(r"c:\tmp\bar","r")
>>> f
<open file 'c:\tmp\bar', mode 'r' at 0x03A849BF>
>>> f.fileno()
3
>>>

There are 2 fds with number 3, but each is referring to different file behind.
So now, if you would like to dup(3), which one are we talking about, the one returned by pipe or the one referring to file?

cpython uses transparently fds returned from crt functions. open translates to _wopen, dup - dup, dup2 - dup2, pipe takes advantage of _open_osfhandle ...
Fixed in cb8abd3.Fixed (for real) in cb8abd3.This issue isn't really in __delitem__, it's in pop(). Changing out pop() to not call __delitem__ (or maybe just not call an overriden __delitem__) should be doable. From no_reply at codeplex.com Wed May 29 09:17:25 2013 From: no_reply at codeplex.com (CodePlex) Date: 29 May 2013 00:17:25 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/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] Tracking: Support CPython extension modules (*.pyd) 2. [New issue] how to get ironpython method parameters using .net ---------------------------------------------- ISSUES 1. [New comment] Tracking: Support CPython extension modules (*.pyd) http://ironpython.codeplex.com/workitem/11333 User bc3tech has commented on the issue: "

Looks like Ironclad might have worked in the past, but its DLLs are statically referencing IronPython 2.6 and won't work with IP 2.7 :(
Would be great if IP would pull in Ironclad since it looks like it is mostly there as of 2.6 - might just need to recompile against 2.7 IP DLLs From no_reply at codeplex.com Thu May 30 09:17:26 2013 From: no_reply at codeplex.com (CodePlex) Date: 30 May 2013 00:17:26 -0700 Subject: [Ironpython-users] IronPython, Daily Digest 5/29/2013 Message-ID: Hi ironpython, Here's your Daily Digest of new issues for project "IronPython". In today's digest:ISSUES 1. [New comment] how to get ironpython method parameters using .net ---------------------------------------------- ISSUES 1. [New comment] how to get ironpython method parameters using .net http://ironpython.codeplex.com/workitem/34104 User MarkusSchaber has commented on the issue: "

This tracker is for bug reports and similar work items, not for support questions. You may target the IronPython users mailing list for questions. From necroak at hotmail.com Thu May 30 18:48:48 2013 From: necroak at hotmail.com (Jason Barner) Date: Thu, 30 May 2013 12:48:48 -0400 Subject: [Ironpython-users] ResourceManagement Message-ID: Hello, I have recently stumbled upon IronPython, and have taken quite an interest in getting to know the workings of it. I've got experience with C#, and many other languages so I am quite comfortable with most of the underlying principles of how things work. I've been tinkering with simple WinForms apps, and have come upon a bit of a snag. In normal C#, (with design view) you can simply drag and drop a toolstrip, insert the "standard" items to it, and it ever so nicely generates a bunch of code for you. While I have certainly informed myself through Google that PTVS just doesn't support the WYSIWYG designer for WinForms (I see it does for WPF) I haven't let it deter me from fiddling around. I also noticed that SharpDevelop does support the designer for WinForms with python, and can handle the toolstrip issues I am facing now, but I would rather understand the issue I am having rather then just using a tool/designer to spew code out for me... I've got a few IronPython books, of which I believe only one touches on the issue I have, but I just can't get a good understanding from how they present it...so hopefully one of you fine people can help me out =) My problem : In SharpDevelop, when using the standard items on the toolstrip, you are generated this : resources = System.Resources.ResourceManager("Test.MainForm", System.Reflection.Assembly.GetEntryAssembly()) Which allows this to be done : self._newToolStripButton.Image = resources.GetObject("newToolStripButton.Image") In C#, when doing the same you are generated this : System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(Form1)); Which allows this : this.newToolStripButton.Image = ((System.Drawing.Image)(resources.GetObject("newToolStripButton.Image"))); These images are provided with visual studios as far as I am aware, but I am just not sure how exactly they are found, and more specifically I cannot get an implementation like this to work with normal IronPython and PTVS. If anyone has any knowledge on how I can implement this with IronPython with the PTVS setup, I would love to know how it can be done..it would also be highly appreciated to know what exactly the difference is, and some of (if not all) of what exactly is being done for the images to be pulled... Thanks for your time! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward.matt at gmail.com Thu May 30 21:37:53 2013 From: ward.matt at gmail.com (Matt Ward) Date: Thu, 30 May 2013 20:37:53 +0100 Subject: [Ironpython-users] ResourceManagement In-Reply-To: References: Message-ID: Hi Jason, Take a look at this post about SharpDevelop, IronPython and form resources which goes into more detail than I will cover here. http://community.sharpdevelop.net/blogs/mattward/archive/2009/09/28/IronPythonFormResources.aspx The basic problem is that the forms designer in SharpDevelop generates code that assumes you will be compiling your application to an executable so the resources for the form are compiled into that executable. The image for the toolstrip button will be part of a .resx file in your project and on compilation will be embedded into your exe. PTVS will run your IronPython application with ipy.exe and will not compile it to an executable, instead running your main IronPython file directly, so you are going to have to load the resources in a different way, such as loading them directly from a file or an assembly. Regards, Matt On 30 May 2013 17:48, Jason Barner wrote: > Hello, I have recently stumbled upon IronPython, and have taken quite an > interest in getting to know the workings of it. I've got experience with > C#, and many other languages so I am quite comfortable with most of the > underlying principles of how things work. > > I've been tinkering with simple WinForms apps, and have come upon a bit of > a snag. In normal C#, (with design view) you can simply drag and drop a > toolstrip, insert the "standard" items to it, and it ever so nicely > generates a bunch of code for you. > > While I have certainly informed myself through Google that PTVS just > doesn't support the WYSIWYG designer for WinForms (I see it does for WPF) I > haven't let it deter me from fiddling around. I also noticed that > SharpDevelop does support the designer for WinForms with python, and can > handle the toolstrip issues I am facing now, but I would rather understand > the issue I am having rather then just using a tool/designer to spew code > out for me... > > I've got a few IronPython books, of which I believe only one touches on > the issue I have, but I just can't get a good understanding from how they > present it...so hopefully one of you fine people can help me out =) > > > My problem : > > *In SharpDevelop, when using the standard items on the toolstrip, you are > generated this :* > resources = System.Resources.ResourceManager("Test.MainForm" > , System.Reflection.Assembly.GetEntryAssembly()) > > *Which allows this to be done : * > > self._newToolStripButton.Image = resources.GetObject( > "newToolStripButton.Image") > > > *In C#, when doing the same you are generated this : * > System.ComponentModel.ComponentResourceManager resources = new > System.ComponentModel.ComponentResourceManager(typeof(Form1)); > > *Which allows this :* > > this.newToolStripButton.Image = > ((System.Drawing.Image)(resources.GetObject("newToolStripButton.Image"))); > > > These images are provided with visual studios as far as I am aware, but I > am just not sure how exactly they are found, and more specifically I cannot > get an implementation like this to work with normal IronPython and PTVS. > > > If anyone has any knowledge on how I can implement this with IronPython > with the PTVS setup, I would love to know how it can be done..it would also > be highly appreciated to know what exactly the difference is, and some of > (if not all) of what exactly is being done for the images to be pulled... > > Thanks for your time! > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users at python.org > http://mail.python.org/mailman/listinfo/ironpython-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: