The first question is: where is my.ini of the version 10.6.5?
I used mariadb-10.1.22. Download the zip file, unzip. Path like
D:\Servers\mysql\mariadb-10.1.22-winx64
Find my-medium.ini in root,
D:\Servers\mysql\mariadb-10.1.22-winx64\my-medium.ini
Change to my.ini, make some changes needed.
D:\Servers\mysql\mariadb-10.1.22-winx64\my.ini
Intall to service
D:\Servers\mysql\mariadb-10.1.22-winx64\bin\mysqld --install
But now, there is no my-medium.ini, nor my-xxx.ini. And the MySQL service cannot start.
Follow the instructions in https://mariadb.com/kb/en/mysql_install_dbexe/
This utility is older than 10.1, it debuted in 5.2
my.ini will in your datadir, which you specify on the mysql_install_db.exe command line . If you do not specify anything, data directory will be named 'data', and it will be next to the 'bin' directory.
Those my-medium.ini and friends were many years old. Now you're better off using defaults. you can set innodb_buffer_pool_size to whatever you wish, and maybe innodb_log_file_size, those are the most important ones.
Related
I have just removed a DVC tracking file by mistake using the command dvc remove training_data.dvc -p, which led to all my training dataset gone completely. I know in Git, we can easily revert a deleted branch based on its hash. Does anyone know how to revert all my lost data in DVC?
You should be safe (at least data is not gone) most likely. From the dvc remove docs:
Note that it does not remove files from the DVC cache or remote storage (see dvc gc). However, remember to run dvc push to save the files you actually want to use or share in the future.
So, if you created training_data.dvc as with dvc add and/or dvc run and dvc remove -p didn't ask/warn you about anything, means that data is cached similar to Git in the .dvc/cache.
There are ways to retrieve it, but I would need to know a little bit more details - how exactly did you add your dataset? Did you commit training_data.dvc or it's completely gone? Was it the only data you have added so far? (happy to help you in comments).
Recovering a directory
First of all, here is the document that describes briefly how DVC stores directories in the cache.
What we can do is to find all .dir files in the .dvc/cache:
find .dvc/cache -type f -name "*.dir"
outputs something like:
.dvc/cache/20/b786b6e6f80e2b3fcf17827ad18597.dir
.dvc/cache/00/db872eebe1c914dd13617616bb8586.dir
.dvc/cache/2d/1764cb0fc973f68f31f5ff90ee0883.dir
(if the local cache is lost and we are restoring data from the remote storage, the same logic applies, commands (e.g. to find files on S3 with .dir extension) look different)
Each .dir file is a JSON with a content of one version of a directory (file names, hashes, etc). It has all the information needed to restore it. The next thing we need to do is to understand which one do we need. There is no one single rule for that, what I would recommend to check (and pick depending on your use case):
Check the date modified (if you remember when this data was added).
Check the content of those files - if you remember a specific file name that was present only in the directory you are looking for - just grep it.
Try to restore them one by one and check the directory content.
Okay, now let's imagine we decided that we want to restore .dvc/cache/20/b786b6e6f80e2b3fcf17827ad18597.dir, (e.g. because content of it looks like:
[
{"md5": "6f597d341ceb7d8fbbe88859a892ef81", "relpath": "test.tsv"}, {"md5": "32b715ef0d71ff4c9e61f55b09c15e75", "relpath": "train.tsv"}
]
and we want to get a directory with train.tsv).
The only thing we need to do is to create a .dvc file that references this directory:
outs:
- md5: 20b786b6e6f80e2b3fcf17827ad18597.dir
path: my-directory
(note, that path /20/b786b6e6f80e2b3fcf17827ad18597.dir became a hash value: 20b786b6e6f80e2b3fcf17827ad18597.dir)
And run dvc pull on this file.
That should be it.
I'm writing a script to create virtual hosts in Mamp Pro. I want them to be created and appear in the GUI next to the normal ones I've created manually through the GUI. I've found the following questions on SO:
Automatic Virtual Hosts with MAMP Pro?
Add MAMP Pro Vhosts with script
Here are my findings, so far:
I've found out that the hosts appearing in the MAMP Pro GUI are found in: ~/Library/Application\ Support/appsolute/MAMP\ PRO/settings3.plist; I've tried editing it but I can't seem to get the entries right with the command PlistBuddy -c 'print ":virtualHosts"' settings3.plist which says Print: Entry, ":virtualHosts", Does Not Exist
From the second question I've listed above, I found out that I can edit the httpd.conf files (one found in user library and one in the root library) through the GUI.
The hosts file including all of the IP addressing is in /private/etc/hosts
The questions are dead, even though I commented on the latest one asking for an update on how he solved his scripting problem in the end.
In the end, I can easily add the values into the hosts file and the vhosts.conf files to make the website work. My only problem is getting it to show up in the list with the other virtual hosts in the MAMP Pro GUI.
Update: After further investigation and experimentation, I realized the process in which the virtual hosts are created; when I first create a host through the GUI, the settings3.plist file gets updated, when I hit "save" to save the changes, the hosts and httpd.conf files are updated accordingly. I understand that settings3.plist can be converted to an XML through plutil -convert xml1 -o - settings3.plist > test.txt and then edit it and convert it back to binary through plutil -convert binary -o - test.txt > settings3.plist.
My problem with that is that, even though I got the gist of how the CP$UID works in the XML formats, I cannot create a script to undestand the concept, check for the position of the values through the list, and then put in the values accordingly. I even asked a question about it here: https://stackoverflow.com/q/33775025/1934402
The solution provided in Automatic Virtual Hosts with MAMP Pro? refers to MAMP PRO version 2.x where host configuration is saved in settings.plist which is an XML format property list file while in MAMP PRO version 3.x host settings are stored in settings3.plist which is a binary format property list file.
Even in this format you should be able to do:
/usr/libexec/PlistBuddy -c Print settings3.plist
and still get the contents of the file. Your problem arises from the fact that virtualHosts is no longer there as you will see by running the above command. The above command output is not very helpful for understanding the structure of your plist file so you could run:
plutil -convert xml1 -o - settings3.plist > ~/settings3.plist.xml
and then work out the structure of ~/settings3.plist.xml in order to find out which keys to use in PlistBuddy commands. It is a good idea to check the manual pages for plist and PlistBuddy. Do note that key names have changed and the structure is not that clear even in the xml file.
I hope this helped. I will investigate further into it and modify this answer if I have a full recipe for editing host details.
I'm currently trying to use VVV to develop and test my plugins. My host OS is Win10.
My plugins are in D:\Workshop\projects\vendor\module. I've used this folder structure for a long time, and it is really convenient, especially for use with Composer and friends.
Now I've installed VVV, created a site with VV. I want to test a plugin, the source code of which is in D:\Workshop\projects\XedinUnknown\my-project. So, I create a symlink in D:\Workshop\projects\XedinUnknown\vvv-local\www\my-test-site\htdocs\wp-content\plugins that points to that project's folder. Alas, it doesn't work. If I SSH into VVV and ls /srv/www/my-test-site/htdocs/wp-content/plugins, I can see my-project there, but it points to ../../../../../../../XedinUnknown/my-project, which, of course, doesn't exist. If instead of symlink I create a junction, it's just an empty file.
I suspect that this has to do with how the Linux environment handles Windows symlinks, but I'm not entirely sure. Is it possible to make this work somehow? I really don't wanna copy the whole project folder into VVV.
This is also addressed here.
So, it would seem like I've found somewhat of a solution. I added a synched folder, which maps to my projects home. I then create a symlink to that folder from the WP plugins directory, inside the VM.
Step 1 - Add Shared Folder
This should be done in a Customfile as explained here. This file should go into the same directory as the Vagrantfile, e.g. it will become the Vagrantfile's sibling. In my case, if you're following along from my question, it is in D:\Workshop\projects\XedinUnknown\vvv-local. Anything put here becomes global for the whole of VVV. This also gives you the ability to use different combinations of your projects in different websites. Add these contents to your Customfile, creating it if it does not exist.
config.vm.synced_folder "D:/Workshop/projects", "/srv/projects", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]
Of course, you should replace D:/Workshop/projects with the path to where you store your projects. Note the forward slashes (/). This works on Win/Nix. For a Windows-only configuration, I suspect you'd have to replace them with \\, because this is an escape sequence.
Step 2 - Add Link to Project
This should be done in your site's vvv-init.sh file. In my case, this file was in D:\Workshop\projects\XedinUnknown\vvv-local\www\my-test-site\, because I want to create this symlink specifically for the my-test-site site. Please note that your VVV path will probably be different, and it doesn't have to be inside the projects directory. It's wherever you cloned VVV into. Add the below lines to your site's vvv-init.sh file.
if [ ! -f "htdocs/wp-content/plugins/my-project" ]; then
echo 'Creating symlink to plugin project...'
cd ./htdocs/wp-content/plugins
ln -s /srv/projects/XedinUnknown/my-project my-project
cd -
fi
In the above snippet, change the path to your desired project path, keeping in mind that /srv/projects/ now maps live to the projects root in your host OS. You can also replace the second occurrence (last word) of my-project in ln -s /srv/projects/XedinUnknown/my-project my-project with whatever you want. As long as you don't change it later, your plugin should not suddenly get de-activated.
Also, from what I understood, vvv-init.sh runs during provisioning, not every time the machine is brought up. So, if you want to run the code in there, you have to run vagrant up --provision from the VVV directory. If you don't want to provision, you can run it manually. SSH into VVV with vagrant ssh, then cd /srv/www/my-test-site (replace my-test-site with name of your site), and run . vvv-init.sh.
Afterword
I am quite new to Bash scripting, and I don't know if my solution is the best one, so please feel free to suggest better versions of the Bash script. I also don't know Ruby, and am new to Vagrant, so please feel free to suggest improvements to the Customfile - this is in essence the same as the Vagrantfile.
One possible issue that I can anticipate with this solution (and this is inherently by design of the filesystem architecture) is that if WordPress decides to make changes to your plugin, e.g. if you run a WP update, it will effectively delete all files in your project, including the repository. So, on the testing site I would recommend using something like this. I am in no way associated with this plugin.
qmake generates the following (among the others) rule for installing a target:
-$(INSTALL_PROGRAM) "$(TARGET)" "$(INSTALL_ROOT)/$(TARGET)"
I cannot set INSTALL_ROOT with something like this in a *.pro file
isEmpty(INSTALL_ROOT) {
INSTALL_ROOT=/usr
}
because INSTALL_ROOT is somehow local to generated Makefiles. According to what I've found out so far INSTALL_ROOT is empty by default. It could be used like
INSTALL_ROOT=$HOME make install
when invoking make, which is fine. However I want to be able to specify default installation root, say /usr. I can do it introducing a new variable PREFIX as suggested here.
Then generated rule will look like (if PREFIX was set to /usr)
-$(INSTALL_PROGRAM) "$(TARGET)" "$(INSTALL_ROOT)/usr/$(TARGET)"
however
INSTALL_ROOT=$HOME make install
installs target to /home/<user_name>/usr/$(TARGET) which is not that one would expect.
So setting INSTALL_ROOT to some default value will produce consistent behavior, which is superior to adding PREFIX, but how to set INSTALL_ROOT in a *.pro file?
What is the purpose of INSTALL_ROOT is it supposed to be used at all?
INSTALL_ROOT is for use with package building systems, like NSIS, debian, or any other way for parcelling up built software and delivering it.
For this purpose you want the result of
INSTALL_ROOT=$PWD/package_root make install
to create a tree under $PWD/package_root that exactly mimics that on your target system you plan to deliver to. Note that you need INSTALL_ROOT to be a full path (hence the $PWD), not a relative path.
When you create your package you can compress that tree into an archive and then your installation process simply uncompresses the same tree on to the target file-system.
$PWD/package_root/usr/bin/my_binary
would get installed to
/usr/bin/my_binary
on the target.
So that is the answer to the question what INSTALL_ROOT is for. To answer how to specify "default installation root" requires more information about what you want to achieve.
Have a look at the output of qmake -query:
sez#ubuntu-11.10:~$ qmake -query
QT_INSTALL_PREFIX:/usr
QT_INSTALL_DATA:/usr/share/qt4
QT_INSTALL_DOCS:/usr/share/qt4/doc
QT_INSTALL_HEADERS:/usr/include/qt4
QT_INSTALL_LIBS:/usr/lib/i386-linux-gnu
QT_INSTALL_BINS:/usr/bin
<snipped>
QT_VERSION:4.7.4
and the use of the INSTALLS variable in qmake: http://doc.qt.digia.com/qt/qmake-environment-reference.html#installs - and How do I specify input the QMake INSTALLS variable?
By default if you just do
target.path = $$[QT_INSTALL_BINS]
INSTALLS += target
Then your binary will get installed in whatever qt thinks is the right place, QT_INSTALL_BINS. You can change those defaults of course by setting target.path to something else. Qt supplies those paths but its up to you to use them or not.
You could do
MY_DEFAULT_INSTALL=/opt/myproj
somedocs.files = docs/index.html
somedocs.path = $$MY_DEFAULT_INSTALL/docs
target.path = $$MY_DEFAULT_INSTALL/bin
INSTALLS += somedocs target
for example, where MY_DEFAULT_INSTALL is the one place in your .pro file that defines the default for installs.
I'm answering for Windows here. You appear to be using UNIX, Linux, or Mac OS X so you may have to make a few changes.
INSTALL_ROOT is a poorly documented feature that appears to have been added so that those without root or admin access can install Qt in their local filesystem. It's actually a bit of a hack since, as you have already seen, it is not possible to specify an arbitrary target, but you can always move the files to the desired location afterwards.
Just assume we are installing some libraries from its source distributed by the way GNU promoted. When using "./configure --prefix" to specify where to install.
(1) does Make generate the binaries under the current directory? Does Make install then copies them from the current directory (which is from where Make is run) to $prefix? If the answers are yes, I have two questions, each for different cases.
(2) when the current directory and $prefix are not the same, can I remove all the files generated by Make under current directories to save some space?
(3) when the current directory and $prefix are the same, will make install do nothing or copy the files to themselves? Can I just skip the make install step?
The answer to your first question is probably yes.
As for the rest, you may find a make clean which will tidy up the files created by the initial make.
I think the makefile will be able to handle the situation where current directory and $prefix are not the same, and do the right thing.
The current directory would not usually be the destination of files created by makefiles.
(of course it depends on how the makefile is written, so I can't give definite answers, but I've generally been impressed with the makefiles I've used)
You are absolutely right: make just creates files in current directory and make install copies it to the destination directories, based on $prefix and other variables maintained by configure script.
You can wipe out the whole directory you've ran the build at. It will not be used, because, well, that's what "install" means: you build in one directory and the the files are placed in the proper places of your system.
Usually install destination and the directory you build in differ. The hierarchy of the files being installed usually do not relate to directory hierarchy of the build system. Just install to the other dir: it's cheap to create just yet another directory.