I just got my MBP with Retina and i'm really new to the Mac OS X (using PC before). I noticed that the Mac doesn't have a GUI to show/hide hidden files like Windows. I've researched and saw this site Show Hidden Files on your Mac. And yes, it works.
What i wanted to do is to make an executable script that will perform the above commands when i double-click it so that i don't have to type commands in Terminal in order for me to show/hide hidden files. I saw Applescript but i'm not very familiar with it. I don't know the commands to perform what i want. But i've read some.
I don't remember why I wrote it the way I did, e.g. why I added the return command at the end. I do know that it works on all versions of OSX since 10.6.8. The difference with the other answer by Parag Bafna is that you're not asked whether to show or hide the files. If the files are hidden, they're shown and if they're visible, they're hidden.
My next question for help is how can I get this to then repeat on a group of csv's in a folder, capturing the filename as one of the columns, ideally stacking them as well. aka step1, step2, step3, step4 files.
Below is your script modified with the above items. The code is not tested, and you have to add in the directory etc. to read the files from. It should give you a real good starting point for getting your final product
Is there a way to specify an alternative to build.rs which includes modules spread across multiple files like a normal crate? The Cargo reference mentions that the build script is expected to be a file, so I'm guessing not, but maybe there's a workaround I'm not familiar with.
I think it would work -- cargo just invokes rustc, and that only cares that it can find modules relative to the primary input file. You can even use a starting path other than build.rs if you specify that in Cargo.toml.
I'm in a situation where I 'm using a folder with multiple PSD files, so I open every single file, run a script from folder D:/Temp/Script, then confirm the source location E:/Image/Temp and after that the script does the job.
Is there any way to automate the whole process instead of doing it one by one for every single PSD file?
Thanks,
Alexander
If this doesn't work for you or you wish for the script to be "self-contained" there are many examples of scripts on this site that open files from a folder, process them and then save them. So it should be easy enough to add the batch processing code into the existing script code (depending on the existing script, this could be easy or not).
"If this doesn't work for you or you wish for the script to be "self-contained" there are many examples of scripts on this site that open files from a folder, process them and then save them. So it should be easy enough to add the batch processing code into the existing script code (depending on the existing script, this could be easy or not)."
An Action can also record the path to a script that is run/recorded via File > Scripts > Browse... (obviously if the script is moved, then the Action is broken and this is an absolute path, not relative).
Thanks for the prompt response but it does the same thing: PS opens a Select Folder window before every PSD file so interrupts the whole process. I believe modifiing this part of the original script will do the job:
I found from other topic in this Forum.
You can unzip the .urp file and use xml to open it.
and then you can check the information from this .urp, but I not sure you can edit it or not. this also bother me.
For the .urp inside the VM, what is the accessory that we used to see the file other than opening that with Polyscope.
In connection to this after running the .script file will that also generates the .txt .urp files.?
Yeah its hard to edit a saved .script file that was straight from the pendant. What I have been doing is Uploading the .script file in chunks the same way Nrivas described. What error are you getting when trying to use your .script file? You might be duplicating the code the initializes the cobot.
In my case, after I change the .script to create a different program and put it back to UR with the original .urp file.
the program will still be the same program as the original .urp file, not the .script program I created.
So, just having a little UR program that just runs a .script is the easiest way for now.
This .script you can edit it directly if you have any remote client active on your controller, or you can copy-paste it back and forth with a usb or through ssh.
None of these is actually ideal.
So I'd like to propose add the ability to import a swift file from another swift file, only when in interpretation mode. Here's a suggestion on the syntax:
How do you execute the script? I assume it's some way of invoking the swift myfile.swift right? And if so, then it is not too hard to list all the necessary files in the invocation, is it? And it also has a benefit of specifying what files are needed (in a single place!) and their relative locations, as opposed to an import, that would require working out the details of where to look for the .swift files.
Specifying all the files on command line is cumbersome and really not developer friendly.
Plus installing a (multiple files) script on your machine and importing it into your own script would be rather complicated.
As for the details of where to look for .swift files there a many possibilites:
FWIW, it would be great to have a bigger, consistent story for Swift command-line use. I think Perl 5 has a lot of inspiration to offer in this case, with its -E one-liner wonder machine or -p and -n implicit loops; see man perlrun. If we collected a bunch of command-line use cases, we would have more data to design the import feature, too.
I feel import is taken to mean import a module, and in this context you're not really importing a "module", but a file. So, I feel like this kind of "import" would be better expressed as a #include compiler directive that would only function in REPL mode.
It would also be very neat if we could have site-wide modules, that could be used from such scripts. Similar to global packages installed by python/pip. That way you could install some common tooling (libraries) and use them from such ad-hoc scripts without all the overhead of creating full-blown SwiftPM projects.
Please please please do not use -enable-source-import. It does not work. It's barely good enough for the tests today and we are really hoping to take it out. (If you want concrete things to worry about, it may straight-up miscompile your code.)
Swift doesn't have script file importing because Swift modules are usually more than one file, and we don't want to have different conventions for scripts vs. larger packages, and because you'd probably want to cache the results of compiling each module anyway. Your script would just be very slow otherwise.
At some point we probably need to sit down and really consider what Swift scripting should look like. The current interpreter mode is good enough for things that fit in one file and that don't need to be optimized, but as you've all noted it doesn't really scale. But that's a bigger effort than just allowing source imports.
What is possible today is compiling packages as libraries and then putting them in some common search path that your scripts find with -I /path/to/libs/. That lets you use optimized versions of the libraries as well. I don't remember if the package manager makes it easy to get at the dylib and swiftmodule you'd need to do such a thing, though.
I do agree that having different conventions for scripts vs compiled code is not cool, but Swift does not have any notion of module outside of compiled code. It is not defined in the code, but in command line.
The latter seems rather important to me (hence the topic) and I think we should resolve it before trying to do any performance optimization. By definition scripting is some kind of slow so I wouldn't care about it right now.
Including compiled scripts is probably better for dependencies.
What if the script itself is made of multiple files though? Would that require to compile the script at every edit? I suppose you could make a compile&run script for doing that though...
Modules definitely do show up in code: they're the extent of the internal (default) access control; they're usable (usually) for disambiguation of top-level names (Swift.Sequence vs. MyKit.Sequence); they affect diagnostics as an approximation of what is and isn't under your control; and, of course, they're what you get today when you say import.
You're totally right that not performing well isn't a showstopper for enabling source import. But I think this is something that needs more design to fit in the Swift world than just "import this file". For example, maybe import FooKit could pick up a directory named FooKit, perhaps a directory containing a Package.swift manifest. (And yes, since that's complicated, maybe it would work for a single file as well.)
Let's say we don't use -enable-source-import;)
What sort of import the user should be able to do from script file?
Importing a compiled library should obviously work, but IMO importing a scripting library (hence not compiled) and a single file should work too. Thoughts?
Is there an update around this? Looks like when I do the source-import it wants an SDK. I do agree having a import file "/path/to/file.swift" would be nice as scripting is going to grow with the number of macOS administrators looking at swift to provide native notifications.
Currently, I'm running two skill files as a script file but would prefer to use one skill file to run multiple skill files or one skill file to run multiple script files.
b37509886e