[Haskell] ANN: hledger 0.4 released

[Simon Michael]

Dear all,

I have released hledger 0.4 on hackage. There is also a new website at http://hledger.org 
 , with screenshots (textual!), a demo (will it survive!?), and docs  
(not too many!) Release notes are at http://hledger.org/NEWS , and  
bravely pasted below.


In case you forgot: hledger is a text-mode double-entry accounting  
tool. It reads a plain text journal file describing your transactions  
and generates precise activity and balance reports. I use it every day  
to track money and time, and as the basis for client invoices and tax  
returns. hledger is a partial clone, in haskell, of John Wiegley's  
excellent ledger. I wrote it because I did not want to hack on c++ and  
because haskell seemed a good fit.


Please cabal update and cabal install hledger and give it a whirl.  
Install with the "-f happs" flag to enable the new happstack-based web  
interface. I am sm on the #ledger channel on freenode, and I welcome  
your feedback, especially if you notice a problem.


Best - Simon

-

2009/04/03 hledger 0.4 released

Changes:

   * new "web" command serves reports in a web browser (install  
with -f happs to build this)
   * make the vty-based curses ui a cabal build option, which  
will be ignored on MS windows

   * drop the --options-anywhere flag, that is now the default
   * patterns now use not: and desc: prefixes instead of ^ and ^^
   * patterns are now case-insensitive, like ledger
   * !include directives are now relative to the including file  
(Tim Docker)
   * "Y2009" default year directives are now supported, allowing  
m/d dates in ledger

   * individual transactions now have a cleared status
   * unbalanced entries now cause a proper warning
   * balance report now passes all ledger compatibility tests
   * balance report now shows subtotals by default, like ledger 3
   * balance report shows the final zero total when -E is used
   * balance report hides the final total when --no-total is used
   * --depth affects print and register reports (aggregating with  
a reporting interval, filtering otherwise)

   * register report sorts transactions by date
   * register report shows zero-amount transactions when -E is used
   * provide more convenient timelog querying when invoked as  
"hours"

   * multi-day timelog sessions are split at midnight
   * unterminated timelog sessions are now counted. Accurate time  
reports at last!

   * the test command gives better --verbose output
   * --version gives more detailed version numbers including  
patchlevel for dev builds
   * new make targets include: ghci, haddocktest, doctest,  
unittest, view-api-docs
   * a doctest-style framework for functional/shell tests has  
been added

   * performance has decreased slightly:

   || hledger-0.3 | hledger-0.4 |  
ledger-0.3

 ==++==
 -f sample.ledger balance  ||0.02 |0.01  
|   0.07
 -f sample1000.ledger balance  ||1.02 |1.39  
|   0.53
 -f sample1.ledger balance ||   12.72 |   14.97  
|   4.63


Contributors:

   * Simon Michael
   * Tim Docker
   * HAppS, happstack and testpack developers

Stats:

   * Known errors: 0
   * Commits: 132
   * Committers: 2
   * Tests: 56
   * Non-test code lines: 2600
   * Days since release: 75

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

Re: [Haskell] Re: Marketing Haskell

[Jean-Philippe Bernardy]

On Fri, Apr 3, 2009 at 7:12 AM, Marc A. Ziegert  wrote:

> how about an octopus?

I could not resist the opportunity to combine two great ideas and give
you the haskell octopus logo in attachment. It's a bit rough, but with
a bit more polish, what do you think?

Cheers,
JP.
<>___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Marketing Haskell

[Anton van Straaten]

Jean-Philippe Bernardy wrote:

  On Fri, Apr 3, 2009 at 7:12 AM, Marc A. Ziegert  wrote:
  
  
how about an octopus?

  
  I could not resist the opportunity to combine two great ideas and give
you the haskell octopus logo in attachment. It's a bit rough, but with
a bit more polish, what do you think?

  

Octopus?  I thought it was a narwhal orgy.

  
  
  




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

[Haskell] Re: Marketing Haskell

[Benjamin L . Russell]

On Fri, 3 Apr 2009 09:09:26 +0200, Jean-Philippe Bernardy
 wrote:

>On Fri, Apr 3, 2009 at 7:12 AM, Marc A. Ziegert  wrote:
>
>> how about an octopus?
>
>I could not resist the opportunity to combine two great ideas and give
>you the haskell octopus logo in attachment. It's a bit rough, but with
>a bit more polish, what do you think?

