I would like to be able to check if two words are similar (using the path similarity) in WordNet with Prolog.
I found on the internet this article doing exactly what I want.
I'll paste here the steps needed to let this work:
Download WordNet 3.0 Prolog version from
http://wordnetcode.princeton.edu/3.0/WNprolog-3.0.tar.gz
and unzip it in a directory of your choice. For example:
c:\wn_prologDB
Set the environment variable WNDB to this newly created directory.
For example, use either the system dialog box in Control Panel
(Environment Variables), or write in a Command Prompt (cmd.exe):
set WNDB=c:\wn_prologDB
Download the modules of WN_CONNECT from
https://dectau.uclm.es/bousi-prolog/applications and unzip
it in a directory of your choice. For example:
c:\wn
Add to the PATH environment variable the directory where this tool
is located (similar to step 2 above):
set PATH=c:\wn;%PATH%
Open a terminal and execute the shell script:
wn.sh
I followed those steps, and run wn.bat (since I'm using windows).
As you can see from the picture, the wn_word_info predicate is working, while I cannot understand why wn_path is not working.
Here is the signature:
wn_path(+Word1, +Word2, -Degree)
Any tips on how I could get it to work? Or any solution to calculate path similarity?
The signature was a bit different:
wn_path(+Word1:SS_type1:W1_Sense_num, +Word2:SS_type2:W2_Sense_num, -Degree)
So this actually works:
wn_path(cat:A:B, dog:C:D, E).
Here I'm specifying only the word and the other parameters are variables, but one can specify all three the parameters.
I paste here some of the docs I found in the WN_CONNECT folder:
** wn_path(+Word1:SS_type1:W1_Sense_num, +Word2:SS_type2:W2_Sense_num, -Degree):
This predicate implements the PATH similarity measure.
Takes two concepts (terms -- Word:SS_type:Sense_num) and returns the degree of similarity between them. Note that we do not explicitly require information about the synset type and sense number of a word (that can be variables).
Related
I like to modify my Windows environmental variables by opening the Advanced System Settings -> Environmental Variables. I particularly like that when I try to modify the system path (by clicking on System Variables -> Path), that I get a nice, easy to read list of the folders on the path:
However, when I click on the User Variables -> Path, I still get the old dialog, which is not very user friendly:
Is it possible to have Windows always display the list, as is the case for the System variables?
For what its worth, I think I remember seeing the desired behavior on a friend's computer, so I believe it should be possible.
EDIT:
It seems that having a variable as part of the path is the problem. Is there a way to get path list even when the path contains variables?
Context:
When I want to add a program to my path, I will create a new variable that redirects to its path. The reason to do that is simple... Programs typically have compound paths, and so making a consolidated variable seems like a wise decision. For instance, on my machine, I have multiple python instances (sometimes I need an Anaconda installation of Python 3.6, and sometimes I want a version of the bare-bones Python 3.5). To accomodate this, I create environmental variables for the paths to each installation.
Now if I want to switch which version is on my path, I can simply update my path variable from
path=...;%PATH_PYTHON35%
to
path=...;%PATH_PYTHON36A%
See how easy that was?
The problem is that the GUI doesn't seem to like this for the local variables. I can confirm that this is the case because when I remove the variables from the local path, I get the nice list like the System Variables case. However, what is perplexing to me is that the System Variables path DOES include some variables as well:
So I take this to mean that there must be a way of getting the local variables list to pop up, just like the System Variables case...
Guess I'm late to the party, but this works for me:
PATH=C:\DATA\bin;%JAVA_HOME%\bin
whereas this does not work:
PATH=%JAVA_HOME%\bin;C:\DATA\bin
A speculation based on my own observations.
It seems list view is only presented when at least one of the first two entries begins either with a drive letter notation (like C:\) or a specific variable. I'm not sure which variables are considered "valid", but here are a few environmental variables that show up as list:
%USERPROFILE%+%LOCALAPPDATA%;aaa;bbb;
aaa;Q:\%LOCALAPPDATA%;bbb;
These however show up as a string:
%LOCALAPPDATA%+%USERPROFILE%;aaa;bbb;
aaa;bbb;%USERPROFILE%;
Not sure what makes %USERPROFILE% different, but i tried a few other variables instead of %LOCALAPPDATA% (%OS%, %HOMEDRIVE%) - result was the same.
I'm finding a lot of suggestions online for one of two basic ways to specify the PATH export in ~/.bashprofile for Git on Mac, but I haven't found an explanation for which of the two is preferable and why.
Could anyone describe the difference between these two placements of the $PATH? Thanks!
export PATH=/usr/local/git/bin:$PATH
export PATH=$PATH:/usr/local/git/bin
Changing my search terms, I found this technical piece outlining the difference: http://www.troubleshooters.com/linux/prepostpath.htm
It seems placing the $PATH at the end of the statement (export PATH=/usr/local/git/bin:$PATH) assures that the system looks in this custom place before searching default places (that is, the specified path is appended before the standard places contained within $PATH).
Placing the $PATH variable at the beginning of the statement (export PATH=$PATH:/usr/local/git/bin) doesn't work in cases where a default path already exists, because the system looks in the default places (given in PATH) before getting to the statement's custom-specified path.
I am looking for resolving the paths of files in an MSI with or without installing (whichever is faster) from outside an MSI, using VBScript.
I found a similar query using C# instead and Christpher had provided a solution, below: How can I resolve MSI paths in C#?
I am going through the very same pain now but is there anyway to achieve this using WindowsInstaller object in VBScript, rather than go with endless queries through SQL Tables of MSI back and forth to achieve the same. Though any direction would be welcoming as I have tried tested whatever I can with very limited success.
yes there is a solution without installing the msi and using vbscript.
there is a very good example in the Windows Installer SDK called "WiFilVer.vbs"
using that example i've thrown together an quick example script that does exactly what you need.
set installer = CreateObject("WindowsInstaller.Installer")
const READONLY = 0
set db = installer.OpenDataBase("<FULL PATH TO YOUR MSI>", READONLY)
set session = installer.OpenPackage(db, READONLY)
session.DoAction("CostInitialize")
session.DoAction("CostFinalize")
set view = db.OpenView("SELECT File, Directory_, FileName, Component_, Component FROM File,Component WHERE Component=Component_ ORDER BY Directory_")
view.Execute
set record = view.Fetch
do until record is nothing
file = record.StringData(1)
directoryName = record.StringData(2)
fileName = record.StringData(3)
if instr(fileName, "|") then fileName = split(fileName, "|")(1)
wsh.echo(session.TargetPath(directoryName) & fileName)
set record = view.Fetch
loop
just add the path to your MSI file.
tell me if you need a more detailed answer. i will have some more time to answer this in detail this evening.
EDIT the promised background (and why i need to call ConstFinalize)
naveen actually MSDN was the only resource that can give an definitive answer on this, but you need to know where and how to look since windows installer ist IMHO a pretty complex topic.
I really recommend a mix of the msdn installer function reference, the database reference, and the examples from the windows installer SDK (sorry couldn't find a download link, i think its somewhere hidden in the like 3GB windows SDK)
first you need general knowledge of MSIs:
an MSI is actually a relational database.
Everything is stored in tables that relate to each other.
(actually not everything, but i will try to keep it simple ;))
This database is interpreted by the Windows Installer,
this creates a 'Session'
also some parts are dynamically resolved, depending on the system you install the msi on,
like 'special' folders similar to environment variables.
E.g. msi has a "ProgramFilesFolder", where windows generally has %ProgramFiles%.
All dynamic stuff only exists in the Installer session, not the database itself.
In your case there are 3 tables you need to look at, take care of the relations and resolve them.
the 'File' table contains all Files, the 'Component' table tells you which file goes into which directory and the 'Directory' table contains all information about the filesystem structure.
Using a SQL Query i could link the Component and File table to find the directory name (or primary key in database jargon).
But the directory table has relations in itself, its structured like a tree.
take a look at this example directory table (taken from the instEd MSI)
The columns are Directory, Directory_Parent and DefaultDir
InstEdAllUseAppDat InstEdAppData InstEd
INSTALLDIR InstEdPF InstEd
CUBDIR INSTALLDIR hkyb3vcm|Validation
InstEdAppData CommonAppDataFolder instedit.com
CommonAppDataFolder TARGETDIR .
TARGETDIR SourceDir
InstEdPF ProgramFilesFolder instedit.com
ProgramFilesFolder TARGETDIR .
ProgramMenuFolder TARGETDIR .
SendToFolder TARGETDIR .
WindowsFolder_x86_VC.1DEE2A86_2F57_3629_8107_A71DBB4DBED2 TARGETDIR Win
SystemFolder_x86_VC.1DEE2A86_2F57_3629_8107_A71DBB4DBED2 WindowsFolder_x86_VC.1DEE2A86_2F57_3629_8107_A71DBB4DBED2 System
The directory_parent links it to a directory. the DefaultDir contains the actual name.
You could now resolve the tree by yourself and replace all special folders(which in a vbscript would be very tedious)...
...or let the windows installer handle that (just like when installing a msi).
now i have to introduce a new thing: Actions (and Sequences):
when running (installing, removing, repairing) an msi a defined list of actions is performed.
some actions just collect information, some change the actual database.
there are list of actions (called sequences) for various things a msi can do,
like one sequence for installing (called InstallExecuteSequence), one for collecting information from the user (the UI of the MSI: InstallUISequence) or one for adminpoint installations(AdminExecuteSequence).
in our case we don't want to run a whole sequence (which could alter the system or just take to long),
luckily the windows installer lets us run single actions without running a whole sequence.
reading the reference of the directory table on MSDN (the remarks section) you can see which action you need:
Directory resolution is performed during the CostFinalize action
so putting all this together the script is easier to read
* open the msi file
* 'parse' it (providing the session)
* query component and file table
* run the CostFinalize action to resolve directory table (without running the whole MSI)
* get the resolved path with the targetPath function
btw i found the targetPath function by browsing the Installer Reference on MSDN
also i just noticed that CostInitialize is not required. its only required if you want to get the sourcePath of a file.
I hope this makes everything clearer, its very hard to explain since it took me like half a year to understand it myself ;)
And regarding PhilmEs answer:
Yes there are more influences to the resolution of the directory table, like custom actions.
keeping that in mind also the administrative installation might result in different directorys (eg. because different sequence might hold different custom actions).
Components have conditions so maybe a file is not installed at all.
Im pretty sure InstEd doesnt take custom actions into account either.
So yes, there is no 100% solution. Maybe a mix of everything is necessary.
The script given by weberik (deriven from MS SDK VB code) is very good, because it makes it easy to analyse the directory table without an own algorithm (which is a mid-size effort to do it in a loop or with a recursion algorithm).
But it gives not a 100% perfect view for all files, see below.
The method of the script is semi-dynamic (can be extended by other actions), but in effect it gives only the static directory structure, similar to a default administrative install or advanced MSI viewers.
Normally this is enough and what we want.
But be aware, that this is not the 100% solution (Knowing before exact the path of each file afterwards). That does mean, this will not give you always the correct paths in some cases:
You use command line parameters which substitute predefined directory table entries.
The MSI uses custom actions which change paths.
Especially it is not guaranteed, that every file is installed. There may be optional conditions and features and this may depend on the install environment.
In effect, a 100% solution is very very hard to achieve, without installing really. It comes near to reprogram nearly the whole windows installer engine. So simplifications are normally sufficient and accepted.
But you can extend the method to cover custom actions, e.g. with adding a line "session.DoAction(..)" for each additional action needed. Or to include command line parameters.
Sometimes it can be tricky. The easier the structure of the MSI is, the more likely it is that you succeed without more efforts.
Alternative to write an own program:
The question is, what you really want to find out, and if it is really necessary to program it:
If you don't want to write an automatical every-day MSI analyzer maybe the following is sufficient for you:
First tip: install the MSI with "msiexec /a mysetup.msi TARGETDIR="c:\mytestpath" . (similar restrictions as script above by weberik)
If the MSI has not used custom actions to change pathes including forgetting to add to the admin sequence ("forgetting" should be taken as the normal case for 99% or existing setups :-), you get the filestructure like if you install "really" with some special namings for the Windows predefined folders which you will find out easily.
If the administrative install lacks some folders, it is often a better idea of fixing the custom action (adding to the admin sequence) and using this scenario as your primary test case.
The advantage is, that only you limit the dynamics used by admin install. BTW, you can use the same command line params or path settings custom actions as in real install.
Second tip: Google for the InstEd tool , go to the file or component table and you will see the resulting MSI paths in the same static way as with the mentioned VB-script after calling CostInitialize/CostFinalize. For human view such an editor view maybe better.
For automatic testing and improvements or accuracy, you need an own program of course.
For those of you that mentioned snippet given is a good starting point. :-)
The rest of you should live easier with one of the two given methods without programming.
I need to create a shortcut for my application in Installshield, and the path to do so is:
C:\app\bin\exe.exe -basekey ini -ininame settings.ini -p cal.p -pf s:\pfs\sec_l_oea.pf
This shortcut is essentially split up into three bits:
C:\app\bin\exe.exe
This is the location of a pre existing software that I would like to find using System Search.
-basekey ini -ininame settings.ini -p cal.p -pf
This will always be the same and does not need any variables
s:\pfs\sec_l_oea.pf
The user should have to browse to find this file.
My problem is I don't know how to get the path for part one, I have set up a System Search to hopefully find it, and store it in the "PROWIN" variable, however, how do I access that variable when setting a shortcut?
I could also do with knowing how to take a user variable (from installation) and set the shortcut depending on that for part 3.
Any help is appreciated
Once you have the file stored in a variable/property I think it can be used in multiple places by putting the name in a string with square brackets around it.
Your argument might look something like this:
-basekey ini -ininame settings.ini -p cal.p -pf [PROWIN]
As a side point: In the installshield termanology, dynamically stored values are always strings and they are refered to "properties" not variables, this might help with future searches.
I have a Coq project with a number of files (say x1.v, x2.v, ... xn.v) including a Makefile stored in folder "C:\Users\WK\Desktop\Personal\coq-project" and have installed Coq 8.3 at "C:\Coq" on my Windows 7 machine.
The Coq programs (files) are dependent on each other. How can I execute a single program (say x1.v) in Coq? I want to open a file in Coq and compile line by line to understand it, but it gives errors as there are many imported files in each, with no one in (.vo) format. I think there is some use of commands coqc, coqtop, make or any combination of these but I dont know the exact format of commands, arguments, and order. Please let me give complete commands with full paths keep in mind the above paths.
Thanks,
Wilayat
just run make
It should create all the .vo files, if your Makefile is correct.