Re: [Haskell-cafe] FFI for a beginner
FIXED IT!!!
The problem with charm.hs and its FFI dependency charm.c is that both want
to produce an intermediary charm.o file.
Solution: rename charm.hs to hscharm.hs.
Cheers,
Andrew Pennebaker
www.yellosoft.us
On Tue, Apr 12, 2011 at 5:55 PM, Andrew Pennebaker
andrew.penneba...@gmail.com wrote:
hsc2hs and c2hs are good suggestions, and some of the tutorials I'm
following use them.
But 1) Many Haskell FFI tutorials don't require them, so they only seem to
help, or only help in older versions of GHC.
And 2) When I did compile using c2hs, it just produced the same file, but
with filler comments like {#- LINE 13 #-}. And they still refused to compile
for the same reason:
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
Cheers,
Andrew Pennebaker
www.yellosoft.us
On Sat, Apr 9, 2011 at 9:50 PM, Jason Dagit dag...@gmail.com wrote:
I don't know how to make ghc load them without using either hsc2hs or
c2hs. I've had better experiences with hsc, but your mileage may vary.
On Apr 8, 2011 3:34 AM, Andrew Pennebaker andrew.penneba...@gmail.com
wrote:
ncurses is proving too difficult to setup, so I'm working on a new library
called charm. The C code works by itself, but I can't compile a Haskell
wrapper for it. While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examplesare
helpful, they're outdated. Argh! The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headerssay
that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
GitHub: charm https://github.com/mcandre/charm and
hscharmhttps://github.com/mcandre/hscharm
https://github.com/mcandre/charm$ make
cp /usr/include/charm.c .
ghc --make -fforce-recomp -o hellocharm hellocharm.hs charm.hs charm.c
-I/usr/include -dylib-install-name /usr/lib/libcharm.dynlib
[1 of 2] Compiling Charm( charm.hs, charm.o )
[2 of 2] Compiling Main ( hellocharm.hs, hellocharm.o )
Linking hellocharm ...
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
collect2: ld returned 1 exit status
make: *** [hellocharm] Error 1
Cheers,
Andrew Pennebaker
www.yellosoft.us
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI for a beginner
FIXED IT!!! The problem with charm.hs and its FFI dependency charm.c is that
both want to produce an intermediary charm.o file. Solution: rename charm.hs to
hscharm.hs.
Would you (or anyone else) care to update the tutorials on the Haskell Wiki?
As someone wrote below:
While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examples are
helpful, they're outdated. Argh!
It would be great if someone was public-spirited enough to fix this. The root
page is here
http://haskell.org/haskellwiki/GHC/Using_the_FFI
which in turn links to the complete examples page mentioned above.
The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
Ah, now that is a GHC documentation question. Can you tell us what should the
docs should say instead? Then we can fix the docs.
Simon
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Andrew Pennebaker
Sent: 14 July 2011 07:57
To: Jason Dagit
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] FFI for a beginner
FIXED IT!!!
The problem with charm.hs and its FFI dependency charm.c is that both want to
produce an intermediary charm.o file.
Solution: rename charm.hs to hscharm.hs.
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
On Tue, Apr 12, 2011 at 5:55 PM, Andrew Pennebaker
andrew.penneba...@gmail.commailto:andrew.penneba...@gmail.com wrote:
hsc2hs and c2hs are good suggestions, and some of the tutorials I'm following
use them.
But 1) Many Haskell FFI tutorials don't require them, so they only seem to
help, or only help in older versions of GHC.
And 2) When I did compile using c2hs, it just produced the same file, but with
filler comments like {#- LINE 13 #-}. And they still refused to compile for the
same reason:
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
On Sat, Apr 9, 2011 at 9:50 PM, Jason Dagit
dag...@gmail.commailto:dag...@gmail.com wrote:
I don't know how to make ghc load them without using either hsc2hs or c2hs.
I've had better experiences with hsc, but your mileage may vary.
On Apr 8, 2011 3:34 AM, Andrew Pennebaker
andrew.penneba...@gmail.commailto:andrew.penneba...@gmail.com wrote:
ncurses is proving too difficult to setup, so I'm working on a new library
called charm. The C code works by itself, but I can't compile a Haskell wrapper
for it. While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examples are
helpful, they're outdated. Argh! The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
GitHub: charmhttps://github.com/mcandre/charm and
hscharmhttps://github.com/mcandre/hscharm
$ make
cp /usr/include/charm.c .
ghc --make -fforce-recomp -o hellocharm hellocharm.hs charm.hs charm.c
-I/usr/include -dylib-install-name /usr/lib/libcharm.dynlib
[1 of 2] Compiling Charm( charm.hs, charm.o )
[2 of 2] Compiling Main ( hellocharm.hs, hellocharm.o )
Linking hellocharm ...
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
collect2: ld returned 1 exit status
make: *** [hellocharm] Error 1
Cheers,
Andrew Pennebaker
www.yellosoft.ushttp://www.yellosoft.us
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.orgmailto:Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI for a beginner
I think you should definitely use hsc2hs.
It is simple to you use and would allow you to replace things like:
peek ptr = do*a - peekByteOff ptr 0
b - peekByteOff ptr 4*
return (MyStructType a b)
By:
#include MyStruct.h
-- ^ Needs to be defined in a separate header
peek ptr = do
a - (#peek MyStruct, foo) ptr
b - (#peek MyStruct, bar) ptr
return (MyStructType a b)
But I just know hsc2hs. Does c2hs automatically writes the Storable
instances ? (Because it's kind of a daunting task...)
2011/4/12 Andrew Pennebaker andrew.penneba...@gmail.com
hsc2hs and c2hs are good suggestions, and some of the tutorials I'm
following use them.
But 1) Many Haskell FFI tutorials don't require them, so they only seem to
help, or only help in older versions of GHC.
And 2) When I did compile using c2hs, it just produced the same file, but
with filler comments like {#- LINE 13 #-}. And they still refused to compile
for the same reason:
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
Cheers,
Andrew Pennebaker
www.yellosoft.us
On Sat, Apr 9, 2011 at 9:50 PM, Jason Dagit dag...@gmail.com wrote:
I don't know how to make ghc load them without using either hsc2hs or
c2hs. I've had better experiences with hsc, but your mileage may vary.
On Apr 8, 2011 3:34 AM, Andrew Pennebaker andrew.penneba...@gmail.com
wrote:
ncurses is proving too difficult to setup, so I'm working on a new library
called charm. The C code works by itself, but I can't compile a Haskell
wrapper for it. While the tutorials at
HaskellWikihttp://www.haskell.org/haskellwiki/FFI_complete_examplesare
helpful, they're outdated. Argh! The
docshttp://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headerssay
that -#include pragmas no longer work, but fail to explain how to load
code without them. Suffice to say I have no recourse but trial and error.
GitHub: charm https://github.com/mcandre/charm and
hscharmhttps://github.com/mcandre/hscharm
https://github.com/mcandre/charm$ make
cp /usr/include/charm.c .
ghc --make -fforce-recomp -o hellocharm hellocharm.hs charm.hs charm.c
-I/usr/include -dylib-install-name /usr/lib/libcharm.dynlib
[1 of 2] Compiling Charm( charm.hs, charm.o )
[2 of 2] Compiling Main ( hellocharm.hs, hellocharm.o )
Linking hellocharm ...
ld: duplicate symbol _Charm_getWidth_info in charm.o and charm.o
collect2: ld returned 1 exit status
make: *** [hellocharm] Error 1
Cheers,
Andrew Pennebaker
www.yellosoft.us
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compiler support for orphan instances
Yesterday I tried to install fix-imports and ran into another example of
problems with changing transitive closures of orphan instance propagation:
$ cabal install fix-imports
Resolving dependencies...
Configuring fix-imports-0.1.2...
Preprocessing executables for fix-imports-0.1.2...
Building fix-imports-0.1.2...
[1 of 6] Compiling Types( src/Types.hs,
dist/build/FixImports/FixImports-tmp/Types.o )
[2 of 6] Compiling Util ( src/Util.hs,
dist/build/FixImports/FixImports-tmp/Util.o )
[3 of 6] Compiling Index( src/Index.hs,
dist/build/FixImports/FixImports-tmp/Index.o )
src/Index.hs:48:15:
No instance for (Monad (Either [Char]))
arising from a use of `sequence' at src/Index.hs:48:15-40
Possible fix:
add an instance declaration for (Monad (Either [Char]))
...
It is a repeating problem that you use an instance without noting it (here
Monad (Either [Char])) and import it without noting it (you import a
module, that possibly by accident imported and thus re-exported that
instance). If the modules you import, decide to no longer use the Monad
Either instance, then your imports will ignore the instance.
I thought that some compiler support could reduce this problem.
Proposal 1
GHC might warn, if you use an orphan instance but import it from a module,
that does not define it.
Example:
module A where
instance Msg s = Monad (Either s) ...
module B where
import A
module C where
{-
B does not define instance Monad Either,
but propagates that instance from A.
-}
import B
test :: Either String Int
test = do
fail bla
return 5
{-
Here GHC should emit a warning,
since the Monad Either instance is imported from B
but not directly from A.
If B drops the 'import A' this will no longer work.
-}
Proposal 2
Sometimes a module is actually intended for re-exporting an instance.
Sometimes an instance is moved from module A to module Z, but A still
re-exports the instance in order to maintain compatibility. In these cases
proposal 1 would yield false alarms. So maybe there should be a pragma for
tagging instances that are intentionally re-exported. Problem: How to
identify instances? This is certainly related to earlier ideas of explicit
named instance imports.
module A where
instance Msg s = Monad (Either s) ...
module B where
import A
{-
Explicitly propagate the instance from A,
which is as good as defining it here.
If the instance is not in scope,
then compilation should fail at this pragma.
This way it is asserted, that the instance is really exported.
-}
{-# INSTANCE-EXPORT Monad (Either s) #-}
module C where
import B
test :: Either String Int
test = do
fail bla
return 5
{-
No warning here, because B intentionally propagated the Monad Either
instance.
-}
Proposal 3
Forget about all those proposals and implement named instances. However
the proposals 1 and 2 let you write code that works on all Haskell 98
compilers. Compilers may just not warn or ignore the INSTANCE-EXPORT
pragma. Proposal 3 requires a language extension and using it will work
only on the compilers that support that extension.
Proposal 4
Forget about flexible, undecidable, overlapping, orphan and other
instances and create a system, where classes are replaced by explicit
method dictionaries and some rules for inserting these dictionaries, where
the rules can be declared by the package author in the modules.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for GUI examples - Functional Reactive Programming
Paul Liu wrote: You guys might want to checkout the recent work on Euterpea at Yale CS. In particular: 1. Paul Hudak is writing a new book. http://plucky.cs.yale.edu/cs431/reading.htm 2. It uses FRP and arrows for sound synthesis. 3. It combines FRP signals with monadic (which recently gets re-written in arrows) GUI composition. 4. New novel techniques is being developed to handle I/O within arrows framework. The code can be obtained through darcs, details at http://plucky.cs.yale.edu/cs431/software_resources.htm Thanks! Paul Hudak has kindly drawn my attention to Euterpea as well. Notably, the way it handles GUI is that the composition of widgets are static, but the signals flowing between them are dynamic. This closely follows Conal Elliott's Phooey approach, and greatly reduces the complexity of GUI programming. From what I understand, this new approach to I/O for arrows is equal in expressiveness to the approach I took in reactive-banana . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [iteratee] empty chunk as special case of input
2011/7/14 John Lato jwl...@gmail.com:
Sorry for the followup, but I forgot about one other important reason
(probably the real reason) for the nullC case in bindIteratee. Note
what happens in the regular case: the iteratee is run, and if it's in
a completed state, the result is passed to the bound function (in the
m_done line), which is then also run. Examine what happens if the
inner iteratee is also complete:
const . flip onDone stream
which would be more clearly written as
\b _str - onDone b stream
so in this case the leftover stream result from the first iteratee
(stream) is used as the result of the second iteratee, and the
leftover stream from the second iteratee (_str) is discarded.
This doesn't seem right; what should happen is that the two streams
should be appended somehow.
Yes I see. From this point ov view, the way of ignoring second
iteratee's leftover stream is neither worse or better comparing to
other possible ways, like ignoring stream of first iteratee or
appending them together somehow. I thought about it, and now it seems
that all this problem exists because of iteratee's possibility to jump
into done state without processing any data.
I came to iteratees from IncrementalGet library (binary-strict
package), and thought that they are using similar concepts, but now I
see big difference - IncrementalGet's approach doesn't allow such
state change. That is how they define /Get/ (iteratee-like structure).
newtype Get r a = Get { unGet :: S - (a - S - IResult r) - IResult r }
data IResult a = IFailed S String
| IFinished S a
| IPartial (B.ByteString - IResult a)
data S = S ... -- contains data chunk (bytestring) and some other state holders
unGet has similar design in onDone branch, but onCont is hidden inside
IResult. So, user can't obtain the result without providing a stream
as input. Well, there is also black magic there.. but I think It
makes impossible to have two conflicting iteratees like bindIteratee
may discover.
I would like to compare those approaches and decide what is better
(it depends on task of course, but how?).. binary-strict's code is
easier to understand, but iteratees are more general and offer more
features, including very powerfull stream transformations. Is it good
idea to merge somehow those approaces? For example, if I'll replace
IncrementalGet's hardcoded stream type with type variable like
iterarees do, will I be able to implement convStream on top of Get,
how do you think? What about enumeratees?
By the way, Iteratee package contains itertut.lhs - very good
tutorial, thanks! It says that CPS was used to eliminate constructors.
How do yo think, may I hope that one day compiler will be able to
transform constructor-based approach, introduced there, into CPS
automatically?
Thanks,
Sergey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI for a beginner
The docs
http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#glasgow-foreign-headers
say that -#include pragmas no longer work, but fail to explain how to
load code without them. Suffice to say I have no recourse but trial
and error.
Ah, now that is a GHC documentation question. Can you tell us what
should the docs should say instead? Then we can fix the docs.
- I believe I would say (agreeing with M Parès) that hsc2hs serves this
purpose - put #include termios.h in the .hsc file and use hsc2hs
features like #const and (#peek x, y). The termios example could
cover a lot more ground by operating on the termios struct and calling
tcsetattr directly from Haskell, using hsc2hs # macros (I append an
example implementation), but you'd also want to explain that hsc2hs
is only needed for these # macros, not for FFI in general.
But hsc2hs as of GHC 7.0.3 generates a {-# INCLUDE pragma, which
of course is cause for complaint from ghc. So there might be more
to be fixed, beyond just the documentation. That line probably has
no actual purpose other than to annoy ghc, and as a workaround it
can simply be removed from the .hs file.
- My impression is that Greencard isn't the best way to get started
with FFI and hasn't been for a decade or so, so it should probably
be purged from docs.
- The root page needs some attention from someone who understands
what safe and unsafe mean. Currently (under Improving efficiency)
it cites the conventional interpretation that a function must be safe
if it calls back into the runtime, but neglects to mention that it
must also be safe if it is not to block execution of other threads,
including bound OS threads - so related to efficiency issues you
might want to make any slow I/O operation safe to avoid this.
There may be other points about unsafe that need to be documented.
Donn
{-# LANGUAGE ForeignFunctionInterface #-}
module TTY (clearICANON) where
import Data.Word (Word32)
import Foreign
import Foreign.C
#include termios.h
type TCFlag = (#type tcflag_t)
type Speed = (#type speed_t)
data Termios = Termios {
termios_c_iflag :: TCFlag
, termios_c_oflag :: TCFlag
, termios_c_cflag :: TCFlag
, termios_c_lflag :: TCFlag
, termios_c_cc :: [CChar]
, termios_c_ispeed :: Speed
, termios_c_ospeed :: Speed
}
deriving Show
instance Storable Termios where
sizeOf _ = #size struct termios
alignment _ = alignment (undefined::CDouble)
peek a = do
iflag - (#peek struct termios, c_iflag) a
oflag - (#peek struct termios, c_oflag) a
cflag - (#peek struct termios, c_cflag) a
lflag - (#peek struct termios, c_lflag) a
cc - peekArray 20 ((#ptr struct termios, c_cc) a)
ispeed - (#peek struct termios, c_ispeed) a
ospeed - (#peek struct termios, c_ospeed) a
return (Termios iflag oflag cflag lflag cc ispeed ospeed)
poke a (Termios iflag oflag cflag lflag cc ispeed ospeed) = do
(#poke struct termios, c_iflag) a iflag
(#poke struct termios, c_oflag) a oflag
(#poke struct termios, c_cflag) a cflag
(#poke struct termios, c_lflag) a lflag
pokeArray ((#ptr struct termios, c_cc) a) (take 20 (cc ++ repeat 0))
(#poke struct termios, c_ispeed) a ispeed
(#poke struct termios, c_ospeed) a ospeed
foreign import ccall tcgetattr tcgetattr
:: CInt - Ptr Termios - IO CInt
foreign import ccall tcsetattr tcsetattr
:: CInt - CInt - Ptr Termios - IO CInt
setLFlag :: TCFlag - Termios - Termios
setLFlag c a = a { termios_c_lflag = ((termios_c_lflag a) .|. c) }
clearLFlag :: TCFlag - Termios - Termios
clearLFlag c a = a { termios_c_lflag = ((termios_c_lflag a) .. (complement c))
}
setTTYAttr :: CInt - (Termios - Termios) - IO ()
setTTYAttr fd fn = alloca $ \ termiosp - do
status - tcgetattr fd termiosp
if status == 0
then do
termios - peek termiosp
poke termiosp (fn termios)
status - tcsetattr fd (#const TCSAFLUSH) termiosp
if status == 0
then return ()
else throwErrno tcgetattr
else throwErrno tcgetattr
clearICANON = setTTYAttr 0 (clearLFlag (#const ICANON))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for GUI examples - Functional Reactive Programming
Heinrich Apfelmus wrote: Dear Haskellers, Can GUI programming be liberated from the IO monad? Functional Reactive Programming (FRP) promises as much, and I'm trying to make this dream a reality with my [reactive-banana][] library. Having released version 0.4.0.0, I am now looking for example programs to direct the future evolution of the library. Do you know any *small GUI programs* that you would *like* to see *implemented with Functional Reactive Programming?* Many thanks to everyone for telling me of your examples! I have implemented a few of them: http://haskell.org/haskellwiki/Reactive-banana/Examples Overall, the library held up very well, it's already perfectly usable for implementing GUIs in the functional reactive style. I was particularly surprised that I was able implement an animation, even though the library has no notion of time yet! The CRUD/database example was the most exciting; while still somewhat messy by Haskell standards, I quite like the result. Concerning the future evolution of the library, I now have a better sense of the remaining primitive combinators that are still missing. I also added a few immediate improvements, like * MonadFix instance for NetworkDescription * Overloaded (@) and (@) operators for the `apply` function and uploaded a corresponding version 0.4.1.0 on Hackage http://hackage.haskell.org/package/reactive-banana As said, the library is already very usable. In the future, I hope to implement more support for animations/audio/time; and then, only dynamic event switching will be left. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Animas/Yampa: ArrowChoice?
Hello all, I really like the way Animas (fork of Yampa) represents reactive systems, and I would love to write some of my simulations using it. Unfortunately most of what I want to do requires dynamic systems, which can be boiled down to me believing to need an ArrowChoice instance for the SF arrow, because I have to choose between different signal paths depending on the input signal or events. Animas appears to be only suitable for robot-like systems with specific, predefined actors. Is there anything I can do about it? Is it difficult to write the ArrowChoice instance? Or is there a different solution, which I overlooked? Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Animas/Yampa: ArrowChoice?
On Thu, Jul 14, 2011 at 5:04 PM, Ertugrul Soeylemez e...@ertes.de wrote: Hello all, I really like the way Animas (fork of Yampa) represents reactive systems, and I would love to write some of my simulations using it. Unfortunately most of what I want to do requires dynamic systems, which can be boiled down to me believing to need an ArrowChoice instance for the SF arrow, because I have to choose between different signal paths depending on the input signal or events. Animas appears to be only suitable for robot-like systems with specific, predefined actors. Is there anything I can do about it? Is it difficult to write the ArrowChoice instance? Or is there a different solution, which I overlooked? If I understand the thesis about the Frag game correctly it uses rSwitch, or rpSwitch, to make a dynamic switch: http://www.haskell.org/haskellwiki/Yampa/rSwitch http://haskell.org/haskellwiki/Frag I've never used yampa though so I may have misunderstood the problem and/or question. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
