Using grunt-contrib-concat, I have the following entry:
application: {
files: {
'purgatory/js/appbase.js': [
'src/js/**/*.js', '!src/js/**/tests/**', '!src/js/**/workers/**'
],
'purgatory/js/appworkers.js': [
'src/js/workers/shared.js', 'src/js/workers/*.js'
],
'purgatory/js/application.js': [
'purgatory/js/appbase.js', 'purgatory/js/appworkers.js'
]
}
}
The explanation is this:
"purgatory" is what I call the staging area. In theory, temp files can live here and not necessarily make it to production. So, what happens in the "application" task is that I construct a temp file called "appbase" that contains most of my logic except my web workers and tests. I make the workers phase separate because the order is important. Then I assemble the two temp files into the final application file.
It works.
But my current process eventually just grabs ALL of purgatory/js, because until today, none of my files were actually temp, they were all final targets. I would like to continue doing this instead of granularizing the copy phase or running a clean on the temp files first.
I can't help feel that I'm missing an opportunity right within grunt-contrib-concat.
Something that goes,
"grab everything except workers and tests, but then grab a particular workers file, and then grab the rest of the workers files".
I feel like if I understood the destination map better, I could do it all in one shot instead of bothering with the two temp files. The end goal is to only ever send "application.js" to purgatory. meaning there are no other temp files to clean up or otherwise deal with. Any suggestions?
Well, the answer was staring me straight in the face: you just have to think of the list of paths as a progressively built filter. So, you can exclude all of "workers" earlier in the list, and then include the specific ordered files afterwards. All in the same entry:
application: {
files: {
'purgatory/js/application.js': [
'src/js/**/*.js', '!src/js/**/tests/**', '!src/js/**/workers/**', 'src/js/workers/shared.js', 'src/js/workers/*.js'
]
}
of course, having done that, you could then just use the src/dest properties if that's what you're more comfortable with.
Related
I would like to retrieve from artifactory the files that follow this pattern:
"my-artifactory-repo/project-name/branch-name/1234/*"
Where 1234 is the build number of the latest published build, and where * should not recurse into folders but just match the immediate files. I use build-publish to publish each build under the build name "project-name.branch-name".
I have written a filespec which specifies a "build" but not a build number, causing Artifactory to automatically select the latest published build. This works fine if I simplify the pattern to my-artifactory-repo/project-name/branch-name/*, which results in all artifacts for the latest build being downloaded.
However, where I run into trouble is with the requirement to download only the immediate files instead of recursing into folders. So I tried to use a regex as follows.
{
"files":
[
{
"pattern": "my-artifactory-repo/project-name/branch-name/(\\d+/[^/]+)",
"build": "project-name.branch-name",
"recursive": "false",
"regexp": "true","
"target": "./artifactory-tmp/"
}
]
}
However, each time I try to use a regex, I get zero results.
Some other things I've tried which didn't work:
Not surrounding regex with parentheses
Using a simpler regex like ..../build.bat (because currently I have 4 digit build numbers, and I know a build.bat file is there), with or without parentheses
not using a regex and instead using the pattern my-artifactory-repo/project-name/branch-name/*/*. But this causes recursing in spite of "recursive":"false"
using this search command to retrieve the available build numbers first, so that I can extract the last one and insert it into the filespec. However, there's no way to tell whether the latest build folder is already complete and published, or still currently uploading.
jfrog search --recursive=false --include-dirs=true "my-artifactory-repo/project-name/branch-name/"
The "regexp" option is supported only for the upload command, and not the download command. I believe that the file spec schema under the jfrog-cli documentation shows that. Options that are included in the file specs and are not supported are ignored. This is perhaps something that should be improved.
When the "recursive" option is set to "false" when downloading files, the command indeed avoids recursive directory search. However patterns that include multiple wildcards together with non recursive search, cause some ambiguity in the sense of how deep should the search get. Notice that a single wildcard can include multiple directories. It easy to understand what recursive means when the pattern includes a single wildcard, but with more than one, recursive is practically undefined.
See if you can make your pattern more specific, so that it catches exactly what you need. If this is impossible, consider splitting your pattern into multiple patterns. All patterns can still be included into the same file spec, because "files" inside the spec is a list, which can include multiple pattern and target pairs.
I am new apache storm, i want to use storm to get similarity of files. I want get cosine of all of file in folder "A" with all of file in folder "B". can you help me to show the way to get result.
Thanks so much.
I did not understand what you meant by 'cosine of all files', but in general,
you can think of each folder as a 'stream'. You can have spoutA that read-understand-format-emit the files in folderA and spoutB that does the same for folderB into two tuple streams (I am assuming there are some differences between the two folders like encoding, formatting etc.). Your processing bolt can then 'subscribe' to those streams. For e.g.,
bolt.fieldsGrouping(spoutA, streamname, new Fields("field_in_stream"));
bolt.fieldsGrouping(spoutB, streamname, new Fields("field_in_stream"));
If on the other hand, you meant something like two different instances of the same spout to read from different folders
Not a great idea, because the number of spout executors is now
tied to the #folders you have. Not scalable.
Load distribution will probably be pretty bad.
If you still want to do it, you can
use the task-index of a spout to have different spout executors with
slightly different behavior (different meaning reading from different folders)
Like this, maybe
public class MySpout extends BaseRichSpout {
public void open(Map conf, TopologyContext context,
SpoutOutputCollector collector) {
System.out.println("Spout Index = " + context.getThisTaskId());
}
}
I see that the ability to specify JSHint options on a per directory basis was added here.
However it is not clear to me how you actually take advantage of this. What do I do to set JSH options in a single directory, so that the options differ from other directories?
It appears that the change in question actually allows you to specify overriding options on a per-file basis. You can add an overrides property to your config, the value of which should be an object. The keys of this object are treated as regular expressions against which file names are tested. If the name of the file being analysed matches an overrides regex then the options specified for that override will apply to that file:
There's an example of this in the cli.js test file diff in the commit you linked to:
{
"asi": true,
"overrides": {
"bar.js$": {
"asi": false
}
}
}
In that example there is a single override which will apply to any files that match the bar.js$ regular expression (which looks like a bit of an oversight, since the . will match any character and presumably was intended to only match a literal . character).
Having said all that, it doesn't look like the overrides property is going to help you. I think what you actually want is a new .jshintrc file in the directory in question. JSHint looks for that file starting in the directory of the file being analysed and moves up the directory tree until it finds one. Whichever it finds first is the one that gets used. From the docs:
In case of .jshintrc, JSHint will start looking for this file in the same directory as the file that's being linted. If not found, it will move one level up the directory tree all the way up to the filesystem root.
A common use case for this is to have separate JSHint configurations for your application code and your test code. This allows you to define the different environments and globals separately.
I'm relatively new to grunt and I'm working to concat my files. I've been digging and haven't been able to come up with a good answer for this:
concat({
src : ['file1.js', ...all other files... ],
dest : 'dist/build.js'
});
Where file1.js is always added first, then it pulls in all remaining files. I could do it all by hand, but in the spirit of automation I was hoping to find a more dynamic method.
src is just a simple array which you can of course fill dynamically. e.g. you can read the files manually, sort them by whatever you want, and add that array to your config!
I want one script to command several computers to break up a highly distributable workload. In order to distribute the workload I put half of the task labels in one file, and half of the tasks in another file that i distribute to the computers with google drive (which is why i need different file names). So C:\googledrive\task1.txt and C:\googledrive\task2.txt
The autohotkey command looks like:
loop, read, c:\googledrive\task*.txt
But instead of reading task1.txt, it appears to try to read "task*.txt" as a literal file name, fails, and ends the loop.
Ideas? Thanks.
OK, tried ensuring everything was running with administrator rights (they are) and ensured that the files exist (they do) and no typos in the file path (everything good there). Still wont actually read the file.
There is one bit that I didn't include in the original post part of the file name is actually a variable, so the loop command is actually like:
loop, read, c:\googledrive\%task%*.txt
I just figured that bit was inconsequential.
If i save a different script for each computer, i can go ahead and replace the wildcard with the actual bit, and it works.
so... Im just going to name each file with the computer's name in the file, and change the command to:
loop, read, c:\googledrive\%task%%A_ComputerName%.txt
I do it this way....
Loop, C:\Temp\Source\*.txt ; Lists the next file as A_LoopFileName
{
Loop, read, C:\Temp\Source\%A_LoopFileName% ; process current file
{
IfInString, A_LoopReadLine, abc
{
.......
}
}
}