Nice try, but an octupus has eight arms, not seven.  What about the
remaining arm?

Or is that a logo of two octopi, one with four arms, and the other
with three?  Oh no, the poor octopi!

-- Benjamin L. Russell
-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile:  +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." 
-- Matsuo Basho^ 

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

Re: [Haskell] Re: Marketing Haskell

[Thomas Davie]

On 3 Apr 2009, at 09:25, Benjamin L.Russell wrote:


On Fri, 3 Apr 2009 09:09:26 +0200, Jean-Philippe Bernardy
 wrote:


On Fri, Apr 3, 2009 at 7:12 AM, Marc A. Ziegert  wrote:


how about an octopus?


I could not resist the opportunity to combine two great ideas and  
give
you the haskell octopus logo in attachment. It's a bit rough, but  
with

a bit more polish, what do you think?


Nice try, but an octupus has eight arms, not seven.  What about the
remaining arm?

Or is that a logo of two octopi, one with four arms, and the other
with three?  Oh no, the poor octopi!


If it's an octopi, surely it should have 3.1415926... arms?  Where's  
the 0.1415926...?


Bob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: Marketing Haskell

[Benjamin L . Russell]

On Fri, 3 Apr 2009 10:18:17 +0200, Thomas Davie 
wrote:

>On 3 Apr 2009, at 09:25, Benjamin L.Russell wrote:
>
>>[...]
>>
>> Or is that a logo of two octopi, one with four arms, and the other
>> with three?  Oh no, the poor octopi!
>
>If it's an octopi, surely it should have 3.1415926... arms?  Where's  
>the 0.1415926...?

