dlr Discussions Rss Feed

New Post: DLR <> IronLanguages

dmiller — Fri, 05 Apr 2013 22:10:59 GMT

jdhardy wrote:

The DLR is still sort-of actively developed, in the IronLangauges github repo. Tomas Matousek has done a bunch of work to port it to Windows8/Metro. No major work is being done, but that's mainly because it's a pretty solid piece of code that doesn't need
major changes. None of that has been ported back to this project, however, since for a long time there wasn't much interest in the DLR outside of IronPython/IronRuby. I've mulled around the idea of breaking it out into its own github repo, but I'd need to
know that there's enough projects using it to be worth the effort. Unfortunately DLR languages tend to start with good intentions and then fizzle out.

Speaking as someone with a language project still using parts of the DLR and not fizzling out (ClojureCLR), any updates to DLR would be welcome. Win8/Metro has been asked for. A separate github would be nice, but I'd be happy with an official nuget packaged of just the DLR. Some of the folks interested in this have expressed interest that this be signed the same as the regular IronPython package, to aid in compatibility.

-David

New Post: DLR <> IronLanguages

jdhardy — Thu, 04 Apr 2013 19:21:23 GMT

IronPython and IronRuby were developed in the same TFS repo inside Microsoft, and the IronRuby team had a mirror on GitHub. after MS dumped the Iron languages, that GH repo was renamed to IronLanguages, and that's where the primary development of IronPython
and IronRuby take place. Re debugging, I know that IronPython has debugging information (i.e. it can be debugged by the normal VS debugger, although PTVS improves that quite a bit), stack traces, etc. I don't know how much of it is in the DLR and how much
is specific to IronPython though.

New Post: DLR <> IronLanguages

todort — Thu, 04 Apr 2013 06:30:33 GMT

Hi jdhardy,

My impression was that there was at least some development in the IronLanguages project. I've seen Windows 8 related code, and it's nice to see that people add functionality to it. Good Work (Tomas Matousek)!

It's also my impression that large parts of the framework are stable. The whole AST/Expressions part is working well and documented reasonably, and I was surprised how easy it is to use. I am trying to implement Smalltalk on top of the DLR, and most things are straight forward. The only things I am missing is the non-local returns, i.e. returns from a full-closure out of the context where the closure is defined. However, I am sure that it's not a trivial thing to implement and probably will need some CLR/MSIL support.

Anyway, I understand that it's not ported back here. In my opinion, it's enough to have the changes one place. Can you explain what's the purpose of the IronLanguages project? Is it to coordinate the IronPython and IronRuby projects, or is it the actual project where the IronPython and IronRuby development happens?

For now, keep it in IronLanguages. It can always be split later.

A completely unrelated question, do you know, or do you know where to ask if the DLR has debugging functionality? What I would like to be able to do is create stack traces of a dead/dying DLR application (my IronSmalltalk dialect). I've looked into the Python Tools for Visual Studio, bur if I understood the debugger correctly, it communicates with the Python process and contains Python code inside that process. Is that correct? Anyway, any ideas are welcome!

Thanks!

-- Todor

New Post: DLR <> IronLanguages

dsblank — Wed, 03 Apr 2013 19:01:38 GMT

I'd be in favor of anything that we can do to make the DLR more accessible. I have a few languages that I would like to move over to the DLR, but this is a long term project, and it will take some time. I think that the DLR will be interesting to academics, especially as they become more documented, and more wildly known.

New Post: DLR <> IronLanguages

jdhardy — Wed, 03 Apr 2013 18:29:43 GMT

The DLR is still sort-of actively developed, in the IronLangauges github repo. Tomas Matousek has done a bunch of work to port it to Windows8/Metro. No major work is being done, but that's mainly because it's a pretty solid piece of code that doesn't need
major changes. None of that has been ported back to this project, however, since for a long time there wasn't much interest in the DLR outside of IronPython/IronRuby. I've mulled around the idea of breaking it out into its own github repo, but I'd need to
know that there's enough projects using it to be worth the effort. Unfortunately DLR languages tend to start with good intentions and then fizzle out.

New Post: DLR <> IronLanguages

todort — Mon, 01 Apr 2013 23:33:11 GMT

Thanks. I've found the blog and probably the entry you are mentioning. I did some reading earlier and found another blog and entry (I think it was a Ruby developer) on Microsoft's eternally changing policies and how this crippled the project :-/

Well, the hosting spec is not out of date, it's just not complete. Parts of it are written as "To-Do" and looking at the code, I get the same feeling, that those were still under development.

There was a project to create a Smalltalk on the DLR 3-4 years ago, but it didn't get off. I started another project (and took over the name http://ironsmalltalk.codeplex.com/) about 2½ years ago. Unfortunately I had to take a break for about an year, and now I am back working on it.

