I have installed an NixOS in my virtualbox.
I would like to add a shared folder in my NixOS.
I have set up a shared folder called Code in Device->SharedFolder->Setting on my virtualbox side.
I tried to insert Guest Addition image. It says:
Could not mount the media/drive 'C:\Program
Files\Oracle\VirtualBox\VBoxGuestAdditions.iso'
(VERR_PDM_MEDIA_LOCKED).
I force mount it in Device->CDRom
ls -l /dev/cdrom and mount -t iso9660 -o ro /dev/cdrom /cdrom.
Files of Guest Additions can be seen in /cdrom
virtualization.virtualbox.guest.enable = true in /etc/nixos/configuration.nix (I have read about somewhere that this line alone is sufficient to install Guest Addition in nixos.)
Then I set my configuration as:
...
fileSystems = [
{
mountPoint = "/";
label = "nixos";
}
];
...
fileSystems."/virtualboxshare" = {
fsType = "vboxsf";
device = "Code";
option = [ "rw" ];
};
nixos-rebuild switch, it says:
error: attribute fileSystems."/virtualboxshare" at ... already defined
at ... (fileSystems = ...)
So how can I combine these two expressions together and make my shard folder visable in nixOS?
You are defining fileSystems twice in the attrset that makes up your nixos configuration or module. In the first definition it's a list, whereas in the second, you're defining fileSystems as an attrset, by using the nested attribute set shorthand notation. So actually, this error is produced by the Nix language rather than the NixOS module system.
This error can be solved by defining all your filesystems with the same notation you have used for /virtualboxshare.
To get a better feeling for nested attrsets, it may be useful to play around with nix repl:
$ nix repl
Welcome to Nix version 2.0. Type :? for help.
nix-repl> :p { a = {c = 2; }; a.b = 1; }
{ a = { b = 1; c = 2; }; }
(Note the use of :p to evaluate everything instead of just the outermost attrset)
Related
I installed the Castro library for astronomical modelling, and I followed the build setup described here. I successfully changed the parameters in GNUmakefile (as described in the tutorial), but when I ran the command make in ....Castro/Exec/hydro_tests/Sedov directory, I got several errors, the majority of them being 'M_PI' was not declared in this scope. I googled about the error, and the majority of the answers were referring to building of own code (one file, or so). The main reason was clear: I am using MS stuff (I am running Windows, with installed g++ and VS compiler) and M_PI is not supported by default. Instead, I should define _USE_MATH_DEFINES.
The problem is that I want to have a convenient solution: I don't want to search for every instance of M_PI and replace it, or add to every file #define _USE_MATH_DEFINES. Instead, I want to alter the make command so that _USE_MATH_DEFINES is defined in every file. Unfortunately, I haven't yet used make much, so I don't know how to do this.
The GNUmakefile (which is the only make-related file) doesn't help much:
PRECISION = DOUBLE
PROFILE = FALSE
DEBUG = FALSE
DIM = 2
COMP = gnu
USE_MPI = FALSE
USE_OMP = FALSE
USE_MHD = FALSE
USE_FORT_MICROPHYSICS := FALSE
BL_NO_FORT := TRUE
# define the location of the CASTRO top directory
CASTRO_HOME := ../../..
# This sets the EOS directory in $(MICROPHYSICS_HOME)/EOS
EOS_DIR := gamma_law
# This sets the network directory in $(MICROPHYSICS_HOME)/Networks
NETWORK_DIR := general_null
NETWORK_INPUTS = gammalaw.net
Bpack := ./Make.package
Blocs := .
include $(CASTRO_HOME)/Exec/Make.Castro
I, therefore, ask you to give the correct make command, or give any other option of bypassing the error.
EDIT: as #MadScientist points out, the position of DEFINES= in the commandline matters:
make DEPENDS=... is an overriding variable which ignores extensions
DEPENDS=... make sets a value from the environment which is fine.
I originally had the first form, which is wrong.
It looks like that system extends preprocessor defines set in the DEFINES variable, so the following should work:
DEFINES=-D__USE_MATH_DEFINES make
If you don't want to type that everytime, you can do
export DEFINES=-D__USE_MATH_DEFINES
once and then call
make several times.
I have created a game with Python 2.7 and am having some issues with the running of it after converting it to an executable. If I change to the directory through cmd it allows me to run it with all the formatting that has been applied, as such:
If I choose to access it through simply executing the game, it seems to be reading the different entities in the class containing the colours from the backslash as a string.
The class that is providing the information is as follows,
class bcolors:
HEADER = '\033[95m'
OKBLUE = '\033[94m'
OKGREEN = '\033[92m'
WARNING = '\033[93m'
FAIL = '\033[91m'
ENDC = '\033[0m'
The general code looks like this:
print bcolors.FAIL + ("Try combining the cd command and room you want to enter") + bcolors.END
If you are running Windows, you may need to install Ansicon. This link will probably be of use to you: Colorama for Python, Not returning colored print lines on Windows
I am writing a script which checks space on UNIX servers. But I am unable to find the right command. I used the following but it gives me same percentage for all paths.
st = os.statvfs("/dev/hd3")
You give it the mount point, not the device name.
So, instead of e.g.
st = os.statvfs("/dev/hd3")
you do
st = os.statvfs("/boot")
If you have a header file named ThisIsAHeaderFile.h, the following will still locate the file in Visual Studio:
#include <ThisIsAheaderFile.h>
Is there a way to enforce case sensitivity so that the #include will result in an error?
You can't, because the Windows file system is itself case-insensitive.
If you could get into a situation where you had both RICHIE.h and richie.h, it might make sense to control case sensitivity, but you can't.
I would like to point out that this is not an unsolvable problem as many tries to point out to the OP. The case insensitivity is beside the point. The point is as Lorenz03Tx explains in a comment, even though the file system is case insentitive the case is retained, so it can be controlled.
Such a counter measures is really great to have when doing cross platform development, and prevents much after work when the code is compiled for the other platform. Not to forget that making the build process more picky you would induce better habits for the developers, as they gradually will be more consistent how they include and name files.
TL;DR
One solution is to use a script that simply scans the source files for include statements and tries to match them along the include paths. Such a script could be added to visual studio post-build events, and thus run at every build, or (inspired by krlmlr) use the preprocessor of a compiler that enforce case sensitivity.
It is (used to be?) possible to create files with the same name but case differences on NTFS. Maybe someone with cygwin can verify this.
MSDN
Even then, however, it's impossible to access more than one of these at a time from a normal Windows application.
While it might not be possible to enforce this from within Visual Studio, one could implement a quick check by running only the preprocessor on the C/C++ source. This will run quickly enough to be practicable even as post-commit hook in a version control system, and err if the case in file names has been mismatched. So:
Configure your build system in Linux to support preprocessor-only runs (-E with gcc/g++)
Implement a preprocessor-only run as post-commit hook, triggering an early notification to the responsible person and/or to someone willing to routinely fix these errors
Of course, this assumes a VCS as central storage for the code.
Both FAT and NTFS are case insensitive file systems. Foo and fOO are the same file as far as they are concerned. Although the Windows OS will preserve the case you use for a file. If you name a file ThisIsAheaderFile.h it will show up that way in the file system. Although all system function calls to open that file can use any casing they want.
Also having similar problem when trying to build under linux; not full solution...
If you Find in Files #include by VS and copy result to textarea, you will get sorted CSV with include file name, original path and list of files in 3rd column (columns are tab delimited)
Easy to check solution/wide and in case there are not much case problems it should be easy to replace them?
function readIncludes(t)
{
var s = t.value.split('\n');
var res = {};
for(var r in s)
{
if (r == 0) continue;
var dq = s[r].indexOf('(');
var p = s[r].substr(0, dq);
var p2 = s[r].indexOf(':', dq);
p2 = s[r].substring(0, p2);
dq = s[r].indexOf('#', dq);
var i = s[r].substr(dq);
var ip = i.replace(/#include\s+/, "");
if (!ip) continue; // *#includes.*
var st = '<>""';
if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
st = st[st.indexOf(ip[0]) + 1];
ip = ip.substr(1, ip.indexOf(st, 2) - 1);
if (!ip || ip[0] == '/') debugger
if (!res[ip]) res[ip] = [];
res[ip].push(p2);
}
var resSorted = [];
for(var r in res)
{
var shortR = r.replace(/.+[\\/]/, ""); // include file
resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
}
t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
width: 100%;
height: 100%;
white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>
If you have a header file named ThisIsAHeaderFile.h, the following will still locate the file in Visual Studio:
#include <ThisIsAheaderFile.h>
Is there a way to enforce case sensitivity so that the #include will result in an error?
You can't, because the Windows file system is itself case-insensitive.
If you could get into a situation where you had both RICHIE.h and richie.h, it might make sense to control case sensitivity, but you can't.
I would like to point out that this is not an unsolvable problem as many tries to point out to the OP. The case insensitivity is beside the point. The point is as Lorenz03Tx explains in a comment, even though the file system is case insentitive the case is retained, so it can be controlled.
Such a counter measures is really great to have when doing cross platform development, and prevents much after work when the code is compiled for the other platform. Not to forget that making the build process more picky you would induce better habits for the developers, as they gradually will be more consistent how they include and name files.
TL;DR
One solution is to use a script that simply scans the source files for include statements and tries to match them along the include paths. Such a script could be added to visual studio post-build events, and thus run at every build, or (inspired by krlmlr) use the preprocessor of a compiler that enforce case sensitivity.
It is (used to be?) possible to create files with the same name but case differences on NTFS. Maybe someone with cygwin can verify this.
MSDN
Even then, however, it's impossible to access more than one of these at a time from a normal Windows application.
While it might not be possible to enforce this from within Visual Studio, one could implement a quick check by running only the preprocessor on the C/C++ source. This will run quickly enough to be practicable even as post-commit hook in a version control system, and err if the case in file names has been mismatched. So:
Configure your build system in Linux to support preprocessor-only runs (-E with gcc/g++)
Implement a preprocessor-only run as post-commit hook, triggering an early notification to the responsible person and/or to someone willing to routinely fix these errors
Of course, this assumes a VCS as central storage for the code.
Both FAT and NTFS are case insensitive file systems. Foo and fOO are the same file as far as they are concerned. Although the Windows OS will preserve the case you use for a file. If you name a file ThisIsAheaderFile.h it will show up that way in the file system. Although all system function calls to open that file can use any casing they want.
Also having similar problem when trying to build under linux; not full solution...
If you Find in Files #include by VS and copy result to textarea, you will get sorted CSV with include file name, original path and list of files in 3rd column (columns are tab delimited)
Easy to check solution/wide and in case there are not much case problems it should be easy to replace them?
function readIncludes(t)
{
var s = t.value.split('\n');
var res = {};
for(var r in s)
{
if (r == 0) continue;
var dq = s[r].indexOf('(');
var p = s[r].substr(0, dq);
var p2 = s[r].indexOf(':', dq);
p2 = s[r].substring(0, p2);
dq = s[r].indexOf('#', dq);
var i = s[r].substr(dq);
var ip = i.replace(/#include\s+/, "");
if (!ip) continue; // *#includes.*
var st = '<>""';
if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
st = st[st.indexOf(ip[0]) + 1];
ip = ip.substr(1, ip.indexOf(st, 2) - 1);
if (!ip || ip[0] == '/') debugger
if (!res[ip]) res[ip] = [];
res[ip].push(p2);
}
var resSorted = [];
for(var r in res)
{
var shortR = r.replace(/.+[\\/]/, ""); // include file
resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
}
t.value = resSorted.sort().join('\n'); // sort again long lines of results
}
html,body,textarea {
width: 100%;
height: 100%;
white-space: nowrap;
}
<textarea onchange="readIncludes(this)">
</textarea>