Actually, according to the Wikipedia entry for "octopus" (see
http://en.wikipedia.org/wiki/Octopus), I probably should have written
the plural as either "octopuses" or "octopodes":

>The Oxford English Dictionary (2004 update[26]) lists octopuses, octopi
> and octopodes (in that order); it labels octopodes "rare", and notes 
>that octopi derives from the mistaken assumption that octopus is a
> second declension Latin noun, which it is not.

Since the 3.1415926... derives from a mistaken assumption, the
0.1415926... disappears in a poof of logic.  

-- Benjamin L. Russell
-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile:  +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." 
-- Matsuo Basho^ 

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

[Haskell] Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library

[Edward Kmett]

Very nice to have!

FYI- there is at least one more quantification-based automatic
differentiation implementation in Hackage:

http://comonad.com/haskell/monoids/dist/doc/html/monoids/Data-Ring-Module-AutomaticDifferentiation.html

My implementation is/was focused upon use with monoids and other
more-limited-than-Num classes and only included the equivalent of your
'lift' and 'diffUU' operations, however.

-Edward Kmett

On Thu, Apr 2, 2009 at 10:28 PM, Bjorn Buckwalter <
bjorn.buckwal...@gmail.com> wrote:

> I'm pleased to announce the initial release of the Haskell fad
> library, developed by Barak A. Pearlmutter and Jeffrey Mark Siskind.
> Fad provides Forward Automatic Differentiation (AD) for functions
> polymorphic over instances of 'Num'. There have been many Haskell
> implementations of forward AD, with varying levels of completeness,
> published in papers and blog posts[1], but alarmingly few of these
> have made it into hackage -- to date Conal Elliot's vector-spaces[2]
> package is the only one I am aware of.
>
> Fad is an attempt to make as comprehensive and usable a forward AD
> package as is possible in Haskell. However, correctness is given
> priority over ease of use, and this is in my opinion the defining
> quality of fad. Specifically, Fad leverages Haskell's expressive
> type system to tackle the problem of _perturbation confusion_,
> brought to light in Pearlmutter and Siskind's 2005 paper "Perturbation
> Confusion and Referential Transparency"[3]. Fad prevents perturbation
> confusion by employing type-level "branding" as proposed by myself
> in a 2007 post to haskell-cafe[4]. To the best of our knowledge all
> other forward AD implementations in Haskell are susceptible to
> perturbation confusion.
>
> As this library has been in the works for quite some time it is
> worth noting that it hasn't benefited from Conal's ground-breaking
> work[5] in the area. Once we wrap our heads around his beautiful
> constructs perhaps we'll be able to borrow some tricks from him.
>
> As mentioned already, fad was developed primarily by Barak A.
> Pearlmutter and Jeffrey Mark Siskind. My own contribution has been
> providing Haskell infrastructure support and wrapping up loose ends
> in order to get the library into a releasable state. Many thanks
> to Barak and Jeffrey for permitting me to release fad under the BSD
> license.
>
> Fad resides on GitHub[6] and hackage[7] and is only a "cabal install
> fad" away! What follows is Fad's README, refer to the haddocks for
> detailed documentation.
>
> Thanks,
> Bjorn Buckwalter
>
>
> [1] http://www.haskell.org/haskellwiki/Functional_differentiation
> [2] http://www.haskell.org/haskellwiki/Vector-space
> [3]:  http://www.bcl.hamilton.ie/~qobi/nesting/papers/ifl2005.pdf
> [4]: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/22308/
> [5]: http://conal.net/papers/beautiful-differentiation/
> [6] http://github.com/bjornbm/fad/
> [7] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fad
>
>
> 
>
>   Copyright  : 2008-2009, Barak A. Pearlmutter and Jeffrey Mark Siskind
>   License: BSD3
>
>   Maintainer : bjorn.buckwal...@gmail.com
>   Stability  : experimental
>   Portability: GHC only?
>
> Forward Automatic Differentiation via overloading to perform
> nonstandard interpretation that replaces original numeric type with
> corresponding generalized dual number type.
>
> Each invocation of the differentiation function introduces a
> distinct perturbation, which requires a distinct dual number type.
> In order to prevent these from being confused, tagging, called
> branding in the Haskell community, is used.  This seems to prevent
> perturbation confusion, although it would be nice to have an actual
> proof of this.  The technique does require adding invocations of
> lift at appropriate places when nesting is present.
>
> For more information on perturbation confusion and the solution
> employed in this library see:
> 
> 
>
>
> Installation
> 
> To install:
>cabal install
>
> Or:
>runhaskell Setup.lhs configure
>runhaskell Setup.lhs build
>runhaskell Setup.lhs install
>
>
> Examples
> 
> Define an example function 'f':
>
> > import Numeric.FAD
> > f x = 6 - 5 * x + x ^ 2  -- Our example function
>
> Basic usage of the differentiation operator:
>
> > y   = f 2  -- f(2) = 0
> > y'  = diff f 2 -- First derivative f'(2) = -1
> > y'' = diff (diff f) 2  -- Second derivative f''(2) = 2
>
> List of derivatives:
>
> > ys = take 3 $ diffs f 2  -- [0, -1, 2]
>
> Example optimization method; find a zero using Newton's method:
>
> > y_newton1 = zeroNewton f 0   -- converges to first zero at 2.0.
> > y_newton2 = zeroNewton f 10  -- converges to second zero at 3.0.
>
>
> Credits
> ===
> Authors: Copyright 2008,
> Barak A. 

[Haskell] Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library

[Edward Kmett]

A somewhat tricky concern is that that the extra functionality in question
depends on a bunch of primitive definitions that lie below this in the
package and the AD engine is used by a layer on top.

So moving it out would introduce a circular dependency back into the package
or require me to stratify into two packages.  When I looked into
partitioning the package for another reason I found that I couldn't do so
without introducing some orphan instances, so it'll probably be a tricky bit
of surgery to split out. That said, it's probably still worth doing.

I also agree that I should be somewhat more pedantic about the name. =)
-Edward Kmett

On Fri, Apr 3, 2009 at 10:49 AM, Barak A. Pearlmutter wrote:

> I feel silly, did not even notice that!  Thanks for the pointer.
>
> Would be sensible to merge the functionalities; will try to import
> functionality in Data.Ring.Module.AutomaticDifferentiation currently
> missing from Numeric.FAD.
>
> (One pedantic note: should really be named
> Data.Ring.Module.AutomaticDifferentiation.Forward, since it is doing
> forward-mode accumulation automatic differentiation; reverse is
> an adjoint kettle of fish.)
> --
> Barak A. Pearlmutter
>  Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
>   http://www.bcl.hamilton.ie/~barak/
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] TFM09: Call for Papers (Formal Methods Week, Eindhoven, November 6th 2009)

[J.N. Oliveira]

  TFM2009
 2nd Int. FME Conference on Teaching Formal Methods
"Widening Access to Formal Methods"
   Friday, November 6th 2009
  co-located with
 FM2009 : 16th International Symposium on Formal Methods
