www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement

reply "alex" <info alexanderbothe.com> writes:
Morning D folks,

Implemented some new features concerning pre-compile time mixin
analysis and expression evaluation:

http://mono-d.alexanderbothe.com/?p=814 (Screenshot included)

I'd furthermore suggest that the prospective generational GC (not
the current one, I mean the fictional that actually can collect
nearly everything wisely! ;)) also supports weak references -
because they're imho essential for a nice caching flow:

In this version of mono-d I used a weak-keyed dictionary to store
mixin expression results until the owner module is free'd and
probably reparsed. This allows me to be more lazy regarding the
deletion of those cache entries after I reparsed e.g. a module +
mem leaking is prevented + less muddy code in the module update
routines! :)


Cheers,
Alex
Jan 27 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
Gets better and better!

Makes me wonder though: if this works, may be it is possible to 
provide a context helper with mixin resulting code if all it 
parameters are already defined? Similar to C macro expansion 
helper in Eclipse.
Jan 27 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Sunday, 27 January 2013 at 11:31:58 UTC, Dicebot wrote:
 Gets better and better!

 Makes me wonder though: if this works, may be it is possible to 
 provide a context helper with mixin resulting code if all it 
 parameters are already defined? Similar to C macro expansion 
 helper in Eclipse.
So like.. you click somewhere in your document, have an extra panel in which you can enter an expression (even a CTFE call later on), and get your expressions evaluated? Sure - even stuff like template mixins or similar..no problem :) Uhm, even pre-defining variable contents shouldn't be a problem - then you would have a D math-script interpreter :D
Jan 27 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 27 January 2013 at 12:05:28 UTC, alex wrote:
 On Sunday, 27 January 2013 at 11:31:58 UTC, Dicebot wrote:
 Gets better and better!

 Makes me wonder though: if this works, may be it is possible 
 to provide a context helper with mixin resulting code if all 
 it parameters are already defined? Similar to C macro 
 expansion helper in Eclipse.
