|
Surely, it should be Curtains for Windows?
Apart from the pun, it is actually quite a good analogy - when the curtain(s) across, you can't see the windows...
|
|
|
|
|
Either that or the hamsters have been given too much fermented sunflower seed...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
 I don't get it?
|
|
|
|
|
CP disappeared for 15 minutes or so - even isup.me agreed it wasn't working.
I blame the legalisation of Hamster Narcotics, myself.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks for clarifying!
Quote: I blame the legalisation of Hamster Narcotics, myself.
This is entirely possible. Pot is legal in Canada as far as I remember! 
|
|
|
|
|
OriginalGriff wrote: fermented sunflower seed
While browsing CP this evening, I got a page saying that "CP's crack team of sysadmins" were performing an upgrade. They obviously prefer a different poison.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: I got a page saying that "CP's crack team of sysadmins" were performing an upgrade.
As opposed to microsoft update's sysadmin team of crack-heads?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: microsoft update's sysadmin team of crack-heads?
You've just offended every crack-head out there. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
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'm not a fan. I wouldn't trust it. I prefer it to tell me the code is running when I accidently press a key and prompt to stop the run -- which is what I usually want to do.
|
|
|
|
|
EDIT: I decided to ship it as is
I messed up, I think.
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. 
Real programmers use butterflies
modified 22-Feb-20 10:27am.
|
|
|
|
|
honey the codewitch wrote: 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!
|
|
|
|
|
Hahaha it's funny because it's true!
Real programmers use butterflies
|
|
|
|
|
you forgot microsoft:
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!
|
|
|
|
|
lopatir wrote: queue the haters
"Cue", not "queue".
That'll be 50 cents.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
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
|
|
|
|
|
It will not simply accept V+
I'm saying it accepts any grammar, not any input (maybe I misspoke somewhere above? i haven't looked)
The inputs must conform in some way to the grammar provided, but the grammar can be ambiguous in any way.
Real programmers use butterflies
|
|
|
|
|
You're simply confirming that (good) design is an iterative process. More bangs too.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Is it just me or has the latest update to VS2019 made it a bit of an unstable mess? At least once a day it locks up and rolls over with all 4 paws in the air and restarts, losing whatever I had unsaved.
I feel like I'm back in 1996, hitting Ctrl+S every 3 carriage returns
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: I feel like I'm back in 1996, hitting Ctrl+S every 3 carriage returns
ahh, life on the bleeding edge.... I DONT miss those days at all.
ON ERROR GOTO RULE 1
RULE 1 to 100: You will only update when I know it's safe and only when I say to do so.
RULE 101+: see: (rule # MODULO 100) + 1
GOTO RULE 1
You have auto-updates on ???
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!
|
|
|
|
|
lopatir wrote: You have auto-updates on
For VS? No. (didn't know that was even a thing)
cheers
Chris Maunder
|
|
|
|
|
I'm currently using Microsoft VS2019, smoothly, with no crashes. Probably, you'll need to completely reinstall VS2019 on your development machine. Beforehand, I recommend creating a complete VS2019 installation layout on your local drive and then use the offline installer. Here's how: Create an offline installation - Visual Studio | Microsoft Docs[^].
Simply, re-install VS2019 without any add-ins such as Intel Parallel Studio XE integration or whatsoever. And, then, try using it. Will it crash again? Specifically, for some time ago, I've experienced a problem using Intel Compiler 2019 XE integrated with VS2019. A complete re-install of Windows from my system drive backup helped to solve the following problem.
Also, this could be also a hardware problem with system memory (RAM) on your development machine. In this case, I also recommend checking your PC's system memory with memtestx86+.
|
|
|
|
|
You mistake me for someone far less lazy than I am 
(but thanks for the tips)
cheers
Chris Maunder
|
|
|
|
|
You're very welcome. 
|
|
|
|
|
Have you tried changing your desktop wallpaper?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
