Haskell - importing functions from prelude - function

I have kind of a newbie question. I want to use some functions from prelude, but I'm getting same error all the time.
For example:
Undefined variable "diff"
Some other functions are working, some not. I guess I have to import something, Google didn't help me... I'm using WinHugs.

Here are two sites you should bookmark, because they'll help you find functions you need -- and find out what you need to import.
http://haskell.org/hoogle/
http://holumbus.fh-wedel.de/hayoo/hayoo.html
Searching both those sites, I don't see anything that looks like the function you want. Some possibilities that occur to me are:
You're learning from a book that has examples of things you'd type at the Linux command line. "diff" is a common Linux command for comparing two files. I believe the windows equivalent is comp.
You're using some sample code that you got somewhere, but you didn't import everything you needed. If you can find the file that contains the "diff" function, import that.
You've written a function called "diff", and put it in another file. In the file where you want to use "diff", you need to import the module that contains it.

Prelude is typically imported implicitly. Are you sure that is really your problem? Undefined variable "diff" is a bit vague, since I don't know of a diff function imported with Prelude. Can you elaborate?

Related

Importing Python module from desktop, inexperienced programmer

First off I have very little Python experience and don't understand much about the terminology. Secondly I have never had to use a file path in Python before and therefore related terminology and methods may need to be explained (or have an easy to understand link, that isn't too strong in pythonic terminology like the Python Docs are).
I'm using modular programming and my functions are separate into three different files all in one file on my desktop C:\Users\User\Desktop\Folder_name\file1.py.
I plan on using all of the functions within and as such would like it to work similar to import random.
The problem is your python file doesn't appear in python search path.
A few ways to solve.
As #Jeff says:
import os
path = os.path.dirname(os.path.realpath(__file__))
sys.path.append(path)
this one will add the current file's directory to the search path in the current run context. With these lines in file /path/b.py, you can use /path/a.py or any python program in /path/.
Using IDEs function for it. Just run it from your IDE, they will fill the path.
Put your python file into any search path directory. This fulfiil your demand that using all of the functions within and as such would like it to work similar to import random. However it will make you running environment dirty. Better to use virtualenv.
If the dependent modules are in the same folder as the script you are executing:
import os
path = os.path.dirname(os.path.realpath(__file__))
sys.path.append(path)
If they're in a different spot you can just specify path to something manually, but you should try to make it robust to moving around by defining the path in relation to where you execute from.

How to encapsulate the autotools' macro definitions?

In the autoconf manual, it is noted that
AC_INIT (package, version, [bug-report], [tarname], [url])
defines multiple macro names such as AC_PACKAGE_NAME and PACKAGE_NAME.
Running configure also generates a config file with definition like the following:
define HAVE_LIBGMP 1
As I am writing C++ code, I find these macros annoying yet useful. In fact, it happened many times that I needed to link with a library that uses the autotools and thus has these macros in its headers. So the situation is that there is conflict on headers macros such as:
define PACKAGE_NAME "library"
define PACKAGE_NAME "mine"
So, I was wondering if there was a way to tell the autotools to define at least some of these macros inside some kind of structure as follows:
`struct header_information{
static string package_name;
static bug_report;
....
}`
and then initialize it with the right macro names.
This solution would keep these informations encapsulated and does not pollute the global namespace ?
It seems to me like you want to abuse a package-private, build-system-ony configuration header file (config.h) that just so happens to define a convenient macro name that you'd like to use. I think the pretty obvious answer is "don't do that", or else you're on your own.
Unless I'm misunderstanding you?
Those defines are there so that the particular library can use them. It's not meant for other things to include. In fact, the majority of the things in config.h are completely useless outside of the particular package.
That doesn't mean that the library that config.h file belongs to couldn't provide what you're looking for, by defining a public struct in a header that uses those variables. Or perhaps a library that uses pkg-config (if you're just looking for package names) can provide some of information for you. But I don't think that autotools would or should provide that information to you.

namespace conflict in C

