Re: [Haskell-cafe] attoparsec and backtracking

[Roman Cheplyaka]

* Niklas Hambüchen  [2013-03-16 03:49:29+]
> I would agree that what attoparsec does for <|> of Alternative and mplus
> for MonadPlus is correct since e.g. the mplus laws say that a failure
> must be identity and therefore the following alternatives must be
> considered. I also find it very convenient that attoparsec works this
> way, and prefer it to what parsec does by default.

empty/mzero are indeed identities in Parsec.

What doesn't hold is the law

   v >> mzero = mzero

But this one is often violated:

  > flip runState 0 $ runMaybeT mzero
  (Nothing,0)

  > flip runState 0 $ runMaybeT $ lift (modify (+1)) >> mzero
  (Nothing,1)

Roman

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimization flag changing result of code execution

[Azeem -ul-Hasan]

Hi Carter,

 Thank you for your help, but I can confirm that this is not due to 
floating point errors. My own hunch is that it is due to the way I am using 
random number generation from System.Random.MWC. To check it I wrote a version 
of mkNetwork function using random number generation from System.Random and it 
works fine with optimizations turned on. So any ideas why optimizations are 
messing with System.Random.MWC?

Azeem
From: carter.schonw...@gmail.com
Date: Fri, 15 Mar 2013 17:09:36 -0400
Subject: Re: [Haskell-cafe] Optimization flag changing result of code execution
To: aze...@live.com
CC: haskell-cafe@haskell.org

Hey Azeem,have you tried running the same calculation using rationals? Theres 
some subtleties to writing numerically stable code using floats and doubles, 
where simple optimizations change the orders of operations in ways that 
*significantly* change the result. In this case it looks like you're averaging 
the averages, which i *believe* can get pretty nasty in terms of numerical 
precision.  Rationals would be a bit slower, but you could then sort out which 
number is more correct.



On Fri, Mar 15, 2013 at 4:07 PM, Azeem -ul-Hasan  wrote:





I was trying to solve a computational problem form James P Sethna's book 
Statistical Mechanics: Entropy, Order Parameters, and Complexity[1]. The 
problem is on page 19 of the pdf linked and is titled Six degrees of 
separation. For it I came up with this code: http://hpaste.org/84114


 
It runs fine when compiled with -O0 and consistently yields an answer around 
10, but with -O1 and -O2 it consistently gives an answer around 25. Can 
somebody explain what is happening here?



[1] 
http://pages.physics.cornell.edu/~sethna/StatMech/EntropyOrderParametersComplexity.pdf



Azeem

  

___

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] Optimization flag changing result of code execution

[Roman Cheplyaka]

Perhaps the problem is in withSystemRandom, which uses unsafePerformIO?

Does the problem persist if you seed your program with some predefined
seed?

Roman

* Azeem -ul-Hasan  [2013-03-16 13:46:54+0500]
> 
> Hi Carter,
> 
>  Thank you for your help, but I can confirm that this is not due to 
> floating point errors. My own hunch is that it is due to the way I am using 
> random number generation from System.Random.MWC. To check it I wrote a 
> version of mkNetwork function using random number generation from 
> System.Random and it works fine with optimizations turned on. So any ideas 
> why optimizations are messing with System.Random.MWC?
> 
> Azeem
> From: carter.schonw...@gmail.com
> Date: Fri, 15 Mar 2013 17:09:36 -0400
> Subject: Re: [Haskell-cafe] Optimization flag changing result of code 
> execution
> To: aze...@live.com
> CC: haskell-cafe@haskell.org
> 
> Hey Azeem,have you tried running the same calculation using rationals? Theres 
> some subtleties to writing numerically stable code using floats and doubles, 
> where simple optimizations change the orders of operations in ways that 
> *significantly* change the result. In this case it looks like you're 
> averaging the averages, which i *believe* can get pretty nasty in terms of 
> numerical precision.  Rationals would be a bit slower, but you could then 
> sort out which number is more correct.
> 
> 
> 
> On Fri, Mar 15, 2013 at 4:07 PM, Azeem -ul-Hasan  wrote:
> 
> 
> 
> 
> 
> I was trying to solve a computational problem form James P Sethna's book 
> Statistical Mechanics: Entropy, Order Parameters, and Complexity[1]. The 
> problem is on page 19 of the pdf linked and is titled Six degrees of 
> separation. For it I came up with this code: http://hpaste.org/84114
> 
> 
>  
> It runs fine when compiled with -O0 and consistently yields an answer around 
> 10, but with -O1 and -O2 it consistently gives an answer around 25. Can 
> somebody explain what is happening here?
> 
> 
> 
> [1] 
> http://pages.physics.cornell.edu/~sethna/StatMech/EntropyOrderParametersComplexity.pdf
> 
> 
> 
> Azeem
> 
> 
> 
> ___
> 
> Haskell-Cafe mailing list
> 
> Haskell-Cafe@haskell.org
> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> 
> 

> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimization flag changing result of code execution

[Azeem -ul-Hasan]

Nope that isn't the case either. Even if I make use of defaultSeed through 
create the problem still remains. The problem seems to be in the generation of 
a vector of (a,a) i.e in the part 

V.generateM ((round $ p*(fromIntegral $ l*z)) `div` 2) (\i-> R.uniformR ((0,0) 
, (l-1,l-1)) gen)

in line 16. Thanks again.

Azeem

> Date: Sat, 16 Mar 2013 10:58:50 +0200
> From: r...@ro-che.info
> To: aze...@live.com
> CC: carter.schonw...@gmail.com; haskell-cafe@haskell.org
> Subject: Re: [Haskell-cafe] Optimization flag changing result of code 
> execution
> 
> Perhaps the problem is in withSystemRandom, which uses unsafePerformIO?
> 
> Does the problem persist if you seed your program with some predefined
> seed?
> 
> Roman
> 
> * Azeem -ul-Hasan  [2013-03-16 13:46:54+0500]
> > 
> > Hi Carter,
> > 
> >  Thank you for your help, but I can confirm that this is not due to 
> > floating point errors. My own hunch is that it is due to the way I am using 
> > random number generation from System.Random.MWC. To check it I wrote a 
> > version of mkNetwork function using random number generation from 
> > System.Random and it works fine with optimizations turned on. So any ideas 
> > why optimizations are messing with System.Random.MWC?
> > 
> > Azeem
> > From: carter.schonw...@gmail.com
> > Date: Fri, 15 Mar 2013 17:09:36 -0400
> > Subject: Re: [Haskell-cafe] Optimization flag changing result of code 
> > execution
> > To: aze...@live.com
> > CC: haskell-cafe@haskell.org
> > 
> > Hey Azeem,have you tried running the same calculation using rationals? 
> > Theres some subtleties to writing numerically stable code using floats and 
> > doubles, where simple optimizations change the orders of operations in ways 
> > that *significantly* change the result. In this case it looks like you're 
> > averaging the averages, which i *believe* can get pretty nasty in terms of 
> > numerical precision.  Rationals would be a bit slower, but you could then 
> > sort out which number is more correct.
> > 
> > 
> > 
> > On Fri, Mar 15, 2013 at 4:07 PM, Azeem -ul-Hasan  wrote:
> > 
> > 
> > 
> > 
> > 
> > I was trying to solve a computational problem form James P Sethna's book 
> > Statistical Mechanics: Entropy, Order Parameters, and Complexity[1]. The 
> > problem is on page 19 of the pdf linked and is titled Six degrees of 
> > separation. For it I came up with this code: http://hpaste.org/84114
> > 
> > 
> >  
> > It runs fine when compiled with -O0 and consistently yields an answer 
> > around 10, but with -O1 and -O2 it consistently gives an answer around 25. 
> > Can somebody explain what is happening here?
> > 
> > 
> > 
> > [1] 
> > http://pages.physics.cornell.edu/~sethna/StatMech/EntropyOrderParametersComplexity.pdf
> > 
> > 
> > 
> > Azeem
> > 
> >   
> > 
> > ___
> > 
> > Haskell-Cafe mailing list
> > 
> > Haskell-Cafe@haskell.org
> > 
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > 
> > 
> > 
> >   
> 
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Monad.Reader Issue 21

[Edward Z. Yang]

I am pleased to announce that Issue 21 of the Monad Reader is now available.