So, the DLR is not developed actively any more, not even as part of the IronPython or IronRuby projects. And the PTVS is a stand-alone project.

I'll look at the PTVS and try to see if I can figure anything out. My first goal will be to create an extension to VS to be able to see the stack-trace of IronSmalltalk project.

Take care.

New Post: DLR <> IronLanguages

billchi — Mon, 01 Apr 2013 23:12:44 GMT

Fundamentally, we wanted to work toward standard python since that's what lots of people use.

Search for Jason Zander's blog on what happened to the iron languages, the full story is there. They are active and wholely owned by the community. Yes, the DLR was promising interop, and we had that with common hosting APIs, etc. We're not focusing on that now.

Is the hosting spec really out of date? Also, there was a smalltalk started at one point, but I don't recall what happened to it. I imagine you already searched for something to start from though.

In terms of more reading, it would be the ironpython mailing list since we do not work on this stuff now and are not updating docs.

Bill

New Post: DLR <> IronLanguages

todort — Mon, 01 Apr 2013 23:04:49 GMT

Thanks for the reply.

Did I understand you correctly? The Python Tools for Visual Studio (http://pytools.codeplex.com/) are based on the IronPython Studio (http://ironpythonstudio.codeplex.com/). So, why did the projects split? Different goals?

Did the same happen to IronPython / IronRuby and IronLanguages? Are they all active? Do they still cooperate? The idea behind the DLR was to have a common shared infrastructure, so interoperation between the languages is possible. Shame if people are branching indefinitely.

Anyway, I am trying to implement a Smalltalk dialect on top the DLR - strangely enough called IronSmalltalk. The DLR documentation is not 100% up to date. Figuring out the expression and dynamic object and code generation was doable. Figuring out the hosting frameworks was much more tricky (and I still only get the basics).

My next task is to figure out how to write some debug tools. Ideally, I'd like to see a stack trace inside Visual Studio and being able to inspect the offending objects and code. I am currently thinking to investigate how PTVS works and if I can learn something from it.

Can you recommend some relevant reading or what direction to go from here?

Thanks,

Todor

New Post: DLR <> IronLanguages

dinov — Sat, 30 Mar 2013 17:05:39 GMT

There's no current connection. PTVS is based upon the IronPythonTools which were originally shipped w/ the IronLanguages but has changed a huge amount since then. And I've personally worked on both, but there's no on going work that's shared between the two.

New Post: DLR <> IronLanguages

todort — Sat, 30 Mar 2013 03:17:08 GMT

Hi,

What's the relationship between this DLR project and the IronLanguages project on GitHub (https://github.com/IronLanguages)?

New Post: .NET 4.5

TomasMatousek — Fri, 12 Oct 2012 05:37:25 GMT

They do compile on 4.5, among other platforms. Check out https://github.com/IronLanguages/main

Tomas

From: [email removed]
To: [email removed]
Date: Thu, 11 Oct 2012 08:49:24 -0700
Subject: .NET 4.5 [dlr:398992]

From: Alxandr

What would it take to get the the Microsoft.Scripting-projects compiling under .NET 4.5?

Read the full discussion online.
To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)
To start a new discussion for this project, email dlr@discussions.codeplex.com
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: .NET 4.5

Alxandr — Thu, 11 Oct 2012 15:49:19 GMT

What would it take to get the the Microsoft.Scripting-projects compiling under .NET 4.5?

New Post: Custom Scope Storage as default for ScriptEngine.CreateScope()

SPARTAN563 — Mon, 17 Sep 2012 20:49:31 GMT

I have subsequently made the relevant changes to the DLR to implement option 1, these changes are contained within Pull Request 80.

Changes add the following methods to LanguageContext:

public virtual Scope CreateScope();
public virtual Scope CreateScope(IDictionary<string,object> dictionary);
public virtual Scope CreateScope(IDynamicMetaObjectProvider storage);

The changes also make calls to ScriptEngine.ExecuteFile(string file) and ScriptCode.CreateScope() both reference the LanguageContext's implementation of the CreateScope method.

New Post: Custom Scope Storage as default for ScriptEngine.CreateScope()

SPARTAN563 — Mon, 17 Sep 2012 18:09:05 GMT

Issue

I am currently in the process of polishing a DLR Lua implementation, fixing bugs and generally getting it to a usable state, and I have hit a bit of a wall. I am trying to implement a default Scope storage which will be used when another is not specified (i.e. through calls to ScriptEngine.ExecuteFile) however I cannot seem to find any way to override this default behaviour for the ExecuteFile(*) methods. [It is possible to provide a CreateScope override on ScriptCode which is then called when Execute(*) methods are called, thus fulfilling my requirements]

Possible Solutions

