Aug 12, 2007 at 3:11 AM
Edited Aug 12, 2007 at 3:15 AM
sigh I feel like I’m running in circles making changes and trying to follow what you changed too :-p I’ve been busy with refactoring, but I still have one threading bug which popped up on me.
And are you sure you don’t want to switch to 3.5? I mean, who is the typical PoshConsole user? I think PowerShell enthusiasts won’t be so reluctant to install a beta (second one, already! ) of a small “.NET service pack”.
Well, I guess I don’t know … the guys that I’m aware of that are using it are a mix of powershell users that just wanted a better console (some of whom will probably switch to PSPlus when it comes out) and random people who just like the fact that it has the
quake console mode and generally looks better than the regular console. ;) Personally, I worked with ASP.NET AJAX and .Net 2.0 when they were in beta, and in both cases I was frustrated to have to rewrite several things after additional releases, not to mention
pain and suffering to get the beta uninstalled when the final was released.
Anyway, point being, part of the reason I’m reluctant to work on 3.5 is that MS doesn’t have a good record with me of moving smoothly from beta to final – not to mention that the only schedule I know of for when 3.5 is going to be final is the fact that they’re
calling the new VS “2008” … the rest is the fact that when I did release .Net 2 beta stuff, people were surprisingly reluctant to install betas of .Net in particular -- I mean, even people who run beta software don’t like the idea of a beta framework.
What kind of threading bug? I found that if the prompt function uses $host.UI, it deadlocks on Dispatcher, because the UI thread is waiting on the pipeline to complete. You might want to check it out, everything except TabExpasion is asynchronous now.
Oh, I had screwed up the brushes. Something about how I had created the brush on the non-gui thread and was trying to use it from the GUI thread, or … something. I really don’t get it: how I fixed it was the changes I made in the Colors stuff to Dispatcher.Invoke
them. The problem was: I had it working on my XP box, but when I tried to put it together to release on my Vista box, it died (deep inside the dispatcher)
every time the Write method was called … but not in a deterministic place. I could step through the whole Write method, and when I stepped off the end, it would crash (like, not in my code, and before I got back to the line that called Write). Anyway,
I fixed that, and I guess I should async everything, Mow’s powertab script writes to the gui and does Buffer* stuff too, so we’d probably have to async tab completion to get it to work.
BTW I was thinking about integrating PowerTab, since I really don’t want to re-implement it. We talked that with Oisin (x0n) the day before yesterday, he said MoW is willing to donate PowerTab to PSCX. He also said it has a pluggable output script, so we should
be able to provide Out-PoshTabExpansion command, which would display the popup or fill the <Tab> buffer.
Define “integrate.” It should already work if you just turn off his console-based menu output. I call the TabExpansion script, so his would return a collection of things which we’d put in our menu…
I don’t want to re-implement PowerTab either, but… to be honest, I think it does too much and is slower than I’d like … I
do think it will already work within our menu if you turn off his console menu display though. In order to avoid duplicates I was going to make the tab-completion pieces I already wrote optional, and I actually thought about making them plugins
(ie: make a “TabComplete” event where the argument carries a collection of completion strings that plugins add to) so that people could enhance the tab completion with, uhm compiled code.
You know, we should probably have these conversations on the forums so people can see them ;)
OK, it’s your turn
I copied it to the forum (here we are).
Adding the current item to the history if you arrow up makes sense to me, I’ll have to take a look at what you did, I was struggling with how to do that and not leave it in there if they don’t end up using it. Incidentally, right now the history buffer is circular
… I was thinking I should probably change that because it’s probably a little confusing and not normal for consoles.
You can take my ConsoleControl..History, it’s a pretty self-contained class, which does this non-circular buffer. I changed it just that it keeps the history in a list, instead of asking the runspace every time. I’ve done it this way because the runspace history
does not contain lines that could not be parsed, which is quite annoying for the arrow history. I’ll provide a method for adding the entries on startup, so it will support persistent history across sessions.
Yep, already on it ;)