My goal
I am trying to submit a fix to the Filebeat documentation, written in asciidoc.
Source
Currently it is not possible to recursively fetch all files in all subdirectories of a directory. However,
the /** pattern can be used to fetch all files from a predefined level of subdirectories. For example,
/var/log/**/*.log and /var/log/**/**/*.log fetch all .log files from the subdirectories and sub-subdirectories of /var/log, respectively. Note that neither fetch log files from the /var/log folder itself.
Result
From asciidoclive.com:
My problem
The /** becomes / in the output, and the words after it are unintentionally marked in bold.
My question
How do I properly escape /** in asciidoc?
This is tricky, ’cause escaping is de facto broken in Asciidoctor. :(
I know about two possible workarounds:
use passthrough: +++\**+++,
or define attribute for asterisk, e.g. :star: * and write \{star}{star}.
Yes, it sucks and it’s not easily fixable in Asciidoctor. The best option would be to implement new AsciiDoc parser based on proper grammar etc, Asciidoctor is unfortunately in very bad shape in sense of code-quality. :( (If anyone would be willing to sponsor such project, pls contact me.)
Related
here is a complex problem that I am struggling to find a clean solution for:
Imagine having a Snakemake workflow with several rules that can be parameterized in some way. Now, we might want to test different parameter settings for some rules, to see how the results differ. However, ideally, if these rules depend on the output of other rules that are not parameterized, we want to re-use these non-changing files, instead of re-computing them for each of our parameter settings. Furthermore, if at all possible, all this should be optional, so that in the default case, a user does not see any of this.
There is inherent complexity in there (to specify which files are re-used, etc). I am also aware that this is not exactly the intended use case of Snakemake ("reproducible workflows"), but is more of a meta-feature for experimentation.
Here are some approaches:
Naive solution: Add wildcards for each possible parameter to the file paths. This gets ugly, hard to maintain, and hard to extend really quickly. Not a solution.
A nice approach might be to name each run, and have an individual config file for that name which contains all settings that we need. Then, we only need a wildcard for such a named set of parameter settings. That would probably require to read some table of meta-config file, and process that. That doesn't solve the re-use issue though. Also, that means we need multiple config files for one snakemake call, and it seems that this is not possible (they would instead update each other, but not considered as individual configs to be run separately).
Somehow use sub-workflows, by specifying individual config files each time, e.g., via a wildcard. Not sure that this can be done (e.g., configfile: path/to/{config_name}.yaml). Still not a solution for file re-using.
Quick-and-dirty: Run all the rules up to the last output file that is shared between different configurations. Then, manually (or with some extra script) create directories with symlinks to this "base" run, with individual config files that specify the parameters for the per-config-runs. This still necessitates to call snakemake individually for each of these directories, making cluster usage harder.
None of these solve all issues though. Any ideas appreciated!
Thanks in advance, all the best
Lucas
Snakemake now offers the Paramspace helper to solve this! https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html?highlight=parameter#parameter-space-exploration
I have not tried it yet, but it seems like the solution to the issue!
Twine looks great, but the documentation is a bit lacking, and there is no sample iOS project. I'm wondering how I would incorporate this tool into my project.
Specifically:
Is it recommended that my keys be arbitrary codes (e.g. path_not_found_error) or English words/sentences as Apple recommends (e.g. Unable to find path). The article that introduces Twine mentions how English words/sentences fall short when a single word could mean two different things (e.g. list as noun vs. a verb), but then also mentions the drawbacks of using keys: if you forget to include one, the user will see your key name (path_not_found_error) rather than the English counterpart (Unable to find path).
Say I'm writing code and I want to include a new string. What are the steps in order to do so? When following Apple's recommendation, I can simply type NSLocalizedString(#"Sample text", nil), and I am done. What is the process in order to get it working with Twine?
In their examples, they show categories such as [[General]] and [[Errors]]. How do I categorize a string?
In their examples, they show tags. what exactly are these, and how would I use them?
To generate the first version of strings.txt:
Generate Localizable.strings from all the NSLocalizedString macros in your code.
find . -name \*.m | xargs genstrings -o /tmp
It is recommended to save this in Resources/Locales/en.lproj/Localizable.strings
Create the initial, empty strings.txt file:
touch strings.txt
Populate it with the contents of Localizable.strings:
twine consume-all-string-files strings.txt Resources/Locales --developer-language en --consume-all --consume-comments
It seems that after doing this once, it's recommended that you manually modify the strings.txt file going forward.
To create a new string in your code:
Type in the string you want to use, for example:
NSString *prompt = NSLocalizableString(#"prompt_user_name", nil);
Manually add the key/value to the strings.txt file, optionally placing them in a category:
[prompt_user_name]
en = Please enter in a user name
Now when you build the project, it will generate Localizable.strings and when you run the app you will see the correct string. (Assuming you followed the Twine and Your Build Process steps.)
In their examples, they show categories such as [[General]] and [[Errors]]. How do I categorize a string?
Actually, there is no way to add sections automatically, checked their master and there is no section parser in apple strings formatter. So I suppose that the only way is to do it manually.
In their examples, they show tags. what exactly are these, and how would I use them?
This works when you have app on multiple platforms. For example you can add tags iOS and Android and then generate resources based on your tag for particular platform.
Im using doxygen outside of its design, but well within its capability. I have a bunch of essentially text files, appended with some doxygen tags. I am successfully generating doxygen output. However, somehow doxygen occasionally discovers what it assumes to be a variable, and proceeds to document it using surrounding text, causing a lot of confusing documentation. I cant see any direct relationship between these anomalies, only that they're reproducing the same output on each run, and what I can see is at least some are next to a ';' or a '='.
I only want doxygen to document what I've manually tagged. I am hoping to remove any occurrence of these anomalies, however I cannot alter existing text. I can only add doxygen tags, or alter the configuration file. Any ideas?
Many thanks.
Because in my particular case, I do not need any automatically generated documentation, only that which I have tagged with doxygen tags, setting
EXCLUDE_SYMBOLS = *
removes any instance of doxygen "finding" and documenting variables. This however may remove any ability to find any class declarations, namespaces or functions, however this is acceptable for me.
I'm wondering whether the merge=union option in .gitattributes makes sense for .pbxproj files.
The manpage states for this option:
Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result.
Normally, this should be fine for the 90% case of adding files to the project. Does anybody have experience with this?
Not a direct experience, but:
This SO question really advices again merging .pbxproj files.
The pbxproj file isn't really human mergable.
While it is plain ASCII text, it's a form of JSON. Essentially you want to treat it as a binary file.
(hence a gitignore solution)
Actually, Peter Hosey adds in the comment:
It's a property list, not JSON. Same ideas, different syntax.
Yet, according to this question:
The truth is that it's way more harmful to disallow merging of that .pbxproj file than it is helpful.
The .pbxproj file is simply JSON (similar to XML). From experience, just about the ONLY merge conflict you were ever get is if two people have added files at the same time. The solution in 99% of the merge conflict cases is to keep both sides of the merge.
So a merge 'union' (with a gitattributes merge directive) makes sense, but do some test to see if it does the same thing than the script mentioned in the last question.
See also this question for potential conflicts.
See the Wikipedia article on Property List
I have been working with a large team lately and tried *.pbxproj merge=union, but ultimately had to remove it.
The problem was that braces would become out of place on a regular basis, which made the files unreadable. It is true that tho does work most of the time - but fails maybe 1 out of 4 times.
We are back to using *.pbxproj -crlf -merge for now. This seems to be the best solution that is workable for us.
I've been trying to figure out if there is already an accepted method for testing file io operations in Haskell, but I have yet to find any information that is useful for what I am trying to do.
I'm writing a small library that performs various file system operations (recursively traverse a directory and return a list of all files; sync multiple directories so that each directory contains the same files using inodes as the equality test and hardlinks...) and I want to make sure that they actually work, but the only way I can think of to test them is to create a temporary directory with a known structure and compare the results from the functions executed on this temporary directory with the known results. The thing is, I would like to get as much test coverage as possible while still being mainly automated: I don't want to have create the directory structure by hand.
I have searched google and hackage, but the packages that I have seen on hackage do not use any testing -- maybe I just picked the wrong ones -- and anything I find on google does not deal with IO testing.
Any help would be appreciated
Thanks, James
Maybe you can find a way to make this work for you.
EDIT:
the packages that I have seen on hackage do not use any testing
I have found an unit testing framework for Haskell on Hackage. Including this framework, maybe you could use assertions to verify that the files you require are present in the directories that you want them to be and they correspond to their intended purpose.
HUnit is the usual library for IO-based tests. I don't know of a set of properties/combinators for file actions -- that would be useful.
There is no reason why your test code cannot create a temporary directory, and check its contents after running your impure code.
If you want mainly automated testing of monadic code, you might want to look into Monadic QuickCheck. You can write down properties that you think should be true, such as
If you create a file with read permission, it will be possible to open the file for reading.
If you remove a file, it won't open.
Whatever else you think of...
QuickCheck will then generate random tests.