Relative newb to sas enterprise miner. Whenever I run a node I almost never get the green check mark and the status bar at the bottom shows running. However, if I close and reopen the project the check mark shows and then I can proceed.
Any idea what is wrong with my set up that causes this. It's really annoying to have to continually close and reopen the project to be able to proceed.
Related
I've just updated a major C++ project from VS2010 to VS2019, and I'm having problems getting Edit and Continue to work like it used to, specifically in relation to the 'Require source files to exactly match the original version' setting (which I will refer to as the 'require match' setting, because it's shorter).
I'm used to running my program, making changes to the source code while it's running, then setting a breakpoint to catch the running application just before the changed code. When the breakpoint is hit, I could hit F5 to rebuild and continue.
In VS2019, it seems that Edit and Continue will not work without the 'require match' setting, but setting breakpoints in existing code cannot be done with 'require match' once any changes are made.
There's a couple of workarounds, but none are ideal. It's possible to turn on "require match" to build and run the program, then after some code changes are made, turn it off to set the breakpoint, then turn it back on again for the rebuild and continue. That's a huge pain. It's possible to use pause and continue to force a rebuild of any edits, but this only works if the code change is complete enough to build. If I want to break to inspect a variable, this doesn't work. Once or twice I did manage to set a breakpoint on changed code, and it automatically went to the stale code, which is acceptable, but I can't get this to happen now. Also, now I have breakpoints that are showing as valid on edited code that has been rebuilt and I know is running, but the breakpoints are not being hit.
Any solutions here, or does Edit and Continue simply not work as well as it used to?
Here's some pictures...
Firstly, while my program is running, I made some change to surfdraw_panels.cpp, then went to add a breakpoint. It shows the following message...
Then loads up a [stale] version of the code, with the breakpoint set in the stale code...
Other times, when I make a change, I get a different result, and it won't allow me to set a breakpoint at all... In VS2010, it was possible to turn off the 'require match' setting and still use 'Edit and continue', but VS2019 will not allow this, even though it is still the recommended 'solution' in the message!
Github project that shows the issue is below. It's a simple MFC app, dialog based, created by the new project wizard in VS2019. There is a single button on the dialog, and some simple code to do something in the button. To recreate the problem, start the app in the debugger, then make a change to OnBnClickedButton1(), and then try to set a breakpoint.
https://github.com/surfdabbler/MFCApplication1
Not quite understand your specific situation and operation, because there are not some pictures and code to explain the issue in detail.
But this function which I used could break into the changed code during debugging with require match option. You should move your cursor back to the changed code and then Debug the below code step by step. And when you move the cursor back to the changed code, vc++ project will rebuild the changed code automatically and you do not have to stop debugging and restart build.
Update 1
I also faced the same behavior in my side. And since we could not handle the issue here any more, I reported the issue on our DC Forum.
You can vote it and add any comments if I did not describe the issue in detail so that it will get more Microsoft's attention. And I hope the Team will give you a satisfactory reply.
My Log window seems happend some font cahe issue, Sometimes it suddenly makes the font BOLD and that bothered me these days. Here is my first question: Dose anybody has any hints about the font issue?
Forunately I find the Log window return to normal if only I close and reopen it, so here comes my
second question: Is it possible to open and close the Log window in SAS DMS? If so, how to write it?
Use the DM statement to programmatically submit available SAS Commands under Windows or SAS Display Manager Windows Window Commands and most important for this question SAS Windows and Access Methods
The LOG command has a seemingly undocumented (online web docs) option OFF. There is likewise a seemingly undocumented command CLEAR. These commands are documented in Windows DM via F1 (Help) -- do a Quick Search for "SAS Windows and Access Methods".
DM 'CLEAR LOG; LOG OFF' LOG;
You might also want to check the DM windows font setting. Submit or issue DLGFONT
DM `DLGFONT`;
Finally, worst case, there is a possibility the SAS DM configuration file is damaged. Locate regstry.sas7bitm, profile.sas7bcat in the sasuser operating system folder and , when SAS is closed, rename them so they are recreated anew at the next DM SAS session start.
If you are using a different SAS client, update your question and add your system setup.
I've been using WAMP server for a few of my school projects however I have had a lot of trouble with it staying green. I am pretty sure its an internal issue but I'm not really sure how to figure out what exactly is happening. The main problem I experience is that it installs fine and runs. However, whenever I restart my laptop it will not turn green. It stays orange and says 1 of 2 services running. I tried the methods I saw online however it does not even let me right-click it to see what isn't running or to restart the services. I've had to reinstall it about five times to keep using it and it's getting extremely annoying. I think it has to do with mySQL not starting properly but then why do I not get the option to right click?
check if you have any previous installations ( for example : mysql,MariaDB ..ect ) and open task manager and see the proccess of mysql ( open the properties ) if the path isn't from the wamp mysql then desactivate it / kill the process.
here's FAQ Link that helped me alot in the past , you may find it usefull
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
I have developed the python script for checking out a source code from repository and build it using visual studio.When i run the script,a GUI opens(developed using wxPython) which shows a button,clicking on which does the checkout and build.I would want to show a progress bar showing the process running when i click on the button and a success message after the script finishes it's work.Please help me out.
Thanks in advance.
You probably won't be able to get an accurate progress unless your build scripts are generating some progress information in the output that you can parse and represent in your GUI. Either way you will probably want to use wx.ProgressDialog or use a wx.Gauge in your main panel or something like that. Both wx.ProgressDialog and wx.Gauge can be used in a mode that shows actual values (a percentage complete) or an 'indeterminate' mode that represents that something is happening but there isn't any way to tell how far in the process it is.