[Haskell-cafe] Hackage upload problem
Hi, I get the following error when I try to upload gf-3.5.tar.gz [1] to Hackage. 400 Error in upload could not extract gf-3.5 directory from gf-3.5.tar.gz I get the same error when I try to Check the previous version, gf-3.4.tar.gz [2], which was uploaded without problems 6 months ago [3], so it seems that something has changed on the server. Does anyone know what it could be that is going wrong? Is there a way to get a more informative error message? Thomas H [1] http://www.grammaticalframework.org/download/gf-3.5.tar.gz [2] http://www.grammaticalframework.org/download/gf-3.4.tar.gz [3] http://hackage.haskell.org/package/gf-3.4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage upload problem
On 2013-08-07 17:06 , Duncan Coutts wrote: On Wed, 2013-08-07 at 14:32 +0200, Thomas Hallgren wrote: Hi, I get the following error when I try to upload gf-3.5.tar.gz [1] to Hackage. 400 Error in upload could not extract gf-3.5 directory from gf-3.5.tar.gz I get the same error when I try to Check the previous version, gf-3.4.tar.gz [2], which was uploaded without problems 6 months ago [3], so it seems that something has changed on the server. Does anyone know what it could be that is going wrong? Is there a way to get a more informative error message? You're welcome to try uploading it to the new-hackage.haskell.org and see if that gives a more informative error message. If it's a poor error message there then we can fix that. Duncan new-hackage.haskell.org didn't work either, it says: Reached disk quota of 100 bytes. gf-3.5.tar.gz is a lot bigger than 100 bytes. I am guessing this restriction only applies on new-hackage, and that there is a different problem on old hackage... Thomas H ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite this imperative in FP way
How about this: import Array a = [1,1,1,1] b = [0,1,2,3] c = [0,2] d = elems $ accumArray (+) 0 (0,3) [(i+j,a!!i) | i-b, j-c, i+j3] -- Thomas H On 2012-02-06 12:01 , Haisheng Wu wrote: *d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] * This is cool. -Simon On Sun, Feb 5, 2012 at 5:07 PM, L Corbijn aspergesoe...@gmail.com mailto:aspergesoe...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu fre...@gmail.com mailto:fre...@gmail.com wrote: a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe There are several ways to make it nicer. Without assumption on what lists a, b and c contain it can be written as d = [sum $ map (a !!) [i | i - b, j - c, i + j 3, i + j == dIndex] | dIndex - [0..3]] With the assumption that b and c are both [0..3] this can be 'improved' to d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 This generates the first three values by the complicated expression and then adds the extra zero's by using the replicate expression. This works as the value of the i-th element of d is the sum over the first i elements in a if i 3 and 0 otherwise. A list of lists with the first i elements is generated with 'tail $ inits a' which is then summed and restricted to length 3. An alternative for this is d = (take 3 . snd $ mapAccumL (\acc ai - (acc + ai, acc + ai)) 0 a) ++ replicate (4 - 3) 0 Where the summation and tail generating is done in the mapAccumL function. Greetings, Lars P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to explicitly include the length (4) of the expected list. ___ 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] Re: Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On 2009-01-08 12:10, Achim Schneider wrote: Manlio Perillomanlio_peri...@libero.it wrote: Unfortunately Haskell is not yet ready for this task. Could you -- or someone else -- please elaborate on this? I think Haskell is ready for a lot more than most people think. How about an operating system in Haskell, for example? I think House shows that it could be done. http://programatica.cs.pdx.edu/House/ I've heard it once in the context of a webbrowser, the reason given was that ghc doesn't deallocate memory, that is, the gc heap only increases. I doubt it'd be hard to fix, Even if the GHC RTS doesn't return unused heap memory to the operating system, I don't see why this would prevent you from implementing a useful web browser in Haskell. As a comparison, my Firefox process currently uses 717MB of memory. I usually restart Firefox every day to bring the memory use down to a reasonable level. The situation would probably be the same if I used a browser implemented in Haskell. Incidentally, I did implement a web browser in Haskell back in the 90s, and it worked fine :-) But that was before JavaScript and CSS, so it would take some work to make it useful on the web of today... http://www.cs.chalmers.se/~hallgren/wwwbrowser.html Thomas Hallgren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
Brian Hulley wrote: Another thing which causes difficulty is the use of qualified operators, and the fact that the qualification syntax is in the context free grammar instead of being kept in the lexical syntax (where I think it belongs). You are in luck, because according to the Haskell 98 Report, qualified names are in the lexical syntax! http://www.haskell.org/onlinereport/syntax-iso.html So, C.f is a qualified name, but C . f is composition of the Constructor C with the function f. -- Thomas H ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] programatica and haddock
Hi,
Christian Maeder wrote:
I would like to see the advantages of both, programatica's documentation
generation and haddock, to be united. (programatica sources don't go
through haddock and have few type signatures that haddock could exploit,
and haddock comments are useless for programatica.)
Unfortunately, the markup used by both programs is different. {-+ in
programatica and {- | in haddock.
Is there any chance that both documentation approaches could be streamlined?
Yes, adding support for Haddock style comment markup to the current HTML
renderer in the Programatica tools shouldn't be hard, so I might do
that. If I also add support for generating Haddock style documentation,
I could take advantage of the fact that the Programatica tools can infer
types, to compensate for the lack of explicit type signatures in source
code.
--
Thomas H
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Tool To Show Functions Relationship?
Dimitry Golubovsky wrote: Does there exist a tool which given a Haskell source, shows functions that are mutually recursive (i. e. call each other, even via calling third, etc. functions)? With pfe, the Programmatica tools command line interface, you can currently get a list of definition level dependencies like this (assuming your module is called Example): % pfesetup +h Example.hs % pfe deps Example module DepExample: declarator: Text.ParserCombinators.Parsec.Prim.? Text.ParserCombinators.Parsec.Prim.try Hugs.Prelude.Monad Hugs.Prelude.= pointer idd Text.ParserCombinators.Parsec.Prim.many cpi Hugs.Prelude.return Declarator Text.ParserCombinators.Parsec.Prim.inst__Text_ParserCombinators_Parsec_Prim_Monad__l_GenParser_tok_st_r_ idd: Text.ParserCombinators.Parsec.Prim.? Text.ParserCombinators.Parsec.Prim.| Text.ParserCombinators.Parsec.Prim.try Hugs.Prelude.Monad Hugs.Prelude.= anyIdString Hugs.Prelude.return Hugs.Prelude.Either Hugs.Prelude.Left Hugs.Prelude. tkOp declarator Hugs.Prelude.Right Text.ParserCombinators.Parsec.Prim.inst__Text_ParserCombinators_Parsec_Prim_Monad__l_GenParser_tok_st_r_ ... The dependency information is computed after type checking, so it includes dependencies on instance declarations (which are assign names starting with inst__). I guess it would be usesful to also have an option to eliminate dependencies on imported stuff, and an option to display mutually recursive groups (strongly connected components of definitions). Knowledge of that would help to split the module into smaller modules without risk to create recursive modules. The Programatica tools actually support mutually recursive modules, so that wouldn't be a problem. We are still waiting for other Haskell implementations to catch up :-) -- Thomas H ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bit fiddling
Hi, Florian Weimer wrote: I'm toying a bit with Haskell and wondering what's the best way to implement bit fiddling. Most of my applications involve serializing and deserializing small blobs (IP packets, for instance), and after browsing the GHC library documentation, I'm not sure which appraoch I should use. That's why I'd appreciate pointers to sample code. In the protocol stack in House [1], I have used parsing/unparsing combinators to (de)serialize network packets. This allows the code to be simple, pure and modular, even though you are dealing with data down to the bit level. The way things work at the moment, the network device driver returns incoming packets as unboxed arrays of bytes (values of type UArray Int Word8), and the parsing combinators maintain these along with position information down to the bit level, allowing you to parse input bit by bit. The process is reversed in the unparsing combinators. (What would be nice to have for this is efficient library functions for manipulation of bit vectors of arbitrary dynamic size...) The source code is available on the web, see for example modules Net.Ethernet, Net.ARP, Net.ICMP, Net.IPv4: http://www.cse.ogi.edu/~hallgren/House/kernel/#Net Note though that this is work in progress, there is not much documentation, and the code for several of the protocols is incomplete. -- Thomas H [1] http://www.cse.ogi.edu/~hallgren/House/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] coercion to Int
james pentland wrote: what coercion can i use to get the below program to compile? ... various combinations of fromInteger, toInteger do not help. Did you try fromIntegral? fromIntegral :: (Integral a, Num b) = a - b fnK_ :: Int - Int fnK_ x = round (sqrt x) -- line 2 -- Thomas H ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality of functions
Adam Zachary Wyner wrote: Hi All, After some weeks of experimenting and digging around, I understand that functions cannot be compared for equality. Thanks to Bjorn Lisper for pointing this out. I basically understand (?) the underlying mathematical issue, which is that functions in general may have infinite domains... Other suggestions? You can define equality for functions with finite domains. See the enclosed Haskell module. Loading package base ... linking ... done. Compiling Finite ( Finite.hs, interpreted ) Ok, modules loaded: Finite. *Finite not == not True *Finite () == () True *Finite () == (||) False -- Thomas H module Finite where instance (Finite a, Eq b) = Eq (a-b) where f == g = and [ f x == g x | x - allValues ] -- A class for finite types class Finite a where allValues :: [a] instance Finite () where allValues = [()] instance Finite Bool where allValues = [False,True] --instance Finite Ordering where ... --instance Finite Char where ... --instance Finite Int where ... instance (Finite a,Finite b) = Finite (a,b) where allValues = [ (x,y) | x-allValues, y-allValues] instance Finite a = Finite (Maybe a) where allValues = Nothing:[Just x|x-allValues] instance (Finite a,Finite b) = Finite (Either a b) where allValues = [Left x|x-allValues]++[Right y|y-allValues] -- ... ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] readEitherChan
Tomasz Zielonka wrote: On Tue, Jun 15, 2004 at 06:29:59PM -0400, S. Alexander Jacobson wrote: readEitherChan::Chan a - Chan b - Either a b eitherChan a b left right = readEitherChan a b = either left right ... I think it would be safer to create once new Chan (Either a b), and then read from it. createEitherChan :: Chan a - Chan b - IO (Chan (Either a b)) Although createEitherChan might be the best solution for some application, it would be interesting to know what the recommended way to implement the function eitherChan above is, if that is what you really need? The eitherChan function corresponds to guarded nondeterministic choice, usually written (a?P)+(b?Q) process calculi, i.e., a rather fundamental concurrency operator. Section 5 of [1] enumerates some reasons why guarded nondeterministic choice is not available as a primitive in Concurrent Haskell. Section 5.2 describes a function select for nondeterministic choice, but I don't see how to use that to implement readEitherChan (or takeEitherMVar)... I got interested in this the other day when I was contemplating reviving Gadget Gofer [2], by porting it to Concurrent Haskell. Gadget Gofer has a non-deterministic choice operator, though, so the port would probably require more work than I expected... -- Thomas H [1] Concurrent Haskell http://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz [2] Lazy Functional Components for Graphical User Interfaces, Rob Noble, PhD thesis, York, 1996 signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Simple Fudgets-question
Henrik Berg wrote: Thomas Hallgren [EMAIL PROTECTED] writes: ... All I want to do is to resend the input out on the output. If that is all you want, this combinator is the right choice: throughF :: F a b - F a (Either b a) Yes, but (Either b a) won't give me the input _together_ with the output, will it? I need a fudget that accepts some input, does some work on it, and outputs the result _and_ the original input for further processing by other fudgets. As far as I can see, this means I need a tupple (a, b), and not the disjoint sum (Either a b). Aha, I suspected you wanted something more :-) Fudgets are asynchronous in nature, so there is no single right way to merge two streams into a stream of pairs, and I guess that is why there is no combinator for it in the library. Here is some code I found in an old example, illustrating one way to do it... collectF :: F (Either a b) (a,b) collectF = absF (collectSP Nothing Nothing) collectSP :: Maybe a - Maybe b - SP (Either a b) (a,b) collectSP x y = case (x,y) of (Just x,Just y) - putSP (x,y) (collectSP Nothing Nothing) _ - getSP (\msg - case msg of Right y - collectSP x (Just y) Left x - collectSP (Just x) y ) -- This is how collectF was used: --fileF = collectF==throughF fileDialogF==fileMenuF -- Thomas H ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: interact behaves oddly if used interactively
John Meacham wrote: personally, I think the easiest solution would be to punt the whole issue by having: getContents lazily read the file if it is mmapable or a pipe eagerly slurp the whole file if it refers to a tty I think this kind of irregular behaviour would make the IO functions even more difficult to understand. Why should some invokations of the same program exhibit utterly different space/time behaviour from others?! mycomputer% ./myprogram mycomputer% cat | ./myprogram mycomputer% ./myprogram myfile mycomputer% luit ./myprogram of course this makes 'interact' not really interactive, Exactly, it defeats the whole purpose of the interact function (to provide support for Landin-stream IO), so you might just as well remove it completely... -- Thomas H ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fudgets
Ashley Yakeley wrote: Would it be worth rewriting Fudgets to take advantage of such recent advances in Haskell as monadic IO? A rejuvenation of Fudgets, taking advantage of things like subtyping, multi-parameter classes with functional dependencies, syntactic sugar for arrows, making room for monadic IO, and using a more modern graphics subsystem, would probably make Fudgets much more interesting. Actually, Fruit [1], although it is independent work, could be seen as a redesign/rejuvenation of Fudgets. Allowing arbitrary monadic IO inside fudgets is not impossible, see [2], but while it would give access to modern things like the FFI, it would also mean giving up some of the purity and elegance of fudgets. The old approach to IO, where every IO operation is a constructor in a data type, means that all IO operations can be examined and manipulated within the program in interesting ways, by just adding a wrapper around the main function. For example, when a fudget program is run with the -debug flag, a trace of all IO operations and their results is printed on stderr. As another example, the cacheF fudget wrapper speeds up fudget programs by caching the result of requests for colors, fonts and other GUI resources. It would be easy to write a wrapper that swaps the left and right mouse buttons, or makes a program ask for the user's permission before deleting a file. Try doing things like that by adding a wrapper around a value of type IO()! I must confess I'm not all that familiar with Fudgets, although it certainly looks interesting. For what sort of problems is it currently the best solution? I guess it depends on what you are comparing to, but if you like programming GUIs in a declarative style, you don't need the FFI but can live with the IO operations already provided by the fudget library (which includes file/directory access and networking), or perhaps you want to experiment with implementing your own special purpose widgets in Haskell (Fudgets implements its own widget set in Haskell), then using Fudgets might be a good choice. But when the GUI starts getting big and irregular, the plumbing can become a bit clumpsy (some would even say painful, worse than having a tooth pulled :-). -- Thomas H [1] http://www.haskell.org/fruit [2] http://www.cs.chalmers.se/~hallgren/Thesis/fudgets-implementation.html#fudgets-on-monadIO ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: unification
David Feuer wrote: Has anyone written an efficient purely-functional implementation of unification (for type checking)? Well, if you have ever used hbc or nhc, you have used type checkers containing purely functional implementations of unification. Purely functional unification can be efficient enough for practical purposes... Thomas H ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
