How to delete past working directories in Octave GUI? - octave

Does anyone know how to delete those past working directories in Octave GUI? They are very annoying and useless.

I see from your image that you are on windows.
I don't know the equivalent directory on windows, but on linux, this information seems to be stored under ~/.config/octave/octave-gui.ini, in a section called current_directory_list which you can edit and clear of all unwanted entries.
See if you can find the equivalent folder where this octave-gui.ini file is stored on windows; it may be in an AppData/Local directory, or in the octave installation folder itself...
PS: In the same directory I also had a qt_settings file which seems to mirror some of this information, but I think this may have been from an older octave installation.

In addition to deleting the file path from octave-gui.ini, try removing the path from .octaverc file as well. This will remove the warning you see at launch if the path no longer exists.

Related

How do I modify the defaul graphdb.home directory?

I have installed GraphDB Free v9.3 in LinuxMint 19.3.
The workbench is running fine though I haven't created any repositories yet. This is because I have noticed that although the application is installed at /opt/graphdb-free, the data, conf and log files are in a hidden folder below my home folder: /home/ianpiper/.graphdb/conf (etc).
I would prefer to store these folders on a separate volume, mounted at /mnt/bigdata. In the documentation it suggests that I can set graphdb.home using the graphdb.properties file (though I don't seem to have such a file in my installation) or in the startup script. I think this script might be /opt/graphdb-free/app/bin/setvars.in.sh, and that I could use this to change
-Dgraphdb.home=""
to
-Dgraphdb.home="/mnt/bigdata"
Could a knowledgeable person advise as to whether my understanding is correct, and if so what the best way is to change the location of graphdb.home?
Thanks,
Ian.

TortoiseHg: ‘hg’ is not recognized as an internal or external command, operable program or batch file

I'm unable to find the command line tools in Mercurial-TortoiseHg version 2.7.2. I checked for hg.exe file and it is present at C:\Program Files\TortoiseHg path but whenever I try running the command it fails and throws the error :
‘hg’ is not recognized as an internal or external command, operable program or batch file.
I have also added it to the windows PATH= ; C:\Program Files\TortoiseHg.
Not sure what else to look for. Please help.
Notes:
As mentioned in "Mercurial not working after TortoiseHg update", TortoiseHg v2.X.X no longer uses the hg command, but rather thg.
That means your PATH might not be updated properly to reference hg.exe of TortoiseHg.
to update your PATH, make sure not add any extra space:
set PATH=%PATH%;C:\Program Files\TortoiseHg
(no space between ';' and 'C:\...')
As mentioned by the OP Sowmya Guru, if you modify the user environment variable, a restart (or at least a new DOS windows) is necessary.
Posting my answer related to vanilla Mercurial install (not 'TortoiseHg') as it was the first page in search results, my solution was to use the 'Mercurial-3.4 (64-bit msi)' installer instead of the 'Mercurial-3.4 (64-bit exe)' from this page.

Adding an external project directory in phpStorm 6.0 to keeping workspace files separated from code?

I am try to keep separate workspace directory and code directories in my php project and sweating to understand/find how this could be achieved. A couple of revisions back I tried phpStorm and found that it does not provide such feature.
I just want to know if phpstorm 6.0 has this feature or still lacking it ? If possible please help me out.
Work Around
File > Settings >[Directories]
+[Add Content Root] to add external directory
Assuming that you have created project separate from code.Some of the tool might not work
as expected
This works for linux using sshfs, sorry for windows users.
I've created this folder structure in my pc
/mnt/remote_code/code/
And i have to mount code from server like this
sshfs user#server:/var/www/server_code/ /mnt/remote_code/code/
Code from server will be mounted in code folder
In PS I open this directory: /mnt/remote_code/
So, that means PS will create this folder /mnt/remote_code/.idea (indexing and saving all project and ide settings), and keeps the code folder (with remote code inside) without changes.
Hope it help you.
Greetings.

TortoiseHg 'No space left on device' error while pushing

We are using TortoiseHg as our Mercurial client UI. Today we ran into an issue while trying to push from one particular workstation. It was receiving the following error:
abort: No space left on device
[command returned code 255 ..........]
This error occurs while TortoiseHg/Mercurial is bundling files in preparation to pushing to the repository. I did some testing and noticed that the workstations (C:) drive was gradually being filled up as the file were being bundled. The (C:) drive went from ~900MB to ~100MB and then the error message was received. So this is obviously the cause.
My question is this:
Does anyone know which default directory is used to store the temp files created while TortoiseHg/Mercurial bundles files in prep for a push? This seems to be independent of the drive TortoiseHg is installed to. I re-installed to a data drive with plenty of space and still used (C:) to store whatever temp files it was using.
Is there a way to configure TortoiseHg/Mercurial to use a temp directory of your choice?
Thanks in advance for any help!
Mercurial is python and python has good platform specific defaults for temporary file locations. They're pretty easily overridden if you want something other than the defaults, which on Windows are probably c:\temp.
http://docs.python.org/library/tempfile.html#tempfile.tempdir says it's:
The directory named by the TMPDIR environment variable.
The directory named by the TEMP environment variable.
The directory named by the TMP environment variable.
A platform-specific location:
On RiscOS, the directory named by the Wimp$ScrapDir environment variable.
On Windows, the directories C:\TEMP, C:\TMP, \TEMP, and \TMP, in that order.
On all other platforms, the directories /tmp, /var/tmp, and /usr/tmp, in that order.
As a last resort, the current working directory.
So if you've got software using Mercurial on a client computer set the environment variable to some place you know has space.
Mercurial always stores internal files inside the ".hg" folder in the local repository folder.
Maybe TortoiseHg has a additional temp folder... don't know. Anyway you should try to push the files using the Mercurital command line client:
hg push
More information about the command line client you can find here Mercurial: The Definitive Guide
Another temporary solution might be the move these files via a file system simlink to another drive with more space left.

When Jenkins or Hudson says it can't find files to archive, how do I troubleshoot it?

In the job configuration for a Jenkins 1.418 job (older versions are Hudson) on Windows, I am having trouble with "Archive the artifacts". In the box titled "Files to archive" I have
foo/**/Release/Install/App.exe
The error it gives me at configuration time is:
'foo//Release/Install/App.exe' doesn't match anything: 'foo' exists but not 'foo//Release/Install/App.exe'
Now, if I'm correct, ** is "search all subdirectories" as per ant. What is odd, is that no matter what I enter it tells me the top level folder exists (foo), but no other folder exists underneath it. Yet when I use the windows explorer to navigate, all my folders exist.
How can I troubleshoot this or fix it?
Update: I figured out a technique to troubleshoot - use the workspace browse features in hudson/jenkins to find what is visible and what is not visible. Turns out some directories had file permissions that blocked them being visible inside jenkins/hudson.
I had hudson configured to run a batch file, and my folder references were failing because of some errors in the batch files I was using. This was not a hudson problem, but a batch file problem. I saw the error and thought it was the problem because it was a reported error, but the real problem was a silent failure in a batch file.