Re: [Haskell-cafe] hledget: mtv vs transformers
On Fri, Jan 21, 2011 at 8:02 AM, Michael Snoyman wrote: > Couldn't you depend on either version of mtl? > Point is that in this particular case two different versions of mtl are being pulled in the compilation by different dependencies. Plus, transformers 0.2.* is selected as well. Cabal reasons along the following lines: one dependency is hledger 0.13, which is built against the mtl 1.x. Selecting both another dependency is Chart, which is built against transformers 0.2.x Now instances from transformers conflict with those from mtl 1.x, when you are building hledger-chart Plus, when you are rebuilding hledger-0.13 from scratch, they start to conflict as well. Add in the mix deficiency of 6.12.1 which is sometimes picks up wrong version of packages (or so I remember), and all the hell breaks loose. The only solution for me was to bump mtl to 2.x, rebuild everything depending on mtl, and something pulled in newer "process" in the process, which caused another wave of rebuilds. With 6.12.3 or 7.0.1 everything is way easier (as expected) :) > > On Fri, Jan 21, 2011 at 3:37 AM, Simon Michael wrote: > > You mean mtl 2.*, right ? > > > > Yes that is a problem. I'm nervous about requiring mtl 2 because when I > > bumped hledger 0.13's process dependency to 0.14 for similar reasons it > made > > all kinds of trouble for folks who just want to install the hledger core > in > > standard/older haskell environments. > > > > On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: > >> > >> Since hledger-chart depends on Chart, which in turn depends on > >> transformers 0.2.*, it will make a sense to bump all mtl dependencies in > >> hledger to 2.2 > >> > >> When one does "make install" with older GHC (like 6.12.1, for example), > >> and mtl 1.x is available, it would be happily used for hledger-lib and > >> hledger, but compilation of hledger-chart will pull in transformers 0.2 > (but > >> not the newer mtl) and will fail due to conflicting instances. > > > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- Dmitry Astapov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hledget: mtv vs transformers
On Fri, Jan 21, 2011 at 3:37 AM, Simon Michael wrote: > You mean mtl 2.*, right ? > > Yes that is a problem. I'm nervous about requiring mtl 2 because when I > bumped hledger 0.13's process dependency to 0.14 for similar reasons it made > all kinds of trouble for folks who just want to install the hledger core in > standard/older haskell environments. Well, chalk me up as the person with standard/old haskell environment :) I have many versions of GHC installed, plus I have a Haskell Platform from .debs as provided by Debian/unstable. That version of HP still carries GHC 6.12.1 and mtl 1.* Using that, it is impossible to "make install" hledger for the reasons outlined below - you either have to exclude hledger-chart, or build fails. > > > On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: > >> Since hledger-chart depends on Chart, which in turn depends on >> transformers 0.2.*, it will make a sense to bump all mtl dependencies in >> hledger to 2.2 >> >> When one does "make install" with older GHC (like 6.12.1, for example), >> and mtl 1.x is available, it would be happily used for hledger-lib and >> hledger, but compilation of hledger-chart will pull in transformers 0.2 (but >> not the newer mtl) and will fail due to conflicting instances. >> > > -- Dmitry Astapov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] haskell-mpi-1.0.0
Dear Haskellers, We are pleased to announce the release of haskell-mpi-1.0.0, a suite of Haskell bindings to the C MPI library and convenience APIs on top of it. About MPI - MPI, the Message Passing Interface, is a popular communications protocol for distributed parallel computing (http://www.mpi-forum.org/). MPI applications consist of independent computing processes which share information by message passing. It supports both point-to-point and collective communication operators, and manages much of the mundane aspects of message delivery. There are several high-quality implementations of MPI available, all of which conform to the standard API specification (the latest version of which is 2.2). The MPI specification defines interfaces for C, C++ and Fortran, and bindings are available for many other programming languages. About Haskell-MPI - As the name suggests, Haskell-MPI provides a Haskell interface to MPI, and thus facilitates distributed parallel programming in Haskell. It is implemented on top of the C API via Haskell's foreign function interface. Haskell-MPI provides three different ways to access MPI's functionality: * A direct binding to the C interface (see Control.Parallel.MPI.Internal). * A convenient interface for sending arbitrary serializable Haskell data values as messages (see Control.Parallel.MPI.Simple). * A high-performance interface for working with (possibly mutable) arrays of storable Haskell data types (see Control.Parallel.MPI.Fast). We do not currently provide exhaustive coverage of all the functions and types defined by MPI 2.2, although we do provide bindings to the most commonly used parts. In future we plan to extend coverage based on the needs of projects which use the library. The package is available from http://hackage.haskell.org/package/haskell-mpi. Examples and comprehensive testsuite are included in the source distribution. Code was tested on 32- and 64-bit platforms, with MPICH2 and OpenMPI. The Fast API shows performance comparable to C, and the Simple API is generally 2-7 time slower due to (de)serialization overhead and necessity to issue additional MPI requests behind the curtains in some cases. Bernie Pope started this project as a rewrite of hMPI which was written by Michael Weber and Hal Daume III. He was later joined by Dmitry Astapov, working on the library as part of Well-Typed LLP's Parallel Haskell Project. Development is happening on GitHub, in git://github.com/bjpop/haskell-mpi. Please join in! Sincerely yours, Dmitry Astapov, Bernie Pope -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] Parallel Haskell project underway
On Mon, Nov 15, 2010 at 5:44 PM, Neil Brown wrote: > On 15/11/10 15:23, Dmitry Astapov wrote: > >> >> [snip] > This is slightly OT, but having used WinBUGS a little, I am very pleased to > see this listed as a project. WinBUGS is a commendable piece of work, but > is really showing its age these days. Between its really horrible error > messages if anything goes wrong, awkward scripting/job-running interface > (slightly eased by R2WinBUGS), and of course lack of support for multicore, > I think this is a case where parallel Haskell could provide a lot of > benefits over the existing software. > This is very interesting, thank you for your input! > > Also, can you tell us which (if any) of these projects will be released as > open-source? > This is a multi-faceted issue. First of all, all work done in the scope of this projects on the existing tools (like GHC, Cabal, various other packages, ...) would be released under the respective licenses. If, during the course of the project, we would identify the need to develop libraries and tools that would be of general utility, we would strive to release them under open-source licenses. What would happen with anything developed for the specific need of project participants would be up to them, but then such sources would probably be of little interest to public anyway. -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] Parallel Haskell project underway
Parallel Haskell project underway GHC HQ and Well-Typed are pleased to report that work has started on the MSR-funded project to push the real-world use of parallel Haskell. We will be working with four industrial partners over the next two years, with the aim of demonstrating that parallel Haskell can be employed successfully in industrial projects. The participating organizations are: * Dragonfly (New Zealand) * IIJ Innovation Institute Inc. (Japan) * Los Alamos National Laboratory (USA) * Willow Garage Inc. (USA) Each group is working on their own project, applying parallel Haskell and their domain-specific expertise. In addition to providing advice on Haskell tools and techniques, we will work with these partners to identify and resolve any issues that are hindering progress. We are prepared to handle issues covering anything from the compiler and runtime system, through to platform, tool and library problems. All the participants are working on complex, real-world problems. Three projects involve scientific problems, and the fourth involves network servers. Three of the projects are targeting single-node SMP systems, while the fourth is targeting clusters. In two cases, Haskell will be directly pitted against existing code written in C or C++. Project progress reports will be posted to the Well-Typed blog [1] and to the new Parallel Haskell mailing list [2]. [1]: http://www.well-typed.com/blog/ [2]: http://groups.google.com/group/parallel-haskell == Dragonfly == http://www.dragonfly.co.nz/ Participants: Finlay Thompson, Edward Abraham Cloudy Bayes: Hierarchical Bayesian modeling in Haskell The Cloudy Bayes project aims to develop a fast Bayesian model fitter that takes advantage of modern multiprocessor machines. It will support model descriptions in the BUGS model description language (WinBUGS, OpenBUGS, and JAGS). It will be implemented as an embedded domain specific language (EDSL) within Haskell. A wide range of model hierarchical Bayesian model structures will be possible, including many of the models used in medical, ecological, and biological sciences. Cloudy Bayes will provide an easy to use interface for describing models, running Monte Carlo Markov chain (MCMC) fitters, diagnosing performance and convergence criteria as it runs, and collecting output for post-processing. Haskell's strong type system will be used to ensure that model descriptions make sense, providing a fast, safe development cycle. == IIJ Innovation Institute Inc. == http://www.iij-ii.co.jp/en/ Participants: Kazu Yamamoto Haskell is suitable for many kinds of domain, and GHC's support for lightweight threads makes it attractive for concurrency applications. An exception has been network server programming because GHC 6.12 and earlier have an IO manager that is limited to 1024 network sockets. The upcoming GHC 7 has a new IO manager implementation that gets rid of this limitation. This project will implement several network servers to demonstrate that Haskell is suitable for network servers that handle a massive number of concurrent connections. == Los Alamos National Laboratory == http://www.lanl.gov/ Participants: Michael Buksas, Timothy M. Kelley This project will use parallel Haskell to implement high-performance Monte Carlo algorithms, a class of algorithms which use randomness to sample large or otherwise intractable solution spaces. The initial goal is a particle-based MC algorithm suitable for modeling the flow of radiation, with application to problems in astrophysics. From this, the project is expected to move to identification of suitable abstractions for expressing a wider variety of Monte Carlo algorithms, and using models for different physical phenomena. == Willow Garage == http://www.willowgarage.com/ Participants: Ryan Grant Distributed Rigid Body Dynamics in ROS Willow Garage seeks a high-level representation for a distributed rigid body dynamics simulation, capable of excellent parallel speedup on current and foreseeable hardware, yet linking to existing optimized libraries for low-level message passing and matrix math. This project will drive API, performance, and profiling tool requirements for Haskell's interface to the Message Passing Interface (MPI) specification, an industry-standard in High Performance Computing (HPC), as used on clusters of many nodes. Competing internal initiatives use C++/MPI and CUDA directly. Willow Garage aims to lay the groundwork for personal robotics applications in everyday life. ROS (Robot Operating System - ROS.org) is an open source, meta-operating system for your robot. -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://
Re: [Haskell-cafe] Stack Overflow?
On Thu, Nov 11, 2010 at 4:58 PM, Ben Christy wrote:
> I have implemented a scene graph in Haskell and I have a problem. I walk
> down the scenegraph and at each node I recalculate translation matrix and
> pass it to each child. Well it seems to be causing a stack overflow and I am
> lost as to how to resolve the issue without issue a state variable of some
> kind to hold a "matrix stack" as is common in imperative implementations of
> scene graphs. When I run the program fromghci I get
[snip]
> Matrix4x4 {i1j1 = : <>
> : interrupted
Check the expression for i1j1 - seems like it boils down to "let x = x in x"
--
Dmitry Astapov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: flow2dot
Anakreon Mendis csd.auth.gr> writes: > > I've installed the flow2dot utility. It fails to produce a dot > file from the sample provided by it's author. The output of the program > is: [skip] Are you sure you are using version 0.7, since this is when "order" directive came into existence? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Uniplate + strict fields = fail. Why?
Hi,
I've been playing with generics in general (pardon the pun) and Uniplate in
particular, and found out that strict data fields somehow derail Uniplate.
Observe:
=== code ===
{-# LANGUAGE DeriveDataTypeable #-}
module Test where
import Data.Generics (Data(..),Typeable(..))
import Data.Generics.PlateData
import Data.ByteString
import Data.ByteString.Char8 as C
data Foo = Foo String deriving (Show, Data, Typeable)
tst1 = [ Foo "a", Foo "b" ]
test1 = [ show x | Foo x <- universeBi tst1 ]
-- *Test> test1
-- ["\"a\"","\"b\""]
data Bar = Bar ByteString deriving (Show, Data, Typeable)
tst2 = [ Bar (C.pack "a"), Bar (C.pack "b") ]
test2 = [ show x | Bar x <- universeBi tst2 ]
-- *Test> test2
-- *** Exception: Prelude.undefined
=== end of code ===
First, I thought that instance of Data for ByteString is somehow deficient,
but this is not the case.
If you change definition of Foo to "data Foo = Foo !String", you would get
the same error with "Prelude.undefined".
Since all fields in ByteString constructors are strict, I have no joy trying
to use it with Uniplate.
Howere, my type-foo is not strong enough to understand what's wrong. Could
someone give me a hint?
PS
ghc 6.10.4
uniplate 1.2.0.3
bytestring 0.9.1.4
PPS
Neil Mitchell is receiving a copy of this email
--
Dmitry Astapov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] Hitchhikers guide to Haskell - chapter 5 is online
It's bigger. It's better. It now comes with source code included. If you already know what it is - just go and read a new chapter. If you dont know what it is - just go and read it from the very beginning. http://www.haskell.org/haskellwiki/Hitchhikers_guide_to_Haskell Or "darcs get http://adept.linux.kiev.ua/repos/hhgtth"; and drown me in patches. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Chapter 4 of Hitchhikers Guide to the Haskell is out
Hello, After great amount of procrastination I finally put online the next installment of my Haskell tutorial, which could be found at http://www.haskell.org/haskellwiki/Hitchhikers_Guide_to_the_Haskell Many thanks to all who commented on my efforst, spell-checked the text and urged me to go forward. As alway I'm interested in any feedback. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HitchhickersGuideToTheHaskell - Chapter 3 ...
... which deals with QuickCheck and type classes, have been uploaded to http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell. Any feedback and criticism is gratly appreciated! -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Guess what ... Tutorial uploaded! :)
Evening, Ben. Ben Rudiak-Gould <[EMAIL PROTECTED]> 00:46 24/1/2006 wrote: BR> Dmitry Astapov wrote: >> http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell BR> I like the approach too, but the section on IO actions, which I'm BR> reading now, is not correct. I significantly rewrote it. This one should be better. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Guess what ... Tutorial uploaded! :)
Evening, Ben. Ben Rudiak-Gould <[EMAIL PROTECTED]> 00:46 24/1/2006 wrote: BR> Dmitry Astapov wrote: >> http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell BR> I like the approach too, but the section on IO actions, which I'm BR> reading now, is not correct. It's not true that "a <- someAction" BR> has the effect of associating a with someAction, with the actual BR> work deferred until later. Ahem.. I got a "little" carried away on the topic of getContents, apparently :( BR> All of the IO associated with someAction happens at the program BR> point where "a <- someAction" appears, whether or not it's needed BR> later. getContents is a rare exception to this rule. But of course. Now I'll have to think how to back out of the mess I created :) -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Guess what ... Tutorial uploaded! :)
Hi all, Recend thread "Tutorial upload" reminded me of my intentions to write haskell tutorial which I suppresend from the times when Hal Daume began to write YAHT. Unusually low temperature here (-22C) freed me a lot of time this weekend, and the result it here: http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell This is a work in progress, plus I'm trying it on C++/Java folk around me, so it's bound to be heavily corrected, but main direction could already be seen (I hope). If you want - jump on the wagon, and provide me with (constructive) criticism, edits on hawiki or anything else you see fit. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: We need "Documentation"
EO> Hi Hal, EO> On Thursday 13 December 2001 20:47, Hal Daume III wrote: >> I think we should move this off the mailing list. I'm willing to >> spear-head such an effort. Anyone who is interested in contributing, >> please email me. I'll compile a list of people and we can figure out >> what we want to do. EO> I think it's okay to discuss in haskell-cafe. Well, original author decided to took discussion off-list ... EO> I'd like to contribute too but I have little time nowadays trying to EO> finish writing my msc. thesis. I do have a few suggestions though: EO> 1. Using wiki does not seem to be a bad idea. You may also consider EO> using a word processing system such as LaTeX though. It's easy to EO> convert LaTeX to html and it yields very quality prints as you all EO> know. However, for true collaboration wiki is the king. There is EO> already a nice Haskell wiki appropriate for such a project IIRC. But Wiki at haskell.org has many limitations :( Does someone know nice Wiki interface which combines Wiki's ease of use and CVS-like revision management and conflict resolution? Most implementations I've seen does not seem to deal well with several ppl editing same page at once - changes often got lost -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: sending values between actions
NS> can anyone tell me how to send values from one action to another??? NS> I have NS> main0 = do s <- getLine writeFile "text.txt" s NS> main1 = do NS> I'd like to use main0 info on main1 action to build a nXm multisquares NS> box... anyone understood this please help... First of all, main0 and main0 are not actions. Then, there are no special "info" (like, say, local variables) associated with any of them. Are you sure you know what are you doing? PS I have some gut feeling that you might be much better off with Erlang (www.erlang.org), if you want to pass events/datastructures between processes... -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to write a lazy variant ?
>> I hate to followup to myself, but looks like I had to. I really was >> too tired and lazy version could be obtained by simple use of >> accumulator: ADR> Are you _sure_ that's all it takes? Well, I cannot be 100% sure, but what I observe in ghci is that evaluating 'recs <- readRecordFile "some_name"' with first variant of routines takes about two minutes to complete (file is quite large) and gobbles up substatial amount of memory, while second variant returns almost immediately, and consumes memory only when I start to process recs. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to write a lazy variant ?
DA> Consider the following functions: DA> readRecFile fname = DA> do ifh <- openFile fname ReadMode DA>readRecords ifh DA> readRecords ifh = DA> do x <- decodeNextRecord ifh DA>more <- isEof ifh DA>if (more == False) DA> then return [x] DA> else do rest <- readRecords ifh DA> return (x:rest) DA> They allow me to read contest of file fname into a list of data DA> structures. But "do rest <- readRecords ifh ; return (x:rest)" part makes DA> them behave non-lazily. Maybe I'm just too tired right now, but it escapes DA> me how can I write a lazy variant of those functions, so that they will DA> behave like getContents. Does anyone have a clue? I hate to followup to myself, but looks like I had to. I really was too tired and lazy version could be obtained by simple use of accumulator: > readRecFile fname = > do ifh <- openFile fname ReadMode >readRecords ifh [] > readRecords ifh acc = > do x <- decodeNextRecord ifh >more <- isEof ifh >if (more == False) > then return (x:acc) > else do readRecords ifh (x:acc) That's it. Sorry for noice on the list. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
How to write a lazy variant ?
Consider the following functions: readRecFile fname = do ifh <- openFile fname ReadMode readRecords ifh readRecords ifh = do x <- decodeNextRecord ifh more <- isEof ifh if (more == False) then return [x] else do rest <- readRecords ifh return (x:rest) They allow me to read contest of file fname into a list of data structures. But "do rest <- readRecords ifh ; return (x:rest)" part makes them behave non-lazily. Maybe I'm just too tired right now, but it escapes me how can I write a lazy variant of those functions, so that they will behave like getContents. Does anyone have a clue? -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskell and ASN.1
JM> not to raise a religious war but I have been working on something JM> similar but with XDR instead of ANS.1, if you just want persistant JM> portable serialization then that should do. John Unfortunately, I have to deal with data from other proprietary system, which can do only BER-encoded ASN.1-described output, nothing else. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskell and ASN.1
Two keywords mentioned in 'Subject' - does it ring the bell for someone? Any usefull links? I'm interested in something like Erlang's "asn1" compiler or snacc/C++ -- that is, I'm looking for translator from ASN.1 layout into native Haskell data type, along with I/O functions. Seems like pretty easy thing to write myself, though, but I dont want to reinvent the wheel, if there is any. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Evolution of a Haskell Programmer
It's a pity that such a link is not mentioned in "Haskell Bookshelf" :) http://www.willamette.edu/~fruehr/haskell/evolution.html -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: HaXml, memory usage and segmentation fault
JE> I got it to compile with ghc 5.02 using JE> ghc --make -package lang translate.hs JE> The compiled version succeeds, but on a large document it uses a *lot* JE> of memory and starts paging pretty badly. Exactly. iPIII-800/192M ram died on me swapping when I tried to run compiled version with 16M big stack and input file with 10 children in one node. >> JE> Try the identity transform 'main = processXmlWith keep' on your sample >> JE> document and see if that runs out of heap too. If so, there's not >> JE> much you can do short of replacing the HaXml parser. I tried this with ghc 5.02, and it run in 20M RAM or so. It could be less, but at least it runs, and not segfaults as hugs :) JE> I tried this as well, modifying your program to use an XML parser I JE> wrote a while ago that has better laziness properties than the HaXML JE> one. Alas, my parser also suffers from a space leak under Hugs, so JE> this only deferred the problem. Under ghc/ghci, though, it has modest JE> memory requirements and runs without paging. Is it's distribution restricted? Is it possible to get it somwhere, use it, patch it, etc? -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: HaXml, memory usage and segmentation fault
>> What's the reason: bug in hugs, bug in HaXml, or my own bad programming
>> techniques?
JE> More an inappropriate use of Hugs -- 10 s with 999
JE> s each is a moderately large input file,
Almost 6 megs
JE> and the Hugs interpreter just isn't designed to work with large
JE> inputs. Try compiling the program instead.
well, ghc-5.02 seems to dislike something inside XmlLib.hs - it could not
find interface defs file for modules IOExts .. I plan to look more deeply
into it though.
JE> The other issue is that HaXml's XML parser is insufficiently lazy
JE> (although the rest of HaXml has very nice strictness properties). For
JE> instance, there's no reason why your program shouldn't run in
JE> near-constant space, but due to the way the parser is structured it
JE> won't begin producing any output until the entire input document has
JE> been read.
I suspected it, and your comment encouraged me to look more deeply in the
code, and yes - it seems that examples like mine simply do not fit in :(
JE> Try the identity transform 'main = processXmlWith keep' on your sample
JE> document and see if that runs out of heap too. If so, there's not
JE> much you can do short of replacing the HaXml parser.
I got:
runhugs98 +sgt -h500 translate_invoices.hs invoice.xml invoice_small.html
runhugs: Error occurred
{{Gc:4788153}}{{Gc:4619912}}{{Gc:4442164}}{{Gc:4271039}}{{Gc:4122687}}{{Gc:3964107}}{{Gc:3827478}}{{Gc:3680235}}{{Gc:3554593}}{{Gc:3417827}}{{Gc:3286249}}{{Gc:3175771}}{{Gc:3053698}}{{Gc:2936095}}{{Gc:2839042}}{{Gc:2729711}}{{Gc:2624806}}{{Gc:2539770}}{{Gc:2442035}}{{Gc:2347994}}{{Gc:2257773}}{{Gc:4077399}}{{Gc:3715115}}
(47153895 reductions, 79953374 cells, 23 garbage collections)
{{Gc:3812956}}ERROR - Control stack overflow
I tried to put several "observe" statements in the code, but they seem to
be ignored in the case of "Control stack overflow".
--
Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED]
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
HaXml, emeory usage and segmentation fault
I have Hugs version February 2001, HaXml version 1.02 and this program:
> module Main where
> import XmlLib
>
> main = processXmlWith (invoices `o` tag "invoice")
>
> invoices =
> html
> [ hhead
> [ htitle [ ("Invoices"!)] ],
> hbody
> [ customers `o` children `with` tag "customer" ]
> ]
>
> customers =
> cat
> [ h2 [ ("Customer"!) ],
> contracts `o` children `with` tag "contract"
> ]
>
> contracts =
> cat
> [ h3 [ ("Id:"!), ("id"?)],
> hpara [ ("Access:"!), keep /> txt ] `o` children `with` tag "access",
> hpara [ ("Intl:"!), keep /> txt] `o` children `with` tag "inter"
> ]
This program can process following file:
1
1
2
2
(I use "runhugs translate.hs invoice.xml invoice.html")
Now increase amount of s to 10, and amount of s within
each customer to 999. After that, "runhugs -h600 translate.hs
invoice.xml invoice.html" dumps core :(
What's the reason: bug in hugs, bug in HaXml, or my own bad programming
techniques?
--
Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED]
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Newbie question about classes and class parameters
Let's say we have infamous Set class defined this way: > class Set s a where > empty :: s a > isEmpty :: s a -> Bool Lets also say that we could define sets as lists: > data SetAsList a = SL [a] deriving (Eq,Ord,Show) > instance Set SetAsList a where > empty = SL [] > isEmpty (SL []) = True > isEmpty _ = False So far, so good. Lets define type synonim for set of integers: > type IntegerSet = SetAsList Integer And set of sets of integers: > data IntegerSuperSet = ISS (SetAsList IntegerSet) Testing in Hugs show that everything seems to be working: Main> :t ISS (SL [ (SL [1,2,3])::IntegerSet, (SL [4,5,6])::IntegerSet ]) ISS (SL [SL [1,2,3],SL [4,5,6]]) :: IntegerSuperSet However: Main> isEmpty (ISS (SL [(SL [1,2,3])::IntegerSet, (SL [4,5,6])::IntegerSet])) ERROR - Type error in application *** Expression : isEmpty (ISS (SL [SL [1,2,3],SL [4,5,6]])) *** Term : ISS (SL [SL [1,2,3],SL [4,5,6]]) *** Type : IntegerSuperSet *** Does not match : a b This is completely understood - I need to state that IntegerSuperSet is an instance of Set for isEmpty to be working. But: > instance Set IntegerSuperSet where > empty = ISS (SL []) > isEmpty (ISS (SL [])) = True > isEmpty _ = False gives me: Reading file "/tmp/bug.lhs": ERROR /tmp/bug.lhs:38 - Wrong number of arguments for class "Set" Obviously I am missing something very important here. Could someone enlighten me? -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] Information Systems Expert Office: +380-50-110-3876 Ukrainian Mobile Communications Mobile: +380-50-330-2019 GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Doing exercises from "Haskell tutorial" ...
MK> 02 Oct 2001 15:16:27 +0300, Dmitry Astapov <[EMAIL PROTECTED]> pisze: >> I need to define SetsAsLists as an instance of Set by supplying >> definitions for all Set methods, but definitions I wrote led me to >> adding additional constraints on "union" and "memeber" methods. MK> What constraints? The class already says that these operations require MK> Eq on the element type: [skip] Yes, they already there, but only because I placed them there. Original text from Tutorial does not have these constraints. -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Doing exercises from "Haskell tutorial" ...
It seems like an appropriate page for aske newbie questions, isnt it? I was reading through Haskell tutroial (http://www.di.uminho.pt/afp98/PAPERS/Tutorial.ps) and trying to do exercises from there. I'm stuck in the first exercise for "Classes" chapter (page 11). I need to define SetsAsLists as an instance of Set by supplying definitions for all Set methods, but definitions I wrote led me to adding additional constraints on "union" and "memeber" methods. Is it ok or it's possible to define "union" and "member" without using "==" ? Code follows: class Set s where empty :: s a isEmpty :: s a -> Bool singleton :: a -> s a union :: Eq a => s a -> s a -> s a member :: Eq a => a -> s a -> Bool choice :: s a -> (a, s a) data SetsAsLists a = SL [a] instance Set SetsAsLists where empty = SL [] isEmpty (SL []) = True isEmpty _ = False singleton x = SL [x] member x (SL ys) | isEmpty (SL ys)= False | otherwise = if x==head ys then True else member x (SL (tail ys)) union (SL []) (SL ys) = SL ys union (SL (x:xs)) (SL ys) | member x (SL ys) = union (SL xs) (SL (x:ys)) | otherwise= union (SL xs) (SL ys) -- Dmitry Astapov //ADEpt E-mail: [EMAIL PROTECTED] GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