http://themonadreader.files.wordpress.com/2013/03/issue21.pdf

Issue 21 consists of the following two articles:

* "A Functional Approach to Neural Networks" by Amy de Buitléir, Michael 
Russell, Mark Daly
* "Haskell ab initio: the Hartree-Fock Method in Haskell" by Felipe Zapata, 
Angel J. Alvarez

Feel free to browse the source files. You can check out the entire repository 
using Git:

git clone https://github.com/ezyang/tmr-issue21.git

If you’d like to write something for Issue 22, please get in touch!

Cheers,
Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Win32-services

[Ivan Perez]

I am happy to see this implemented. Thanks Michael!

On 15 March 2013 00:49, Michael Steele  wrote:

> I uploaded a new packaged named Win32-services. This library is a partial
> binding to the Win32 System Services API. It's now easier to write Windows
> service applications in Haskell.
>
> The hackage page  [1]
> demonstrates simple usage. There are also 2 examples included with the
> sources. One is a translation of Microsoft's official example.
>
> [1]: http://hackage.haskell.org/package/Win32-services
>
> -- Michael Steele
>
> ___
> 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] ANNOUNCE: Ajhc 0.8.0.2 Release

[Kiwamu Okabe]

We are happy to announce Ajhc 0.8.0.2.

It's first release announce for Ajhc.
Major change on this release is ability to compile Haskell code for tiny CPU.
There is demo on tiny CPU at https://github.com/ajhc/demo-cortex-m3.
And you can watch demo movie at http://www.youtube.com/watch?v=bKp-FC0aeFE.
Perhaps changes on the announce will be merged to jhc.

Ajhc's project web site is found at http://ajhc.masterq.net/.
You can get Ajhc 0.8.0.2 source code from https://github.com/ajhc/ajhc/tags.

## Changes

* Fix warning messages on compiling.
* Ready to compile with GHC 7.6.2.
* New RTS for tiny CPU. How to use:
  https://github.com/ajhc/demo-cortex-m3#porting-the-demo-to-a-new-platform

- - -
Metasepi team

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [jhc] ANNOUNCE: Ajhc 0.8.0.2 Release

[John Meacham]

I have merged your changes back into the main jhc tree. Thanks!
John

On Sat, Mar 16, 2013 at 5:28 AM, Kiwamu Okabe  wrote:
> We are happy to announce Ajhc 0.8.0.2.
>
> It's first release announce for Ajhc.
> Major change on this release is ability to compile Haskell code for tiny CPU.
> There is demo on tiny CPU at https://github.com/ajhc/demo-cortex-m3.
> And you can watch demo movie at http://www.youtube.com/watch?v=bKp-FC0aeFE.
> Perhaps changes on the announce will be merged to jhc.
>
> Ajhc's project web site is found at http://ajhc.masterq.net/.
> You can get Ajhc 0.8.0.2 source code from https://github.com/ajhc/ajhc/tags.
>
> ## Changes
>
> * Fix warning messages on compiling.
> * Ready to compile with GHC 7.6.2.
> * New RTS for tiny CPU. How to use:
>   https://github.com/ajhc/demo-cortex-m3#porting-the-demo-to-a-new-platform
>
> - - -
> Metasepi team
>
> ___
> jhc mailing list
> j...@haskell.org
> http://www.haskell.org/mailman/listinfo/jhc

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Maintaining lambdabot

[James Cook]

On Mar 15, 2013, at 5:33 PM, Jason Dagit  wrote:

> Do you know if the constraints on:
> regex-posix-0.95.1
> regex-compat-0.95.1
> 
> Need to be what they are? Could we relax them without breaking anything?

The constraints were added recently, and I believe they were a very 
conservative estimate based on what versions were specifically present on Jan's 
machine at the time.  Almost all of them could probably be relaxed.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [jhc] ANNOUNCE: Ajhc 0.8.0.2 Release

[Joachim Breitner]

Hi,

Am Samstag, den 16.03.2013, 05:53 -0700 schrieb John Meacham:
> On Sat, Mar 16, 2013 at 5:28 AM, Kiwamu Okabe  wrote:
> > We are happy to announce Ajhc 0.8.0.2.
>
>I have merged your changes back into the main jhc tree. Thanks!
> John

