I am learning "Atomic Kotlin" course by Bryce Eckel and Svetlana Isakova. In topic Lists there is a phrase:
Lists are part of the standard Kotlin package so they don’t require an import.
I've searched Internet but I cannot find the deterministic explanation of what is "standard Kotlin package".
List is declared in kotlin.collections that is in Kotlin Standard Library and for some reason I do not need to import it directly while sin() function is a part of kotlin.math that in turn also a part of Kotlin Standard Library BUT I have to import kotlin.math explicitly.
Can you help me to figure out where is the definition of "standard Kotlin package"?
Packages that are imported by default are:
kotlin.*
kotlin.annotation.*
kotlin.collections.*
kotlin.comparisons.*
kotlin.io.*
kotlin.ranges.*
kotlin.sequences.*
kotlin.text.*
They are listed here: https://kotlinlang.org/docs/packages.html#default-imports
Related
Do you know a c++ library where the Digamma Function (http://en.wikipedia.org/wiki/Digamma_function) is implemented with complex arguments?
I did not find a library, but google found this for me:
GammaFunctions.c++
However I did not check the validity of this code.
Try one of these:
GSL - GNU Scientific Library contains gsl_sf_complex_psi_e.
http://www.ensta-paristech.fr/~lunevill/doc_melina++_v039/src/special_functions/GammaFunctions.c++.html
http://www.mathworks.com/matlabcentral/fileexchange/978-special-functions-math-library/content/psi.m - You'll need to convert this to C++.
http://www.netlib.no/netlib/slatec/fnlib/cpsi.f - You'll need to convert this to C++.
I'm in need of a bignum library for representing large integers. What options do I have with the D programming language? Are there, for instance, GMP bindings?
Update:
I'm trying to use the inbuilt BigInt as described below but it appears it's not available with the GDC.
import std.bigint;
import std.stdio;
void main()
{
BigInt n = "123";
writefln(n);
}
When I try to compile this code with gdc main.d I'm told it can't find bigint.d. Does gdc only implement some of the library or am I doing something wrong?
If what you're looking for is a big integer type, then there's BigInt in the standard library. On the other hand, if you're specifically looking to use GMP, then all you have to do is have extern(C) declarations for the appropriate types and functions in GMP that you need, and you can call them directly from D. Check out out this page for more details on how to use C code in D.
Paul Anderson is working on a BigFloat abstraction for the standard library.
Is there any way to determine whether the Accelerate.framework is available at runtime from straight C or C++ files?
The examples I've found for conditional coding all seem to require Objective-C introspection (e.g., respondsToSelector) and/or Objective-C apis (e.g., UIDevice's systemVersion member)
The usual trick for this is that you weak link against the framework and then check a function pointer exported by that framework for the actual availability. If the framework failed to link because it is not available then the function will be NULL.
So for Accelerate.framework you would do something like this:
#include <Accelerate/Accelerate.h>
if (cblas_sdsdot) {
NSLog(#"Yay we got Accelerate.framework");
} else {
NSLog(#"Oh no, no Accelerate.framework");
}
This is described in TN2064 - Ensuring Binary Backwards Compatibility
I have this old C++ COM component. I took the latest code base, built it and found that one of the properties has become lower case. For example, in the pre-compiled dll i have a property "Type", but when building from source it's called "type". The idl shows that the property is called "Type". So what could possibly be happening here?
COM is case-insensitive, so there is only one entry in the library's symbol table for the symbol "type". The version which is put into the symbol table is the first one that the compiler encounters.
Microsoft's advice on the matter is simply:
Make sure that the same name is not already present in the IDL file when introducing a new identifier.
You should stick to either Type or type in the IDL, for consistent results.
You discovered a quirk in the OS stock implementation of ICreateTypeLib, used by practically all tool chains on Windows that can create a type library. It uses a rather crude way to deal with possible problems caused by languages that are not case-sensitive, VB/A being a prominent example.
At issue is the definition of an identifier with one casing, being referenced elsewhere in the type library with another casing. Not a problem at all in, say, VB, big problem when the client programmer uses a case-sensitive language like C# or C++.
The "fix" it uses is to force the casing to be consistent everywhere in the library. Unfortunately it is not very sophisticated about it. Best example is a method declaration earlier in the type library that takes an argument named type. Any identifier named Type in the rest of the type library will now get case-converted to type.
Repairing this problem is easy enough, just change the name of the identifier so it no longer matches. You'll have to find it, not so easy, best to use Oleview.exe, File > View Typelib command. Copy/paste the decompiled IDL into a text editor and use its Search command.
I had the same problem almost 10 years after this question was asked and I would like to share my solution (thanks for the help in understanding the problem).
First I would like to say that I had several names whose casing was changed by tlbimp and changing all the instances of these names to my expected casing in the IDL fixed all but one. I'm assuming that that name (Text) came from a different IDL I imported. I was also not happy with the solution of changing the names of parameters and the like since in the future someone else may change them.
The solution I found was to introduce a dummy interface with the casing I wanted. I did this before all other imports and then referenced it in the library section of the IDL. Note that both these details are required. If you don't put it in the library section it's ignored and if I defined it at the beginning of the library section after the imports it's too late.
import "oaidl.idl";
import "ocidl.idl";
[
uuid(4EA92D5A-BF84-46C4-AA38-0F7DEADC69B),
helpstring("Ensure that names used in interop have correct casing")
]
interface IAmHack : IUnknown
{
HRESULT Space();
HRESULT The();
HRESULT Final();
HRESULT Frontier();
};
// ...
library MyLib
{
interface IAmHack;
importlib("stdole2.tlb");
I have a program in C++ that uses the cryptopp library to decrypt/encrypt messages.
It offers two interface methods encrypt & decrypt that receive a string and operate on it through cryptopp methods.
Is there some way to use both methods in Python without manually wrapping all the cryptopp & files included?
Example:
import cppEncryptDecrypt
string foo="testing"
result = encrypt(foo)
print "Encrypted string:",result
If you can make a DLL from that C++ code, exposing those two methods (ideally as "extern C", that makes all interfacing tasks so much simpler), ctypes can be the answer, not requiring any third party tool or extension. Otherwise, it's your choice between cython, good old SWIG, SIP, Boost, ... -- many, many such 3rd party tools will let your Python code call those two C++ entry points without any need for wrapping anything else but them.
As Alex suggested you can make a dll, export the function you want to access from python and use ctypes(http://docs.python.org/library/ctypes.html) module to access e.g.
>>> libc = cdll.LoadLibrary("libc.so.6")
>>> printf = libc.printf
>>> printf("Hello, %s\n", "World!")
Hello, World
or there is alternate simpler approach, which many people do not consider but is equally useful in many cases i.e. directly call the program from command line. You said you have already working program, so I assume it does both encrypt/decrypt from commandline? if yes why don't you just call the program from os.system, or subprocess module, instead of delving into code and changing it and maintaining it.
I would say go the second way unless it can't fulfill your requirements.