Eindhoven, the Netherlands, November 2 - November 6, 2009

   CALL FOR PAPERS

(URL: http://www.di.uminho.pt/tfm09)


1. About the conference
---
Ten years after the First World Formal Methods Congress (FM'99) in  
Toulouse,
formal methods communities from all over the world will once again  
have an
opportunity to come together.  As part of the First Formal Methods  
Week event
surrounding the FM2009 conference in Eindhoven, Formal Methods Europe  
will
be organizing TFM2009, the Second International Conference on  
Teaching Formal

Methods.

The conference will serve as a forum to explore the successes and  
failures

of Formal Methods (FM) education, and to promote cooperative projects to
further education and training in FMs. We would like to provide a  
forum for
lecturers, teachers, and industrial partners to discuss their  
experience,

present their pedagogical methodologies, and explore best practices.

TFM2009 follows in a series of recent events on teaching formal methods,
including: two BCS-FACS TFM workshops (Oxford in 2003, and London in  
2006),

the TFM 2004 conference in Ghent (with proceedings published as Springer
LNCS Volume 3294), the FM-Ed 2006 workshop (Hamilton, co-located with  
FM'06),

FORMED (Budapest, at ETAPS 2008), FMET 2008 (Kitakyushu 2008, co-located
with ICFEM), etc.

2. Topics of interest
-
Formal methods (FM) have an important role to play in the development of
complex computing systems - a role acknowledged in industrial  
standards such
as IEC 61508 and ISO/IEC 15408, and in the increasing use of precise  
modeling

notations, semantic markup languages, and model-driven techniques. There
is a growing need for software engineers who can work effectively  
with simple,
mathematical abstractions, and with practical notions of inference  
and proof.
However, there is little clear guidance ? for educators, for  
managers, or
for the engineers themselves ? as to what might comprise a basic  
education
in FM. Neither the present IEEE/ACM Software Engineering Body of  
Knowledge
(SWEBOK) nor the forthcoming Graduate Software Engineering Reference  
Curriculum
(GSWERC) provide the kind of specific information that teachers and  
practitioners

need to establish an adequate, balanced programme of learning in FM.

Original contributions are solicited that provide insight, opinions, and
suggestions for courses of action regarding the teaching FMs,  
including but

not limited to the following aspects:

* experiences of teaching FMs, both successful and unsuccessful;
* educational resources including the use of books, case studies  
and the internet;

* the education of weak and mathphobic students;
* the integration, or otherwise, of FMs into the curriculum,  
including
  contributions to the definition of a Formal Methods Body of  
Knowledge (FMBOK);

* the advantages of FM-trained graduates in the workplace;
* changing attitudes towards FMs in students, academic staff and  
practitioners;

* the necessary mathematical background.

Submissions may be up to 20 pages long, using the Springer LNCS  
format. Negotiations
are under way with Springer Verlag for the publication of the  
proceedings

of the conference in the LNCS series.

3. Important dates
--
Please put the following dates in your diary:

Submission deadline May 25, 2009
Notification of acceptance  July 6, 2009
Final version   August 3, 2009

4. Invited speakers
---
To be announced

5. Programme Committee
--
Izzat Alsmadi   (North Dakota State University, USA)
Dines Bjorner   (IIMM Institute, Denmark)
Eerke Boiten(University of Kent, UK)
Raymond Boute   (Universiteit Gent, Belgium)
Andrew Butterfield  (Trinity College, Dublin)
Jim Davies  (University of Oxford, UK)
David Duce  (Oxford Brookes University, UK)
John Fitzgerald (University of Newcastle upon Tyne, UK)
Jeremy Gibbons  (University of Oxford, UK)
Randolph Johnson(National Security Agency, USA)
Michael Mac an Airchinnigh  (Trinity College, Dublin)
Dino Mandrioli  (Politecnico di Milano, Italy)
Jose Oliveira   (Universidade do Minho, Portugal)
Kees Pronk  (Technische Universiteit Delft, NL)
Bernhard Schaetz(Tecnical University of Munique, Germany)
Wolfgang Schreiner  (Johannes Kepler University Linz, Austria)
Simao Melo de Sousa (Universidade da Beira Interior, Portugal)
Kenji Taguchi   (National Institute of Informatics, Japan)
Jeannette Wing  (Carnegie-Mellon University, USA)




smime.p7s
D