Can't figure out how i can choose another output directory for such methods like:
extractAsynchronously,
exportAsynchronously,
reverseAsynchronously
Is it possible?
An app produces huge amount of temporary files and i just want to create separate directory for all temp files and clean it after work is done.
All of those take a baseDir BaseDirectory argument. One idea is that if you choose .custom, the directory will be the same as the input file. Then you could clean out both input and output files together.
If you don't want to do that you could extend AKAudioFile with a new location, perhaps calling it "output" and then do what you need there.
Related
I have a lot of folders each containing a lot of .txt files which i need to process with matlab.
i have a script finished which does it, it reads all .txt files in 1 folder and does some computing.
so if i want to process those files i move the script into the desired folder and run it, it is kinda lame to move the script every time.
is it possile to start a script in a standard directory, then make the script to ask me to browse for the desired directory to run the script in that directory? because it doesnt write any files, it just reads. after it finishes it should reset it, so i could browse to different folders every time. like save the path in a value and clear it at the end...
i use "fopen" in that script to open the .txt files, so it could be possible to assign the full path to that function, but its important to me to being able to browse the right folder every time i run the script.
i use
path=uigetdir;
fileid=fopen([path filesep 'file.txt']);
and it works just the way i wanted.
thanks #excaza and #Laure for a quick reply
I have a bunch of codes that are currently stored on my local machine. There are two folders, one called "Resources" and another called "src". There is one main script that needs to be run called "main.m" in "src" which calls files from "Resources".
If I copy this whole thing onto a new computer, the paths will change and MATLAB may not be able to find "Resources" anymore. I know that relative to "main.m", I need to go up one level and then into "Resources".
What is the best way of getting MATLAB to point to "Resources"?
I am currently trying along the lines of
P = mfilename('fullpath')
which gives the path for main.m. Now, I want to navigate from here, one folder up and then into "Resources". Or if there is a better way, please let me know.
Eventually, I want to extend it to work for multiple folders "Resources1", "Resources2" etc. so MATLAB needs to be able to navigate to the right folder.
You can get it like:
fullfile(fileparts(mfilename('fullpath')), '..', 'Resources');
Explanation:
mfilename('fullpath') will return the full path and name of the
M-file in which the call occurs, without the extension
fileparts will return the path of the passed file (only the containing directory)
fullfile will build the full directory specification from the folder names passed (Note: '..' always means the parent directory)
Based on this it is quite simple to write a function that gets the sibling directory of the directory containing the file:
getSiblingOfParentDirectory.m
function siblingDirPath = getSiblingOfParentDirectory(filepath, siblingDirName)
siblingDirPath = fullfile(fileparts(filepath), '..', siblingDirName);
end
then to use it in an M-file:
for i = 1:3
disp(getSiblingOfParentDirectory(mfilename('fullpath'), ['Resources', num2str(i)]));
end
Sample output:
D:\pathtest\Resources1
D:\pathtest\Resources2
D:\pathtest\Resources3
You can try the following:
ResourcesFolder = strrep(mfilename('fullpath'), 'src\main', 'Resources');
addpath(ResourcesFolder);
%%Your code here where you need those files
rmpath(ResourcesFolder);
Which is fully dependant on the names of your folders & files of course. Basically "addpath" enables you to access the files in the mentioned directory by adding it to the search path, and "rmpath" does the exact opposite.
Also, if you literally want to navigate to a folder present on one level up, you can execute the following:
cd ..\Resources
Which goes one level up, searches for the folder 'Resources', then changes the current directory to that folder .
My job has following steps:
- Connect to ftp location
- Download compressed files
- Uncompress files to different folder
- Delete compressed files
- Write file names to a tracking file
ftpConnection -OnComponentOk--> ftpList-Iterate--> ftpGet -Iterate--> fileList-Iterate--> fileUnarchive-Iterate--> fileDelete
Question is where can i write the uncompressed filenames to the tracking file. When i try to Iterate from fileUnarchive to fileOutputDelimited it does not
allow me, similarly if i want to add a map from fileDelete it does not allow me. Do i need a map or can i make use of the global variable somehow?
One way i can do it getting it after ftpGet but i would prefer to do it at a latter stage (after unarchiving or deletion) so i don't update the file if the
process fails at one of these steps.
Thanks.
try with tfiledelete-->oncomponentok-->tfixedflowinput(here you can use the same global variable which contains current file name from tfilelist)-->(mainflow)-=->tfileoutputdelimeted...
Upon numerous searches, I am here to see if someone has any idea on how I should go about tackling this issue.
I have a folder with sub-folders. The sub-folder containers each has files of different file types e.g. pdf, png, jpeg, tiff, avi and word documents.
My goal is to write a code in C# that will go into the subfolder, and combined all the files into one pdf using the name of the folder. The only exception is that a file such as avi will not be pdf'ed in which case I want a nudge as to which folder it is and possibly file name. I am trying to use the form approach, so that you can copy in the folder pathname and also destination of the created pdf.
Thanks.
to start, create a FolderBrowserDialog to get the root folder. Alternatively just make a textbox in which you paste the folder name ( less preferred since the first method gives you nicer error-handling straight out of the box )
In order to iterate through, see How to: Iterate Through a Directory Tree
To find the filetype, check System.IO.FileInfo.Extension for each file you iterate through. Add those to list with the data you need. ( hint, create a list of objects in which your object reflects the data you need such as path, type etc,... ). If its an avi don't toss it in the list but flash a warning (messagebox?) instead.
From here the original question gets fuzzy. What exactly do you need in the pdf. Just the filenames and locations or do you actually want to throw the actual contents of the file in pdf?
I have a couple of modules (DZP::Catalyst and DZP::OurPkgVersion) both of their purposes involve writing out files to the disk. I'm not sure how to test them, are there any good strategies for testing files written out to disk? any place I could go to read up on it?
Well, in this particular case (Dist::Zilla plugins), you're going to want to use Dist::Zilla::Tester. It takes care of much of the grunt work of creating a temporary directory, populating it with files, and cleaning up afterwards. For example, see the tests from my DZP::CJM or the tests from Dist::Zilla itself, especially the plugins directory.
Update: Dist::Zilla 4.200002 introduced the Test::DZil module, which adds some utility functions useful for testing plugins. You'll probably want to use it instead of using Dist::Zilla::Tester directly.
It depends somewhat on the module, but my general strategy is:
Ensure that file content logic is 100% separate - as far as being in different methods - from file mechanics (e.g. choosing directory/opening files/closing files/error handling).
Ensure that the file mechanics is 100% flexible, e.g. you can choose the directory/filename from the external driver.
Write tests for the file mechanics, by simply opening the specified file in specified directory, closing it, making sure no errors happen and that expected file exists and has size zero
create an array of test data, with each element of the array consisting of 3 parts
Input data for file content logic, possibly coupled with test configuration indicating which methods from file content logic to call on that data if warranted.
Expected file name to be set
Expected file contents, in the form of tar-balled expected files (exact files with exact expected content to be generated and the correct expected name).
The expected results tarballs should be in a separate sub-directory (say "expected_results" under the directory where your test script lives.
You need a tarball in case your file generation logic produces >1 file.
Then, run a loop over each test in the test array you previously created:
Create a new "actual results" temp directory (or clean up the one from prior test)
Set the directory in you module to the temp directory; set the filename of your module to the expected filename from test info.
Run the file opener method (previously tested)
Run the content generation logic from the module using test's logic directions (if applicable) and test's input data.
Run the file closer method (previously tested)
Create an "temp expected results" temp directory (or clean up the one from last test)
Copy an "expected results" tarball from "expected_results" test sub-directory to the "temp expected results" temp directory created in last bullet point
untar that tarball in "temp expected results" temp directory and delete the tarball from there.
directory-diff the "temp expected results" temp directory with "actual results" temp directory (e.g. ensure both have 100% identical list of files and that each file's contents are 100% the same, either via native Perl or using diff via system() calls.
Since the logic above is very generic, I generally abstract most of it away into a "Test::FileGenerator" module re-used by all of the unit and integration tests that test file generation ability.