Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


androidi androidi
  • VS2015: Writing comments into code while debugger is running?

    I posted this here...



    This suggestion above should be less involved to implement than the one I mentioned earlier as it works with the existing edit & continue, should be doable without any runtime/clr changes.

    The difference with to this earlier idea idea is quite subtle. I worded the suggestion differently so as to make it sound simpler to implement by allowing the idea to work with the existing edit & continue.




  • VS2015: Writing comments into code while debugger is running?

    Can you write comments into code while debugger running in VS2015?

    In 2013 I have to pause, which may cause debugger to change editor to another file. Much of the time what I run is stuff that simply pausing it in debugger causes things to break beyond what the bug might be (eg. server maybe expecting responses every n seconds, otherwise the whole thing needs to be restarted and that could be really heavy process).


    A possible way to do this is, while the debugger is running, if you start to write comment with / it should allow writing that while running. A future improvement would be to allow writing code with intellisense by having the IDE notice which lines were added while running and highlighting them (if the file is saved, the new code could be inside //#/ /#// tags for example so the IDE knows that that code is inactive and needs to be highlighted. Then remove the tags when program is stopped. If it's paused then maybe you could "commit and continue" the edits you made by right clicking the highlighted code and "committing" it.



  • Apple going ​full-​gimmicker?

    (I'm not suggesting this but if Apple is going forward with this then lets see how it could work)

    To take the "bar gimmick" to max: 

    Keep the function keys and add the oled bar in a way that it can be used like those "keytar" slides, so it can instead of keypresses send pressure and the horiz/X position of finger in the bar. Then have it user/app-mappable to keys or whatever without needing to write a driver to access it in either the X mode or the mapped key mode.

    While at it, make the keyboard backlight light the keyboard keys like piano keyboard (no-backlight representing the black keys) and have n-key rollover. (Surface Pro 4 can only detect 3 keys at once worst case I tried) (typically Z and Q are white "C3/C4 note", so SD,GHJ would be "black" and not backlit - based on how typical keyboard piano controls work in music apps.

  • Apple going ​full-​gimmicker?

    "He goes on to explain that the OLED display touch bar will replace the physical function keys,"


    I hope the OLED can be turned off as sometimes you just don't want to see lights from your keyboard. I do see uses for it but if it deters from the physical feel and can't be fully adjusted it could prove annoying gimmick.


    Umm yeah. Where can I find a 3:2 display device beside Surface Book? Another rumor I saw was that Microsoft would go for widescreen Book.. I just want a 3:2 13-14" display (not incl.bezel) and as light as feasible. IDEALLY with some internal bays that can take a battery/custom ports/2nd ssd - so if port X goes obsolete or break you can later replace the internal ports without buying a new device or getting screwed in repair after warranty over. That would justify the $$$$ price tag better than these 1 port jokes that have no lifespan because repair is always half the cost of new unit after warranty is out.



  • So I heard Windows 10 has better MIDI timing?

    Would be nice to get similar comparison and details of what hardware was involved. Surface Book or Pro vs asrock z97 extreme 6 (which I got based on AT review suggesting it had lowest dpc latency) and what interface... (having comparison to the ES interface and RME pcie + usb interfaces would be nice along with some cheaper USB interfaces)



    And if W10 needs some power management tweaks, turning of a bunch of background updates, services etc to keep the midi timing stable across say 6 hours, then that should be mentioned too.


    Some background to those not familiar with what this is about:


    Typical PC experience in the comments: "I have tried for a decade to get a PC to be as good, and failed after throwing a couple of grand at it."



  • Anyone familiar with 'Common Lisp'?


    Yes if there is a large buffer involved and you could write the code in the editor such that you can apply the whole code during edit&continue. In that scenario you could pause the synthesis without glitching. (you could temporary increase the buffer size also just before applying the changes)


    On funny note, this concept of updating the compiled code without pauses & glitches could be applied elsewhere:



  • Anyone familiar with 'Common Lisp'?

    @bondsbw: Could you use it for this type of scenario?

    (just making this up but it's very close to audio/procedural synthesis, dsp programming, AR/VR/simulation tweaking etc needs)

    Lets suppose you have large resource to deserialize that contains large loop of brainwaves (or AR/VR environment). You have a requirement to playback these these waves without interruption as you use a device to put these brainwaves in your head while developing the algos. The idea being that you can manipulate a complex piece of code that modifies the brainwave in realtime. In order to be effective you'd want to flip flop between the freshly tweaked algo and the old algo, without any interruptions, such that the tweaks "align" in a way that the output does not glitch, kind of like fading from one piece of music to next without pause while programming algos to modify the music.


    The key here is that the tweaking is such that in order to "notice" the tweak effects, you'd have to "feel" the changes as they happen as they might be subtle and you'd miss them otherwise (imagine tiny tweak to audio EQ, if you restart the music on every slight EQ change, you'd probably not notice it).

    Now of course you could program UI with a control to tweak the algo but... I only do console apps and what if you want to do complex modifications and compare their results quickly etc. You'd need script language inside the playback engine (like winamp AVS has). But C# should be the script language and it should be usable right out of the gate, no need to write UI or separate engine to run it for such scenarios.

  • Anyone familiar with 'Common Lisp'?

    There is the problem of runtime side effects changing state such that after lot of tweaks, you get the program working "live" but after restarting it doesn't work as it worked during live edit.

    The solution to this is to count how many different variables were touched after/between every live-edit-commit. Show this number in a list of 2 columns : variables changed inside my project, addresses touched by dll's called. Then you can see if there are anomalous number of changes between edits and based on this restart the project before starting to take dependency on those changes.

    Scenario: Using immediate window to pull stuff from network, writing code against that stuff outside the immediate window, then expecting that "stuff" is still around after restarting. The persistent list of # of variables changed allows to notice if some "unusual tweaking" was done during the live edit - after all the tweaking should be about tweaking logic not initializing resources or doing side effects but C-like programs don't section these in a way that is visible to debugger & runtime. (such sectioning might be useful for the live editing but maybe not useful for some type of programs, so perhaps an option)

  • Anyone familiar with 'Common Lisp'?

    A possible ~answer~ (rather than perfect solution which may not be possible or worthwhile) to a & b problems is that edits made inside "main loop" while the code is running are highlighted and new files, classes created are also highlighted. And a warning is shown that the results seen from current edits may not reproduce after program is restarted, because "obviously" the state might be very different then.

    The live/runtime-made edits could prefix the changed lines in the C# files with eg. #++.

    After happy with the live edits one could restart to validate that the changes do what was intended before removing the #++ from those lines permanently. The prefix allows for easily finding&storing away those various live-edits in .patch files incase later edits are less desirable (think tweaking some audio/gfx/dsp code where the ideal result was not known until many iterations of tweaking) .

    This way you get best of all worlds : ability to runtime code in the editor (as opposed to command line) without initialization burden and also ability to verify the code works after restarting + ability to develop a system for quickly comparing various small tweaks by momentarily "enabling" the stored-away 'previous live edits/.patch-files'.

  • Anyone familiar with 'Common Lisp'?


    But umm.. lets say you tweak up something nice in the Interactive window.. And decide you want to make it persistent in the program. You have to rewrite all the code again?

    I much prefer the full editor and "committing" changes to a live program, with highlighting of unmodifiable areas. edit: + option to merge those "live changes" after verifying them after restarting project with the live changes but before "persistent merging".

    Now the reason why this probably is not "welcome" to some is that it's a) not super robust b) it's "hack'ish" - edit: but I will explain in next post a solution to these problems