Make ScriptEngine.CreateScope virtual and call _language.CreateScope from within ScriptEngine
- Advantages
  - Also allows all scopes created by calls to ScriptEngine.CreateScope to make use of the default backing store, allowing languages finer control over this.
  - If not overridden by a language it will revert to the current behaviour, making this a non-breaking change.
- Disadvantages
  - Requires changes to the DLR source code to implement
Make ScriptEngine.ExecuteFile call _language.GetScope(file) instead of CreateScope() [Not feasible: would break the ability to call ExecuteFile multiple times and have each execution separately boxed]

I'll add more alternatives here as I think of them, but at the moment I am tending towards the first. If anyone has any better ideas, or knows of a way I can implement this using existing functionality (without requiring the user to create a scope each time) then I'd appreciate it.

Example

//Initialize ScriptEngine instance var engine = Lua.CreateEngine(); //ScriptEngine.CreateScope() var scope = engine.CreateScope(); //Expected: scope.Storage should be of type: LuaTable //Actual: scope.Storage is of type: ScopeStorage //ScriptEngine.ExecuteFile(file) scope = engine.ExecuteFile(file); //Expected: scope.Storage should be of type: LuaTable //Actual: scope.Storage is of type: ScopeStorage

New Post: Sympl Example - Source Code?

billchi — Fri, 27 Jul 2012 17:37:20 GMT

If you go to dlr.codeplex.com and click "source code" in the top nav bar, then click "browse" in the sub nav bar that's flush left, that gets you here: http://dlr.codeplex.com/SourceControl/changeset/view/54115

Then click dlr_main->runtime->samples->sympl. The python dir is an implementation in ironpython. The csharp dir is C# implementation that works with only shipping DLR .NET 4.0 bits. The csharp-cponly dir is a C# version that uses some features that only shipped open source on the dlr.codeplex.com site, and there are comments or a section in the doc that explains the extensions used in that version (don't recall what they were now :-)).

Cheers,

Bill

From: fholm [email removed]
Sent: Friday, July 27, 2012 10:13 AM
To: Bill Chiles
Subject: Re: Sympl Example - Source Code? [dlr:389326]

From: fholm

It's in the DLR main source code dump.

Regards,
Fredrik Holmström

On Fri, Jul 27, 2012 at 7:11 PM, yogeshshetty <notifications@codeplex.com> wrote:

From: yogeshshetty

I am exploring DLR runtime, and i see that there is a nice documentation on Sympl language. Does anyone know where can i find the source code for this sample project ?

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Sympl Example - Source Code?

fholm — Fri, 27 Jul 2012 17:12:40 GMT

It's in the DLR main source code dump.

Regards,
Fredrik Holmström

On Fri, Jul 27, 2012 at 7:11 PM, yogeshshetty <notifications@codeplex.com> wrote:

From: yogeshshetty

I am exploring DLR runtime, and i see that there is a nice documentation on Sympl language. Does anyone know where can i find the source code for this sample project ?

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Sympl Example - Source Code?

yogeshshetty — Fri, 27 Jul 2012 17:11:29 GMT

I am exploring DLR runtime, and i see that there is a nice documentation on Sympl language. Does anyone know where can i find the source code for this sample project ?

New Post: Understanding how the BinaryOperationBinder works

Alxandr — Wed, 30 May 2012 19:27:22 GMT

billchi wrote:

Languages can be smarter and can implement their own “Less than + convert to bool sites” which combine the 2 operations into a single operation. The DLR outer layer even includes the ComboBinder to automatically combine the 2 dynamic operations into a single one given sub-binders which work correctly.

Can you provide a small concrete example of this? I'm currently implementing a language, and doing stuff like "if(a < b)" turns out to be a pain because of stuff like this, but even more, I've been completely unable to use

Utils.LightDynamic(engine.GetUnaryBinder(ExpressionType.IsTrue), valueExpr)

because it complains about the binder returning a bool while the callsite requires an object-result, and this is before any of my code even runs! So what seems to be the problem is that I should probably specify the call-site type-argument myself, but I've found myself unable to figure out how to do that from Expression-objects. Even conversion to bool requires an object-result because the call-site is miss-matched.

What I currently do is parse my language, then hand it generate an Expression-tree, and hand a LightLambda of that delegate over to a SourceCode-object. How can I change the generation of the Expression-tree to enable stuff like this?

New Post: Understanding how the BinaryOperationBinder works

billchi — Wed, 16 May 2012 16:32:40 GMT

Thanks for the followup, and very sorry it took us a while to get back to you. I just got some insight from dev this morning since I was not sure of the answer. I won't include his text on the change you sited, but here's a bit of extra info that may be interesting.

