Release

[KeKl]

Hi,

could you please release a ready lib? Im not able to build the haskell things.

It would be great!

Thank you!

[marektq]

Did you have any success building the lib? I am also trying to get a dll and use it from C# bindings, and it would be great time saver if the dll was available.

[ShabbyX]

For some reason I never got a notification that there is an issue here!

Cabal is a bitch. That said, I recently compiled everything successfully under Linux, and I'd try to do the same with windows (if I can manage to get my hands on one). I'd do a release then, although I wouldn't be sure how 32-bit vs 64-bit stuff would interact. I'd most likely be building on 64-bit operating systems only.

[ShabbyX]

Alright, it turned out I had a virtual machine with windows 7 lying around.

Using the same configuration as Linux, I managed to build a windows x64 DLL. However, running a test for me resulted in "CreateTimerQueueTimer: A potential deadlock condition has been detected"! The resulting file is called libpandoc.dll.exe when cabal builds it and my guess at this point is that somehow the dll has bad entry points or something. I tried adding APIENTRY to pandoc_init/exit functions, but that didn't change anything.

FYI, I used MinGHC 7.10.2. Following instructions from here: https://wiki.haskell.org/Windows#Quickstart_on_Windows_7

Unfortunately, I'm not a windows programmer, but perhaps you (@marektomsa) could understand what's going on since you seem to understand dlls better.

[ShabbyX]

Just a couple of comments @marektomsa :

• Please update to the latest master and try building it.
• I fixed the problem with the dyn package missing on windows (a9f5ac9d). Turns out on Windows dynamic packages don't exist.
• In libpandoc.cabal, you need to rename libpandoc.so to libpandoc.dll.

Since you managed to install all dependencies correctly, the build process should go without a problem. Well, except that the resulting dll doesn't work ;)

Please let me know if you manage to understand the problem (or send a PR if you can fix it). Thanks.

[ShabbyX]

Here is a test program:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "pandoc.h"

#define BUF_SIZE 1024

int reader(char *buf, void *user_data)
{
    if (fgets(buf, BUF_SIZE, stdin) == NULL)
        return 0;

    return strlen(buf);
}

void writer(const char *buf, int len, void *user_data)
{
    fwrite(buf, 1, len, stdout);
}

static const char *settings =
"{\n"
    "\"writerOptions\": {\n"
    "\"writerStandalone\": false\n"
    "}\n"
"}";

int main()
{
    pandoc_init();
    char* error = pandoc(BUF_SIZE    /* buffer size */,
            "markdown"    /* input format */,
            "html"        /* output format */,
            settings      /* JSON settings */,
            reader        /* the reader function */,
            writer        /* the writer function */,
            NULL          /* private user data */);
    pandoc_exit();

    if (error)
        fprintf(stderr, "Error: %s\n", error);
    free(error);

    return 0;
}

[itechbear]

@ShabbyX How is the memory pointed by buf managed in your test program? I can't see any malloc/free statements here.

If it is manged by pandoc itself, should there be a maximum length limit in case of "out of range" problem?

[ShabbyX]

It's handled by libpandoc. What out of range problem? The pandoc() function takes the size of the buffer, so it knows how much to allocate and what range to access. The reader() and writer() callbacks can also know this size and not access beyond it.

Was that what you meant?

[itechbear]

OK, I see.