Re: [Haskell-cafe] Data structure containing elements which are instances of the
It's only a test case. The real thing is for a game and will be
something like:
class EntityT e where
update :: e - e
render :: e - IO ()
handleEvent :: e - Event - e
getBound:: e - Maybe Bound
data Entity = forall e. (EntityT e) = Entity e
data Level = Level {
entities = [Entity],
...
}
I suspected the real case would look like that. It is also covered on
the same web page on Eliminating existentials. Here is your example
without existentials, in pure Haskell98 (I took a liberty to fill in
missing parts to make the example running)
data Event = Event Int -- Stubs
type Bound = Pos
type Pos = (Float,Float)
data EntityO = EntityO{
update :: EntityO,
render :: IO (),
handleEvent :: Event - EntityO,
getBound:: Maybe Bound
}
type Name = String
new_entity :: Name - Pos - EntityO
new_entity name pos@(posx,posy) =
EntityO{update = update,
render = render,
handleEvent = handleEvent,
getBound = getBound}
where
update = new_entity name (posx+1,posy+1)
render = putStrLn $ name ++ at ++ show pos
handleEvent (Event x) = new_entity name (posx + fromIntegral x,posy)
getBound = if abs posx + abs posy 1.0 then Just pos else Nothing
data Level = Level {
entities :: [EntityO]
}
levels = Level {
entities = [new_entity e1 (0,0),
new_entity e2 (1,1)]
}
evolve :: Level - Level
evolve l = l{entities = map update (entities l)}
renderl :: Level - IO ()
renderl l = mapM_ render (entities l)
main = renderl . evolve $ levels
I think the overall pattern should look quite familiar. The
code shows off the encoding of objects as records of closures. See
http://okmij.org/ftp/Scheme/oop-in-fp.txt
for the references and modern reconstruction of Ken Dickey's
``Scheming with Objects''.
It is this encoding that gave birth to Scheme -- after Steele and
Sussman realized that closures emulate actors (reactive
objects). Incidentally, existentials do enter the picture: the
emerge upon closure conversion:
Yasuhiko Minamide, J. Gregory Morrisett and Robert Harper
Typed Closure Conversion. POPL1996
http://www.cs.cmu.edu/~rwh/papers/closures/popl96.ps
This message demonstrates the inverse of the closure conversion,
eliminating existentials and introducing closures.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
Your idea looks _much_ better from code clarity point of view, but it's unclear to me, how to deal with it internally and in error messages. I'm not a compiler guy, though. Worse, it does not allow to set up fixity relative to operator that is not in scope and it will create unnecessary intermodule dependencies. One should fall back to numeric fixities for such cases, if it is needed. On 08/13/2012 11:26 PM, Ryan Ingram wrote: When I was implementing a toy functional languages compiler I did away with precedence declarations by number and instead allowed the programmer to specify a partial order on declarations; this seems to be a much cleaner solution and avoids arbitrary precedences between otherwise unrelated operators defined in different modules. You could write statements like -- define + and - to have the same precedence infixl + - -- define * to have higher precedence than + infixl * above + -- define / to have the same precedence as * infixr / equal * -- $ is right-associative infixr $ -- you can also separate precedence from fixity declaration precedence $ below + -- function application has higher precedence than all operators by default, but you can override that infixl . above APP -- == is non-associative infix == Here's some parses with this system: a + b - c = (a+b)-c f.x.y z == g w = (((f.x).y) z) == (g w) a == b == c = parse error (non-associative operator) a * b / c = parse error (left-associative/right-associative operators with same precedence) a == b $ c = parse error (no ordering known between == and $) a $ b + c = a $ (b+c) I think this is a much cleaner way to solve the problem and I hope something like it makes it into a future version of Haskell. -- ryan On Sun, Aug 12, 2012 at 11:46 AM, Евгений Пермяков permea...@gmail.com mailto:permea...@gmail.com wrote: fixity declaration has form *infix(l|r)? [Digit]* in haskell. I'm pretty sure, that this is not enough for complicated cases. Ideally, fixity declarations should have form *infix(l|r)? [Digit](\.(+|-)[Digit])** , with implied infinitely long repeated (.0) tail. This will allow fine tuning of operator priorities and much easier priority selection. For example, it may be assumed, that bit operations like (..) operator have hightest priority and have priorities like 9.0.1 or 9.0.2, anti-lisps like ($) have lowest priority like 0.0.1, control operators have base priority 1.* and logic operations like () have priority of 2.* and it will be possibly to add new operators between or above all (for example) control operators without moving fixity of other ones. Agda2 language supports wide priority range, but still without 'tails' to my knowledge. Is there any haskell-influenced language or experimental syntactic extension that address the issue? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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] overloading integer literals
During development some toy base library I found impossible to use
Numeric literals. Quick search showed, that one need both fromInteger in
scope (reasonable) and, as I understand, access to Integer type from
'base' package ('base' for clarity later). It is perfectly reasonable if
we assume that every module must depend on 'base'. However, with
ghc-prim and NoIplicitPrelude it is not necessary this way. One may wish
to drop 'base' dependency entirely. Currently, the only workaround I
found is to use cast from string literals (that works perfectly okay) or
use unboxed literals like 0xBB## (of unboxed type). Both solutions look
dirty, especially in pattern guards.
Is there any better solution or movement to improve RebindableSyntax
facilities ? for example, moving out classes for RebindableSyntax into
ghc-prim package and tuning them so all syntax facilities in base could
be defined in terms of RebindableSyntax would be great.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
On 13 August 2012 23:49, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote: This isn't that hard - a pipe shouldn't be needed anymore. Just require a post-2003 glibc. fexecve is a system call in most BSDs. It is also implemented in glibc using a /proc hack. fexecve is now in the Single Unix Specification, based on POSIX as of 2008, I believe. However, http://www.gnu.org/software/gnulib/manual/html_node/fexecve.html says Portability problems not fixed by Gnulib: * This function is missing on many non-glibc platforms: MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, Interix 3.5, BeOS. That warning doesn't seem to be fully up to date. I'm using MacOS X 10.6.8 and fexecve() isn't in the manuals or in unistd.h. FreeBSD 8.0 is covered. OpenBSD not covered OS X not covered http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/execve.2.html Solaris probably not covered. So support is pretty good, I'd say. For non-modern systems, checking the existence of the file first is possible. The race isn't important, and one can always upgrade to a modern operating system. Alexander ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
On Tue, Aug 14, 2012 at 1:04 AM, Евгений Пермяков permea...@gmail.comwrote: Your idea looks _much_ better from code clarity point of view, but it's unclear to me, how to deal with it internally and in error messages. I'm not a compiler guy, though. How to deal with it internally: It's pretty easy, actually. The hardest part is implementing an extensible partial order; once you have that and you can use it to drive comparisons, parsing is not hard. Basically, at each step when you read an operator token, you need to decide to shift, that is, put it onto a stack of operations, reduce, that is, apply the operator at the top of the stack (leaving the current token to check again at the next step), or give a parse error. The rules for deciding which of those to do are pretty simple: Given X, the operator at the top of the stack, and Y, the operator you just read: (1) Compare the precedence of X and Y. If they are incomparable, it's a parse error. (2) If Y is higher precedence than X, shift. (3) If Y is lower precedence than X, reduce. (At this point, we know X and Y have equal precedence) (4) If X or Y is non-associative, it's a parse error. (5) If X and Y don't have the same associativity, it's a parse error. (At this point we know X and Y have the same associativity) (6) If X and Y are left associative, reduce. (7) Otherwise they are both right associative, shift. So, for example, reading the expression x * y + x + g w $ z Start with stack [empty x]. The empty operator has lower precedence than anything else (that is, it will never be reduced). When you finish reading an expression, reduce until the empty operator is the only thing on the stack and return its expression. * is higher precedence than empty, shift. [empty x, * y] + is lower precedence than *, reduce. [empty (x*y)] + is higher precedence than empty, shift. [empty (x*y), + x] + is the same precedence as +, and is left associative, reduce. [empty ((x*y)+x)] + is higher precedence than empty, shift [empty ((x*y)+x), + g] function application is higher precedence than +, shift. [empty ((x*y)+x), + g, APP w] $ is lower precedence than function application, reduce. [empty ((x*y)+x), + (g w)] $ is lower precedence than +, reduce. [empty (((x*y)+x) + (g w))] $ is higher precedence than empty, shift. [empty (((x*y)+x) + (g w)), $ z] Done, but the stack isn't empty. Reduce. [empty x*y)+x) + (g w)) $ z)] Done, and the stack is empty. Result: x*y)+x) + (g w)) $ z) Each operator is shifted exactly once and reduced exactly once, so this algorithm runs in a number of steps linear in the expression size. Parentheses start a new sub-stack when parsing the 'thing to apply the operator to' part of the expression. Something like this: simple_exp :: Parser Exp simple_exp = (ExpId $ identifier) | (ExpLit $ literal) | (lparen * expression * rparen) expression :: Parser Exp expression = do first - simple_exp binops [ (Empty, first) ] reduceAll [ (Empty, e) ] = return e reduceAll ((op1, e1) : (op2, e2) : rest) = reduceAll ((op2, (ExpOperator op1 e1 e2)) : rest) binops :: Stack - Parser Exp binops s = handle_binop | handle_application | reduceAll s where handle_binop = do op - operator rhs - simple_exp reduce_until_shift op rhs s handle_application = do rhs - simple_exp reduce_until_shift FunctionApplication rhs s reduce_until_shift implements the algorithm above until it eventually shifts the operator onto the stack. identifier parses an identifier, operator parses an operator, literal parses a literal (like 3 or hello) lparen and rparen parse left and right parentheses. I haven't considered how difficult it would be to expand this algorithm to support unary or more-than-binary operators; I suspect it's not ridiculously difficult, but I don't know. Haskell's support for both of those is pretty weak, however; even the lip service paid to unary - is a source of many problems in parsing Haskell. Worse, it does not allow to set up fixity relative to operator that is not in scope and it will create unnecessary intermodule dependencies. One should fall back to numeric fixities for such cases, if it is needed. You can get numeric fixity by just declaring precedence equal to some prelude operator with the desired fixity; this will likely be the common case. I would expect modules to declare locally relative fixities between operators imported from different modules if and only if it was relevant to that module's implementation. In most cases I expect the non-ordering to be resolved by adding parentheses, not by declaring additional precedence directives; for example, even though (a == b == c) would be a parse error due to == being non-associative, both ((a == b) == c) and (a == (b == c)) are not. The same method of 'just add parentheses where you mean it' fixes any parse error due to incomparable precedences. -- ryan ___
Re: [Haskell-cafe] Fixity declaration extension
On 08/14/2012 02:52 PM, Ryan Ingram wrote: On Tue, Aug 14, 2012 at 1:04 AM, Евгений Пермяков permea...@gmail.com mailto:permea...@gmail.com wrote: Your idea looks _much_ better from code clarity point of view, but it's unclear to me, how to deal with it internally and in error messages. I'm not a compiler guy, though. How to deal with it internally: It's pretty easy, actually. The hardest part is implementing an extensible partial order; once you have that and you can use it to drive comparisons, parsing is not hard. Basically, at each step when you read an operator token, you need to decide to shift, that is, put it onto a stack of operations, reduce, that is, apply the operator at the top of the stack (leaving the current token to check again at the next step), or give a parse error. The rules for deciding which of those to do are pretty simple: Yes, I can guess it. This way. however, is linearly dependent in time from number of operators in scope. It is clearly much worse then looking into Map OperatorName Fixity . But changing numeric fixity in Map when adding operator somewhere in between existing stack is also linearly - dependent. Of course, associated penalties are small if few operators are in scope. It is unclear for me, how heavy associated penalties will be for both cases. I would expect modules to declare locally relative fixities between operators imported from different modules if and only if it was relevant to that module's implementation. Noway. Monoid, Monad and Functor are absolutely independent typeclasses and defined in different modules. There is, however, type [], which has instances for all three typeclasses, so operators for all three of them have to play together. Thus, when you create typeclass and operator-combinators for it, you should add them to entire set of operators on all hackages, as you never know, which typeclass instances will give some yet unknown types. So, rules for such cases must exists, and leaving priorities undefined is not a good way. In most cases I expect the non-ordering to be resolved by adding parentheses, not by declaring additional precedence directives; for example, even though (a == b == c) would be a parse error due to == being non-associative, both ((a == b) == c) and (a == (b == c)) are not. The same method of 'just add parentheses where you mean it' fixes any parse error due to incomparable precedences. I hate lisp-like syntax. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data structure containing elements which are instances of the same type class
On Mon, Aug 13, 2012 at 6:53 PM, Alexander Solla alex.so...@gmail.comwrote:
In a classical logic, the duality is expressed by !E! = A, and !A! = E,
where E and A are backwards/upsidedown and ! represents negation. In
particular, for a proposition P,
Ex Px = !Ax! Px (not all x's are not P)
and
Ax Px = !Ex! Px (there does not exist an x which is not P)
Negation is relatively tricky to represent in a constructive logic --
hence the use of functions/implications and bottoms/contradictions. The
type ConcreteType - b represents the negation of ConcreteType, because it
shows that ConcreteType implies the contradiction.
Put these ideas together, and you will recover the duality as expressed
earlier.
I'd been looking for a good explanation of how to get from Ex Px to !Ax! Px
in constructive logic, and this is basically it. What is said here is
actually a slightly different statement, which is what had me confused!
If you do the naive encoding, you get something like
-- This is my favorite representation of Contradiction in Haskell, since
-- it has reductio ad absurdum encoded directly in the type
-- and only requires Rank2Types.
newtype Contradiction = Bottom { absurd :: forall a. a }
-- absurd :: forall a. Contradiction - a
type Not a = a - Contradiction
newtype NotC (c :: * - Constraint) = MkNotC { unNotC :: forall a. c a =
Not a }
type UselessExists (c :: * - Constraint) = Not (NotC c)
-- here I'm using ConstraintKinds as, in a sense, the 'most generic' way of
specifying a type-level predicate,
-- at least in bleeding edge Haskell. It's trivial to make a less generic
version for any particular constraint
-- you care about without going quite so overboard on type system
extensions :)
-- i.e.
-- newtype NoShow = MkNoShow { unNoShow :: forall a. Show a = Not a }
-- type UselessExistsShow = Not NoShow
-- A simple example: there is a type that is equal to Bool:
silly :: UselessExists ((~) Bool)
silly (MkNotC k) = k True
-- need silly :: NotC ((~) Bool) - Contradiction
-- after pattern matching on MkNotC
-- k :: forall a. (a ~ Bool) = a - Contradiction
-- i.e. k :: Bool - Contradiction
-- therefore, k True :: Contradiction.
This type is useless, however; NotC c isn't usefully inhabited at any
reasonable c -- there's no way to actually call it!
The magic comes when you unify the 'return type' from the two Nots
instead of using bottoms as a catch-all... I guess this is the CPS
translation of negation?
type NotR r a = a - r
newtype NotRC r (c :: * - Constraint) = MkNotRC { unNotRC :: forall a. c a
= NotR r a }
-- MkNotRC :: forall r c. (forall a. c a = a - r) - NotRC r
type ExistsR r (c :: * - Constraint) = NotR r (NotRC r c)
-- ~= c a = (a - r) - r
newtype Exists (c :: * - Constraint) = MkExists { unExists :: forall r.
ExistsR r c }
-- MkExists :: forall c. (forall r. NotR r (NotRC r c)) - Exists c
-- ~= forall c. (forall r. c a = (a - r) - r) - Exists c
-- A simple example: there is a type that is equal to Bool:
silly2 :: Exists ((~) Bool)
silly2 = MkExists (\(MkNotRC k) - k False)
This version allows you to specify the type of 'absurd' result you
want, and use that to let the witness of existence escape out via whatever
interface the provided constraint gives.
caseExists :: (forall a. c a = a - r) - Exists c - r
caseExists k (MkExists f) = f (MkNotRC k)
main = putStrLn $ caseExists show silly2
-- should print False
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
AntC anthony_clay...@clear.net.nz writes: I agree. I don't declare operators very often, and when I do I always struggle to remember which way round the precedence numbers go. [...] (Anything else we can bikeshed about while we're at it?) infixl * before + Perhaps before and after clearer than higher and lower? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lost global Contents of haddock
Hi. I just noticed that my global Contents of the haddock documentation of modules ( file:///home/marcot/.cabal/share/doc/index.html ) lost most of the modules. My workflow is fairly straightforward, but I do some --reinstall --force-reinstalls with cabal install. For instance, the link for Prelude is not there, but Prelude.Unicode from base-unicode-symbols is present. I can still access documentation from the package's Contents page ( file:///usr/local/share/doc/ghc/html/libraries/base-4.5.1.0/index.html ). What could have caused this? Is there a way to recover all the links? I'm using Debian Squeeze with ghc-7.4.2 (installed with http://www.haskell.org/ghc/dist/7.4.2/ghc-7.4.2-x86_64-unknown-linux.tar.bz2 ), cabal install version 0.14.0, using version 1.14.0 of the Cabal library. Greetings. -- marcot http://marcot.eti.br/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Debian 6.0.5: 'cabal install curl' problem
Please help to solve a problem installing curl package ( http://hackage.haskell.org/package/curl/) on Debian 6.0.5. I am running the most recent Debian Haskell platform with GHC 6.12.1. I did: - cabal update - cabal install cabal-install It is interesting that in case you do again 'cabal update you again get a suggestion from cabal to upgrade cabal-install, and this process never ends: - cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install Anyway, then I did: - apt-get install curl - cabal install curl Cabal fails to install 'curl' because it can not find curl library. Please see detailed cabal output at the end of this message. So my questions: 1) What is missing to install curl package? 2) Should I upgrade Debian GHC 6.12.1 to the latest GHC 7.4.2? Maybe this should solve the problem with 'cabal install'? Thanks! -- cabal install output -- - cabal install curl Resolving dependencies... Configuring curl-1.3.7... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E configure: error: curl libraries not found, so curl package cannot be built See `config.log' for more details. cabal: Error: some packages failed to install: curl-1.3.7 failed during the configure step. The exception was: ExitFailure 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Debian 6.0.5: 'cabal install curl' problem
Hi dokondr. On Tue, Aug 14, 2012 at 11:23 AM, dokondr doko...@gmail.com wrote: (...) Cabal fails to install 'curl' because it can not find curl library. Please see detailed cabal output at the end of this message. Cabal means the curl C library, which must be installed by either the packages libcurl4-openssl-dev or libcurl4-gnutls-dev. If a situation like this happens again, you can search for candidate packages with: $ apt-cache search lib curl dev collectd-core - statistics collection and monitoring daemon (core system) libcurl4-gnutls-dev - Development files and documentation for libcurl (GnuTLS) libcurl4-openssl-dev - Development files and documentation for libcurl (OpenSSL) devscripts - scripts to make the life of a Debian Package maintainer easier libflickcurl-dev - C library for accessing the Flickr API - development files libghc6-curl-dev - GHC 6 libraries for the libcurl Haskell bindings liblua5.1-curl-dev - libcURL development files for the Lua language version 5.1 liblua5.1-curl0 - libcURL bindings for the Lua language version 5.1 libwww-curl-perl - Perl bindings to libcurl libcurl-ocaml-dev - OCaml libcurl bindings (Development package) python-pycurl-dbg - Python bindings to libcurl (debug extension) python-pycurl - Python bindings to libcurl tclcurl - Tcl bindings to libcurl php5-curl - CURL module for php5 Or, even better, use the aptitude interface and search (with /) for lib curl dev, which will lead you directly to the right package in this case. Greetings. (...) -- marcot http://marcot.eti.br/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
On 14/08/12 13:46, Ketil Malde wrote: AntC anthony_clay...@clear.net.nz writes: I agree. I don't declare operators very often, and when I do I always struggle to remember which way round the precedence numbers go. [...] (Anything else we can bikeshed about while we're at it?) infixl * before + Perhaps before and after clearer than higher and lower? I would pick tighter than and looser than, but I suppose that before and after are also clear enough. Or maybe inside and outside? I don't think that we really need a new keyword for precedence declarations. The current infix would suffice if the default was for operators to be non-fix and of indeterminate precedence. Multiple fixity declarations for the same operator should then be allowed. Or perhaps just require that separate declarations use the same infix[lr]? keyword. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
2012/8/14 Alexander Kjeldaas alexander.kjeld...@gmail.com: On 13 August 2012 23:49, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote: This isn't that hard - a pipe shouldn't be needed anymore. Just require a post-2003 glibc. fexecve is a system call in most BSDs. It is also implemented in glibc using a /proc hack. fexecve is now in the Single Unix Specification, based on POSIX as of 2008, I believe. However, http://www.gnu.org/software/gnulib/manual/html_node/fexecve.html says Portability problems not fixed by Gnulib: * This function is missing on many non-glibc platforms: MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, Interix 3.5, BeOS. That warning doesn't seem to be fully up to date. I'm using MacOS X 10.6.8 and fexecve() isn't in the manuals or in unistd.h. FreeBSD 8.0 is covered. OpenBSD not covered OS X not covered http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/execve.2.html Solaris probably not covered. So support is pretty good, I'd say. For non-modern systems, checking the existence of the file first is possible. The race isn't important, and one can always upgrade to a modern operating system. The check would be unreliable, the file's existence doesn't imply that it's executable. Furthermore it would add unnecessary overhead, createProcess can be run thousands of times in a program and should be lean and mean. Niklas Alexander ___ 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] Debian 6.0.5: 'cabal install curl' problem
Marcot, Thanks for the detailed info! Looks like aptitude install libcurl4-gnutls-dev solved the problem. cheers, Dmitri On Tue, Aug 14, 2012 at 6:29 PM, Marco Túlio Pimenta Gontijo marcotmar...@gmail.com wrote: Hi dokondr. On Tue, Aug 14, 2012 at 11:23 AM, dokondr doko...@gmail.com wrote: (...) Cabal fails to install 'curl' because it can not find curl library. Please see detailed cabal output at the end of this message. Cabal means the curl C library, which must be installed by either the packages libcurl4-openssl-dev or libcurl4-gnutls-dev. If a situation like this happens again, you can search for candidate packages with: $ apt-cache search lib curl dev collectd-core - statistics collection and monitoring daemon (core system) libcurl4-gnutls-dev - Development files and documentation for libcurl (GnuTLS) libcurl4-openssl-dev - Development files and documentation for libcurl (OpenSSL) devscripts - scripts to make the life of a Debian Package maintainer easier libflickcurl-dev - C library for accessing the Flickr API - development files libghc6-curl-dev - GHC 6 libraries for the libcurl Haskell bindings liblua5.1-curl-dev - libcURL development files for the Lua language version 5.1 liblua5.1-curl0 - libcURL bindings for the Lua language version 5.1 libwww-curl-perl - Perl bindings to libcurl libcurl-ocaml-dev - OCaml libcurl bindings (Development package) python-pycurl-dbg - Python bindings to libcurl (debug extension) python-pycurl - Python bindings to libcurl tclcurl - Tcl bindings to libcurl php5-curl - CURL module for php5 Or, even better, use the aptitude interface and search (with /) for lib curl dev, which will lead you directly to the right package in this case. Greetings. (...) -- marcot http://marcot.eti.br/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
On 14 August 2012 17:22, Niklas Larsson metanik...@gmail.com wrote: 2012/8/14 Alexander Kjeldaas alexander.kjeld...@gmail.com: On 13 August 2012 23:49, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote: This isn't that hard - a pipe shouldn't be needed anymore. Just require a post-2003 glibc. fexecve is a system call in most BSDs. It is also implemented in glibc using a /proc hack. fexecve is now in the Single Unix Specification, based on POSIX as of 2008, I believe. However, http://www.gnu.org/software/gnulib/manual/html_node/fexecve.html says Portability problems not fixed by Gnulib: * This function is missing on many non-glibc platforms: MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, Interix 3.5, BeOS. That warning doesn't seem to be fully up to date. I'm using MacOS X 10.6.8 and fexecve() isn't in the manuals or in unistd.h. FreeBSD 8.0 is covered. OpenBSD not covered OS X not covered http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/execve.2.html Solaris probably not covered. So support is pretty good, I'd say. For non-modern systems, checking the existence of the file first is possible. The race isn't important, and one can always upgrade to a modern operating system. The check would be unreliable, the file's existence doesn't imply that it's executable. See access(2) Furthermore it would add unnecessary overhead, createProcess can be run thousands of times in a program and should be lean and mean. Just to keep the bikeshedding doing, I'm going to state as a fact that running performance sensitive *server* workload on any unix other than Linux is purely of theoretical interest. No sane person would do it. Therefore, from a performance overhead, Linux performance is the only important performance measure. But even given the above, the overhead we're talking about is minuscule. A program like '/bin/echo -n ''' which does exactly *nothing*, requires 35(!) system calls to do its job :-). A more complex program like 'id' requires 250 system calls! Also, to see just how minuscule this is, the dynamic linker, ld-linux.so does a few extra access(2) system calls *to the same file*, /etc/ld.so.hwcaps, on startup of every dynamically linked executable. 2 in the 'echo' case, and 8 in the 'id' case above. Even the glibc folks haven't bothered to optimize those syscalls away. Alexander ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I use cabal install repa but then WinGHCi says module Data.Array.Rep.Algorithms.Ramdomish not found.
On 14/08/2012 7:17 AM, KC kc1...@gmail.com wrote: The install of repa-algorithms fails saying it can't cannot find an llvm. In any case why can't the install syntax be cabal install repa.algorithms then it would be more consistent with the import statement. Because the name of the package is repa-algorithms, not repa.algorithms or Repa.Algorithms. On Sun, Aug 12, 2012 at 4:00 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I think you need to install repa-algorithms. On 13 August 2012 04:18, KC kc1...@gmail.com wrote: -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Debian 6.0.5: 'cabal install curl' problem
On Tue, Aug 14, 2012 at 10:23 AM, dokondr doko...@gmail.com wrote: Anyway, then I did: - apt-get install curl - cabal install curl Cabal fails to install 'curl' because it can not find curl library. Please see detailed cabal output at the end of this message. Just as a general thing, almost all Linux distributions separate the runtime and development components of any package; if you need developer libraries, you need to install the -dev / -devel package corresponding to the runtime package. (I have never been convinced this actually accomplishes anything other than causing lots of support questions; any space that might be saved by not installing a bunhc of tiny headers and a symlink or two is then lost by having several GB of Gnome libraries in a basic install.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] For consistency; it would be better if the import statement matched the cabal install statement or :m form.
:m +Data.Array.Repa.Algorithms.Randomish cabal install repa.algrothms would be more consistent. -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For consistency; it would be better if the import statement matched the cabal install statement or :m form.
On Tue, Aug 14, 2012 at 11:04 PM, KC kc1...@gmail.com wrote:
:m +Data.Array.Repa.Algorithms.Randomish
cabal install repa.algrothms
would be more consistent.
What do you do when multiple modules use the same namespace?
(monads-{fd,tf} and the regex modules being cases in point)
--
brandon s allbery allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess running non-existent programs
Quoth Alexander Kjeldaas alexander.kjeld...@gmail.com, See access(2) ... a classic code smell in UNIX programming, for the same reasons. We can solve this problem in an efficient way that works well, and equally well, on any POSIX platform that supports F_CLOEXEC on pipes, and I can't think of anything that doesn't. The appended code is the basic gist of it. This was not invented by the Python world, but as suggested it's one of the things that we'd get from a review of their subprocess module. Donn spawn file cmd env = do (e0, e1) - pipe fcntlSetFlag e1 F_CLOEXEC t - fork (fex e0 e1) close e1 rx - readFd e0 256 if null rx then return t else ioerr (chrToErrType rx) file where fex e0 e1 = do close e0 catch (execve file cmd env) (\ e - writeFd e1 (errToChr e : ioeGetErrorString e)) ioerr (e, s) file = ioError (mkIOError e s Nothing (Just file)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
