I have the most basic of question that should be easy but proving to be a pain. I have a f# FSX file and would like to include Deedle.
I ran the install package and it put it in C:\Users\myName.nuget\packages
Under this directory, the deedle.fsx is in deedle\2.0.4
Now, some of the documentation I have read instructs to do this at the top of the FSX file:
"#I "../../packages/Deedle"
"#load "Deedle.fsx"
Issue#1. That relative path for #I does not work, so I use an explicit path. That resolves that issue.
Issue#2. I cannot get the load statement to find the deedle.fsx file. It appends a bin/net45 to the path.
Therefore, the question is is there a trick I am missing in using this library and how I am referencing it for use?
Thx,
Marc.
try this in your fsx file
#r #"C:\Users\myName\.nuget\packages\deedle\2.0.4\lib\net45\deedle.dll"
change myName to your username.
Related
In FSI, is it possible to run something like
#I #"%APPDATA%/npm/node_modules/blabla/bin/"
instead of
#I #"C:/Users/username/AppData/Roaming/npm/node_modules/blabla/bin/"
Any other options to make it not sensitive to username?
Not likely you can use environment variables in #I FSI directives.
However you may make your package installation agnostic of user name by using the trick with __SOURCE_DIRECTORY__ built-in identifier similar to one I've described in this SO answer:
create a file anchorfsi.fsx with the single line of code
#I __SOURCE_DIRECTORY__
and put it into the directory %APPDATA% points to
add to the command line starting your FSI the term
--load:%APPDATA%\anchorfsi.fsx
Now you can use relative paths in your #r directives.
Just for illustration I put into directory associated with my user profile a folder testlib containing FSharp.Data.dll. The snip below shows how it gets referenced from FSI using the outlined above technique:
I need to include some head files from Erlang/OTP module, is there any practical method other than using absolute path like
-include("/usr/lib64/erlang/lib/snmp-4.25/include/snmp_types.hrl").
Yes, ref the Question: Erlang: what is the difference between "include_lib" and "include"?
you should use -include_lib(XXX) instead of -include(XXX) if include from its system library.
I think you can use:
-include_lib("snmp/include/snmp_types.hrl").
include_lib is similar to include, but should not point out an
absolute file. Instead, the first path component (possibly after
variable substitution) is assumed to be the name of an application.
Example:
-include_lib("kernel/include/file.hrl").
The code server uses code:lib_dir(kernel) to find the directory of the current (latest) version of Kernel, and then the subdirectory
include is searched for the file file.hrl.
When in a separate Fsharp project in a SomeLib.fs file the following code is compiled:
namespace SomeNameSpace
type SomeType =
member this.SomeMember = "Some member"
and you want to reference and use this type in a script file like:
#I #"c:/pathToDll/"
#r "SomeLib.dll"
This is not possible, although the path to the dll is correct and I checked everything. Also when the SomeLib.fs file is in the same project and referenced by #load, you still cannot open the namespace.
I know you can put the type in a module, but I cannot do this as the type has te be used as a Wcf service type.
After a lot of experimental work and surprisingly little info on the internet or in F# books I found out the following:
// Cannot use a relative path
//#I #"bin\Debug"
// Have to use a absolute path
#I #"C:\Development\FSharpNameSpaceTest\SomeCSharpLib\bin\Debug"
// But I can reference a Csharp dll lib
#r "SomeCSharpLib.dll"
// I cannot add a reference to an external F# library dll
// #I #"C:\Development\FSharpNameSpaceTest\NameSpace\bin\Debug"
// #r "NameSpace.dll"
// If I directly load the external fs file, it works"
#load #"C:\Development\FSharpNameSpaceTest\NameSpace\SomeNameSpace.fs"
#load "Library1.fs"
// Namespaces in both the local and the external fs files can only be openend if every single file is loaded instead of referencing the dll.
// Referencing a C# dll is no problem
open FSharpNameSpaceTest
open SomeCSharpLib
open NameSpace
I do not know if this is the most optimal approach but it works. What I will do is, I will create a fsx file for every project that loads the individual fs files in that project and then I will load that fsx file in the fsx file that references the project.
I still find this all very confusing and counterintuitive. But that might be my limited knowledge of the innerworks of F#
Edit: And the right and complete answer is, I didn't implement a default constructor. Still, if you do not wan't to do this, the above approach is an alternative. Thanks to Marc Sigrit.
If on Windows, the slashes in the import directive should be replaced by backslashes.
I want to let perl use the DBI module in my own path(suppose, /home/users/zdd/perl5/lib/DBI), but the sysem also has a DBI module which is /usr/lib/perl5/lib/DBI.
when I write the following code in my script, perl use the system path be default, how to force it use the one under my path?
use lib './perl5/lib/DBI';
use DBI;
sub test {
....
}
/usr/lib/perl5/lib/DBI was added to the PATH environment variable in my bash profile, it was used by many scripts, so I can't disable it.
The file for the main DBI module is in ./perl5/lib. So your path is not pointing to it.
The DBI folder contains sub-modules of DBI, e.g. DBI::Foo (the :: in module names is a representation of your module directory structure).
Try using ./perl5/lib as your library instead.
Also, using a relative path will fail if the current directory is not what you think it is. If you are in doubt, have your script call cwd to see what the current directory is.
For debugging purposes, it may be helpful to use:
no lib '[main Perl module library path here]';
That way you can be sure you are only using your custom module path. Any failure to find a module will cause an error, rather than silently using the system version.
Update: For more information, see Perldoc on use lib. Perl will use the library that you have specified first. If it does not, that indicates it is not actually finding the module in the location you have given.
In addition to what dan1111 suggested, I would also recommend you print out #INC (just before your use DBI statement) and dump %INC (just after your use DBI statement) to see what your script is doing. That may help you debug the issue.
How do you solve the error message that looks like this?
`Binding session to 'C:\Program Files (x86)\NLog\.NET Framework 4.0\NLog.dll'...
error FS0193: API restriction: The assembly
'file:///C:\Program Files (x86)\NLog\.NET Framework 4.0\NLog.dll' has
already loaded from a different location. It cannot be loaded from a
new location within the same appdomain.
Code that triggers it, might look like this:
#r #"..\packages\NLog.2.0.0.2000\lib\net20\NLog.dll"
NLog.Config.SimpleConfigurator.ConfigureForConsoleLogging()
It seems that FSI won't load from the given DLL other than by name, so this would sort the problem out:
#I #"..\packages\NLog.2.0.0.2000\lib\net20"
#r #"NLog.dll"
NLog.Config.SimpleConfigurator.ConfigureForConsoleLogging()
#I means to add that folder to the load-path
#r means to reference by dll-path; focusing on name. This means that FSI will use the file name first, looking in the system-wide search path and only then try to use the string after #r as a directory-relative hint.
So by doing it this way, you make the NLog load from your specified directory rather than a system-wide one.