- Glasgow-haskell-users

Why is ghc looking for version 2.1.0.1 of Parsec?
by Captain Freako 14 Jan '12

14 Jan '12

Hi all, Does anyone know what may be causing ghc to be looking for such an old version of Parsec, here? $ ghc -o libami.so -shared -dynamic -package parsec -package dsp -package arrows -lHSrts -L/usr/lib/ghc-7.0.3/ -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o ExmplUsrModel.o MaybeT.o Filter.o /usr/bin/ld: cannot find -lHSparsec-2.1.0.1-ghc7.0.3 Thanks, -db

1 0

Re: [Haskell-cafe] named pipe interface
by Serge D. Mechveliani 14 Jan '12

14 Jan '12

On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote: > Quoth "Serge D. Mechveliani" <mechvel(a)botik.ru>, > ... > > Initially, I did the example by the Foreign Function Interface for C. > > But then, I thought "But this is unnatural! Use plainly the standard > > Haskell IO, it has everything". > > > > So, your advice is "return to FFI" ? > > Well, it turns out that the I/O system functions in System.Posix.IO > may work for your purposes. I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. > > Specifically, > openFile "toA" WriteOnly Nothing defaultFileFlags > openFile "fromA" ReadOnly Nothing defaultFileFlags > > fdWrite toA str > (str, len) <- fdRead fromA 64 > return str Great! Thank you very much. As I find, Posix.IO is not of the standard, but it is of GHC. Anyway, it fits my purpose. By openFile you, probably, mean openFd. Another point is the number of open files, for a long loop. I put toA_IO = openFd "toA" WriteOnly Nothing defaultFileFlags fromA_IO = openFd "fromA" ReadOnly Nothing defaultFileFlags axiomIO :: String -> IO String axiomIO str = do toA <- toA_IO fromA <- fromA_IO fdWrite toA str (str, _len) <- fdRead fromA 64 return str When applying axiomIO in a loop of 9000 strings, it breaks: "too many open files". I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO axiomIO :: String -> IO String axiomIO str = do fdWrite toA str (str, _len) <- fdRead fromA 64 return str And now, it works in loong loops too (I need to understand further whether my usage of unsafePerformIO really damages the project). Its performance is 9/10 of the C <-> C performance (ghc -O, gcc -O, Linux Debian). It is still slow: 120000 small strings/second on a 2 GHz machine. But this is something to start with. > I was able to get your example to work > with these functions, which correspond to open(2), read(2), write(2). > > I would also use these functions in C, as you did in your C program. > Haskell I/O functions like hGetLine are analogous to C library I/O > like fgets(3) - in particular, they're buffered, and I would guess > that's why they don't work for you here. Indeed. Initially, I tried C <-> C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). Then, I tried read/write, as it is in fifoFromA.c which I posted. And it works. Now, Haskell <-> C gives a hope. Nice. Thanks, ------ Sergei mechvel(a)botik.ru

1 0

Re: [Haskell-cafe] named pipe interface
by Serge D. Mechveliani 13 Jan '12

13 Jan '12

On Fri, Jan 13, 2012 at 04:34:37PM +0100, Chadda?? Fouch?? wrote: > On Thu, Jan 12, 2012 at 7:53 PM, Serge D. Mechveliani <mechvel(a)botik.ru> wrote: > > [..] > > I need to organize a string interface for a Haskell function > > Main.axiom and a C program > > fifoFromA.c > > > > via a pair of named pipes (in Linux, UNIX). > > The pipes are created before running, by the commands > mkfifo toA > > > mkfifo fromA > > > > Main.axiom outputs a string to toA and inputs the respond string > > from fromA as the result. > > fifoFromA inputs a string from toA, > > converts it to the string resStr, outputs resStr to fromA. > > > Now that seems interesting, but just to be clear : did you choose > this solution (and why won't you use the FFI instead) or is this just > to see how to work it out ? I am trying to interface my large DoCon program for algebra to (a much larger algebra program) Axiom (the FriCAS license allows this). And for many reasons, there is no real way for this except the string interface. Further, the first candidate for the string interface is Unix named pipes. If the GHC IO cannot sufficiently work with named pipes, I would return to the attempt with the Foreign Function Interface and C <-> C exchange. Sergei. mechvel(a)botik.ru

1 0

Re: Records in Haskell
by Matthew Farkas-Dyck 12 Jan '12

12 Jan '12

Certainly not no conflicts: lambda expressions. On 30/12/2011, Colin Adams <colinpauladams(a)gmail.com> wrote: > On 30 December 2011 15:55, Matthew Farkas-Dyck <strake888(a)gmail.com> wrote: > >> On 30/12/2011, Andriy Polischuk <quuxity(a)gmail.com> wrote: >> > Yet another idea: >> > Consider using '\' as record access operator. No conflicts with anything >> at >> > all, and, >> > moreover, it really looks like hierarchical access. Reminds of >> filesystems >> > though. >> >> I hope this is a joke. >> > > Why? >

7 15

Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)
by Johan Tibell 12 Jan '12

12 Jan '12

