So I have a script that takes an input and prints whatever. It needs access to a file written by a third party. My Xcode project structure is just two files, main.swift and ThirdParty.swift. If I just run it from Xcode main.swift happily sees ThirdParty.swift and I'm apply to instantiate an object defined within. When I run from the command line it cannot find ThirdParty.swift (which is pretty much to be expected; how would it know it's there?).
None of the command line options to pass to /usr/bin/swift seem to be appropriate for pointing to a file I'd like to use and pointing it to the current directory doesn't work either. Is this even possible or should I just give up?
The ideal end result is the ability to do something like:
./main.swift --option1 --option2 thing
But an acceptable place to end up would be:
swift -X ThirdParty.swift main.swift --option1 --option2 thing
Where X is whatever option I need to be passing in.
You can't pass two files into "immediate" mode (swift REPL mode) but you have several other options:
Combine the files together on the fly into a temporary file (with e.g. /bin/cat)
Compile the two files into a normal binary with swiftc.
I recommend option 2, though it means every time you change the code you'll need to recompile, and the binaries it creates aren't portable between OS X and Linux.
Related
So I noticed, while answering this question, that the one who asked the question appears to be a javascript developer. And as the code I wrote in haskell is easy enough, I thought I give haste a try and try to compile it to javascript.
So, I downloaded the Windows binary package of haste (why does the .msi require a reboot?!!?), added it to my path, issued haste-cabal update and haste-cabal install split and after a bit of reading the output of hastec --help, I issued:
PS E:\h\stackoverflow> hastec -o hexagon.js --pretty-print hexagon.hs
as my best guess on how to get the output I am looking for.
Opposite to my expectation, haste output was this:
hastec.exe: user error (shell expression failed in readModule: Data.Binary.Get.runGet at position 8: not enough bytes)
So, my question: What do I have to do to get a java script source file?
Is it possible that you have an old version of Haste lying around, or have intermediate files (.jsmod, for instance) from a different version of the compiler in your source directory? This sounds like the (quite unhelpful) error message Haste produces when it runs into a corrupted intermediate file.
Check that the version of the binary you're calling is what you expect (hastec --version). Then, try getting rid of all intermediate files in the directory as well as any files in %USERPROFILE%\AppData\Roaming\haste, reinstalling split, and recompiling with the -fforce-recomp flag. You should also add a main function, so that Haste has an entry point to your program from which to start linking. If all you want to do is to make some Haskell function available to external JavaScript, you can use the export foreign function interface:
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Haste.Foreign
import Hexagon
main = export "picture" Hexagon.picture
You will probably also want to compile your program with the --onexec flag, to make sure that main runs and exports picture immediately when loaded, and not on page load which is the default:
> hastec -o hexagon.js --pretty-print --onexec hexagon.hs
After doing this, any code included after hexagon.js will be able to call e.g. Haste.picture(5); in order to produce a picture of size 5.
(Re: MSI installer requiring a reboot, this is required since it adds the Haste binaries to your %PATH%, which does not take effect immediately. I assume that a re-login would be enough to make it take effect, however.)
Objective:
I'm trying to use a program called Texmod.exe to start another program (exe) with certain parameters.
Background:
Texmod is program that opens up another exe and extracts/replaces textures that are pulled up in the second program while it is running. I'm trying to start the second exe with the parameters: -AlwaysFocus -ControllerOffset=1 -SaveDataId=2. Starting the second exe with shortcuts/.bat that have these parameters in a command line DOES work. However, I would like to do this in conjunction with Texmod.
Complications:
I'm using Texmod v0.9 b which doesn't support starting an exe with command line parameters. Newer versions, such as the open source reboot known as uMod, does support but it doesn't replace textures as well and crashes often compared to the original version.
Texmod.exe must start the second exe directly. Texmod can't select a shortcut to start the exe. I've tried making Texmod start another exe/.bat that then starts the second desired exe with parameters but this causes Texmod not to function.
Methods I have thought about but not sure if they work or even possible:
Somehow forcing all processes started by Texmod.exe to start with certain parameters
Somehow force the desired exe to always start with certain parameters regardless of start method (via Texmod, shortcuts, .bat, etc)
Add parameters to the process started by the desired exe after it is already running
Obviously I'm open to any ideas. Is what I'm asking even possible? Sorry if it seems unclear or I sound irrational; my knowledge on this is limited.
Edit: #Toby Speight I'm not sure what you mean by an example of the code I'm having trouble with as I'm just wondering if it's possible to perform the scenario I described. This is where I got the Texmod program from (it's the oldest release texmod.zip - Original TexMod 0.9 beta). I've searched the internet for possible solutions but I've found very few so some of the methods I've tried are:
Used Texmod.exe to start a desktop shortcut with target: "directory to exe" -AlwaysFocus -ControllerOffset=1 -SaveDataId=2. The result was Texmod couldn't use the shortcut and just opened the exe without the parameters.
Used Texmod to start an exe named caller.exe which started the exe I desired using the method described here. In command.txt, described by the instructions, I put ""name of exe.exe" -AlwaysFocus -ControllerOffset=1 -SaveDataId=2." The result was the exe started with the parameters but Texmod failed to modify the textures because it was modifying textures pulled up by caller.exe instead.
Used Texmod to open a .bat file with the lines: ""name of exe.exe" -AlwaysFocus -ControllerOffset=1 -SaveDataId=2." The result was the same as attempt described in #2.
Edit2: I also stumbled on this page where someone else claims they managed to achieve what sounds like the objective I desire. However, I do not know enough about code to understand it. If someone could look over this to see if it would work or see if they can modify it to fit the arguments that I desire.
You can use windows registry to force Windows run another app when specific .exe is called. Let me show an example: i'm trying to use TexMod with Remember Me.
Required setup:
Create a copy of game .exe, place it near original with different name, eg RememberMe_copy.exe
Go to windows registry location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
create new key named as original .exe, in my case it's RememberMe.exe. Registry key looks like a folder.
In this key, create new string value named Debugger with full path to copy of .exe with required commandline args. For example: "C:\Program Files (x86)\Steam\steamapps\common\Remember Me\Binaries\Win32\RememberMe_copy.exe" -ReadPoolSizeFromIni. Note the path to .exe is quoted, commandline arguments are not. String value has type REG_SZ.
Now when you try to run anything called RememberMe.exe, Windows will instead run the RememberMe_copy.exe with specified parameters (and something else but we don't care). This feature is left in Windows for debugging purposes.
Finally, open TexMod, select RememberMe.exe. It will think it's running original file, but instead Windows will silently run another file with another parameters. As there is nothing else in between, TexMod is happy.
Why can't we use single file? Well, Windows will run original .exe instead of original .exe, then instead of it will run original .exe... causing infinite loop.
Tried Googling, but couldn't find anything.
I have a few files and folders in my current MATLAB folder.
One of those folders is called 'Map' and it has a 'map1.m' file which I want to call from my code in the current MATLAB folder.
In my code, I can't call it like this:
/Map/map1;
but I can do so like this:
cd Map;
map1;
cd ..;
Somehow the above method seems incorrect. Is there a more elegant way to do it?
You can run the file without adding the folder to your path manually, using the run command, which is specifically for such cases. From the documentation:
run is a convenience function that runs scripts that are not currently on the path.
You call your function/script as
run /Map/map1
If you want to run the function/script by merely entering its name and not with the full (or relative) path, then you should add the folder to your path.
As noted by #mutzmatron, you cannot use run to call functions with input/output arguments. So, unless if it's a script/function without input/output arguments, using run will not work and you'll have to add the folder to your path.
EDIT
Just as a matter of good coding practice, and to work in cases where your function has inputs/outputs, adding/removing the folder from your path is the correct way to go. So for your case,
addpath /Map
...
map1;
...
rmpath /Map
The important thing is that your function call is sandwiched between the addpath and rmpath commands. If you have functions of the same name in both folders, then you should sandwich it tighter i.e., a line before and a line after, so as to avoid conflicts.
Just add all those directories to the Matlab path with addpath like gnovice suggests. Then you'll be able to call the functions normally, and they'll be visible to which(), help(), depfun(), and the other Matlab meta-programming commands. You can put the addpath() calls in your startup.m file to have them automatically appear each time you start Matlab.
Changing the path with addpath/map1()/rmpath each time has some drawbacks.
It's a performance hit because you're adding path manipulation to each call.
Functions in different directories won't be able to see each other.
It'll be harder to write and debug functions because the path context in which they execute will change dynamically, and won't be the same as what you see when you're in the editor and the base workspace.
You need additional error handling code to make sure the path is properly restored if the called function errors out.
This won't work with the Matlab Compiler, if you want to deploy this code at some point.
And using run() or cd() yourself is ugly, because relative paths are going to have problems.
If you really want to separate the functions in the subdirectories so they can't "see" each other, you can make those directories namespaces by putting a "+" in front of their names, and then qualify the function calls with the namespace, like Map.map1().
Just to contribute to the path-altering debate...
One way to make it a bit "safer" is to write
% start of my code: create function handles
% to the functions I need:
try
cd Map
map1_func = #map1;
catch mexception
end
cd ..
This tries to preserve the current directory, and you get a handle to the function in a different directory.
Only thing is, this method won't work if map1 relies upon other functions in the Map directory.
Currently, running prove with TAP::Formatter::JUnit supports an environment variable PERL_TEST_HARNESS_DUMP_TAP that sets a path where a directory t/ will be created, and for each test file x, new files named x and x.junit.xml are created in the directory. I would like to be able to format the output filenames in a different way. Is there any way to do this?
A quick look at TAP::Formatter::JUnit::Session says "no" - there is no way to modify it without writing your own formatter, deriving off TAP::Formatter::JUnit and overriding its open_test method to point to your own session, which would, in turn, be derived off TAP::Formatter::JUnit::Session with its dump_junit_xml overridden to do what you want - but now you're modifying the entire dump (and thus don't need to rely on that environment variable if you prefer).
I guess all that derivation is a way, though probably not the way you thought/were hoping.
I have a program on a Windows XP computer on another continent. If I start it by double-clicking on an associated file, so that it runs the program according to the file-type association, it crashes at a certain point. If I start it by dragging an associated file to the program icon, it works fine. If I double-click on the icon and drag the associated file to the window, it works fine.
The guy on site assures me that he's triple-checked the file-type association, and it should be correct.
Assuming that the icon points to the same executable as the registry, what differences would there be in starting the program in these two different ways?
EDIT: In response to a comment, the machine I'm having problems on is running in Japanese, while my normal machine is US English.
One possible difference is the initial working directory: if you drag a file onto the executable, the initial working directory is set to the directory containing the executable, whereas if you double click the file, the initial working directory is set to some default value independent of where the file or executable is located.
If you want to get consistent behavior in all cases, you can use SetCurrentDirectory() to set the current working directory to whatever you want; I recommend the directory containing the executable, which can be found by calling GetModuleFileName(NULL, ...) and stripping off the executable name, or by examining argv[0] inside main().
When you double click the file, the program is run, and (usually) the name of the file that you double click, is passed in to the program as a command line argument.
When you are dragging onto the window, the program is already running.
The difference is obviously in the startup process that the program has. Is this software written in-house? Perhaps check how it handles starting up, and make sure that all appropriate code paths are still executed when there is a file in the command line arguments.
If you can't check the program code, or how it behaves at startup, about the only thing to check in the registry, and possibly change, is how the filename is passed in. Usually they are passed in inside talking marks, so that the path to the file can have spaces and not confuse the program. Something to try would be to make sure the association uses talking marks on the argument, or if it already does, try it without. Perhaps the program isn't handling the talking marks correctly.