I have little to no experience with C# but I'm attempting to import a C# class into a python script for a project I'm working on but I constantly run into a pylint(import-error).
Originally, I thought that the issue was due to compiling .Net Core instead of .Net Framework as pointed at in this post; however, I'm still running into the same import error after compiling with .Net Framework 4.7.2.
The C# class I am trying to import is the same as the aforementioned post (built under the ClassLibrary(.Net Standard) type):
TestClassLibrary.cs
using System;
namespace TestClassLibrary
{
public class MyClass
{
public string function()
{
return "Hello World!";
}
}
}
Python script that I'm trying to import the C# class into:
import sys
import clr
sys.path.append(r"<Ablsloute Path to \bin>\Debug\netstandard2.0")
clr.AddReference(r"TestClassLibrary")
from TestClassLibrary import MyClass
To provide more context:
I'm using Python 3.8.1 with PythonNet 2.5.1
The C# solution was built successfully and the .dll file is created (using VS 2019)
I noticed some responses to similar questions suggested that the directory should be added to the python path but I don't think that is the issue I'm running into. As a sanity check, I created a python file in the same directory as the .dll file which contained a class/function that I was able to successfully call in my script.
I do not think Python.NET probes Python's sys.path when searching for C# assemblies. Instead, .NET logic is used. On Windows you can simply add the path to DLL directory to PATH environment variable.
Related
After asking how to use PathCchCanonicalizeEx with C++Builder 10.2, I was told to create missing import libraries using the tools IMPLIB or MKEXP. I've tested both apps and they are creating lib files based on KernelBase.dll of my Windows 10. Though, both file contents look different, they start with different headers, are differently large overall etc. MKEXP documents to Creates an import archive from an input file, but doesn't seem to explain what that actually means.
So, when to use which of the both tools? What is the difference in purpose, how they work, possibly what they do support, etc?
IMPLIB is for generating an import lib for a 32bit DLL.
MKEXP is for generating an import lib for a 64bit DLL.
Effective dart says
"DON’T import libraries that are inside the src directory of another package."
reason being it breaks abstraction and could potentially break your app if the library was to change its underlying implementation.
They do not provide an alternative or a solution.
Im currently working on a dart package that my app depends on.
What would be the correct way to import the models or classes from it instead of importing it directly from package src folder?
As previously mentioned in the comments, you can define which classes you can expose from your package. You're correct that it's recommended to avoid exposing more API than intended - it's also mentioned in the docs. To do this, you can define the exposed classes:
export 'src/your_file.dart' show ExposedClass hide HiddenClass;
I'm building a board game from ES6 modules using Electron 2 (for Chromium 61+) and the esm shim on the server side of things. This is the first time I've written isomorphic JavaScript, let alone ES6 modules; I intend to be able to run game logic on the client in single-player mode, and on the server in networked play mode. So far so good, I'm happy to report! And it's satisfying to not rely on any heavy transpilers.
Now, though, I have a problem: I intend to use types from Immutable JS on the client as well as the server, and I only know how to import them into the server code. Until now, all the import statements in the isomorphic code referred to other JS modules in the app, not to dependencies from npm. A module like the one below causes an "Uncaught TypeError: Failed to resolve module specifier 'immutable'" runtime error in the client when the app loads:
import Immutable from "immutable";
Immutable.List.of([]);
export { foo: {} };
In fact, I'm virtually certain that the import statement is failing because Chromium can't resolve "immutable" to a JS file. But how am I supposed to go about resolving it? And is there a way to resolve it that would work for any node module that is written to be isomorphic?
TL;DR - You can't without help of bundler like webpack as long as you're using npm modules.
Most of node.js package ecosystem is not ready for native module yet. About 99% of published package in npm currently using node.js's CommonJS module system, while there are very few module written to support esm (ES module syntax as well).
esm shim is intended to help latter - if module's written in esm and to be imported in current node.js version doesn't support it helps to resolve those modules. Opposite case doesn't work. Chromium can import your code directly which is written in native syntax, then try to resolve dependency module you specified and failed to resolve as 1. it doesn't know where to resolve (as it doesn't follow node.js's module resolution rules) 2. when it's available to resolve, actual import will fail cause module'll be cjs export instead of native.
Get back to TL;DR above - if the intention is achieving isomorphic code to run on both processes, use bundler accordingly.
My research team wrote a script for loading some data from edn files into a Titan database. We are now attempting to migrate our work to a Datastax Enterprise Graph database. When we use :load on gremlin-server the script gets through the import statements but fails as soon as it hits any instance of a class from one of the imported libraries. For instance we import
import static us.bpsm.edn.parser.Parsers.defaultConfiguration;
import us.bpsm.edn.*;
import us.bpsm.edn.parser.*;
import us.bpsm.edn.printer.*;
and after the import we call
parser = Parsers.newParser(defaultConfiguration())
but gremlin returns "No such property: Parsers for class: Script2"
When running the commands one at a time we run into the same issue. Our initial thoughts are that we need to add the libraries to the right class path, but we have tried a few spots with little avail. When we switch from remote to local gremlin we are able to load the script, but don't have access to the graphs in system.
Any thoughts?
MFin, you're on the right track, essentially you will want to add the libraries to the class path on each of the nodes as well as locally.
My goal is to use the hosebird client provided by Twitter to stream tweets in my Grails project.
I'm really not sure how I will approach this, but I first tried including it in the dependencies in my BuildConfig.groovy like this:
dependencies {
compile 'com.twitter:hbc-core:2.2.0'
}
And then, when I tried to mimic the example code, FilterStreamExample.java, in my TwitterService.groovy, GGTS (the IDE) just shows me errors as I write these lines of code:
import com.google.common.collect.Lists
import com.twitter.hbc.ClientBuilder
import com.twitter.hbc.core.Client
import com.twitter.hbc.core.Constants
import com.twitter.hbc.core.endpoint.StatusesFilterEndpoint
import com.twitter.hbc.core.processor.StringDelimitedProcessor
import com.twitter.hbc.httpclient.auth.Authentication
import com.twitter.hbc.httpclient.auth.OAuth1
Obviously, this makes me unable to run the code because of the compile time error. It just tells that the error is something "Groovy was unable to resolve".
Can you tell what am I missing?
Is it just a groovy syntax error that I'm not noticing? I'm new to Groovy so please bear with me.
OR
Is the problem here is in the inclusion of the library in the dependencies?
My first aim is to be able to use the library this way as I have told it above (the BuildConfig way) before trying to make jars and put it in the src/java. Who knows, the compile time error will appear too. I just want to know if the current obstacle in the approach I did is easy to fix.
GGTS and STS don't parse BuildConfig.groovy - they get all classpath information from Grails. When you update BuildConfig.groovy with a new plugin or jar dependency, right-click on the project node in the tree on the left and select Grails Tools | Refresh Dependencies and GGTS will rebuild its classpath based on the current state of the app.