I have defined list_t in my project that got list module API like list_pop(). But now I have to use MySQL lib to communicate with DB, but the MySQL lib still got its list implements, and also defined a list_pop() API. In my other modules, I have to link both of them, and comes the conflict.
One of my solution is, separately include header file for different list API calling, this works well, but while some function need to call both of MySQL::list_pop() and local::list_pop(), how to notify the compiler the correct link point? Is there some GCC trick that can do these without any changes to local::list_pop()?
For most practical purposes, you are going to have to rename one or the other set of functions. It is probably easier to rename your own than those of MySQL.
The simplest approach is to simply add a prefix that has a higher probability of being unique (enough), such as your initials, or the codename of your project, or something. Or you can rename everything to avoid collisions, being aware that MySQL might add a new function in the future.
This is exactly why namespaces were invented for C++, and why C projects usually have systematic prefixes on sets of functions.
There is a way to solve this. Refactor your list_pop() to, say, my_list_pop().
There is one other way to solve this,
Looking at the header of the MySQL my_list.h here, https://github.com/lgsonic/mysql-trigger/blob/master/mysql/my_list.h you can see that list_pop is just a macro, and its binded at compile time, not at runtime(hence not a real library function). Changing list_pop of MySQL to list_pop_my(just in the #define) can make it do what you want it to do.

Read all CSV files in a directory into an internal table

I have a parameter and, on F4, we can choose the directory. I'm trying to figure out how to choose a folder and read the content of all the files in it (the files are in .CSV) to an internal table. I think I have to use TMP_GUI_DIRECTORY_LIST_FILES function. Hope I'm explaining myself. Thank you.
You'll have to do this manually: first read the list of files, the go through each file and process its contents. There may be some odd function modules to read CSV files, but be aware that many of them are broken - for example, they just clip the lines that exceed a certain length. Therefore I won't recommend any of them - personally, I'd implement the CSV import part myself.
If you have access to the transaction KCLJ in your system you could analyze the coding behind it. This tool has an option to interpret CSV files so you might find interesting function modules that might help you with your tasks.
EDIT: I looked at it very quickly and the piece of coding you could reuse is reconvert_format from include RKCDFILEINCFOR. An example how to call it is located starting from line 128 in the same include.

Problems converting a C header to D

I'm trying to translating the MySql C connector 6.02 headers to D, but I get some weird crashes.
My guess is I've made some mistakes on translating the structs or function (I'm not very good at C).
I used implib /system on the libmysql.dll to create a lib file.
I couldn't get htod.exe to work. Using -hs (include system files) complained it couldn't find system files.
Coffimplib.exe didn't have an option to prepend _ to exported internal names.
I couldn't find a free version of coff2omf.
mysql.d is the wrapper. I've included the C definition before each wrapped definition to easier spot bugs. The file includes the mysql dll and converted libfile too.
When compiling mytest_fails.d it crashes. mytest_works.d only has an assert, and this makes it work.. Compiling mytest_works with -release makes it crash too.
I've been using dmd 2.051
Download mytest.zip from share1t.com
Update: I've also asked some question regarding this on the D.learn newsgroup, but I don't think anyone has gone through the code.
C Const
Compiler extensions
Connot get htod.exe to work
The weird crashes
stdcall is a Windows function calling convention (very different from the C calling convention). HTOD failed to mark several functions with extern(Windows). This is normal, since HTOD isn't equipped to handle macros (STDCALL is defined as a macro, I can see that from the leftover comments in msyql.d).
Here's an updated mysql.d file:
http://dl.dropbox.com/u/9218759/mysql.d
Now, you need the proper import library in OMF format. I'd generally advise that you do not use implib for this. I've had several problems with it and others have reported having problems using it. Using coffimplib is the way to go. But first, you will need a COFF import library.
If you need it, the Mysql release with the COFF import library can be downloaded from here: http://dev.mysql.com/downloads/mirror.php?id=377977#mirrors (Libraries in DLL form marked for Visual Studio usually come with a COFF import library).
But I'm providing you the translated COFF import library in OMF format here: http://dl.dropbox.com/u/9218759/libmysql.lib
I've tried both of your test cases and they both seem to work fine now. In case of problems, try to check the translated header file again (mysql.d), it's possible that I might have missed to specify all the calling conventions properly.