So like.. you click somewhere in your document, have an extra panel in which you can enter an expression (even a CTFE call later on), and get your expressions evaluated? Sure - even stuff like template mixins or similar..no problem :) Uhm, even pre-defining variable contents shouldn't be a problem - then you would have a D math-script interpreter :D
No, a bit different. I.e. --------- string gen(int num) { return format("auto a = %s", num); } mixin(gen("42"); --------- And when you hover over "mixin" keyword, temporary modal window appears with content "auto a = 42". Or even separate panel with full compile-time feature expansion like it was in Descent, as Jacob suggests. I suppose it is hard to have full CTFE engine now, but at least simple cases may be useful.
Jan 27 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-27 12:27, alex wrote:
 Morning D folks,

 Implemented some new features concerning pre-compile time mixin
 analysis and expression evaluation:

 http://mono-d.alexanderbothe.com/?p=814 (Screenshot included)
Nice. I'm not sure if this is what Dicebot suggested but would it be possible to implement a compile time view, like Descent had? It how showed template and string mixins are expanded. It also showed how some language features are lowered to other features, like the scope statement being lowered to try/catch/finally. This clip shows the compile time view in action: http://www.youtube.com/watch?v=oAhrFQVnsrY&noredirect=1 -- /Jacob Carlborg
Jan 27 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Sunday, 27 January 2013 at 12:20:51 UTC, Jacob Carlborg wrote:
 On 2013-01-27 12:27, alex wrote:
 Morning D folks,

 Implemented some new features concerning pre-compile time mixin
 analysis and expression evaluation:

 http://mono-d.alexanderbothe.com/?p=814 (Screenshot included)
Nice. I'm not sure if this is what Dicebot suggested but would it be possible to implement a compile time view, like Descent had? It how showed template and string mixins are expanded. It also showed how some language features are lowered to other features, like the scope statement being lowered to try/catch/finally. This clip shows the compile time view in action: http://www.youtube.com/watch?v=oAhrFQVnsrY&noredirect=1
Well, not displaying the entire module but only displaying resolved expressions. Dunno how to do this in a proper way - only via tooltips or also in an extra panel? Which would be the most useful? Btw, since I'm not that involved in D's magic I definitely haven't planned such extensive pre-compilation :D
Jan 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-27 13:35, alex wrote:

 Well, not displaying the entire module but only displaying
 resolved expressions. Dunno how to do this in a proper way - only
 via tooltips or also in an extra panel? Which would be the most
 useful?
If it cannot show the entire module then I think a tooltip would be best suited.
 Btw, since I'm not that involved in D's magic I definitely
 haven't planned such extensive pre-compilation :D
It can be extremely helpful to see how a template/string mixin is expanded when debugging. It can also be fun to see how the compiler behaves internally, i.e. scope-statements are lowered to try/catch/finally. Any D IDE has quite a lot of expectations to live up since it most certainly will be compared with Descent. -- /Jacob Carlborg
Jan 27 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Sunday, 27 January 2013 at 15:24:23 UTC, Jacob Carlborg wrote:
 On 2013-01-27 13:35, alex wrote:

 Well, not displaying the entire module but only displaying
 resolved expressions. Dunno how to do this in a proper way - 
 only
 via tooltips or also in an extra panel? Which would be the most
 useful?
If it cannot show the entire module then I think a tooltip would be best suited.
 Btw, since I'm not that involved in D's magic I definitely
 haven't planned such extensive pre-compilation :D
It can be extremely helpful to see how a template/string mixin is expanded when debugging. It can also be fun to see how the compiler behaves internally, i.e. scope-statements are lowered to try/catch/finally. Any D IDE has quite a lot of expectations to live up since it most certainly will be compared with Descent.
K..Created an extra panel, and the actual mixin evaluation is working, too. But now there are some last adjustments required to have the entire mechanism as few annoying and performance-reducing as possible.
Jan 28 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-28 13:32, alex wrote:

 K..Created an extra panel, and the actual mixin evaluation is working,
 too. But now there are some last adjustments required to have the entire
 mechanism as few annoying and performance-reducing as possible.
Cool, I guess it's time to give Mono-D another try. -- /Jacob Carlborg
Jan 28 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Monday, 28 January 2013 at 20:20:42 UTC, Jacob Carlborg wrote:
 On 2013-01-28 13:32, alex wrote:

 K..Created an extra panel, and the actual mixin evaluation is 
 working,
 too. But now there are some last adjustments required to have 
 the entire
 mechanism as few annoying and performance-reducing as possible.
Cool, I guess it's time to give Mono-D another try.
http://i.imgur.com/3i5R4Mn.png?1 A first shot - I guess in cases of having template parameters, stuff should get 'expanded' to the final type, right? Well then I still have to work on it. Anyway it also works for template mixins and mixin statements. You just move the caret into a mixin, wait half a sec and then get the evaluated string displayed in a halfway good style. Ah, regarding the style..I also have to optimize it again - never touched any 'pretty printing' of entire ASTs before ;)
Jan 28 2013
parent reply "F i L" <witte2008 gmail.com> writes:
alex wrote:
 http://i.imgur.com/3i5R4Mn.png?1

 A first shot - I guess in cases of having template parameters, 
 stuff should get 'expanded' to the final type, right? Well then 
 I still have to work on it. Anyway it also works for template 
 mixins and mixin statements. You just move the caret into a 
 mixin, wait half a sec and then get the evaluated string 
 displayed in a halfway good style.
 Ah, regarding the style..I also have to optimize it again - 
 never touched any 'pretty printing' of entire ASTs before ;)
Now that's impressive. Can't wait to see exactly what will come of the expression evaluation :D
Jan 28 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Monday, 28 January 2013 at 21:14:07 UTC, F i L wrote:
 alex wrote:
 http://i.imgur.com/3i5R4Mn.png?1

 A first shot - I guess in cases of having template parameters, 
 stuff should get 'expanded' to the final type, right? Well 
 then I still have to work on it. Anyway it also works for 
 template mixins and mixin statements. You just move the caret 
 into a mixin, wait half a sec and then get the evaluated 
 string displayed in a halfway good style.
 Ah, regarding the style..I also have to optimize it again - 
 never touched any 'pretty printing' of entire ASTs before ;)
