OMNet++ v4.6. Windows 7 Professional.
I have been using the supplied omnetpp.cmd from \omnetpp-4.6\bin for over a month with success, after a few failures (null pointers in OMNet) the OMNeT Eclipse editor will start, but when running a simulation the Tkenv window will no longer appear.
I get the taskbar icon, but no window.
When I run OMNet++ using mingwenv.cmd which gives the bash shell, omnetpp works as expected.
I have rebuilt the OMNet++ 4.6 environment from the .zip file again with no improvement.
I deleted the .tklenvrc file for my simulation (as suggested in the "OMNET++ Tkenv/GUI doesn't appear anymore" question) but this has no effect. One could say, "Just use the bash shell" but I'd like to keep at a Windows level. Any ideas?
I would like to point out that the recommended way of running OMNeT++ simulations is to run them from mingwenv.
If you really have to run them from command prompt you must ensure that your path contains:
omnetpp_root/bin;omnetpp_root/tools/win32/usr/bin;omnetpp_root/tools/win32/mingw32/bin
Also be aware that <omnetpp_root>/bin/omnetpp.cmd is used to start the IDE while the simulations should be started from the mingwenv.cmd bash prompt. These two things are totally unrelated (i.e. the IDE and the simulations running in Tkenv)
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I was trying to use OMNeT++ earlier today but I was unable to get any simulation to run. I tried numerous model simulations but they began hanging at the same place during initialization. I deleted and re-installed OMNeT++, but the problem persists. So even after a fresh install of OMNeT++ v5.5.1 on a Windows 10 v1903 machine, I am unable to run any simulation. This is what I saw when I ran the Aloha sample simulation executable directly after following all the OMNeT++ installation steps:
The Qtenv simulation window starts up but it's completely blank, and I can't actually focus on it, which leads me to believe there's something up with Qt. The program hangs indefinitely at this point. OMNeT++ was configured using the default values found in configure.user.
Any suggestions?
EDIT:
This is the last console output I receive after running QT_LOGGING_RULES="*.debug=true" ./aloha.
This is the last console output I receive after running QT_DEBUG_PLUGINS=1 ./aloha.
Did you connect additional monitor to your computer? Sometimes Windows remember position of an application on non-existed screen. Try to change your screen properties or connect second screen and look for Qtenv window of Aloha simulation.
Besides the above, delete .qtenvrc from samples/aloha.
I used Msys1 for many years and was used to CTRL+C for killing processes that I start within my shell.
After updating from Msys1 to Msys2 CTRL+C does not work any more.
For example: I start "make" press CTRL+C. Shell prompts to finished and enables typing more commands, but make.exe is still running+working.
Result of my analysis:
In Msys1: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is (12345).
In Msys2: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is the (34567), which is not alive anymore. So I guess Msys2 uses an additional process for starting subprocesses.
I tried bash.exe, shell.exe, mintty.exe,... all seems to have the same problems.
Content I found searching
:
This ticket just focuses on missing signal types -> I don't care about that.
https://sourceforge.net/p/msys2/tickets/135/
The issue in this mailing list seems to be near my problem, but I do not understand what I should change, or if the change can only be made within the msys2 implementation. (What is CREATE_NEW_PROCESS_GROUP? and how to change it):
https://www.cygwin.com/ml/cygwin/2012-08/msg00062.html
Kindest regards
Luke
It looks like mintty provides the default terminal for MSYS2 (note that this is different from the shell that is run within). If so, then the "Ctrl+C kills native (e.g. MSYS2 compiled) programs abruptly rather than sending a catchable signal" problem is the same one as described over on https://superuser.com/questions/606201/how-to-politely-kill-windows-process-from-cygwin and the MSYS2 wiki porting FAQ.
If what you're attempting works when you are using Windows' default terminal (e.g. when using cmd.exe from the start menu) then this is the issue you're seeing.
It is in fact suggested in the other answer but you can just run each program by winpty.exe which will make CTRL-C working again.
I have little previous experience with Windows (for programming, anyway), but recognizing that Windows has an enormous market share, I am trying to support it in my programs (even though they are just for fun, I like to pretend they're big projects). I have written a tiny shell with minimal (and when I say minimal, I mean minimal) features.
I am trying to port it to Windows and would like to use it independently from cmd.exe in a Win32 Console window (meaning the shell part of cmd.exe isn't running at all, but the window used for it shows). I have already done most of the other porting stuff such as build system (CMake) and changing appropriate Unix syscalls to Windows ones in a #define. I have done a little research and found little on this topic, however. I know it is possible because I've seen it done with Bash. Visual Studio also used to do it when I ran a program in its GUI.
Reference article I got some of this info from: https://en.wikipedia.org/wiki/Win32_console
Note: What I mean is when you click on it and it opens it without running cmd in its own little console window. Or when you type it into cmd it opens in a separate window that isn't running cmd. I am assuming cmd.exe and the console window it runs in are two separate things, but if I am wrong, please let me know. :)
This question is inspired by https://askubuntu.com/questions/111144/are-terminal-and-shell-the-same and a similar question where I got that Wikipedia link. Someone said that the console window and the shell were separate. I was writing my own shell so I started to wonder how to make mine independent of the default one.
The Win32 Console and cmd.exe are two different things. Windows automatically opens a console window when a program that needs one is started. It decides whether do to so by switches hard-wired into the executable. This window will be running said program. If the program that started the process is running in a console window, the two programs will share that console window.
As Noodles said, it really is that simple. You just start it. Double-clicking on it will do it. The CreateProcess() function with CREATE_NEW_CONSOLE passed to it will do it. Running the program from cmd.exe with
start <command>
will do it.
There is also a family of functions in the Windows API, called FreeConsole() and AllocConsole() that will free a program from its current console and create a new console for it, respectively.
Reference link (given by Noodles): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).aspx
Is it there any graphical debugger for bash on mac os x or linux? I mean something in the same fashion that the debugging mode of Visual Studio or Eclipse, where one can stop the program hover the mouse pointer over variables and get instantly values, modify them and go backwards and try modifications without the need to start the program fomr the beginning. I am talking about very long bash scripts
for debugging execute your script with:
bash -x <scriptname>
gui debugger:
http://bashdb.sourceforge.net/
Debugger for Bash version 3(Bourne again shell). Plugin for Eclipse. Will only work with shell script editor ShellEd.
http://sourceforge.net/projects/basheclipse/
I have found the vscode-bash-debug
extension (https://github.com/rogalmic/vscode-bash-debug) for the visual studio code editor (https://code.visualstudio.com/) very useful.
I haven't come across a visual debugger, but bashdb works quite well for debugging. You can set breakpoints, continue, print variables etc..
https://sourceforge.net/projects/bashdb/
Install via your distro's repositories. There is a quick-start guide here:
http://www.rodericksmith.plus.com/outlines/manuals/bashdbOutline.html
(first chapter takes only half an hour to read/try).