Are there any plans on fixing killer bugs, the bugs that are at the same time easy to fix and cause a lot of pain?
Are there any plans on fixing killer bugs, the bugs that are at the same time easy to fix and cause a lot of pain?
1. The Out of memory problem I have reported is still present in the latest version, even got worse.
2. Ctrl+ fucking space works 20 percent of the time and is stupid slow even with obvious things, such as suggesting a unit in the uses section, finding an identifier that is defined in the same unit. WTF? Come on already!!!
3. Ctrl + fucking space in a class definition doesn't suggest anything until you hit Compile and break compile. WTF
4. When you break your app, the debugger shows up some random place in the CPU window, then you have to find your thread, which is not obvious, because it has a meaningless name. WTF.
5. Debugging the functions containing anonymous methods. Ctrl+F7 doesn't see local variables, local consts. Even the consts, Carl !!!
1. The Out of memory problem I have reported is still present in the latest version, even got worse.
2. Ctrl+ fucking space works 20 percent of the time and is stupid slow even with obvious things, such as suggesting a unit in the uses section, finding an identifier that is defined in the same unit. WTF? Come on already!!!
3. Ctrl + fucking space in a class definition doesn't suggest anything until you hit Compile and break compile. WTF
4. When you break your app, the debugger shows up some random place in the CPU window, then you have to find your thread, which is not obvious, because it has a meaningless name. WTF.
5. Debugging the functions containing anonymous methods. Ctrl+F7 doesn't see local variables, local consts. Even the consts, Carl !!!
And Ctrl+F9 got broken some when after XE2. Now if you change something in the interface section of a unit there is 90% chance the app want compile, you have to Shift+F9. WTF
ReplyDeleteIs this situation considered normal? If it is, there is no future for Delphi.
ReplyDeleteI have not seen an out of memory error since that was fixed myself
ReplyDeleteI can make another video-proof
ReplyDeleteAnd I've forgot the .dproj problem. Why do you mess them up after every compilation? Why should I install an extension to fix this? I'm not even sure if it helps.
ReplyDeleteI noticed that the behavior when compiling without Debug DCUs has changed in 10.2. If I opt to not use Debug DCUs now, it won't let me set breakpoints. It's as if Debug build is disabled. But enabling Debug DCUs ends up with F7 going into every stinking system unit!
ReplyDeleteIt seems to be ALL-OR-NOTHING now! You either get ALL Debug DCUs (including 100% of Delphi's libs and VCL), or NONE (including not even the unit you're trying to debug).
David Schwartz I cannot see this in my system (10.2 Upd 1). I have Debug DCUs disabled and can set breakpoints at my wish in my code all over the place (not in the RTL/VCL units of course). To selectively debug also into those units, I use my SelectiveDebugging plug in: uweraabe.de - Selective Debugging
ReplyDeleteUwe Raabe that's odd.I've got 10.2.1 as well, and it does what I said above. I wonder if there's another setting that affects this?
ReplyDeleteI agree that these bugs should be fixed ASAP, but I doubt that they are easy to fix.
ReplyDeleteFirst task to fix a bug is to be able to reproduce it in a reliable way. Otherwise, how can you know if it is fixed at all?
ReplyDeleteIf the bug is only visible at your system, it is most likely be caused by some setting or third party tool. A virgin installation in a VM might reveal that.
When you have a reproducible test case showing the bug and you are on an active Update Subscription and you are not willing to rely on Quality Portal, you can use one of the three technical support incidents to get Embarcadero working on that.
I didn't check, but are these bugs already tracked in Quality Portal? Can you post the issue numbers here so that we can comment and vote for them?
/sub
ReplyDeleteDavid Schwartz I don't use debug DCUs either and it works as Uwe Raabe says
ReplyDeleteThe code completion is very slow in the IDE. Recently I installed CodeInsightPlus and it's very fast. I installed the trial but I am not sure if it is under development anymore as the site seems not to be updated devjetsoftware.com - DevJet Software » CodeInsightPlus
ReplyDeleteCode completion (object.) doesn't work after you Ctrl-F2 a running app. You have to compile again, for it to work again.
ReplyDeleteCnPack has an awesome replacement for CodeInsight -- I stopped using CodeInsight months ago and haven't looked back. CodeInsight was just too slow and buggy. It can take some time to get CnPack configured how you want it -- it has a LOT of options.
ReplyDelete/sub
ReplyDeleteVitali Burkov I'm with Uwe Raabe. Are there reports for these in QP? All I see so far are one-line descriptions with no reproducible steps, no versions etc
ReplyDeleteOn my system, code completion is not slow.
ReplyDeleteVitali Burkov Why are you asking here? We don't develop Delphi. Ask Embarcadero.
ReplyDeletebecause it's the holyday season, and I am lonely af
ReplyDeleteVitali Burkov We have exactly the same issue with Ctrl+F9 not working after changing any code in the interface section. I've had numerous back and forth (email and telephone) with embarcadero support on it, I've made videos showing them the issue, offered to have them login to my machine, etc, and it went nowhere. It only happens in my very large project; all other smaller projects work fine; so it is impossible for me to give them a reproduction scenario. We said we were not going to renew any of our licenses, and they tried to set up a call between us and Marco directly; but they are still unable to actually resolve the problem..
ReplyDeleteBrian Ford same here. 2M lines of proprietary code, and they ask to send it to them so they could find the bug.
ReplyDeleteVitali Burkov That is all reasonably and you would hear the same from me if I were in charge for that. If the bug happens only with your code, how do you expect someone to fix it if you don't let him/her debug it with your code? It will probably still be hard to find the bug with access to the code triggering the bug, so it is near to impossible to do so without.
ReplyDelete1. You can retrospect your code for the possible causes of the bug, because it is a regression.
ReplyDelete2. You can make a version where you log everything suspicious and debug with that.
3. Or you can just say, send me your code, can't reproduce
Vitali Burkov Option three seems to be the one with the fastest results.
ReplyDeleteUwe Raabe I would think they would have some sort of logging or could enable such to help them track down these "internal compiler errors". I offered to give them access to my machine to reproduce the issue; or to run any sort of debug/logging build they wanted.. They just didn't seem to actually care about finding or fixing it.. I was not going to send them my 1.4M line project.
ReplyDeleteVitali Burkov I deleted your comment suggesting violence as a solution. We don't treat anyone like that, no matter what. Keep it constructive, please.
ReplyDeleteaccess violation, privileged instruction
ReplyDeleteVitali Burkov 5. Is there an option for them to remotely debug the IDE failure? Years back CodeGear wanted to see our large full complete source code, which we declined, but we did briefly discuss setting up remote debugging from their end. From what I recall, the problem that I was chasing was luckily solved shortly afterwards without the need for this action. If it is easily reproducible with your source code, then maybe this could be an option which you could request? As a side, it would be kinda cool to have #2 with CodeSite logging of IDE actions enabled with a feature toggle to provide more detailed logging of internal operations but I would wager that's not coming anytime in the next few years as adding extensive logging can adversely affect large legacy code/brittle type applications such as their IDE. (Assumption of legacy code.)
ReplyDelete/sub
ReplyDelete/sub
ReplyDelete