First of all I'd like to say hello to the community, I'm quite new to programming and this community overall, and I'm just learning programming cause I find it interesting. Lately, I've stumbled upon an issue.
This hasn't happened before and I did not change a single setting in Code::Blocks. Whenever I compile and run (F9), the console text shows up only after about 2-3 seconds. This delay is really annoying and I'm unsure what could be the cause. It doesn't matter how long the code is or what I'm compiling and running, as this happens equally from a simple Hello World! program to something of 80 lines. This is not a very big issue but it is quite irritating and I'd like to know if this has happened to others or if I can follow some suggestions.
Thanks!
Ah, nevermind. This issue was due to my antivirus for some reason (Using Panda Antivirus). Whenever I stop it, the problem doesn't happen for some reason. I'll need to look into this.
Related
I'm a student who uses Netbeans on Mac to Program in C. Due to my previous experience with Java, I really like the feeling of Netbeans IDE. However, I recently noticed, as my projects gets longer and longer, simply coding the plain text is starting to lag heavily, inside the IDE editor.
For example, when I type in any words, even if just comments, if feels like it takes the computer a second or two to respond to every type. Things get even worse when I try to scroll up and down in my code, the response takes a long time, making it feel really bad.
I thought this might be a problem that the IDE haven't been given enough memory. However, after increasing the memory given to the program, it still lags heavily.
Is this all due to the fact running Netbeans to program in C is a bad idea? Or is it something else going wrong in my case?
Thank you very much!
Let's see...
The result is kind of clear. There just wasn't really any viable plan to make it work...
I started working on another computer instead. It seems mac just don't really want to work with netbeans, especially about C.
In my case (MacOS Monterey) the problem was the font size. The more I increased it, the worse the IDE would work.
Over 14 font size the lag is pretty extreme.
I would recommend using another IDE as it looks like this problem has not been fixed even in the latest version.
I have come across a wierd vis studio error which only had one other question I could find that is Similar.
When I try to debug the code I hit run and it says there are errors would I like to run the last working version to which I say no. This then comes up with 91 errors which slowly disappear until there are none left.
This may be quite hard to understand what is actually going on, so I have recorded it to make things a bit easier.
Link to video
I have no idea what is going on and cant seem to find anything other than that other question, which the guy did solve but the next day he turned on his computer the same thing happened, I don't want to be fixing this everyday.
Any Suggestions would be great!
Thanks
All fixed now, I still have no idea what was wrong with it. I just deleted it all and pulled it back down from TFS and it worked, it is a bit of a strange one.
Sorry for a more technical question, but I am stumped now. A few of my AP students this year using jGRASP with Java 7 on their MacBooks (Yosemite) are encountering a strange situation, where the first compilation of the day often takes several minutes to finish. Subsequent recompilations of any program proceed almost instantaneously, as if there were no problem. The next day, the problem resurfaces.
Any ideas what might be causing this problem? I have asked the students to download the JDK and jGRASP and reinstall them, but that does not seem to fix the problem. Other students in the class with seemingly identical machine setups have no issue. So confused???
Thanks!
Roger
Most likely this is an issue with the file system cache. Have them try entering the "purge" command in a terminal, and see if the problem repeats immediately afterward. I'm not familiar with diagnosing such problems, but that would at least point you in the right direction. One obvious "cause" would be too many applications running (or not enough memory).
If that isn't it, have them compile from the command line for the first compile of the day, and see if it repeats. That will tell you if it is jGRASP or javac that is triggering the problem (I say triggering, because some OS issue is most likely the actual cause).
I have an issue I don't seem to find a solution for.
One of the transactions gives ABEND ASRA when used in debug mode.
When I compile the Cobol program without debug option and run the program, it works fine.
The error looks like this one (quite exactly like this), only I am using Cobol V4:
http://www-01.ibm.com/support/docview.wss?uid=swg1PM96501
Now the question would be: why is it abending in debugger and not without debugger?
I am using the CICS debugger (DTCN transaction), the program starts normally, I can do steps with F2 and all this, then at some location is abends.
Please note that it is extremely difficult to say where it abends as the program is really big.
This happens only to this program at the moment, others are running fine with debugger. I placed a breakpoint before my modifications, the abend occurs in some other area.
Another weird thing is that this Abend is not consistent, If I do a big portion of the code with small steps (F2 and small breakpoints), sometimes it executes without abend until the end.
Due to the nature of the issue, I can not post much information.
I was hoping you encountered similar issues and you can tell me where to look for.
Thank you!
The issue was solved by deleting my debug tool profile form the system and then login to the debugger (DTCN) again so it creates a new profile (the profile was 3 files: TOOLTEMP.PDTOOLS.{userid}.DBGTOOL.* ). After this the issue was gone. I asked the guys how this happened, they told me this was because I had modified the program between 2 debugging sessions without closing CICS. This was a disfunction that can be avoided by closing CICS while we compile programs used in it (not sure about why exactly.... neither are they).
Hope this helps if you face a similar issue with DTCN debugging.
Ever since I started using Xcode, I've experienced extremely annoying problems with Code Sense. The problem is that when Code Sense kicks in for code completion, sometimes the source code text below the line I'm working on goes "crazy". If I continue typing, the problem gets worse, and after a while the source code is completely screwed up (funny colors, missing lines and characters, ...). Strange enough, the source code itself is unaffected, because when I select another source file and then go back to the one I was working on, everything looks fine again.
The problem can be seen in this screencast: http://www.screencast.com/t/OGY3NWE5
Interesting facts:
This problem has occurred on 3 different machines, so it's not related to a corrupt installation.
Sometimes it's fine for a while (up to one hour) after launching Xcode, but once it starts happening, it's getting worse and worse, until Xcode is restarted. Then it's fine again (for a while)
I've searched the web for similar experiences, and I can't find anything. I would think that it is a known problem, since it occurs on 3 different Macs here (both running 10.5 and 10.6).
Anyone having the same problems? Or a suggestion for fixing this?
Yeah, it can be a real pain. I didn't find a 'fix for it as such, but I do a quick switch from implementation to header (or vice versa) and then back again using Command-option-up. The screen redraws and everything is fine again
Well, I finally (kind of) fixed this problem by simply turning off Quick Help. Previously, I left this on all the time, and it resulted in a very unstable code sense (to the point where Xcode simply became unusable).
This is not a real solution, but it should at least help people experiencing the same issue.
I wrote about it here
My issue was with localization. if your XIB file is localized using xcode 4's, then it was failing for me. removing the localization worked, though not a proper solution.