Hi Guys,
The following calls return "cli" instead of, what I would expect, "win32" or
something simliar:
platform.system()
sys.platform
I'm aware that it's not a new issue (it was mentioned here and there), but I
still couldn't figure out why this behaviour is preserved.. Shouldn't it be
chang
Hello all,
(This might not be the right place for this question...) What are the
current DLR languages, and their states? I'm wondering about those early
stabs, ones under development, from MS and others. I'm especially
interested in those that can be run cross-platform. I'd like to see a
lis
Here's what I know:
1. I've heard that Don Syme has been thinking about DLR integration for F#,
but nothing has been announced.2. According to
http://msdn.microsoft.com/en-us/vjsharp/default.aspx, J# is "retired" so I
don't think you can expect any further versions.
3. There aren't any firm plans
(In case it's not obvious, the IronLua efforts were not at Microsoft.)
On Thu, Jan 8, 2009 at 8:20 AM, Curt Hagenlocher wrote:
> Here's what I know:
>
> 1. I've heard that Don Syme has been thinking about DLR integration for F#,
> but nothing has been announced.2. According to
> http://msdn.micro
This is by design. The platform is not the same as the operating system.
Jython does something similar.
How are you trying to use this?
On Thu, Jan 8, 2009 at 5:20 AM, Oren Held wrote:
> Hi Guys,
>
> The following calls return "cli" instead of, what I would expect, "win32"
> or
> something sim
Curt Hagenlocher wrote:
Here's what I know:
1. I've heard that Don Syme has been thinking about DLR integration for
F#, but nothing has been announced.
2. According to http://msdn.microsoft.com/en-us/vjsharp/default.aspx, J#
is "retired" so I don't think you can expect any further versions.
3
>>I'm also working with a couple of groups who are actively developing
>>additional DLR languages, including a graphical data flow language,
>>and a proper tail-call recursion implementation of Scheme (using
>>continuation-passing style). More on those here soon, I hope.
>>
>>
On Thu, Jan 8, 2009 at 8:36 AM, Douglas S. Blank wrote:
>
> Thanks for the feedback... this is very useful. Can you elaborate on what
> you mean regarding "same level of support for the DLR as C#"? Does that mean
> that VB won't be a dynamic language, but can use the DLR (eg, to host other
> langu
Ok, I've looked at this more closely now and I believe I have a fix. I've also
discovered that changes in the DLR make this much better as well in the 2.1
branch. But the numbers I get are:
2.0: 59.9065353243
2.1: 4.28863087116
2.1 + dict fixes: 1.22241745833
These numbers are quite dependen
Hi,
In my code, I have a section which is not cross platform, thus I'm checking
the OS name to call the matching OS-specific calls.
In all Unices, using platform.system() returned the OS name just fine. Is there
a better way for getting the OS name on both CPython & IronPython?
10x!
- Oren
On Thu, Jan 8, 2009 at 2:01 PM, Oren Held wrote:
>
> In my code, I have a section which is not cross platform, thus I'm checking
> the OS name to call the matching OS-specific calls.
>
> In all Unices, using platform.system() returned the OS name just fine. Is
> there
> a better way for getting t
On Friday 09 January 2009 00:28:49 Curt Hagenlocher wrote:
> On Thu, Jan 8, 2009 at 2:01 PM, Oren Held wrote:
> > In my code, I have a section which is not cross platform, thus I'm
> > checking the OS name to call the matching OS-specific calls.
> >
> > In all Unices, using platform.system() retur
Hi Dino,
This could be at the root of *several* of the really odd performance
issues we've been having with our IronPython 2 port. That is quite an
improvement and mirrors the kind of behaviour we see.
Can we get a patch against the 2.0 source code for your dictionary fix?
On the other hand,
I'm going to back port this perf fixes + the property perf fixes to 2.0.1. I
was planning on doing this tomorrow.
Moving to 2.1 shouldn't be painful. The biggest gotcha is a large number of
renames that have happened in the DLR inner layer (Microsoft.Scripting.Core).
The good news is those s
On Thu, Jan 8, 2009 at 3:01 PM, Oren Held wrote:
> In all Unices, using platform.system() returned the OS name just fine. Is
> there
> a better way for getting the OS name on both CPython & IronPython?
os.name is probably what you're looking for, although I don't know how
it behaves on *nix (it
It'll return "posix" if the .NET implementation reports
System.Environment.OSVersion.Platform as Unix.
> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Thursday, January 08, 2009 4:13 PM
> To: Di
16 matches
Mail list logo
