After downloading the Windows version of the GAP system, I want to ask if GAP can read the file in specified path in Windows? What is the command to load a GAP script in the Windows environment?
The command is called Read (enter ?Read in GAP to see the documentation). The trick on Windows is to replace \ by /. For example one should call
gap> Read("C:/Users/myname/gap/program.g");
to read a file that Windows would call
C:\Users\myname\gap\program.g
Also, I'd recommend to avoid paths containing spaces.
P.S. If you prefer to ask questions about GAP in StackExchange framework, I'd recommend to try to ask them at the Mathematics Q&A site.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.
I am newbie to Object-C programming. After trying the very simple code, I found a *.1 file is generated. what is this file mean?
.1 is the file extension for the man page of a general user command—also used are .2 through .8. This is not specific to Objective-C; see more info here.
I guess you created a project using the template OS X application > Command Line Tool. That file is a manual page for your application in troff format. You can read it with nroff -man nameOfTheFile.1.
At this point, just ignore it. If you want to write your own, see https://serverfault.com/a/109559/102042
For more info on man pages, check Wikipedia: http://en.wikipedia.org/wiki/Man_page
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...
I have a DCL script on VMS which calls a perl script. Is there a VMS/DCL command I can use that will tell me every file handle opened by the perl script?
Set default to the disk the app runs from (or you might have to try each disk in succession if it's a really large or distributed app). Then the command is
show device/files/nosystem
If you're on a more recent version of VMS and the lists are too long, you can pipe it with a search by doing this:
pipe show device/files/nosystem | search sys$input (name of perl script)
You need to find the documentation for undocumented VMS features :-)
Seriously I think that set watch might do what you want. If you issue
$ set watch file/class=(all,nodump)
$ perl yourperlscript.pl
You will get loads of output that will hopefully include what you want. I havent done it for years, you probably tune the options to fine tune it. See
http://www.parsec.com/openvms/undocumented.php?page=13
Jason, I need more clarification for a). Are you saying that you want to run your perl script in a batch file and have the batch file monitor the files being accessed by the perl script? Or something else?
Hmm, not sure about that. Maybe add a linux tag to your post so that some linux people can see this and chime in. I'm not sure why your perl program wouldn't know what files it opened. It's your program, wouldn't it access the files you told it to access? Or if you're computing the filenames somehow (which I've done in cobol, but still know at least which directory to find them in, and what naming scheme they use), you'd still have clues like what I mention. Also, since it's your program, and if you're computing the filenames, coudn't you also make your Perl program output it's own little report of what the files were? Like, just after it computes the filename, have it copy the name string to a separate report file.