Swift - Import Source File by Path? - import

I've been playing around with using Swift as a scripting language, as described here. When executing script files from the terminal in this way, is there a way to include other Swift files by path (i.e. import /path/to/some/file.swift)? I'm aware of the import statement, but that doesn't seem to accept a file path. In Ruby I would use a require statement, but I don't know if there is a Swift equivalent to this.

import only works with modules. If you need to import a module which is located somewhere besides the normal import search path, you can add another directory to the search paths by passing the -I flag to the compiler:
-I <value> Add directory to the import search path
If you're looking at just a .swift file, you'll need to compile that into a module before you can import it from a separate module or the REPL.

Related

No intellisense import suggestions for a module

vscode doesn't give any Code Action import suggestions for a specific python module I install in the python environment (it's a module I created). I can manually add the import - works. I get import suggestions for all other modules I installed . I can also follow up code into the module (after I have the import, go to definition works). It seems it's only missing as a source of import suggestions.
Is the module missing something?

Run simple swift script from terminal with imported library

I would like to migrate some python code to swift which includes numpy and found a library called Matft.
I'm doing this on a VM and Xcode is very slow, so it would be great to avoid that and use the terminal (ideally run the .swift from a shared folder), but than I got the error: "no such module".
I found that I could pass -I flag and specify a path for the lib, but does not working for me.
Can someone give an easy explanation how to import external library in such situation?

Development of the Coq library. (Add LoadPath solution is not good enough.)

I am adding some theorems to the library
https://github.com/coq-contribs/zfc
But there is a not very good thing.
While I developing the code in the CoqIDE I have to add
Add LoadPath "/home/user/0my/GITHUB/".
and to rename all
Require Import Axioms.
to
Require Import ZFC.Axioms.
. All files of the library are in
/home/user/0my/GITHUB/ZFC
and the name of the last folder matters.
But when I want to run the "make" command I have to rename everything back.
The file "Make" contains the names of files and the prefix. Deleting the first line didn't solve the problem.
I don't think that it is the best practice of the developing with the CoqIDE, so what shall I do instead?
Edited1:
I have "run_coqide.sh" which consist of
#!/usr/bin/env bash
COQPATH=/home/user/0my/GITHUB/
/home/user/opam-coq.8.8.1/4.02.3/bin/coqide
"From ZFC Require Import Sets. " raises error "Cannot find a physical path".
Edited2:
I have find out that this is a working script:
#!/usr/bin/env bash
export COQPATH=/home/user/0my/GITHUB/
/home/user/opam-coq.8.8.1/4.02.3/bin/coqide
Is it normal run or a hack?
Rename Make to _CoqProject, this is the name currently recognized by CoqIDE where it will look for project configuration (in particular the -R . ZFC option to make the Coq files in the directory visible to CoqIDE).
It is also possible to change the name CoqIDE is looking for to Make, but _CoqProject seems to really be the new standard.
Note that the -R . ZFC option, that allows you to import libraries unqualified, corresponds to the command Add Rec LoadPath "/.../ZFC" as ZFC.
I would also suggest to actually switch the whole codebase to explicit qualification ZFC.Axiom, that you've been doing locally by hand, making it less error prone to work with different projects at the same time. I'm not sure why it was necessary to rename things back to run make, my understanding is that it shouldn't be necessary.
See also the Coq reference manual, about the coq_makefile utility.

import/require/use for perl modules

I have 2 files perl files which have dependency on one another.
The 1st file, A is a .pl file which multiple package/modules declared inside.
The 2nd file, B will try to access one of the many packages declared in file A. How can that be done?
You may be familiar with how Java or a similar language finds an import com.example.AppName namespace by looking for the com/example/AppName.java file in the classpath. When you ask Perl for use HTML::Template, it likewise looks for HTML/Template.pm in the directories listed in #INC.
The difference is that a Perl file can have multiple packages. When you say use HTML::Template, you'll be pulling in all packages listed in HTML/Template.pm (use automatically translates the :: into the right directory separator for your system, and adds the .pm). If there happens to be a HTML::Template::Extension package in that file, then you can use that package without having to explicitly use it. It's already loaded the complete file, and that's good enough.
If you know the exact file name relative where you'll be running the script, the easiest way to grab it is:
require 'path/to/file.pl';
You need to declare a module in each pl file that is using a function of the module.

How can I import a .PYD module in IronPython?

I'm trying to use a python package from IronPython.
Everything works fine if I import regular python modules.
But when I try to do the following:
import win32ui
I get:
No module named win32ui
I've hunted through the code in IronPython.Runtime.Importer and there's no mention of .pyd
Anyone know a way around this?
You can check out IronClad which is working to provide this support. It may or may not work w/ your PYD of choice.
A .pyd file is a DLL. So unless IronPython (which is written in .net) can correctly load C DLLs written for CPython, you might be out of luck.
Update
In fact, according to the IronPython FAQ, you are unfortunately unable to import .pyd files:
Q: How do I build and call into PYD libraries?
A: IronPython does not support using PYDs built for CPython since they
leverage implementation details of CPython. You can get a similar
effect for new "PYD"s you would like to implement by writing them in C#
or VB and building a DLL for .NET.