Stephen Tetley wrote:
Also binding to a C library is easier than binding to a C++ one, if
you can think of another library rather than SRILM that will meet your
needs...
Alas, SRILM really is the standard tool for this so there aren't other
(worthwhile) options AFAIK. But it's pretty standard
Hi all,
I got it to work...finally. Basically, I used Malcolm's suggestion of
tracking down all the
SRILM .o files needed. I need to run now, but I'll post the gory (oh, so
gory) details soon.
Thanks to all who helped.
Best,
D.N.
--
View this message in context:
I still get the undefined reference errors.
It is likely there is some combination of other mistakes as well
then. Other responses have made suggestions of fixes you require in
the C++ code for instance. You will need those as well.
I did eventually get ghc to compile
Main.hs by
OK. Before anyone expends any e-ink replying to my reply below -- the one
where I
demonstrate that I don't understand what -c, -cpp mean to 'ghc' (not that
you can
blame me, since there isn't any documentation in the 'ghc' man page) -- I
see why
the Main.o file doesn't run. It's an object file,
Which is weird, because 'srilm.o'/'srilm.h' are the files that define the
mysterious undefined references. I'll keep plugging away and report
back when (or whether) I make some progress. In the meanwhile, if anyone
has a clue, I'm all ears.
Best,
D.N.
Malcolm Wallace wrote:
However, if
Am Donnerstag 14 Januar 2010 20:42:42 schrieb DNM:
Which is weird, because 'srilm.o'/'srilm.h' are the files that define
the mysterious undefined references. I'll keep plugging away and
report back when (or whether) I make some progress. In the meanwhile,
if anyone has a clue, I'm all ears.
On Thu, Jan 14, 2010 at 2:08 PM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
Just an idea. Are you on windows?
If so, then your foreign calls would probably have to be
foreign import stdcall srilm.h whatever ...
instead of
foreign import ccall ...
Yes, I came here to say that too. I
Hello Daniel
On Windows, isn't stdcall vs ccall still dependent on the actual
library and what compiled it - commonly MSVC (stdcall) or gcc (ccall)
of course?
I could very easily be wrong...
Best wishes
Stephen
2010/1/14 Daniel Fischer daniel.is.fisc...@web.de:
Am Donnerstag 14 Januar
Hello Daniel,
Thursday, January 14, 2010, 11:08:24 PM, you wrote:
i think you are wrong. stdcall used for std windows dlls, but gcc by
default generates ccall things. and cl anyway useless here
Just an idea. Are you on windows?
If so, then your foreign calls would probably have to be
Nope. Ubuntu Linux (Intrepid Ibex). I wish it were that simple.
--D.N.
Daniel Fischer-4 wrote:
Am Donnerstag 14 Januar 2010 20:42:42 schrieb DNM:
Which is weird, because 'srilm.o'/'srilm.h' are the files that define
the mysterious undefined references. I'll keep plugging away and
Hello DNM,
Thursday, January 14, 2010, 10:42:42 PM, you wrote:
there is better way rather than playing with random bits. just find
tutorial on FFI, and try it. once this example works, start modifying
it to learn various aspects of ffi and add functionality you need
it's one thing i've learned
Am Donnerstag 14 Januar 2010 21:39:57 schrieb DNM:
Nope. Ubuntu Linux (Intrepid Ibex). I wish it were that simple.
--D.N.
Okay, so it's not a borken OS 8-)
Can you post ought to be compiling code?
That might help locate the problem.
___
2010/1/14 Bulat Ziganshin bulat.zigans...@gmail.com:
there is better way rather than playing with random bits. just find
tutorial on FFI, and try it. once this example works, start modifying
it to learn various aspects of ffi and add functionality you need
Also binding to a C library is
Works fine here (Mac OS X 10.5):
MigMit:ngram MigMit$ ghc --make Main.hs srilm.o
[1 of 2] Compiling LM ( LM.hs, LM.o )
LM.hs:9:0: Warning: possible missing in foreign import of FunPtr
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
MigMit:ngram MigMit$ ls
Am Donnerstag 14 Januar 2010 22:19:08 schrieb Miguel Mitrofanov:
Works fine here (Mac OS X 10.5):
MigMit:ngram MigMit$ ghc --make Main.hs srilm.o
[1 of 2] Compiling LM ( LM.hs, LM.o )
LM.hs:9:0: Warning: possible missing in foreign import of FunPtr
[2 of 2] Compiling Main
But when I try to compile it (after having successfully compiled the
C code
with g++), I get:
$ ghc --make Main.hs
You are not telling ghc to link against the C/C++ code, e.g.
ghc --make Main.hs srilm.o
Regards,
Malcolm
___
Haskell-Cafe
Hello DNM,
Wednesday, January 13, 2010, 8:57:45 AM, you wrote:
Note: I'm relatively new to Haskell, and my knowledge of C and C++ is
basically pretty
minimal -- I can read, modify and compile C/C++ programs (usually).
1. you use too much unsafePerformIO. since you need newCString, i
suggest
Bulat,
Some very good suggestions. I will try to appease Ceiling Cat and
reduce my (perhaps gratuitous) use of unsafePerformIO. I'm going to
have to use it somewhere, since I want referentially transparent code
(and I try to avoid the IO monad when possible, anyway).
2. if your function
Malcolm,
I saw this suggestion somewhere else. Unfortunately, it didn't help either.
I still get the undefined reference errors. I did eventually get ghc to
compile
Main.hs by putting the -c and -cpp flags after --make Main.hs.
Then it produces a Main.o file which (even with +x permissions on
Sorry. In my haste to paste in the .c file, I left out all the include
statements. I do have #include srilm.h there (which to my non-
C/C++ mind seems stupid -- why the hell would you need to import
the header file for the code that it's a header *for*?)
Still no dice.
Thanks for your time,
On Jan 13, 2010, at 23:28 , DNM wrote:
Sorry. In my haste to paste in the .c file, I left out all the
include
statements. I do have #include srilm.h there (which to my non-
C/C++ mind seems stupid -- why the hell would you need to import
the header file for the code that it's a header
Hello DNM,
Thursday, January 14, 2010, 7:07:43 AM, you wrote:
Yes, I thought of doing this, but then thought it was better to use a
so-called managed foreign pointer via newForeignPtr.
i recommend to use Ptr and switch to ForeignPtr only when you will
study how to use it. overall, unsafe*
Hello Brandon,
Thursday, January 14, 2010, 7:40:45 AM, you wrote:
Really, the only reason in this case is that there is no equivalent
for `extern C' that you can apply to a function definition, only to
a declaration
it works with GCC:
extern C int c_szOpenArchive (TABI_ELEMENT* params)
{
Note: I'm relatively new to Haskell, and my knowledge of C and C++ is
basically pretty
minimal -- I can read, modify and compile C/C++ programs (usually).
I'm trying to interface with some C++ code by writing a little bit of C code
that uses that C++ code,
and I'm getting undefined reference
On Jan 13, 2010, at 00:57 , DNM wrote:
- srilm.c
// Initialize and read in the ngram model
Ngram* bldLM(int order, const char* filename) { ... }
...
// Delete the ngram model
void deleteLM(Ngram* ngram) {
delete srilm_vocab;
delete ngram;
}
...
// Get the ngram
25 matches
Mail list logo
