I'm trying to add a .mo file for en_US translations but I keep getting this error:
Updating the catalog failed. Click on 'Details >>' for details.
And the content is:
execvp(xgettext--force-po, -o, /tmp/poeditf0AcvR/0extrated.pot <...> ) failed with error 2!
You know what's a much better place to report problems with applications you use than SO? As a rule of thumb, its developer is best able and most qualified to help. It's a good idea to provide relevant details, too (this evergreen is worth every second spent reading it, please do: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html), such as version of the app, your platform, specifics of what you're actually doing ("add a .mo" isn't quite as descriptive as it could be).
Seeing that Poedit is apparently trying to launch a program named xgettext--force-po, which quite obviously doesn't exist, my blind guess would be that you went to Poedit's preferences, messed with the settings for whatever extractor you use for this and accidentally removed a space after xgettext from the extraction command in there.
Remove the extractor, quit Poedit and let it recreate it.
Related
introduction:
In this thread (https://github.com/NixOS/nixpkgs/issues/47201), in order to fix my problem, it is said to add this 2 lines.
services.xserver.enable = true
virtualisation.docker.enable = true;
to
/etc/nixos/configuration.nix
Now my question:
I used to work with the sudoers file. And in this link it said to NEVER edit it with a text editor. Because an improper syntax can leave you with a broken system.
Can an improper syntax have big repercussions on nix?
Is there a way to avoid it like visudo.
Editing your nixos configuration is much less risky than editing your sudoers file. So you don't have to hesitate to edit it with a normal text editor or worry about having syntax errors. After using Nixos for a few years now the only thing that went 'wrong' for me is messing up a config and my build process attempted to build packages that would have taken very long (but it was easy to cancel this).
If there are any syntax errors it'll just return an error. And in the worst case where you mess things up you should be able to just rollback to previous config with nixos-rebuild switch --rollback. Or boot back into the previous working generation.
I come from C-family "mainstream" langages and i'm currently giving a try in Lua .
I made a simple code that check for a user entry and try to open an URL (built with user entry) in the default browser.
Saw the command os.execute("start "URL") that failed, saying that "os is undefined".
Well, seemed to be logical. I then researched the reason and discovered the "require" key word (which seems to act as a LoadLibrary or kind).
This is where I'm lost !
All forums says "yeah yeah just add require os and it will do". But it actually fail !
I obviously suspect that i am missing a "file" or path pointing at that "os" description. And that it's so obvious nobody found useful enough to explain or ask for it.
Can someone explain me what does require, in details ? Which file am i supposed to add (if i really need to ?).
If someone also have an online lesson to advise me, i'll accept it with pleasure. I feel like i'm missing a lot of basics and that's really not a "try to step-up" friendly langage
The standard Lua environment has os available without using require, so you must be using a non-standard Lua environment.
When Lua is embedded into different software, access to libraries like os is usually removed, as it is a security risk. (For example, if you allowed full access to the os library to anyone using Lua on a webserver, it would mean that anyone could run random shell commands on that server.)
If your Lua environment has been altered in this way, then there is a good chance that you will never be able to use the os library whatever you do.
When I try to submit a job, I always get an error. In log I see this message:
The executable pre.exe aborted with system error code 529697949. Please check the .dat, .msg, and .sta files for error messages if the files exist.
I don't have these files. I looked for the solution, but the only idea is that there is not enough free space on my hard drive. I have 20GB free. Does anyone know if something else can cause this error? Or does anyone know how much free space I need for submitting a job in abaqus?
Oh, I found the answer. The problem was solved after I installed Abaqus to user, whose name doesn't contain any cyrillic symbols. Renaming the user didn't help, so, I had to make a new one with name in latin.
I came to this problem when I tried to import the stress status from another odb file, by defining the predefined field as type "stress".
I have solved this problem, by re-meshing the current model, to exactly the same with then meshing in the odb file that I need to read in.
I like to use these to debug (can you tell I'm a noob?) and have left them in my code as is when deploying to the app store. Are there any negative implications for this you can personally think of?
I have looked at these resources and I am getting the feeling it's not a good idea:
http://doing-it-wrong.mikeweller.com/2012/07/youre-doing-it-wrong-1-nslogdebug-ios.html
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/LoggingErrorsAndWarnings.html#//apple_ref/doc/uid/10000172i-SW8-SW7
This was also a good resource:
http://www.theonlylars.com/blog/2012/07/03/ditching-nslog-advanced-ios-logging-part-1/
That said, when you ship to the store and DO keep NSLogs in there, what have you logged?
Create a snippet with the above settings. Where it says "debug statement", replace that with:
<#debug statement#>
Now, since the completion shortcut is set to "NSLog", every time you start typing NSLog, it will autocomplete to this snippet and you will have the "debug statement" part selected and ready to type over.
You'll never have to worry about commenting out your NSLog statements again, and you'll never have to forget about using #if DEBUG since the completion shortcut is what you would type anyway.
Apple's Official Documentation for creating a Snippet (I've included this link because I think it's really kind of sad that this is apparently the only way to do it?)...
And my explanation...
Copy and paste the following code into Xcode:
#if DEBUG
NSLog(<#debug statement#>);
#endif
Select the entire code block you just copy-pasted. Click, hold, and drag this code block down to the snippets section (usually in the bottom right corner).
Select this snippet to get a screen like this:
Click "Edit" and fill out the details. Give it a title and description. Leave platform on "All", and language on "Objective-C". Set the completion shortcut to "NSLog", and leave the completion scope on "Function or Method" (what this option defauts to may depend on where you pasted the code to originally and where you dragged it from).
As Aaron Brager's answer points out, NSLog could be a performance concern, particularly in loops (also in places that don't seem very much like loops but actually are, like cellForRowAtIndexPath...).
But more importantly, you may be exposing information you don't necessarily want to be made publicly available.
I'm not saying there doesn't exist something that might be useful to include to present to the end user in the log statements, but personally, I've yet to find it. How many times have you ever investigated the output of an app's log statements to diagnose an issue you were having with it? How many times have you contacted an app developer and they asked you to check these statements to help diagnose a technical issue you were having?
The Mike Weller post you linked makes the right call. NSLog is for user-facing warnings.
There also might be performance issues, especially within loops, since it uses a string formatter.
You can and should use DDLog or other tools to ignore the debug messages when you make your release build.
Is is possible to open a text file and read the contents while another application is updating the file, in such a way that it does not cause a lock conflict?
I need to monitor a log file from one application which is updated by another application each time an event occurs.
I do check if the file is in use before I try to read it, but that does not seem to work in all cases.
Thanks, Pieter
it depends on how the first app open that file.
i.e when calling CreateFile API to open a file, there is dwShareMode param which tells the api how to open it (if this was given 0, it can't be accessed from other applications IIRC).
otherwise there should be no problem with reading from that file.
if im not mistaken, to check if that file is being opened read only u can call
something like
CreateFile(pchar(fName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0) ;
Download Process Monitor from Sysinternals.
Open the filter dialog and add a "path" filter for your log file.
Start the log-writing application (I'll call this "logwriter").
Look for and click on the event where logwriter does a CreateFile.
Under "Detail", it should have "Desired Access: Generic Write". And it should have "ShareMode: Read", which corresponds to FILE_SHARE_READ in the call to CreateFile. What it means is, "I, logwriter, permit others to read my file".
Now run your log-reading application ("logreader"), and do the same exercise.
The Detail should have "Desired Access: Generic Read". And it should have "ShareMode: Read, Write", which means, "I, logreader, permit others, including logwriter, to read and write to the log file".
Those are the most sensible values, I think, and they will prevent locking. Other combinations may be permissible. There is a table here.
Now, you haven't said what happens when it "does not seem to work in all cases". What to do next will really depend on the details. Hopefully the above will give you enough information to work out what is going wrong.
You won't get a lock conflict because the writing application is very unlikely to have locked the file. Doing what you suggest generally works without problems (it's what the UNIX tail -f command does) and those minor glitches that do occur can be ignored. I've written a couple of log monitoring apps in te past that worked like this, with no problems.
Try using FileSystemWatcher to get events when a file is updated.
A more delphi friendly link
Quite apart from getting the file sharing to work right which may be impossible depending on what the other program requests, some programs will close the file between accesses.
I have had success in the past with my program waiting for the file to become available, then quickly opening it, grabbing the needed data and closing it. At least in DOS an attempt to access a locked file caused a few retries, and I bumped up this setting, so that if the other program tried for the file while I had it they would simply be delayed and never see an error.
I was even able to update the file (I made sure NOT to close it in between!) without the other program ever knowing a thing.
Ugly as sin but we couldn't change the other program so it was the only way to get the job done. It was deployed in-house for years, I never heard a peep from the users of that system. It finally went away when the machinery the other program controlled was retired.
XpoLog will do the trick without changing your env or code, XpoLog log monitor
Avar is right - you are at the mercy of the writing program here. If they are locking the file, then there are a couple of things you can do:
1 - Check for a change in the "last modified" date time - if that changes, then you know something has happened.
2 - If the mod datetime did change, then (depending on the size of the file) it might be good enough to create a copy of the file and check that.
we use "Tail for win32",
i know its not delphi but it might be useful
http://tailforwin32.sourceforge.net/