I have successfully compiled my .erl files and now the .beam files are lying down in my working directory. However, for some reason I need to access those files from another directory... more specifically from the parent directory. The hierarchy is : ...\wkdir\ebin\beam_example.beam, and I wish to access the beam_example.beam from wkdir. Is it possible to do this?
Also, I'm using escript, so a valid import may be very likely to solve this problem, though I just can't figure that out.
You can modify the search path for the .beam with the code:add_path* methods. If the code server is in interactive mode (it should be), that'd be enough for the VM to locate the module files and load them lazily.
Related
I have have library with an artifact: src/lib/prelude.kind that I'd like to access. However, when I call the library code from a different project (which has the library set up as a dependency), the file src/lib/prelude.kind doesn't exist.
I can solve this problem by hardcoding the file location as _build/default/lib/kind/src/prelude.kind instead, but I'd rather not hardcode the Rebar3 default profile path.
Is there a way to refer to _build/default/lib or whatever the current profile location is from Erlang in a Rebar3 project?
You should use code:lib_dir/2
I'd make sure that the file is available with rebar3's artifacts (and move it out of the src subdir)
I have studied https://blog.bazel.build/2017/02/27/protocol-buffers.html . The project I want to hack on is written in Go. At the moment, if I run the build command I can see the compiled binary but I don't see the *.pb.go files anywhere. I want to keep the generated *.pb.go files in the same folder where *.proto files are so that my IDE (Intellij Goland) can find and index them.
Can you please help me how to get this working? If you can show me how to do that for the github.com/cgrushko/proto_library project, I should be able to try that in my particular project.
Bazel will not output generated files (such as .pb.go) into the source tree. They go into the output directories (bazel-out/<config> or bazel-genfiles/<config>). Temporary solution might be to add those as source roots to goland. The real solution is to use https://ij.bazel.build/. It has some Go support, and the team is actively working on improving it.
I want to make changes to the xmldom and XMLDoc files. I tried to, but I don't know how to test those changes because the program does not seem to be running the code in those files. I tried using a ShowMessage to see if that code was being accessed but it never showed up. Even if I rename the directory the files are in, the program still compiles fine as if it is not actively reading the files at run time but instead has the information stored elsewhere.
How can I change these namespaces and then make sure that the changes are being included in my next compile?
Update
Well i'm looking for an answer in general.. Because I have had this problem in multiple situations.. But for specifics Changing XML node attribute value gives "Namespace error" (here the answer talks about changing the 'AdomCore_4_3') I want to be able to change it and have the change show up when I compile.
If you've removed the compiled DCU files from your environment, and your changes still aren't being compiled into your project, then you either aren't really using those units at all, or you have run-time packages enabled.
With run-time packages, the compiled code is accessed from the BPL file, not the DCUs. You're not allowed to distribute modified BPL files, so if you're going to modify the Delphi-provided source code, you need to make sure you're not linking the package with the XML units to your project. You can control that in your project's linker options.
As long as you are not making changes in the interface section of the units, only the implementation section, then you can disable use of Runtime Packages in your Project Options and then add the modified source files directly to your project. The compiler will compile them into new .DCU files and use them instead of the default .DCU files.
I have (quite a bit of) static files that I need to deploy with my application that is built on top of a legacy .NET library. These include several XML and config files, and a read-only database in the 10's of Megabytes.
Most forums I have seen indicate that the best way to accomplish this is to reference the needed files in a project, and set them to Content and "Copy to Output Directory".
I have two issues/questions dealing with this:
Adding these files, and setting them to "Content" seems to not only copy the files over, but embed them into the .dll as well. In other words, I have 40 MB worth of files, and a 40MB dll (this project's only goal is to import these files, there is no substantial code).
How can I prevent this extremely large dll from being made?
Is there an alternative way to get files into the App bundle? I would love to use a custom build command, and although I can copy files into the target directory ${AppDirectory}, but this does not result in these files ending up in the app bundle. Is this approach possible?
Any help is appreciated in advance.
You need to include your files from the main .exe project. You do this by using MonoDevelop's Build Action to Content on each file. They should be copied to the .app without being included inside an .dll (or the .exe).
An alternative (for development) is to use iTunes sharing to copy once your files to your device. This allows you much faster deployment times while developing.
Of course you can't submit such build to the app store (unless the files are not required to make the application work, unlikely). What I do (for my nearly 80MB read-only database) is to use this hack (loading from /Documents) inside #if DEBUG. The release build load the files from the normal location.
I have not automated the process (still debugging the app ;-) but it should be possible to script this so modifying the project options (for each file) is not required when switching from Debug and Release builds.
I'm programming with a deployment target of iOS5.
Is there some directory, which i can put in some static files in at compile time and write to that same directory a runtime?
IMHO the home directory is not writable at runtime. (sandboxing?) At the moment for my runtime writes i use NSTemporaryDirectory(), which is not accessible at compile time..
Help is much appreciated.
The answer is no. You put files in your bundle, and later you can copy them to another folder. I believe (but have not tested) that you can also create a link to them if they are large and you don't want to create two files. If you do this you need to think about what happens when you update the app.