Now that's impressive. Can't wait to see exactly what will come of the expression evaluation :D
Yeah I just named it "Expression evaluation" - dunno why, just thought that it could be used in a more general way than 'only' for mixin insight. Should I do an extra input box where you could type in expressions and other things that could be evaluated? Just thinking of a prototype of an interactive D script console or so.. :)
Jan 28 2013
next sibling parent reply "F i L" <witte2008 gmail.com> writes:
alex wrote:
 Yeah I just named it "Expression evaluation" - dunno why, just 
 thought that it could be used in a more general way than 'only' 
 for mixin insight.

 Should I do an extra input box where you could type in 
 expressions and other things that could be evaluated? Just 
 thinking of a prototype of an interactive D script console or 
 so.. :)
That sounds very useful. It would be awesome if you could evaluate the returned value of functions that already exist in your program, or (like your picture shows) write simple test functions to evaluate. Of course not all functions will work, but It would be great in some areas. So, just to be clear, say you have the following function in your project: int foo(int x, int y) { return x * y + 5; } Then in the expression "command line", you just type: foo(1, 2) Hit Enter, and you get a message: "7". You could also write larger test functions in the Expression Evaluation body (like in your screenshot) which could do more complicated stuff (still limited of course). --- You just gave me an awesome idea though. I know this would be a ton of work (I'm not making a feature request here), but how realistic would it be with your system to do a "side-by-side" expression evaluation with "example data" (where applicable)? :D Meaning, imagine your screen looks like: CODE | EXAMPLE RESULTS ------------------------------------------------------------ | int foo(int x, int y) | params: (2, 3) // editable { | return x * y + 5 | returns: 11 // not-editable } | | That would simply amazing! I don't expect you to make that, lol, only want to know if it's possible (or foreseeable) with your expression evaluation engine. Is it?
Jan 28 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
 ...
 That sounds very useful. It would be awesome if you could 
 evaluate the returned value of functions that already exist in 
 your program, or (like your picture shows) write simple test 
 functions to evaluate. Of course not all functions will work, 
 but It would be great in some areas. So, just to be clear, say 
 you have the following function in your project:

     int foo(int x, int y)
     {
         return x * y + 5;
     }

 Then in the expression "command line", you just type:

     foo(1, 2)

 Hit Enter, and you get a message: "7". You could also write 
 larger test functions in the Expression Evaluation body (like 
 in your screenshot) which could do more complicated stuff 
 (still limited of course).
http://mono-d.alexanderbothe.com/?attachment_id=817 My progress so far. Lots of internals to manage though. The execute-button isn't implemented yet but you can toggle the "Automatically take the mixin at the caret location" button. Concerning things like foo(1,2) - yes, the evaluation engine directly takes the symbols straight out of its parsed modules. So as you create a method body you'll be able to execute stuff in-line. But yeah, remember that CTFE isn't implemented yet ;) - Perhaps I'll do/finish it during the next GSoC. Haha, as a systematical performance pre-improvement I could directly redirect some phobos methods like sqrt() to the .net one - which would save huge amounts of time then.
 You just gave me an awesome idea though. I know this would be a 
 ton of work (I'm not making a feature request here), but how 
 realistic would it be with your system to do a "side-by-side" 
 expression evaluation with "example data" (where applicable)? :D

 Meaning, imagine your screen looks like:

     CODE                       | EXAMPLE RESULTS
    ------------------------------------------------------------
                                |
     int foo(int x, int y)      | params: (2, 3) // editable
     {                          |
         return x * y + 5       | returns: 11    // not-editable
     }                          |
                                |

 That would simply amazing! I don't expect you to make that, 
 lol, only want to know if it's possible (or foreseeable) with 
 your expression evaluation engine. Is it?
Side-by-side? This could be your contribution then :P I actually did watch this one video where that one guy just edited some javascript in his uber-editor and the WebGL animations reacted on his coding in pseudo-realtime in the browser :D
Jan 28 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-29 03:14, alex wrote:
 On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
 Meaning, imagine your screen looks like:

     CODE                       | EXAMPLE RESULTS
    ------------------------------------------------------------
                                |
     int foo(int x, int y)      | params: (2, 3) // editable
     {                          |
         return x * y + 5       | returns: 11    // not-editable
     }                          |
                                |

 That would simply amazing! I don't expect you to make that, lol, only
 want to know if it's possible (or foreseeable) with your expression
 evaluation engine. Is it?
Side-by-side? This could be your contribution then :P I actually did watch this one video where that one guy just edited some javascript in his uber-editor and the WebGL animations reacted on his coding in pseudo-realtime in the browser :D
Yeah, that was soooo cool. I also liked the code bubbles. Instead of having a file as the minimum abstraction unit in the IDE/editor it was a function/class/method. -- /Jacob Carlborg
Jan 29 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Tuesday, 29 January 2013 at 08:02:27 UTC, Jacob Carlborg wrote:
 ...
Yeah, that was soooo cool. I also liked the code bubbles. Instead of having a file as the minimum abstraction unit in the IDE/editor it was a function/class/method.
Which can be done in Eclipse by just selecting e.g. a method or class in the outline - iirc it'll just show the definition of the selected node then, nothing else.
Jan 29 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-29 11:52, alex wrote:

 Which can be done in Eclipse by just selecting e.g. a method or class in
 the outline - iirc it'll just show the definition of the selected node
 then, nothing else.
If I select an item in the outline view it will just scroll the editor view to where that item is defined. I want to be able to have three code bubbles open, side by side, showing three different methods from the same file. -- /Jacob Carlborg
Jan 29 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 29/01/2013 10:52, alex wrote:
 On Tuesday, 29 January 2013 at 08:02:27 UTC, Jacob Carlborg wrote:
 ...
Yeah, that was soooo cool. I also liked the code bubbles. Instead of having a file as the minimum abstraction unit in the IDE/editor it was a function/class/method.
Which can be done in Eclipse by just selecting e.g. a method or class in the outline - iirc it'll just show the definition of the selected node then, nothing else.
By default, yes, but you can do what Jacob wanted with the "Show Source of Selected Element Only" functionality: http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm I personally don't like that feature that much, at least the way it's implemented, because that toggle is global, it will affect all Java editors. Plus it requires the use of the outline view (which I dont typically use), or the package explorer to select the element. I would much rather have the underlying elemented defined *per editor*, (and thus independent of selection). -- Bruno Medeiros - Software Engineer
Jan 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-29 13:26, Bruno Medeiros wrote:

 By default, yes, but you can do what Jacob wanted with the "Show Source
 of Selected Element Only" functionality:
 http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm
That's somewhat similar to what I had in mind. But that just removes all other code that is not selected from the editor. I want to have multiple editors or views of the same file side by side. These views don't need to be any larger than the code they're showing. -- /Jacob Carlborg
Jan 29 2013
next sibling parent reply "alex" <info alexanderbothe.com> writes:
On Tuesday, 29 January 2013 at 19:35:45 UTC, Jacob Carlborg wrote:
 On 2013-01-29 13:26, Bruno Medeiros wrote:

 By default, yes, but you can do what Jacob wanted with the 
 "Show Source
 of Selected Element Only" functionality:
 http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm
That's somewhat similar to what I had in mind. But that just removes all other code that is not selected from the editor. I want to have multiple editors or views of the same file side by side. These views don't need to be any larger than the code they're showing.
Okay, I've uploaded a new version that features a basically working version. There is now a separated mixin insight and expression evaluation available. There are still many things left to do though.
Jan 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-30 00:28, alex wrote:

 Okay, I've uploaded a new version that features a basically working
 version. There is now a separated mixin insight and expression
 evaluation available.
 There are still many things left to do though.
I'll give it a try. -- /Jacob Carlborg
Jan 30 2013
parent "alex" <info alexanderbothe.com> writes:
On Wednesday, 30 January 2013 at 10:45:26 UTC, Jacob Carlborg
wrote:
 On 2013-01-30 00:28, alex wrote:

 Okay, I've uploaded a new version that features a basically 
 working
 version. There is now a separated mixin insight and expression
 evaluation available.
 There are still many things left to do though.
I'll give it a try.
I'm currently too tired to start a new thread for announcing another bug fix release: http://mono-d.alexanderbothe.com/?p=825
Jan 31 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 29 January 2013 at 19:35:45 UTC, Jacob Carlborg wrote:
 On 2013-01-29 13:26, Bruno Medeiros wrote:

 By default, yes, but you can do what Jacob wanted with the 
 "Show Source
 of Selected Element Only" functionality:
 http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm
That's somewhat similar to what I had in mind. But that just removes all other code that is not selected from the editor. I want to have multiple editors or views of the same file side by side. These views don't need to be any larger than the code they're showing.
When on Eclipse I tend to use the Java browsing perspective. http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm It brings back memories when I used Smalltalk at the university. :) -- Paulo
Feb 01 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/29/2013 03:14 AM, alex wrote:
 On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
 ...
http://mono-d.alexanderbothe.com/?attachment_id=817 My progress so far. Lots of internals to manage though. The execute-button isn't implemented yet but you can toggle the "Automatically take the mixin at the caret location" button. Concerning things like foo(1,2) - yes, the evaluation engine directly takes the symbols straight out of its parsed modules. So as you create a method body you'll be able to execute stuff in-line. But yeah, remember that CTFE isn't implemented yet ;) - Perhaps I'll do/finish it during the next GSoC. ...
Probably you should do JIT using System.Reflection.Emit.
Jan 29 2013
parent "alex" <info alexanderbothe.com> writes:
On Tuesday, 29 January 2013 at 09:42:49 UTC, Timon Gehr wrote:
 On 01/29/2013 03:14 AM, alex wrote:
 On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
 ...
http://mono-d.alexanderbothe.com/?attachment_id=817 My progress so far. Lots of internals to manage though. The execute-button isn't implemented yet but you can toggle the "Automatically take the mixin at the caret location" button. Concerning things like foo(1,2) - yes, the evaluation engine directly takes the symbols straight out of its parsed modules. So as you create a method body you'll be able to execute stuff in-line. But yeah, remember that CTFE isn't implemented yet ;) - Perhaps I'll do/finish it during the next GSoC. ...
Probably you should do JIT using System.Reflection.Emit.
Why not write an entire D# compiler? ;) (jk, I originally planned to do this right after I've finished mono-d :D)
Jan 29 2013
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
alex wrote:
 ...
Oh, ps. On a completely unrelated note, Just wanted to say that the new Active Profiler display is completely awesome. Thanks!
Jan 28 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-28 23:09, alex wrote:

 Yeah I just named it "Expression evaluation" - dunno why, just thought
 that it could be used in a more general way than 'only' for mixin insight.

 Should I do an extra input box where you could type in expressions and
 other things that could be evaluated? Just thinking of a prototype of an
 interactive D script console or so.. :)
Sure, why not. -- /Jacob Carlborg
Jan 28 2013
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
alex wrote:
 Morning D folks,

 Implemented some new features concerning pre-compile time mixin
 analysis and expression evaluation:

 ...
The new update seems very fast and stable. Trying the new features, Thanks!
Jan 27 2013
parent "alex" <info alexanderbothe.com> writes:
On Sunday, 27 January 2013 at 23:14:23 UTC, F i L wrote:
 alex wrote:
 Morning D folks,

 Implemented some new features concerning pre-compile time mixin
 analysis and expression evaluation:

 ...
The new update seems very fast and stable. Trying the new features, Thanks!
And if not, you know the routine :)
Jan 28 2013