I have followed the instructions at https://wiki.documentfoundation.org/Development/BuildingOnLinux to build LibreOffice on Ubuntu 16.10. When it finished the make step I ran instdir/program/soffice --writer and the splash screen appeared for a few seconds then disappeared, but no main window appeared in its place. I can see that the soffice.bin process is running, in System Monitor, but I can't use the application. Have I done something wrong? I have already tried git pull and repeating make, and restarting the system, but it hasn't made any difference.
Related
I have created several scripts in PyCharm, inside an Anaconda3 environment. The thing is that I would like to run them with the task scheduler during the night, so hopefully by the time I get up they have done their stuff.
I have read a million post in Microsoft support and in here, and I haven't found an answer for this issue.
This is a print of the set-up for the Task Scheduler:
For the program, I use the path to python.exe inside anaconda ( I take this path from cmd / where python).
Start in: the route to the script: C:\Users\oper\PycharmProjects\MyProject
It doesn't run, and it brings the error: 0x1. Opens a CommandPrompt windows and immediately closes it. I see the error in: Last Run Result.
I have been able to run a much simpler code that prints a .txt in a specified folder - but not this one.
Additional info:
this script runs a Selenium WebDriver and navigates some websites, connects with Google's OCR, etc. All these steps are written in several other modules for ease of coding.
All the libraries used were installed using pip inside PyCharm's terminal. Might be related to not having the libraries in sync? Don't know how to check that.
I would also like to set up a wake-up from sleep for the computer. Probably a different problem for another question.
Thanks in advance.
I am attempting to control my ur10e COBOT using ros2 but I have run into some issues.
I followed the steps of the ros2 install.
https://docs.ros.org/en/foxy/Installation/Ubuntu-Install-Debians.html
Then I installed MoveIt2 Foxy. https://moveit.picknik.ai/foxy/doc/move_group_interface/move_group_interface_tutorial.html
Then downloaded UR-ros2-driver.
https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/tree/foxy
One of the issues I ran into with the UR-ros2-driver download was since I'm using foxy, I had to download the ros2-control-demos found in this link https://github.com/ros-controls/ros2_control_demos/tree/foxy
And after removing files in the /workspace/install folder I was able to launch the trajectory program and it ran great. The files I removed were...
(controller_manager_msgs)
(diffbot_description)
(hardware_interface)
(joint_limits)
(ros2_control_demo_hardware)
(rrbot_description)
Okay now after I bore you with all my startup steps, now lets get into some code. Once everything was downloaded, I first had to source my files in the terminal...
source /opt/ros/foxy/setup.bash
source ~/workspace/ros_ur_driver/install/setup.bash
Then I launched...
ros2 launch ur_bringup ur_control.launch.py ur_type:=ur10e robot_ip:=yyy.yyy.yyy.yyy use_fake_hardware:=true launch_rviz:=true
Which ran great and I was able to see my COBOT model in rviz2.
Next, in a second terminal, I launched...
ros2 launch ur_bringup test_joint_trajectory_controller.launch.py
And watched while the virtual COBOT moved to the command.
Now, to make a long story short I managed to get the my PC and the COBOT pendent connected by setting up the COBOT's IP address with my PC's IP address. No issue there.
WHERE MY PROBLEM IS
I went to launch the IP adjusted code...
ros2 launch ur_bringup ur_control.launch.py ur_type:=ur10e robot_ip:=192.168.56.2 launch_rviz:=true
And my model was stuck colorless and crunched up. I'm unable to interact with the virtual COBOT at this Error state. I do recall this happening with my fake_test version when I would forget to source it properly before I launched it. So I was thinking maybe I messed up in the way I sourced my files. Or maybe I didn't add the control_demo packages correctly. If someone could give my some pointers on this that'll be greatly appreciated.
I'm trying convert .exe into .appx.
I'm using Desktop App Creator, a tool offered by Microsoft.
I've followed their documentation with no problem so far, and when I execute the command to perform the conversion (in verbose mode) the program freezes at the same point every time I launch it (with no errors/exceptions/warnings before the freeze).
In the block of the verbose "Running Installer in Isolated Environment", the last verbose line shown is "Waiting for installer process to complete inside Isolated Environment".
I've left it for 2h waiting but nothing happens.
Also, the only way to stop the shell is to close the window, it seems to be unresponsive for Ctrl+C.
I would appreciate any help for this, there's nothing to be found in the program's documentation about this.
Thanks a lot in advance and regards.
I had the same problem. The solution is that you need to run your installer in the isolated environment in silent mode in order to not display the wizard menu, because you cannot see the isolated environment and click the on the wizard buttons.
Add to DesktopAppConverter -Installer this argument:
-InstallerArguments /SILENT
Before running make sure you can install your application in silent mode by running:
setup.exe /SILENT
I had the same problem a few days ago
replacing "/S" argument with "/quiet" in -InstallerArguments, for me worked!
One day, out of nothing, my app decided not to die.
After pressing ctrl + c when I inspect port it's still there and not only on my machine but also on server that is managed by PM2 so I need to go there each time and kill the process by hand. I tried to look for issues in my code and when I couldn't I just though that it's simply one of the dependencies fault and soon there will be a fix. It was slightly annoying but I could kill the process with kill -9 PID and I had most of the tasks I had on front-end side so it wasn't that big issue. Today, more than a week later problem it's still here.
I went back in history, picked a commit that I made weeks ago, where everything worked perfectly fine, switched NodeJS from 5.1.0 to 4.2.1, cleared npm cache, reinstalled all dependencies and I still see the problem.
I'm using LoopbackJS, but normally I start the app simply with "node server/server.js" and then the problem described above happens, but if I use "slc run" and then try to kill the app with ctrl + c it just hangs forever, I mean I can press ctrl+c as many times as I want and it's still running in console foreground.
If instead of pressing ctrl+c I kill the tab in console, app dies without problems.
This is what I see after running "lsof -i tcp:4000" when the app is supposed to be dead but is not
Edit:
Running and killing it with Strongloop process manager - slc start/slc stop works fine but it would be more convenient to use normal way of running NodeJS app (node server.js) during development and it doesn't change the fact that there is some issue and it would be better to not hide it under the carpet.
Out of anger I stripped out my app to the most basic elements. File by file, piece by piece and I found the answer.
The culprit was phantomJS - https://github.com/sgentle/phantomjs-node. PATCH version 0.8.2 introduced this bug. Fix was created almost a month ago, merged a week ago but not published on npm yet.
I wrote a text mode batch C++ program that since today is giving me some troubles.
The executable worked correctly and it did not change.
The environment did not change; not even a reboot.
When I launch the program from a certain console, everything is fine.
When I launch the program from a new console, everything still works, but I get just the first two lines on the log file, even if the execution completes.
The parameters passed to the executable are the same.
The executable does not interact with the console in any way.
The two consoles' environment variables are the same.
When run from a remote computer as root, everything is fine, the log file is complete.
When logged in again with my user, from another session, everything is fine again.
When logging out and in again, everything is fine again.
So, could it be the from a certain instant on, the new consoles had some issues that caused this problem?
Could this be a problem of my Linux installation?
Or, more realistically, could the problem depend on my program?
Thank you!
Environment:
- Linux OpenSuse 11.4
- gcc 4.5.1
Here is another tool to throw into your debugging toolbox.
Try the command 'reset' -- read the man page for details.
In short, it resets the console to a known state. It is ... possible that your log files may contain control characters that try to interact with tty causing hard-to-trace problems.
You might also want to look at the command 'script' which captures all console activity to at et file for examination.