System.TypeInitializationException: The type initializer for 'Alea.CUDA.IL.CIRCallInstructionBuilder' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Alea.IL, Version=2.1.2.3274, Culture=neutral, PublicKeyToken=ba52afc3c2e933d6' or one of its dependencies. The system cannot find the file specified.
The above is the relevant snippet. I am guessing I did not setup Alea correctly, but the troublesome thing is that everything else works for me perfectly. Only this piece of code below throws an exception.
let absoluteSumModule = (new DeviceReduceModule<float32>(GPUModuleTarget.Worker(worker), fun a b -> abs(a)+abs(b))).Create(hidden_layer_width*dtest_data.num_rows)
I am doing all my work in F# Scripting mode and here is how I set it up.
#I #"C:\F# Packages\packages\Alea.CUDA.2.1.2.3274\private"
#I #"C:\F# Packages\packages\Alea.CUDA.2.1.2.3274\lib\net40"
#I #"C:\F# Packages\packages\Alea.CUDA.IL.2.1.2.3274\lib\net40"
#I #"C:\F# Packages\packages\Alea.CUDA.Unbound.2.1.2.3274\lib\net40"
#r #"Alea.CUDA.Unbound.dll"
#r #"Alea.CUDA.IL.dll"
#r #"Alea.CUDA.dll"
#r #"Alea.CUDA.CT.Native.X86.B64.Windows.dll"
#r "System.Configuration.dll"
My own code, CuBlas, Unbound's random modules, Unbound's block reduce and scan, and the DeviceSumModuleF32 work for me. I tried pointing the Alea.CUDA.Settings.Instance.Resource.AssemblyPath and Alea.CUDA.Settings.Instance.Resource.Path at various library directories, but that does not seem to be doing anything at all. Not having it set at all for the past few weeks did not hinder me. I haven't touched the app.config file because I am not sure how to configure it and am not that comfortable editing config files by hand.
Any advice?
I guess you miss loading Alea.IL.dll. Alea.CUDA.Unbound depends on Alea.CUDA.IL, and Alea.CUDA.IL depends on Alea.CUDA AND Alea.IL. See here for more information.
In your fsx file, you can try add Alea.IL, and you don't need reference Alea.CUDA.CT.XXXX, just point the Resource.AssemblyPath to that private folder is enough.
Related
I want to format my C/C++ source code before every compilation.
I found no information how to do it in SCons.
Ideas I tried:
What I would need: a Builder that has the same files for source and target. Impossible in SCons because cyclic dependency. env.FormatCode(target='bla.c', source='bla.c')
Use env.AddPreAction(source, format_action) on the objects resulted in compilation. Partially works, but not incremental with variant dirs.
def StyleFormatCCode(env, source):
sys.path.append('somePath/clangStyleChecker'))
import styleChecker
def format_action(target, source, env):
for file in source:
styleChecker.main(['-f', '-i', str(file)])
return env.AddPreAction(source, format_action)
sources1 = env.Glob('*.cpp')
sources = env.Object(sources1)
env.StyleFormatCCode(sources)
The style formatter problem is the same as Modify a source file before compilation.
Any idea how to do it or locations where I can find something like this in SCons?
Firstly, don't do this in process.
If you do it in process you will NOT be able to parallel build any where near as efficiently.
Python has the GIL and so there's very limited multithreading if all the logic is in python.
Secondly, modifying the source file before each compile will cause a recompile the next time around. Since you'll be modifying the sources.
If you're okay with either or both of the above, then something similar to your method would work for you.. ;)
You can reach into the Object and SharedObject builders and add prepend an action to their list of actions. You will be reaching in the innards of SCons to proceed carefully.
Another option would be just to do this logic in plain python (no Builder()s involved) in your SConscript/SConstruct. That would prevent the rebuilds as the sources are scanned and checked for changes after all the SConscripts have been processed.
So, in Project AB I have FileA.fs and FileB.fs. FileB uses definitions from FileA, and both FileA and FileB use definitions from Project C (written in C#).
In FileA.FS, I have:
#if COMPILED
namespace ProjectAB
#else
#I "bin\debug"
#r "ProjectZ.dll"
#endif
...which works how it's supposed to -- I can run the whole file in F#-Interactive and it's great.
In FileB.fs, my header is:
#if COMPILED
module ProjectAB.ModuleB
#else
#load "FileA.fs"
#I "bin\debug"
#r "ProjectZ.dll"
#endif
But when I run this (from FileB), I get the error:
FileA.fs(6,1): error FS0222: Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'. Only the last source file of an application may omit such a declaration.
According to the fsi.exe reference, the #load directive "Reads a source file, compiles it, and runs it". But it seems like it must be doing so without the COMPILED directive defined, because it doesn't see the "namespace ProjectAB" declaration.
How can I set up my headers so that I can run either file in F#-interactive?
Edit Per latkin's answer below, I created a script as the last file in the project, _TestScript.fsx. I removed all the precompiler stuff from the other files and set this as the header of the .fsx file:
#if INTERACTIVE
#I "bin\debug"
#r "ProjectZ.dll"
#load "FileA.fs"
#load "FileB.fs"
#endif
When I run this in the interactive, it correctly loads ProjectZ, FileA, and FileB for me to access in the interactive window.
However, in _TestScript.fsx, I get squiggly red lines and no intellisense on any of the functions/types from the referenced files (including the "open" statements).
Is there something else I need to set up in the script file to make the intellisense work? (The answer might be pretty basic since I have not used .fsx files before.)
I don't think there is a way to do this smoothly. A few things to consider:
INTERACTIVE is always defined when you are being processed by fsi.exe, whether you are a .fsx, .fs, #load'ed, whatever. COMPILED is similarly always defined when you are being processed by fsc.exe. I can see how the quoted phrase from the docs maybe doesn't make this totally crystal clear.
You can only declare namespaces in fsi from a #load'ed file
So if you want your file to declare a namespace, and to work as the single file in interactive, then the namespace has to be #ifdef'ed out. But that also means the namespace will be #ifdef'ed out when the file is #load'ed...
You might be able to work around this by conditionally declaring it as a module, not a namespace. Or perhaps creating additional, more granular defines. It will be tricky.
Trying to get source files to work properly as part of a compiled library and simultaneously as single-file scripts is not easy, and I don't think the tooling was designed with this scenario in mind. More common is to have all of your library files behave purely as library files, then use dedicated standalone scripts which #loads the .fs files they need. This keeps the driving code and the library code separate, and things fit together more cleanly.
This is extremely strange, and I'm hoping someone will have some insights to make sense of this.
I have an F# 2.0 (Visual Studio 2010, targeting .Net 4.0) solution which works fine in the location where I originally created it, but if I try and copy it to a new folder (because I want to check it in to source control), I get some very odd errors when building. They tend to be along the lines of:
error FS0803: Invalid use of a type name and/or object constructor. If necessary use 'new' and apply the constructor to its arguments, e.g. 'new Type(args)'. Overloads are: None() : unit.
or
error FS0001: This expression was expected to have type obj option but here has type Some<'a>
These errors are only occurring for uses of the option type, a simple example of one such usage being:
let asOption e =
match e with
| null -> None
| _ -> Some(e)
Now, remember, this is a solution that compiles just fine in its original location. I've tried the obvious like Clean/Rebuild, deleting the obj and bin directories, restarting Visual Studion, and still, the same.
The reference DLLs are all the same in both cases, GAC'd DLLs are being referenced from the GAC, non-GAC'd dlls are copied and being referenced from the same relative path. Just for fun, I've even compared the output window text of the calls to Fsc.exe used to compile each solution to ensure the compiler is being called with the same arguments in both cases, and, naturally, it is.
Anyone have any idea of what may be causing this? Am I getting some strange limbo version of FSharp.Core.dll out of the GAC somehow? Am I just the most unlucky of the unlucky stiffs?
So the weird symptom had an equally weird cause.
It turns out one of the DLLs I was referencing (the ubiquitous "Core" junk-drawer dll every project has) must have some extension methods in place that are causing some issues with the type inference used by the compiler and visual studio.
When I remove the open MyProject.Core and replace any of the references to types I'm using with the fully qualified name, the strange errors magically go away.
So, at this point, two questions remain:
What kind of insane extension methods are in there that could be causing this
Why was the original solution/project unaffected by this? (I'm guessing this may be related to the order in which the references were passed into the call to Fsc.exe...but I'm not sure).
I may actually dig in enough to try and figure out the answer to #1. I'm not sure if it is exposing some sort of bug with the F# compiler (doubtful), or if my co-workers are just doing something unnatural with extension methods (highly likely)
UPDATE:
Looks like someone had some F# envy and created an Option<T> class in the Core project. Pretty much explains things. I've not experimented to see if the order of the includes on the Fsc.exe call make a different, but I have a feeling that is it.
References should almost never come from the GAC, they should come from Reference Assemblies. Post the fsc.exe command-line you are witnessing, perhaps it will shed more light. I am guessing the FSharp.Core reference is messed up somehow (perhaps related to the sigdata/optdata files that stand alongside its reference assembly?)
(Points for a very weird symptom, though!)
Assuming F# compiler is deterministic, there obviously must be some difference in how it is being invoked, perhaps in the environment variables. Have you tried running MSBuild from the command line? It usually helps with these kind of things.
One guess of what's going on is that F# infers different types for your code. Have you tried constraining it a bit to only have to deal with simple types? For example:
let asOption (e: obj) =
match e with
| null -> None
| _ -> Some(e)
Or else:
let asOption<'T> (x: 'T) : option<'T> =
if x :> obj = null then None else Some x
The later gets rid of the null constraint on the generic parameter.
First of - Hello and thank you for reading this,
I have one DLL which I do not have the source code but need to add some functionalities into it.
I made up another DLL implementing all these needed functionalities in C - using Visual Studio.
Now I need to insert the generated code from this new DLL into the target DLL (it has to be done at the file level {not at runtime}).
I am probably creating a new PE section on the target DLL and put there all the code/data/rdata from the dll I made up. The problem is that I need somehow to fix the IAT and the relocs relative to this new inserted code on the target DLL.
My question is:
What is the best way to do it?
It would be nice if Visual Studio came up with an option to build using only (mostly) relative addressing - This would save me a lot when dealing with the relocs.
I guess I could encapsulate all my vars and constants into a struct, hopefully MSVC would then only need to relocate the address of this "container" struct and use relative addressing to access its members. But don't know if this is a good idea.
I could even go further and get rid of the IAT by making a function pointer which would dynamically load the needed function module (kind of the Delay Load Module). And again, put this function pointer inside the "container" struct I said before.
The last option I have is to make it all by hand, manually editing the binary in hex... which I really didn`t want to do, because it would take some good time to do it for every single IAT entry and reloc entry. I have already written a PE file encryptor some time ago so I know most of the inner workings and know it can be done, just want to know your thoughts and maybe a tool already exists to help me out?
Any suggestions is highly appreciated!
Thanks again for your time for reading this!
Since you are asking for suggestions, take a look at the very good PORTABLE EXECUTABLE FILE FORMAT – A REVERSE ENGINEER VIEW PDF Document. The Section "Adding Code to a PE File" describes some techniques (and presents Tools) to add code to an existing PE image without having the code of the target image (your scenario) by manipulation the IAT table and Sections tables.
I am wondering what difference it makes to the debugger (Intellij IDEA + Scala plug-in) when I debug Scala code and not Java code. To my understanding, a debugger is tightly coupled with the language i.e. a Java debugger can not handle Scala code but apparently the JVM is the center of attention here meaning as long as it is byte-code, any debugger would do. right ?
IMPORTANT UPDATE: The problem was to give an example of how a byte-code debugger may be limiting for Scala. Assume a break point is reached and I don't want to go to the next line but I want the debugger to evaluate an Scala expression in the context of the application (e.g. I like to call an operator method from a singleton object). The debugger is stuck because it can not understand Scala. I have to do the transformation myself and input the resulting Java to the debugger.
The problem is that only "breakpoint stuff" could be handled in byte-code level. What if you want to put an expression under watch? Debugger has to understand Scala to evaluate the watched expression,right? This time I'm sure I'm right. Vengeance is mine, Saith the Lord ;-)
Short answer your assumptions are wrong.
The reason is the debugger does not care what language your debugging. It stops at breakpoints which in turn include the line of a particular source file. Note that the source file is merely text for you to read - the debugger never scans the source files. If you change the spot where source files are to another directory with a text file in the right directory w/ the right filename as a breakpoint that has been set, the debugger will happily show it when the breakpoint happens. Everytime you set a breakpoint your ide is telling the debugger hey scan this class for any byte code on this line and stop when you hit it. This of course does not work if your ide is attempting to compile the same text file into a class file - however it will work if you create fake text files as source for a jar file and do the source file mapping thing.
If one thinks about it, writing a simple template and compiling it while support debugging is not that difficult. Simply use asm to create all the print statements and tell asm this print statement is from the template file on this line. After that you can add more clever stuff while keeping things debuggable.