I've compiled scripts in Red before, but once I've been away from it for a while, I forget. I thought I'd ask the question here because I'm sure I'm not the only one.
How does one compile a script in the Red programming language?
I've searched my Red distribution folder in the "Docs" directory, and also looked on http://red-lang.org, but didn't see the instructions. I know I've seen it somewhere before, but I can't seem to find it.
So basically, thanks to #Blender, the information is available at https://github.com/dockimbel/Red.
I knew I saw the information before, but I couldn't remember where. I checked the "Docs" folder in the Red distribution, but that didn't have the information there (might be handy to add it).
Start the Rebol interpreter in the folder where the Red files and folders are stored.
For Red: >> do/args %red.r "%red/tests/console.red"
For Red/System: do/args %rsc.r "%tests/hello.reds"
See the link for more detailed instructions.
Related
This feels too obvious to be unanswered, but if the answer is out there, I haven't found it. For context, I'm incorporating someone else's existing code into a Bazel build, so I'm really not looking for "just don't do it that way"-type answers.
The code produces man dozen related files: Libraries, compiled binaries (from C and C++, if that matters), python and shell scripts, etc. Those files expect to find each other in specific locations (e.g. shell scripts reference binaries by relative or absolute path), and I need to package up and install the whole lot.
Is there a way to do that in Bazel? To pick out a bunch of bazel-generated files (and, in this case, a bunch of input files that we pass through unmodified) and put them in a tarball, or a standard package format (e.g. .deb) or even just place them in the local file system in known locations?
The closest ideas I've seen involve basically doing it by hand (e.g. writing a shell script to go into Bazel's output directory and copy out the files of interest) but that seems easy to get wrong. There has to be a way to use the intelligence of the build system to bundle up a bunch of targets and data files, right?
Naturally, I find what's probably the answer shortly after posting the question: https://docs.bazel.build/versions/master/be/pkg.html. If anyone has further insight, though, I'm definitely happy to hear it!
My friends are losing points in their computer science classes because their submission graders decompress and read zip files, which are obfuscated by a bunch of Apple metadata crap generated from zipping a file through the right-click contextual menu in Finder.
I've written a bash script to zip only unhidden files from a specific directory, and I've added a contextual menu service through Automator so this script can be run from right clicking a file.
The problem is I don't want to manually copy over all this stuff and make Automations on each computer my friends use. I'd like to leverage make or some similar utility to make an executable that will add the bash file and automator menu service to any computer the executable is opened from.
I'm lightly familiar with make (more familiar with rake), but I can't find out how to package the automator service and install it on their machine through an executable.
You'll want to package your automator application and script(s) into an Installer Package (.pkg). The best way to achieve this is to understand some general concepts, the commands to build one, and by checking out some tutorials or other relevant information.
I recommend for creating your first Installer Package using a utility
such as Packages (open-source and free), which has excellent
documentation, and is less complicated than using the command
line tools. Basically it puts a nice gui around the Apple tools which
are somewhat nonintutive by themselves.
Building Installer Packages is not the easiest thing to do your first time, and it might take a bit of patience to finally get it right. Once you've successfully created one you should have a good grasp on what is involved in putting them together along with the concept behind it all. At the very least, this information hopefully points you in the right direction regarding your question, and/or gives you a better idea of how to accomplish what you want to do.
My program needs to locate an existing GhostScript install, and run gswin32.exe (or the 64-bit version if installed) with some command-line options to do a silent conversion of PS to PDF. How should I go about this? I see they add some registry settings under HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\9.07, but I only see a LIB path (which has several paths) and a DLL path, nothing for the EXE. I could work backwards from the DLL path, I guess, but not sure if that will be "future proof".
For the type of app GhostScript is, I would assume they would make this part very easy and obvious, since a lot of programs will be doing exactly this. With all of the free "print to PDF" drivers out there, you would think this info would be easy to find, and maybe it is, but I sure can't find it. Hopefully I'm just missing something, because I don't know where to search, or the right keywords to find it on Google.
I'm tempted to use "GSLite", but so far the only places I've found to download this doesn't have any info on how to download the GS source code for the build of GS they are using, and I think that violates the GS license (not making source code available), so for now I'm just thinking I'll have users install GS themselves, and just look for it -- instead of making it a sub-folder under my app or anything like that.
try ftype (which of course may give acrobat or something, but worth a shot)
maybe some windows expert can tell how to acess the alternate apps list you get by right clicking a ps file...
HKEY_LOCAL_MACHINE\SOFTWARE\Artifex\GPL Ghostscript\9.07
After doing a registry search for a few different keywords, I found the above key which contains a (default) string that points to the install directory. I then did a Google search on that registry key and found some links to the GhostScript source code that sets that value, so I think it is safe to use. I would post those links here, but none of them are good sources (one I had to use Google's "from cache" feature, and the other was just a random person posting a snip-it of GS code). I'm sure it is in the official source code download from their website, if anyone else needs to confirm this, possibly a file named nsisinst.nsi, an install script.
I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?
Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.
For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.
I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.
I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.
Here's a little more explanation of Graham's suggestion:
Create an images directory
Create an images Group in Xcode
Right-click the group and Get Info
"Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:
Created the directory on disk where I wanted it.
Went to the file menu
Right clicked on the group I wanted to add to
Selected "Add Files to PROJECTNAME"
Added the files from the directory I created in (1)
Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.
In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.
Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).
You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.
But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.
My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.
It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.
Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.
I have MANY small "Test Projects" where I put together just enough code to prove or disprove some idea I'm working on. Some time (sometimes several months) later, I need to use some of this code. It can take hours searching through poorly named folders to find the gem of code I'm looking for.
It's not enough to be worth a Blog or wiki entry. I'd just like to have something that includes a description, maybe a screen shot and the zip file of the project (or pointer to version control)
Is there a feature I'm missing in Visual Studio to track projects? Is there a template that can be used to search based on project comments etc?
Has anyone come across something like this?
How long before this question gets closed?
Yes, there is such a feature: it's in the "New Project" dialog, and it is called "Name". This will allow you to give your project a meaningful name, that will aid in your finding it later.
There's a related feature, borrowed from the operating system, called "Folders". This allows you to group various projects that are conceptually related, and put them together into a "folder", which you can give a meaningful name related to the conceptual grouping.
The combination of these two will serve all of your needs. The trick is to avoid the mentality which leads to "poorly named folders". Good working habits will save an absurd amount of time in the future, and it really doesn't take that much longer to come up with a meaningful name, rather than TestProject426
Why not use a version control system (like subversion) for that purpose?
You can put your test projects under version control, and by using a log message you have something you can later search for keywords and check out a project in case you need it again.
Once you have put a project under version control, you can remove it from your local disk (so you have less stuff lying around).
If a wiki is really to much hassle, why not search the root of your project folders with something like
findstr /I /S "nifty comment" *.cs
This would just require you to leave a comment with some keywords inside your code.