Great. Would it be possible for you two to agree on a mode that allows
Kiwamu to develop in his pace, but still avoid having a proper fork of
jhc pushed to distros and users? Something like: Kiwamu hacks away
happily on the ajhc repo and people interested in the very latest state
can pull from there, but ajhc releases get (if there are no technical
issues) merged into jhc, and jhc is the version that regular users
should use (and distributions should package).

Your part-time fork-avoider,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ICFP 2013: Second Call for Papers

[David Van Horn]

=

 18th ACM SIGPLAN International Conference on Functional Programming

 ICFP 2013

 Boston, MA, USA, 25-27 September 2013

 http://www.icfpconference.org/icfp2013

=

Important Dates
~~~

   Submissions due:  Thursday, 28 March 2013 23:59 UTC-11
(Pago Pago, American Samoa, time)
   Author response:  Wednesday, 22 May 0:00 UTC-11
   Friday, 24 May 2013 23:59 UTC-11
  Notification:  Friday, 7 June 2013
Final copy due:  Friday, 5 July 2013

Scope
~

ICFP 2013 seeks original papers on the art and science of functional
programming.  Submissions are invited on all topics from principles to
practice, from foundations to features, and from abstraction to
application.  The scope includes all languages that encourage
functional programming, including both purely applicative and
imperative languages, as well as languages with objects, concurrency,
or parallelism.  Topics of interest include (but are not limited to):

* Language Design: concurrency and distribution; modules; components
  and composition; metaprogramming; interoperability; type systems;
  relations to imperative, object-oriented, or logic programming

* Implementation: abstract machines; virtual machines; interpretation;
  compilation; compile-time and run-time optimization; memory
  management; multi-threading; exploiting parallel hardware; interfaces
  to foreign functions, services, components, or low-level machine
  resources

* Software-Development Techniques: algorithms and data structures;
  design patterns; specification; verification; validation; proof
  assistants; debugging; testing; tracing; profiling

* Foundations: formal semantics; lambda calculus; rewriting; type
  theory; monads; continuations; control; state; effects; program
  verification; dependent types

* Analysis and Transformation: control-flow; data-flow; abstract
  interpretation; partial evaluation; program calculation

* Applications and Domain-Specific Languages: symbolic computing;
  formal-methods tools; artificial intelligence; systems programming;
  distributed-systems and web programming; hardware design; databases;
  XML processing; scientific and numerical computing; graphical user
  interfaces; multimedia programming; scripting; system
  administration; security

* Education: teaching introductory programming; parallel programming;
  mathematical proof; algebra

* Functional Pearls: elegant, instructive, and fun essays on
  functional programming

* Experience Reports: short papers that provide evidence that
  functional programming really works or describe obstacles that have
  kept it from working

If you are concerned about the appropriateness of some topic, do not
hesitate to contact the program chair.

Abbreviated instructions for authors


* By Thursday, 28 March 2013, 23:59 UTC-11 (American Samoa time),
  submit a full paper of at most 12 pages (6 pages for an Experience
  Report), including bibliography and figures.

The deadlines will be strictly enforced and papers exceeding the page
limits will be summarily rejected.

* Authors have the option to attach supplementary material to a submission,
  on the understanding that reviewers may choose not to look at it.

* Each submission must adhere to SIGPLAN's republication policy, as
  explained on the web at
  http://www.sigplan.org/Resources/Policies/Republication

* Authors of resubmitted (but previously rejected) papers have the
  option to attach an annotated copy of the reviews of their previous
  submission(s), explaining how they have addressed these previous
  reviews in the present submission.  If a reviewer identifies
  him/herself as a reviewer of this previous submission and wishes to
  see how his/her comments have been addressed, the program chair will
  communicate to this reviewer the annotated copy of his/her previous
  review.  Otherwise, no reviewer will read the annotated copies of
  the previous reviews.

Overall, a submission will be evaluated according to its relevance,
correctness, significance, originality, and clarity.  It should
explain its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work.  The technical
content should be accessible to a broad audience.  Functional Pearls
and Experience Reports are separate categories of papers that need not
report original research results and must be marked as such at the
time of submission.  Detailed guidelines on both categories are on the
conference web site.

