I am working on a project in Crystal lang which embeds Python3.5 linking Python .so library (no Python.h header).
It seems that PyType_Check() and other check functions actually are macros, so they're not visible while linking the library.
Is there any other alternative or workarount to this?
Exactly, C macros won't be available in Crystal. However, you'll only need to call them from Crystal. In the compiled C library they're already expanded.
So you can just implement these macros in Crystal. Of course, you'll have to do some unwrapping of nested macros.
To my knowledge there is no simple solution to this. Bindgen for example ignores function-like macros as well because they can't be easily converted to Crystal.
I generated a new project using Yesod and am trying to go through the source to see how the pieces fit together. I am still a bit unfamiliar with most of the types so I have to keep a browser open where I hoogle/hayoo for types of things.
When I use Intellij for Java development I can usually just jump in to the source code of most of my dependencies. I wanted to try to replicate this for Haskell.
Since I am using vim for Haskell I thought I would just get the source for everything listed in build-depends and then generate a specific cabal_tags file and add that to vim's tags option.
My cabal skills are very rudimentary though. I noticed there is cabal get which can get the source for a package but it seems you need to explicitly specify the package and there doesn't seem to be an option for getting everything specified under build-depends in the .cabal file.
Is there a way to program in Leksah without creating a main function/module, to test small functions and programns, for example? Can't I just creat a new module and use it?
Thank you
Leksah is designed to get you to structure your whole major project correctly from the start. If you want to use it for a quick editor, recognise that's not what it's for, but you can make a workaround:
Make a new workspace and package called Scratch/Scratchpad/Temp, with just one module in it. Use it when you just want to mess around a bit, and clear it out when you're starting something else.
When working in the ocaml or ghci toplevels I often build up a significant "context" for want of a better word, values bound, functions, modules loaded, and so on. Is there a way to save all of that and reload it later so I can continue exactly where I left off? Or better yet, dump out the entire lot as a text file that could be reloaded or be trivially modified into code that I could compile into an executable (e.g. by adding a Main)?
Users of HOL light have had similar needs, and they use a checkpointing program to save a snapshot of the toplevel. See this message on the caml mailing-list, or page 8 of this HOL tutorial.
In general it is better to keep the definitions as source code, rather than a binary toplevel snapshot. Numerous tools allow to quickly load a .ml file into the toplevel for easy experimentation (emacs modes, etc.). See the warning in the HOL tutorial:
When developing large proofs in HOL, you should always keep the proof script as
an OCaml file ready to reload, rather than relying on ckpt. This will allow the proofs
to be later modified, used by others etc. However, it can be very convenient to make
intermediate snapshots so you do not have to load large files to work further on a proof.
This is analogous to the usual situation in programming: you should always keep your
complete source code, but don’t want to recompile all the sources each time you use
the code.
At least in OCaml there's no built-in support for that. On solution is to use rlwrap or any other readline wrapper to record your input's history to a file. For example :
> rlwrap -H mysession.ml ocaml
The drawback is that this will also record the input that had syntax errors so you'll have to clean that out. Note that by default rlwrap will automatically save your input in ~/.ocaml_history if you invoke it without the -H option.
In Haskell, just use :e file. This opens the standard editor and lets you edit some file. Afterwards, use :r to reload it. It will be automatically recompiled.
Please notice, that all your "ad-hoc" defined functions will be lost after this. Refer to the doc for more information.
ghci uses haskeline for commandline input history, so you can scroll up to repeat/edit inputs. Your input history is usually recorded in a file, which you can find as ghci_history in the directory given by
System.Directory.getAppUserDataDirectory "ghc"
There are various commands to explore the 'context' (:show bindings, :show modules, :def, ..) but their output won't suffice to reproduce your session (though it is worth knowing about them anyway).
In general, the advice to combine your ghci session with an open editor window is sound: if it is more than a throwaway definition, even if just for debugging purposes, better include it in a module to be loaded into ghci, so that you can reuse it.
Oh, and if by 'context', you mean some default settings or modules you want loaded, on a per-project basis, there is also ghci's configuration file. Also handy for defining your own ghci commands.
In ocaml, you can build your own top-level. It solves problem with loaded modules at least.
http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html#sec278
The ocamlmktop command builds OCaml toplevels that contain user code
preloaded at start-up.
The ocamlmktop command takes as argument a set of .cmo and .cma files,
and links them with the object files that implement the OCaml
toplevel. The typical use is:
ocamlmktop -o mytoplevel foo.cmo bar.cmo gee.cmo
This creates the bytecode file mytoplevel, containing the OCaml
toplevel system, plus the code from the three .cmo files. This
toplevel is directly executable and is started by:
./mytoplevel
This enters a regular toplevel loop, except that the code from
foo.cmo, bar.cmo and gee.cmo is already loaded in memory, just as if
you had typed:
#load "foo.cmo";;
#load "bar.cmo";;
#load "gee.cmo";;
on entrance to the toplevel. The modules Foo, Bar and Gee are not
opened, though; you still have to do
open Foo;;
yourself, if this is what you wish.
This has always bothered me too, so I wrote a quick python/expect script to replay ghci_history at the beginning of each ghci session.
It's not very polished. For example it always replays the whole history and that could be slow.
I downloaded a set of source code for a program in a book and I got a makefile.
I am quite new to Linux, and I want to know whether there is any way I can see the actual source code written in C?
Or what exactly am I to do with it?
It sounds like you may not have downloaded the complete source code from the book web site. As mentioned previously, a Makefile is only the instructions for building the source code, and the source code is normally found in additional files with names ending in .c and .h. Perhaps you could look around the book web site for more files to download?
Or, since presumably the book web site is public, let us know which one it is and somebody will be happy to point you in the right direction.
A Makefile does not contain any source itself. It is simply a list of instructions in a special format which specifies what commands should be run, and in what order, to build your program. If you want to see where the source is, your Makefile will likely contain many "filename.c"'s and "filename.h"'s. You can use grep to find all the instances of ".c" and ".h" in the file, which should correspond to the C source and header files in the project. The following command should do the trick:
grep -e '\.[ch]' Makefile
To use the Makefile to build your project, simply typing make should do something reasonable. If that doesn't do what you want, look for unindented lines ending in a colon; these are target names, and represent different arguments you can specify after "make" to build a particular part of your project, or build it in a certain way. For instance, make install, make all, and make debug are common targets.
You probably have GNU Make on your system; much more information on Makefiles can be found here.
It looks like you also need to download the SB-AllSource.zip file. Then use make (with the Makefile that you've already downloaded) to build.