I've got a huge phing build file here. Is there a way to put things like filesets into an external file used by the build.xml? Just need some organisation here.
You can try using the import task, which lets you split a build file into multiple files.
You can also look into property files
FileLists also support a listfile property which is a text file with one file per line.
FileSets support the includesfile and excludesfile property which is a text file with a list of patterns.
Related
I want to configure mplayer to look for an edl when playing a video. Specifically, I want it to use "show.edl" when playing "show.mp4", assuming both are in the same directory. Very similar to how it looks for subtitles.
I can add a default edl in the config file by adding the following:
edl=default.edl
And this will look for the file "default.edl" IN THE CURRENT DIRECTORY, rather than in the directory where the media file is. And it isn't named after the media file either, and thus even if it did look in the right place, I'd have one single edl file for every media file in that directory.
Not really what I wanted.
So, is there a way, in the "~/.mplayer/config" file, to specify the edl relative to the input file name?
Mplayer's config file format doesn't seem to support any sort of replacement syntax. So there's no way to do this?
MPlayer does not have a native method to specify strings in the config file relative to the input file name. So there's no native way to deal with this.
There's a variety of approaches you could use to get around that. Writing a wrapper around mplayer to parse out the input file and add an "-edl=" parameter is fairly general, but will fail on playlists, and I'm sure lots of other edge cases. The most general solution would of course be to add the functionality to mplayer's config parser (m_parse.c, iirc.)
The simplest, though, is to (ab)use media-specific configuration files.
pros:
Doesn't require recompiling mplayer!
Well defined and limited failure modes. I.E. the ways it fails and when it fails are easily understood, and there aren't hidden "oops, didn't expect that" behaviors hidden anywhere.
Construction and updating of the edl files is easily automated.
cons:
Fails if you move the media around, as the config files need to full path to the edl file to function correctly.
Requires you have a ".conf" file as well as an EDL file, which adds clutter to the file system.
Malicious config files in the media directory may be a security issue. (Though if you're allowing general upload of media files, you probably have bigger problems. mplayer is not at all a security-hardened codebase, nor generally are the codecs it uses.)
To make this work:
Add "use-filedir-conf=yes" to "/etc/mplayer.conf" or "~/.mplayer/config". This is required, as looking in the media directory for config files is turned off by default,
For each file "clip.mp4" which has an edl "clip.edl" in the same directory, create a file "clip.mp4.conf" which contains the single line "edl=/path/to/clip.edl". The complete path is required.
Enjoy!
Automatic creation and updating of the media-specific .conf files is left as an exercise for the student.
So I have been trialling Weblate using Docker, and pointing it at a Git repo with some .md files I want to localize. I believe a good way of doing this is to use po4a to first convert the .md (basically text) files to a Gettext .pot file then import these as individual components.
My main aim is to make the process as automated as possible but so far it looks like the steps will be something like this:
Convert from .md to .pot using po4a-getextize
Copy .pot file to .en.po file
Commit both files
Create new Component for this file in Weblate, manually putting in
the name of the '.pot' file
Add new languages to translate this Component to
Wait for translators to do their thing
Download all .po files
Convert back to original format with po4a-translate
Feels like I'm missing something with the way Weblate creates components... or how the .pot & .po files work together... ideally I'd like to automatically pick up and create Components when .potfile appear in the repo, then just set up some scripts outside Weblate to automate the conversion to/from the different file formats.
You can use component discovery or API to automatically create the components.
I am using the xmlpoke task in nant and am looking for a way to use a wildcard when addressing the xml file. Right now I have a file path like project\appFiles\project{versionNumber}\fileToUpdate.xml, I would like to use a wildcard so its something like project\appFiles\project*\fileToUpdate.xml so I don't have to update the version number every time.
How do you get it to respect wildcards?
Looking all over the web, it doesn't look like this is possible, and by design. Like copy command (todir), the file path must point to a single file so no wildcards allowed (Found info on copy command, assuming same applies for XMLPoke, but could confirm exactly).
I ended up changing some design stuff so now the version number is easily calculated by the program calling the script, so passing in not an issue anymore.
I am currently working on a simple tower defense game for iOS (using objective-c), which contains several maps/levels. However, as it is now, each map consists of an image file and a .plist file with information. My question is: is there any way I could create a custom file type (for example, *.map) that contains both the image and the information from the plist?
If this is possible, how do I implement this?
Thanks in advance!
You have several good choices for that:
The simplest solution would be grouping the related files in subfolders: rather than having xyz.map file, you could have an xyz sub-folder, and reference the files out of it. You would not need to use any additional libraries for this, and you would be able to use the same name for all your image files and all your level files, because they would be in separate folders.
You can make a zip archive with the files that you would like to combine, and unzip it before use. Here is a link to an answer referencing a library to do it.
You can use a tar format - here is a list to an answer referencing a library that supports it. You would be able to use tar utility on OS-X to group images with plists on your workstation.
Finally, you can define a format of your own: store the length of the first file in the first four bytes, then store the content of the first file, and then the second. You would need to write a utility for combining the two files into one. This sounds like the hardest choice to implement.
I'm referring to TAGS file generated by ctags or etags in order to have some code navigation in Emacs with M-..
The typical project looks like this:
Large standard library (more than 100 files, but rarely updated).
Project-specific library (updated on the daily basis).
I would like the project to be able to use two (or maybe more TAGS files), but regenerate only the portion of them, only the ones used inside the particular project. How would I approach this problem?
etags --help:
-i FILE, --include=FILE
Include a note in tag file indicating that, when searching for
a tag, one should also consult the tags file FILE after
checking the current file.