Almost all of the standard dynamic operations are expected to return object – in this particular case the problem is less than can be overloaded to return non-bool values (even in static languages like C#). Therefore the DLR requires that you always return object. Some of the logic behind this is probably expressed in these stack overflow posts:

http://stackoverflow.com/questions/1360097/dlr-return-type

http://stackoverflow.com/questions/1835912/how-do-i-express-a-void-method-call-as-the-result-of-dynamicmetaobject-bindinvok/1836591#1836591

So this needs to be declared to return object, and then if you really want a bool you need to add a dynamic convert to bool site – but it doesn’t look like that’s needed here. Languages can be smarter and can implement their own “Less than + convert to bool sites” which combine the 2 operations into a single operation. The DLR outer layer even includes the ComboBinder to automatically combine the 2 dynamic operations into a single one given sub-binders which work correctly. But the core operations are always fixed to returning object (or void)

Bill

From: fgretief [email removed]
Sent: Wednesday, May 16, 2012 9:29 AM
To: Bill Chiles
Subject: Re: Understanding how the BinaryOperationBinder works [dlr:355421]

From: fgretief

Hello DLRs,

I eventually found the answer to the problem. Actually there were two issues.

The first was that the ReturnType of a BinaryOperationBinder is Object.
And my code told the Expression.Dynamic method to return binary. So replacing
the typeof(bool) with typeof(object) fixed that issue.

var binExpr = Expression.Dynamic(
context.CreateBinaryOperationBinder(opr),
typeof(object), left, right);

The second issue was again with the BinaryOperationBinder returning an Object.
Inside the FallbackBinaryOperation method of my binder, I made a call to the
DefaultBinder's DoOperation() method, which return a boolean type. This was the
reason why I added boolean to the Expression.Dynamic call in the first place.
So we need to convert the output to the return type of the binder.

public override DynamicMetaObject FallbackBinaryOperation(
DynamicMetaObject target,
DynamicMetaObject arg,
DynamicMetaObject errorSuggestion)
{
...

// original code
//return _binder.DoOperation(Operation, left, right);

// new code
var returnType = this.ReturnType;
var mo = context.Binder.DoOperation(Operation, left, right);
if (mo.Expression.Type != returnType)
{
mo = mo.Clone(Expression.Convert(mo.Expression, returnType));
}
return mo;
}

Now my example executes as expected.

Regards,
Francois

New Post: Understanding how the BinaryOperationBinder works

fgretief — Wed, 16 May 2012 16:28:42 GMT

Hello DLRs,

I eventually found the answer to the problem. Actually there were two issues.

The first was that the ReturnType of a BinaryOperationBinder is Object.
And my code told the Expression.Dynamic method to return binary. So replacing
the typeof(bool) with typeof(object) fixed that issue.

var binExpr = Expression.Dynamic(
        context.CreateBinaryOperationBinder(opr),
        typeof(object), left, right);

The second issue was again with the BinaryOperationBinder returning an Object.
Inside the FallbackBinaryOperation method of my binder, I made a call to the
DefaultBinder's DoOperation() method, which return a boolean type. This was the
reason why I added boolean to the Expression.Dynamic call in the first place.
So we need to convert the output to the return type of the binder.

    public override DynamicMetaObject FallbackBinaryOperation(
        DynamicMetaObject target,
        DynamicMetaObject arg,
        DynamicMetaObject errorSuggestion)
    {
        ...

        // original code
        //return _binder.DoOperation(Operation, left, right);

        // new code
        var returnType = this.ReturnType;
        var mo = context.Binder.DoOperation(Operation, left, right);
        if (mo.Expression.Type != returnType)
        {
            mo = mo.Clone(Expression.Convert(mo.Expression, returnType));
        }
        return mo;
    }

Now my example executes as expected.

Regards,
Francois

Hello DLRs,

I eventually found the answer to the problem. Actually there were two issues.

The first was that the ReturnType of a BinaryOperationBinder is Object.
And my code told the Expression.Dynamic method to return binary. So replacing
the typeof(bool) with typeof(object) fixed that issue.

var binExpr = Expression.Dynamic(
        context.CreateBinaryOperationBinder(opr),
        typeof(object), left, right);

The second issue was again with the BinaryOperationBinder returning an Object.
Inside the FallbackBinaryOperation method of my binder, I made a call to the
DefaultBinder's DoOperation() method, which return a boolean type. This was the
reason why I added boolean to the Expression.Dynamic call in the first place.
So we need to convert the output to the return type of the binder.

    public override DynamicMetaObject FallbackBinaryOperation(
        DynamicMetaObject target,
        DynamicMetaObject arg,
        DynamicMetaObject errorSuggestion)
    {
        ...

        // original code
        //return _binder.DoOperation(Operation, left, right);

        // new code
        var returnType = this.ReturnType;
        var mo = context.Binder.DoOperation(Operation, left, right);
        if (mo.Expression.Type != returnType)
        {
            mo = mo.Clone(Expression.Convert(mo.Expression, returnType));
        }
        return mo;
    }

Regards,
Francois