On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed > arrays you could get away with FFI, but a PrimOp would be better because it > could be inline. But to get it inline would mean modifying the native and > LLVM backends to support CAS operations. > > If I were you I would use FFI for now. The cost of the out-of-line call is > much less than the cost of the CAS anyway. A gcc dependency is not a big > deal, it's available on all Unix-like platforms and I don't see us removing > it from the Windows installs any time soon. In a recent project (http://hackage.haskell.org/package/ekg) I found myself wanting unboxed mutable integers with CAS semantics (to implement simple counters). What would be required to support (1) unboxed mutable variables, and (2) CAS semantics for these. I guess (2) is easy once you have (1). Just add some new primops. -- Johan

2 3

Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?
by Ryan Newton 12 Jan '12

12 Jan '12

Hello there, I was wondering what the recommendations would be for getting CAS on [mutable] vector elements? I thought that as a first step I might create an a library that does the trick only for unboxed vectors, by using bits-atomic (i.e. FFI + GCC intrinsics). Roman Leshchinskiy recommended against depending on GCC. He thought, therefore, that not only boxed arrays but unboxed ones would need an extra PrimOp to be handled properly: > You can't rely on gcc extensions because code is usually compiled with the > native code generator nowadays and doesn't go through gcc. The dependency > on gcc will (hopefully) be dropped eventually anyway. So you'd probably > also want primops for unboxed arrrays and Addr#. Any advice? Thanks, -Ryan

2 1

Re: Unit unboxed tuples
by Dan Doel 11 Jan '12

11 Jan '12

Copying the list, sorry. I have a lot of trouble replying correctly with gmail's interface for some reason. :) On Tue, Jan 10, 2012 at 11:14 AM, Dan Doel <dan.doel(a)gmail.com> wrote: > On Tue, Jan 10, 2012 at 5:01 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> On 09/01/2012 04:46, wren ng thornton wrote: >>> Shouldn't (# T #) be identical to T? >> >> No, because (# T #) is unlifted, whereas T is lifted. In operational terms, >> a function that returns (# T #) does not evaluate the T before returning it, >> but a function returning T does. This is used in GHC for example to fetch a >> value from an array without evaluating it, for example: >> >> indexArray :: Array# e -> Int# -> (# e #) I don't really understand this explanation. (# T #) being unlifted would mean it's isomorphic to T under the correspondence e <-> (# e #). _|_ = (# _|_ #) : (# T #), so this works. Does the difference have to do with unboxed types? For instance: foo :: () -> Int# foo _ = foo () bar :: () -> (# Int# #) bar _ = (# foo () #) baz = case bar () of _ -> 5 -- 5 quux = case foo () of _ -> 5 -- non-termination Because in that case, either (# Int# #) is lifted, or the Int# is effectively lifted when inside the unboxed tuple. The latter is a bit of an oddity. -- Dan

5 6

kinds for `*'
by Serge D. Mechveliani 11 Jan '12

11 Jan '12

People, GHC provides some extensions for kinds. Does this make possible different kinds, for example, for `*' ? Prelude.Num has * :: a -> a -> a. And mathematicians also like to denote as `*' (\cdot in TeX) a "multiplication of a vector v by a coefficient r". It is expressed by the declaration class (Num r, ...) => LeftModule r v where * :: r -> v -> v Regards, ------ Sergei mechvel(a)botik.ru

2 1

Unit unboxed tuples
by Simon Peyton-Jones 10 Jan '12

10 Jan '12

Dear GHC users I've just discovered something very peculiar with unboxed tuples in GHC. f2 x = (# True, False #) f1 x = (# True #) f0 x = (# #) What types do these functions have? f2 :: a -> (# Bool, Bool #) f1 :: a -> (# Bool #) BUT f0 :: a -> b -> (# b #) I think this is stupid. It should be f0 :: a -> (# #) But in fact even that type isn't what you expect (ie the analogue of f :: a -> () ) Here are the kinds of the type constructors: (,,) :: * -> * -> * -> * (,) :: * -> * -> * () :: * (# ,, #) :: * -> * -> * -> # (# , #) :: * -> * -> # BUT (# #) :: * -> # In both respects unboxed unit tuples are behaving differently to boxed ones. This seems bonkers. I propose to fix this, but I wanted to check if anyone is relying on the current odd behaviour. Simon

10 17

More primops for integer arithmetic with overflow reporting
by Herbert Valerio Riedel 10 Jan '12

10 Jan '12

Hello GHC HQ, As the {Int,Word}{,8,16,32,64} types in Haskell are usually regarded to follow modulo arithmetic (w.r.t. to the Num-class ops), I was trying to implement efficient non-modulo Safe{Int,Word}{,8,16,32,64} types which would throw exceptions when the result falls outside the value domain representable. As ISAs often have hardware support to detect such overflows (e.g. on x86-64 via the OF/CF flags), I guess that by exploiting hardware support, this might allow for a reasonably efficient implementation of non-modulo integer arithmetic. So far I've only found 'addIntC#' and 'subIntC#' which perform the kind of operation I'm looking for. But this is only for signed integers, and as far as multiplication is concerned, there's a 'mulIntMayOflo#' but that may provide false negatives according to the documentation. Therefore, I was wondering whether it'd make sense for GHC to provide more primops for the {Int,Word}{,8,16,32,64} types which return the result value together with an overflow-flag. Thanks, hvr

2 1