Proceedings will be published by ACM Press.  Authors of accepted
submissions are expected to transfer the copyright to the
ACM.  Presentations will be videotaped and released online if the
presenter consents.

Formatti

Re: [Haskell-cafe] attoparsec and backtracking

[Evan Laforge]

> I think the mistake here is to parse something and then decide if
> its it valid. It should be the parser which decides whether its
> valid. So rather than:
>
>  suffix <- A.option "" ((:"") <$> A.letter_ascii)
>
> try:
>
>  typ <- A.choice [ {- list or valid suffix parsers -} ]
>  return $ Score.Typed typ num

I actually had that originally, but but switched to fail-after for the
better error msg.  It worked with parsec, but then I lost it again
when I switched to attoparsec.  I think Wren is right, I really would
need to refactor the parser to put the decisions in the right spot.

> We you using Parsec as a token parser or as a Char parser. Obviously
> the second is going to be slow in comparison to the first.

It was actually the Text version of parsec, back when that was new.  I
should go do a profile again someday, but since attoparsec and parsec
APIs are almost but not quite the same, it's kind of a pain.  I
actually tried the Text version of attoparsec, back when that was not
yet integrated into attoparsec itself, and bytestring was still
significantly faster.  So I don't know how much was Text vs.
ByteString and how much was parsec vs. attoparsec.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Jesper Särnesjö]

On Thu, Mar 14, 2013 at 12:51 AM, Jesper Särnesjö  wrote:
> In short, I have two programs, one written in Haskell [1] and one
> written in C [2], that consist of calls to the same functions, in the
> same order, to the same C library, but which do not exhibit the same
> behavior. Further, the Haskell program behaves differently when
> compiled using GHC, and when run in GHCi. I would like to know why
> this is, and how to fix it.

To be clear, I think this isn't really an OpenGL problem, but rather
one related to FFI or event handling. If anyone could explain to me,
in general, how and why a call to a foreign function returning IO ()
might cause different behavior in Haskell than in C, that might help
me track down the problem.

I've updated my test programs to use glGetString [3] to check which
renderer is active. On my machine, it should return "NVIDIA GeForce GT
330M OpenGL Engine" if rendering happens on the discrete GPU, and
"Intel HD Graphics OpenGL Engine" or "Apple Software Renderer"
otherwise. These are the results of running the C and Haskell programs
in various ways:

$ gcc -lglfw -framework OpenGL glfw_test.c && ./a.out
NVIDIA GeForce GT 330M OpenGL Engine

$ ghc -lglfw -framework OpenGL -fforce-recomp glfw_test.hs && ./glfw_test
[...]
Apple Software Renderer

$ runhaskell -lglfw glfw_test.hs
NVIDIA GeForce GT 330M OpenGL Engine

$ ghci -lglfw glfw_test.hs
[...]
Prelude Main> main
NVIDIA GeForce GT 330M OpenGL Engine

The C program behaves as expected, as does the Haskell one when run
using runhaskell or GHCi. Only the Haskell program compiled using GHC
behaves incorrectly. Again, the OS event that signifies that a GPU
switch has occurred fires either way, but for the compiled Haskell
program, it fires with roughly a second's delay. Why would that be?

-- 
Jesper Särnesjö
http://jesper.sarnesjo.org/

[1] https://gist.github.com/sarnesjo/5151894#file-glfw_test-hs
[2] https://gist.github.com/sarnesjo/5151894#file-glfw_test-c
[3] http://www.opengl.org/sdk/docs/man3/xhtml/glGetString.xml

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] attoparsec and backtracking

[Evan Laforge]

On Fri, Mar 15, 2013 at 8:49 PM, Niklas Hambüchen  wrote:
> Is it not possible to add an alternative (no pun intended) to <|> that
> supports the semantics Evan wants?

I assume it's the performance thing.  Presumably it would need to pass
an extra flag with to the failure continuation to tell it to not
retry, though that doesn't sound so bad.  Actually, Bryan's response
here:

https://github.com/bos/attoparsec/issues/42

