The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
For me all i see is that the desktop term comes from digitising the physical desk. Trach can, draws, folders.
As for for Desktop wallpaper I imagine when the developer working in a cubical, where you could stick things to vertical surfaces. I've only ever worked in "open" work places, because as a developer I want more noise 🤷♂️
This have given me an idea for an unmixed-metaphor GUI.
It will have a desktop, but it will be covered by a proper blotter. The mouse pointer will of course be replaced by a nib, which will need to be periodically dipped into the inkwell at the bottom right of the screen to keep it working (fountain pen upgrades available in the app store). To save a document, you of course turn it over and press it to the blotter. If you want to send an email the pneumatic tubes are there for you on the right, and if you want to open a chat session there's a teletype to your left.
There will be no windows, because as everyone knows if you want work to get done you put people in a room with no windows.
This is golden, I should pitch it to VC guys. A decade ago this would have been enough to get to an IPO.
Back in VS2013 days, you could pretty much code all day on one compile... when it crashed, or stopped on a break, you could move the execution point around, or unwind the exception, change the code, and carry on again.
Ever since VS2015, Edit & Continue has been broken - mostly, the slightest change results in a System.ExecutionEngineException, and everything has to be stopped and rebuilt.
It's still the same with VS2019, slightly improved perhaps, but a long way from being robust enough to be usable.
The guy I work with has refused to move forwards from VS2013 for this reason, as much of what we do is maintaining and enhancing a .net 3.5 Winforms app. It has well over half a million lines of code in it, so moving the whole lot to WPF isn't an option.
Microsoft has closed all the incidents I've raised, despite my sending them a YouTube video I made showing how VS2013 worked perfectly, and VS2017 failed, on exactly the same code.
Any ideas? It would be so amazing to be able to use E&C again, in the way it was obviously intended, as an actual productivity tool.
I had my GLR parser generator all ready to go, so I want it to demo something that only an advanced parser like a GLR parser could parse (at least without handwritten parts, unlike Parsley)
I loaded up my C# subset (Slang) expression grammar and started to port it from parsley to glory which means removing the handwritten components and replacing them with the sort of BNF/XBNF constructs that Parsley couldn't parse.
Here's the problem: GLR grammars are never rejected. No matter how dodgy the grammar you give it is, it will find a way to accept it and parse it, even if what it returned might not be what you intended (as happens with complicated things)
That might not seem like a problem until you're trying to actually build a valid grammar. GLR will accept anything "valid" or not. All "invalid" means to GLR is that your parse trees won't come back in the form you expected them to.
Detecting whether a grammar is globally ambiguous is mathematically impossible (it has been proven undecidable)
So the next best thing would be to do analysis on it by trying to generate a less powerful parser using something like LL(k/*) but that doesn't quite work since LL only works on grammars that are not left recursive. Even if I knew how to implement LL(k/*) (I don't). Even if that wasn't an issue it still doesn't work because there's still a set of grammars GLR parses that LL can't - ambiguous grammars
It's a logic problem. I want it to reject invalid grammars but it can't know what "invalid" means unless I tell it, which is what the grammar is for in the first place!
The only thing i can think of is having a way to specify in the grammar that a certain construct should or should *not* be ambiguous but I am almost positive that will not work as I don't think it's mathematically possible to detect all local ambiguities either.
Frankly, GLR is *too* expressive. I just don't know what I can do about that, but it makes constructing accurate grammars extremely difficult.
Other people have built GLR parsers, so there might be a clever solution somewhere for this, but I'm not likely to google the problem and find much - GLR is rare, aside from Bison, the only "mainstream" parser offering that includes it, and it was only added later on.
If I had thought far enough ahead I would have researched that up front, but now I'm wondering if I should ship like this, or hold off until I can find a better way.
I'm wondering if I should ship like this, or hold off until I can find a better way.
EA games would have shipped a couple of months ago and provide an expensive DLC to fix it.
Apple would call it a battery saving feature and ship a new version of the hardware.
Samsung would call it a hand warmer.
Corel wouldn't even ask themselves the question ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
they would ship, release most of the fix incrementally over a number of 'updates,' then lose interest.
(queue the haters ...c'mon, y'all knew I couldn't resist another dig at les miserablesoft)
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
I am not sure I follow you here. Are you saying that a well designed GLR parser accepts any input? So, if V is the set of terminals, your generated parser will accept V+ ?
It seems to me that there are easier ways to accept "any" input string