I making a program to draw some vector graphics on top of a GTK program written with Haskell.
I upgraded my program to the gi-gtk library in replacement of Gtk2Hs to benefit of Gtk3 and when I see tutorial/example about drawing in Gtk windows with cairo and/or diagram, both gi-cairo and cairo (from Gtk2Hs) are needed at the same time.
For an example I can see :
import GI.Gtk
import qualified GI.Cairo (Context(..))
import qualified Graphics.Rendering.Cairo as Cairo
import qualified Graphics.Rendering.Cairo.Internal as Cairo (Render(runRender))
import qualified Graphics.Rendering.Cairo.Types as Cairo (Cairo(Cairo))
and I don't understand why GI.Cairo (gi-cairo) and Graphics.Rendering.Cairo (cairo) must be imported at the same time.
Does GI.Cairo aim to replace Graphics.Rendering.Cairo or to complete it ?
Is Graphics.Rendering.Cairo still updated or is it a good idea to use another library ?
Any information/explanations about these two libraries would be helpful
TL;DR: treat anything based on GTK2HS as deprecated. Use things with the gi- prefix instead.
Originally there were the GTK2HS libraries, which were a manually written binding to GTK (I think, not sure about the details).
Part of this effort was a binding to the Cairo library. The Cairo functions all take a Cairo context object as an argument, which is used to carry state like the current colour and line style. The Haskell binding wraps this up using a Reader monad inside the Render newtype so you don't have to worry about the context object.
However maintaining this was slow and mandraulic, and there was an obvious better way: GTK has built-in support for other language bindings provided by metadata embedded in the source code. So it is perfectly possible to generate all the GTK bindings automatically, and also to extend this to other libraries which use the GTK metadata system. This is what gi-gtk and its relatives do.
Unfortunately Cairo doesn't work like that. It doesn't include the GTK metadata for the actual drawing API, so the gi-cairo interface is no use for anything.
For some time the only way around this was a manual bodge to bridge the gap between the gi-gtk family and the GTK2HS Cairo library, but no longer. Now there is a complete solution:
The gi-cairo-render library, which is essentially the same as the old GTK2HS library but using the gi-cairo version of the context object.
The associated gi-cairo-connector library which lets you switch between functions that require an explicit Cairo context object and functions that work in the Render monad.
You most often need an explicit Cairo context for drawing text using Pango. The Pango library has its own Context object (confusingly, both types are called Context and you have to import them qualified to disambiguate). You get the Pango context from a Cairo context using createContext, and to do this in the middle of a Render action you have to extract the current context from the Render monad using one of the Connector functions.
The code you have quoted is using the old manual bodge; the Render and runRender internal functions are used get at the Cairo context in the GTK2HS version of the Cairo binding. If you look at the code that calls these functions you will probably see it doing something unsafe with pointers to coerce between the GI.Cairo.Context type and Graphics.Rendering.Cairo.Types.Cairo context type, which both point to the same thing under the hood.
As stated in the title. There is a codebase, where I have seen the following syntax
import "cryptonite" Crypto.Hash
(Context, Digest, SHA256, hash, hashFinalize, hashInit,
hashUpdate)
This syntax doesn't seem to be mentioned on haskell wiki on imports.
What does the "cryptonite" string do here?
Where does this syntax come from?
Is is part of Haskell2010 and if it is so where in the language report is it mentioned?
This is extra syntax that is supported when using the PackageImports extension:
With the PackageImports extension, GHC allows import declarations to
be qualified by the package name that the module is intended to be
imported from. For example:
import "network" Network.Socket
would import the module Network.Socket
from the package network (any version). This may be used to
disambiguate an import when the same module is available from multiple
packages, or is present in both the current package being built and an
external package.
The special package name this can be used to refer to the current
package being built.
It occasionally happens that two packages export a module with the same name. For example both hashmap and unordered-containers export Data.HashSet. If both packages are installed, we want to disambiguate between the different packages. With this type of import, the author thus specifies that the Crypto.Hash module of the cryptonite needs to be used.
This is to to the best of my knowledge not standard Haskell (in the sense that other Haskell compilers do not have to support this, it seems not specified in the import statement section of the Haskell 2010 report), but a Glasgow Haskell compiler extension. Of course other compilers can support this as well, but a compiler without this extension, can still rightfully call itself a "Haskell compiler". In order to activate this extension, you need to compile with the -XPackageImports extension:
ghc -XPackageImports main.hs
This is a dynamic flag, and thus can be specified in the "pragma" of a Haskell source file as well.
C++Builder's 32-bit compiler, bcc32, by default creates shared libraries using the cdecl calling convention, prefixing exported functions with an underscore,
e.g. '_functionName'. Visual studio, on the other hand, don't prefix exported functions.
Python, when importing a pyd module, expects a function named PyInitialize_modulename. Since bcc32 prefix this function with an underscore, rendering it to be _PyInitialize_modulename, Python will not be able to import a bcc32 created module.
Using CMake, does anyone know how to add a module definition file, .def, to alias the prefixed function, to an 'unprefixed' one, when compiling/creating the pyd module?
Update. In response to Mr. Lebeau's answer below (as a comment);
This question is not about CTypes, but SWIG. CTypes allows for a simple way to wrap a C/C++ DLL, but mainly deals with C structures and POD data.
Swig, on the other hand, allows a client to get object oriented objects in Python, analogous to the ones exported from a C++ DLL. Swig can do this as it process C++ headers.
Swig does create a C++ file that is compiled into a .pyd file (in essence a DLL as noted). The first exported function that Python looks for when trying to load it as a module, is Pyinit_MyModule (Python 3). When using C++ Builder, this function is exported as _Pyinit_MyModule, as mentioned. Problem is that it is Swig that exports this function, and I can't as a client of Swig change the calling convention (afaik) for this function.
I believe my initial belief that Python needed __stdcall for this functions is wrong, as VS by default is using cdecl, but without adding the '_', and it that works fine.
However, setting the compiler flag to suppress underscores don't work either, as then some of the functions in the Python import libraries are rendered invisible, and become unresolved externals. So perhaps this problem is more complex than it may first look. But I guess it has nothing todo with calling conventions.
cdecl is simply the typical default calling convention that every C++ compiler uses. If you want to use stdcall instead, you can certainly do that (makes sense why Python would expect stdcall since that is what the Win32 API uses).
In the module's C++ code, you can use __stdcall explicitly in the exported function declarations.
Or, you can change the default calling convention in C++Builder's project settings, and then omit any calling convention in the function declarations.
Now, to answer your question - when importing a pyd module, if the module uses cdecl, use ctypes.cdll to call its functions. If the module uses stdcall, use ctypes.windll instead. This is covered in Python's documentation:
https://docs.python.org/3/library/ctypes.html#loading-dynamic-link-libraries
16.16.1.1. Loading dynamic link libraries
ctypes exports the cdll, and on Windows windll and oledll objects, for loading dynamic link libraries.
You load libraries by accessing them as attributes of these objects. cdll loads libraries which export functions using the standard cdecl calling convention, while windll libraries call functions using the stdcall calling convention. oledll also uses the stdcall calling convention, and assumes the functions return a Windows HRESULT error code. The error code is used to automatically raise an OSError exception when the function call fails.
https://docs.python.org/3/faq/windows.html#is-a-pyd-file-the-same-as-a-dll
Is a *.pyd file the same as a DLL?
Yes, .pyd files are dll’s, but there are a few differences. If you have a DLL named foo.pyd, then it must have a function PyInit_foo(). You can then write Python “import foo”, and Python will search for foo.pyd (as well as foo.py, foo.pyc) and if it finds it, will attempt to call PyInit_foo() to initialize it. You do not link your .exe with foo.lib, as that would cause Windows to require the DLL to be present.
After some fiddling around, I can say that it is possible to create Python extensions using the C++ Builder compiler, swig and CMake.
Below is a brief overview of the steps that I used to wrap a simple C++ class (ATObject) to Python37.
The C++ header file is:
#ifndef atATObjectH
#define atATObjectH
#include <string>
//---------------------------------------------------------------------------
using std::string;
int MyTest(int r);
class ATObject
{
public:
ATObject();
virtual ~ATObject();
virtual const string getTypeName() const;
};
#endif
and source
#pragma hdrstop
#include "core/atATObject.h"
//---------------------------------------------------------------------------
ATObject::ATObject() {}
ATObject::~ATObject() {}
const string ATObject::getTypeName() const
{
return "TYPENAME NOT IMPLEMENTED";
}
int MyTest(int r)
{
return r;
}
1) Create import libraries using implip on the Python3 and Python37 dll's. Use implibs flag -aa, to get an import library that C++ builder understands. Put them in the Python37/libs folder.
2) Create the swig interface file that defines which class, functions and data to wrap. The swig interface file:
// atexplorer.i
%include "std_string.i"
%include "windows.i"
%module atexplorer
%{
#include "atATObject.h"
%}
//Expose class ATObject to Python
%include "atATObject.h"
3) Create CMake files for the project, using SWIG_ADD_LIBRARY to create the .pyd module, e.g.
SWIG_ADD_LIBRARY(atexplorer MODULE LANGUAGE python SOURCES
atexplorer.i ${ATAPI_ROOT}/source/core/atATObject.cpp )
SWIG_LINK_LIBRARIES (atexplorer
${PYTHON_LIB_FOLDER}/Python3_CG.lib
${PYTHON_LIB_FOLDER}/Python37_CG.lib
)
and make CMake pass the .def file to the linker by adding:
set (CMAKE_MODULE_LINKER_FLAGS ${CMAKE_CURRENT_SOURCE_DIR}/atexplorer.def)
The atexplorer.def file should look like this:
EXPORTS
PyInit__atexplorer=_PyInit__atexplorer
4) Compile the project, and confirm that you get a generated "MyModule"PYTHON_wrap.cxx and a MyModule.py file in your CMake build folder. The "MyModule"PYTHON_wrap.cxx file contains generated C++ code for the Python module, and the .py file contain generated Python code.
The Python module is named atexplorer.
Image below shows what is exported in the _atexplorer.pyd module.
Copy the .pyd and the .py files to Pythons site packages folder.
If successful, you will be able to import the module in Python, e.g.
The screen shot above shows how the module, atexplorer, is imported. It has a function called 'MyTest', that returns whatever its argument is, when executed.
It also has a class, ATObject, for which an object named 'a', is created. Last line prints the output of executing the class member function 'getTypeName()', which simply returns, TYPENAME NOT IMPLEMENTED.
I want to import a normal javascript module (e.g. vhost) into my node.js typescript file using CommonJS.
I can do this with the following line:
import vhost = require('vhost')
We assume that I can't find a .d.ts file on the internet, but I also don't want to write it by myself, so I just use the vhost variable without intellisense.
The compiler complains and complains:
How can I tell that I just want it to be 'dynamic' (like the C# dynamic keyword or 'var' in normal javascript) and use all of the things in the picture above?
I could create a vhost.d.ts file, but I don't know what to write in there:
declare module 'vash' {
// what to write here?
}
I found this out while typing the question, it was so easy that it is almost embarrassing, but maybe somebody has this problem too.
Just use var instead of import:
Is there any way to extend library module in Haskell?
For example, I would like to add firstToLower function to Data.String. When I create my own Data.String it masks library one:
module Data.String where
import Prelude
import Data.Char (toLower)
firstToLower :: String -> String
firstToLower (c:cs) = toLower c : cs
firstToLower "" = ""
Then I get error trying to import Data.String (lines):
Module `Data.String' does not export `lines'
It would be really nice if such thing is possible. If not, what are best practices for such situations? Where such extensions should be placed?
Thank you.
Update
I don't plan to release my extensions as a library, just want to organize it inside my project in a meaningful way.
No, this is not possible. One solution that people have used in the past is to put your additions in a module with a name like Data.String.Extra and release that module on Hackage (if you think that your additions could be useful to other people).
Alternatively, you can propose your extension for inclusion in the standard library.