makes it sound like he's not opposed to <||> on performance grounds,
just that <|> is more intuitive.  I agree in general, but not in the
case of error msgs!  So maybe I just need to see if I can make a patch
to add <||>, sounds like Johan at least would be into that.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [jhc] ANNOUNCE: Ajhc 0.8.0.2 Release

[Kiwamu Okabe]

Hi,

On Sun, Mar 17, 2013 at 4:45 AM, Joachim Breitner
 wrote:
> Great. Would it be possible for you two to agree on a mode that allows
> Kiwamu to develop in his pace, but still avoid having a proper fork of
> jhc pushed to distros and users? Something like: Kiwamu hacks away
> happily on the ajhc repo and people interested in the very latest state
> can pull from there, but ajhc releases get (if there are no technical
> issues) merged into jhc, and jhc is the version that regular users
> should use (and distributions should package).

I think good, because I maintain jhs as Debian package already.
http://ftp-master.debian.org/new/jhc_0.8.0~darcs20120314-1.html
Maintaining Ajhc Debian package is bad idea, if jhc has the most
functions had by Ajhc.

How about below policy between jhc and Ajhc.

1. Jhc and Ajhc share same command name "jhc".
2. Jhc controls major version number. Example, jhc controls X, Y and Z
in version "X.Y.Z".
3. Ajhc controls minor version number. Example, Ajhc controls only Q
in version "X.Y.Z.Q".
4. Ajhc show below message with --version option.

(A)jhc 0.8.0.1 (80aa12fb9b57622bba2f0e911d7ebc0c04ddb662)
compiled by ghc-7.4 on a x86_64 running linux

The policy is to keep minimum change between jhc and Ajhc.
And I think that Ajhc having own command name confuses jhc user.

Best regards,
--
Kiwamu Okabe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] attoparsec and backtracking

[Niklas Hambüchen]

@Evan Thanks for that link, I posted a somewhat longer argument in 
there.

Personally, I'd love <||>.

On Sun 17 Mar 2013 02:02:44 GMT, Evan Laforge wrote:
> On Fri, Mar 15, 2013 at 8:49 PM, Niklas Hambüchen  wrote:
>> Is it not possible to add an alternative (no pun intended) to <|> that
>> supports the semantics Evan wants?
>
> I assume it's the performance thing.  Presumably it would need to pass
> an extra flag with to the failure continuation to tell it to not
> retry, though that doesn't sound so bad.  Actually, Bryan's response
> here:
>
> https://github.com/bos/attoparsec/issues/42
>
> makes it sound like he's not opposed to <||> on performance grounds,
> just that <|> is more intuitive.  I agree in general, but not in the
> case of error msgs!  So maybe I just need to see if I can make a patch
> to add <||>, sounds like Johan at least would be into that.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Need some advice around lazy IO

[C K Kashyap]

Hi,

I am working on an automation that periodically fetches bug data from our
bug tracking system and creates static HTML reports. Things worked fine
when the bugs were in the order of 200 or so. Now I am trying to run it
against 3000 bugs and suddenly I see things like - too  many open handles,
out of memory etc ...

Here's the code snippet - http://hpaste.org/84197

It's a small snippet and I've put in the comments stating how I run into
"out of file handles" or simply file not getting read due to lazy IO.

I realize that putting ($!) using a trial/error approach is going to be
futile. I'd appreciate some pointers into the tools I could use to get some
idea of which expressions are building up huge thunks.


Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Carlo Hamalainen]

On Sun, Mar 17, 2013 at 3:08 PM, C K Kashyap  wrote:

> It's a small snippet and I've put in the comments stating how I run into
> "out of file handles" or simply file not getting read due to lazy IO.
>
> I realize that putting ($!) using a trial/error approach is going to be
> futile. I'd appreciate some pointers into the tools I could use to get some
> idea of which expressions are building up huge thunks.
>

Have you tried System.IO.Strict's readFile? I had similar problems (too
many file handles) and fixed it with

import qualified System.IO.Strict as S

and then using S.readFile instead of the standard prelude's readFile.

This is where I used the strict IO readFile in my toy project:
https://github.com/carlohamalainen/checker/blob/master/Checker.hs

-- 
Carlo Hamalainen
http://carlo-hamalainen.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe