[Haskell] OPLSS 2018: Application Extension

[Paul Downen]

We had several cancellations due to entry visas being denied. Therefore, we
are reopening applications to the Oregon Programming Languages Summer
School (OPLSS) to be held from July 9th to July 21st, 2018 at the
University of Oregon in Eugene.  Students can also register for an
introductory session which takes place from July 3rd to July 8th.  This
session is not mandatory; it is also possible to register for the
introductory session only.

Full information on registration can be found here:
   http://www.cs.uoregon.edu/Activities/summerschool

In addition to the previously announced program we have two more
presentations:

William Duff - Jane Street
 Typing speed: how rich types enable performance engineering

Aaron Turon - Mozilla
Help wanted:  research questions in Rust

Hope to see many of you.

   Bob, Guy, Paul and Zena
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] OPLSS 2018

[Paul Downen]

We are pleased to announce the program for the 17th annual Oregon
Programming
Languages Summer School (OPLSS) to be held from July 3rd to July 21th, 2018
at
the University of Oregon in Eugene. The first week, from July 3rd to July
7th,
will be an introductory session covering the foundations of programming
languages (semantics, types, proof techniques, etc.).  The introductory
session
will help attendees who have not taken a course on this material prepare
for the
rest of the school. Please contact the organizers if you have questions
about
whether the introduction session will be helpful given your background.

The registration deadline is April 2nd, 2018. Registration for the first
week is
optional. Full information on registration and scholarships can be found
here:

http://www.cs.uoregon.edu/Activities/summerschool

The program is as follows:

July 3-7Foundations of Programming Languages

Paul Downen
University of Oregon

Jan Hoffman
Carnegie Mellon University

July 9-21   PARALLELISM AND CONCURRENCY

Umut Acar - Carnegie Mellon University
Parallel Algorithms

Arvind - Massachusetts Institute of Technology
Dataflow: A retrospective.
Atomicity in modular design

Stephanie Balzer - Carnegie Mellon University
Session-Typed Concurrent Programming

Andrej Bauer - University of Ljubljana
Algebraic Effects and Handlers

Guy Blelloch - Carnegie Mellon University
Parallel cost semantics and bounded implementations

Dan R. Ghica - University of Birmingham
Game Semantics

Robert Harper - Carnegie Mellon University
Computational Type Theory

Gabriele Keller - University of New South Wales
Purely Functional Array Programming and its Compilation to
High-Performance Architectures

Keshav Pingali - University of Texas, Austin
Parallel program = Operator + Schedule + Parallel Data Structures

Vijay Saraswat - Goldman Sachs
Resilient X10

We hope you can join us for this excellent program.
Zena Ariola, Guy Blelloch, Paul Downen, and Robert Harper

​
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b")

[Paul Connolley]

Hello all,

(I've been lurking on the Haskell community list for a good while now and
I'm just now plucking up the courage to say hello.)

I feel that Wren is spot on: this isn't somehow an attempt to change the
existing behaviour but a way to confirm to existing members and *advertise
to newcomers* that this is a safe and friendly community.

As more of a reader than a contributor to this community I don't feel I
have earnt much say in what a future Haskell Community CoC contains.
However, Wren has linked to some good articles that talk about existing
CoCs that are being used in anger. I think that they would be a really
valuable resource in this endeavour.

I believe that Rust's CoC is MIT licensed and that some of the other codes
of conduct mentioned in those articles are licensed under the Creative
Commons. Deriving our own from one of these which have had a diverse set of
people writing, discussing and refining it sounds, to me, like a good
starting point.

No matter what, I look forward to seeing this discussion continue and also
to the finished document!

Regards,
Paul.


On 25 April 2017 at 02:39, wren romano <w...@community.haskell.org> wrote:

> I'm +1 to having a CoC. It doesn't have to be complicated, and indeed
> CoCs are better when they're uncomplicated (but explicit! vague CoCs
> help noone).
>
> The point of a CoC is not to change people's behavior (if you want
> that, there are more effective approaches). The point is to serve as a
> touchstone for community values. Without a touchstone, communities
> drift over time as people age and come and go. Drifting itself is
> unavoidable and not necessarily bad, but sometimes that drifting is
> the slipping that becomes corrosive. Touchstones give communities a
> way to correct for corrosion: by concretely recording the past they
> make the past visible, and thus make the present visible as something
> that has changed from the past.
>
> CoCs also, as Tom says, make the community values explicit for
> outsiders to see. This is especially important for women and
> minorities, because we are disproportionately affected by breaches of
> civility. This is why numerous organizations for women in STEM
> advocate for having CoCs. To pick a few examples:
>
> https://www.ashedryden.com/blog/codes-of-conduct-101-faq
> https://adainitiative.org/2014/02/18/
> https://geekfeminism.org/2014/06/30/
>
> The mere existence of a CoC indicates that at least at some point the
> community cared enough about civility to try to ensure it. That alone
> indicates that the community has higher standards for civility than
> the vast bulk of online communities for programming. And it is
> something we look for. If you want to avoid discouraging women and
> minorities from joining, it's not enough to play Simon Says, you have
> to write the rules down too.
>
> --
> Live well,
> ~wren
> ___
> Haskell-community mailing list
> Haskell-community@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>



-- 
Paul Connolley
*Software Developer*
https://connrs.uk
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Core libraries

[Paul van der Walt]

Hello GHC users,

For various reasons i'm trying to package something which is compatible
with/equivalent to the Haskell Platform.

I've been looking at the list posted at [0], and it turns out that GHC
7.10.2 doesn't bundle all the packages that are promised.  (Or it's a
case of PEBKAC and i apologise!)

When i do `ghc-pkg list`, the output under ../package.conf.d provided by
GHC notably has the following differences with the website list:

$ diff website-list <(ghc-pkg list | ..prettify..)
2a3,4
> binary
> bin-package-db
10c12,14
< haddock
---
> ghc-prim
> haskeline
> hoopl
12,13c16
< old-locale
< old-time
---
> integer-gmp
15a19
> rts
16a21
> terminfo

What surprises me is the lack of haddock, old-time and old-locale.  Is
this intentional, or a glitch on the website?  I notice that these
"missing" libraries are repeated in the `Additional Platform Libraries'
and `Programs and Tools' sections.  I guess this means that as a GHC
packager, i should add these items separately?

I guess what i'm saying is that i believe there is a bug in that list
[0], but i'm not sure enough that i understand the situation to report
it as such :).

Sorry about the verbiage, and kind regards,
p.

0. 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Found hole

[Stephen Paul Weber]

The leading underscore invokes the typed holes extension. If you want to
use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
of the source file. (I am not sure why this extension was enabled by
default.)


This is very concening for me.  Extensions should *never* be enabled by 
default!  When the TypedHoles discussion originally came up there was 
definitely talk of using a switch to enable them (in fact, IIRC, they 
weren't originally really quite an extension, just a compiler mode, but that 
may have been a misinterpretation on my part).


Having them on by default mean that valid Haskell2010 programs might get 
rejected by GHC by default, which is a pretty bad state of affairs.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Found hole

[Stephen Paul Weber]

Typed holes is not an extension, because it's considered a warning/error. 
The reason for this is that code with typed holes is NOT valid haskell to 
begin with, therefore the behaviour doesn't conflict with any description 
in the report.


Well, now I feel very silly about my last email to this list.  This is what 
I understood.  I'm glad to see this is indeed the case.


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: The future of the Haskell98 and Haskell2010 packages

[Stephen Paul Weber]

RebindableSyntax


I thought this would work, but people seemed pretty sure we would need to do 
more work than RebindableSyntax to get everything in place.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I suppose that -XOverlappingInstances could mean silently honour 
OVERLAPPABLE/OVERLAPPING pragmas, while lacking it would mean honour 
OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings or even don't 
honour them and warn.

But that is different to the behaviour today, so we'd need a new LANGUAGE 
pragma.  Perhaps -XHonourOverlappingInstances or something.

This would be a reasonable alternative to the keyword-based solution.  At 
least for now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8
bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk
dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg
9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb
PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca
khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl
TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9
Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg
/3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+
G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8
ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN
W+DNBoXbr9mp8eNGjl6O
=CFkA
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

instance {-# OVERLAPPABLE #-} Show a = Show [a] where ...

instance {-# OVERLAPPING #-} Show [Char] where ...

This, to me, is an admission that developers are not going to want to turn 
overlapping on globally in general, and so the current language extensions 
would not make sense to get adopted into the core language at any point.  
I agree with this idea, and so would second the proposal mentioned at 
http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/cjb4jmr
 
that a language extension that adds actual keywords to tag instances that 
should be allowed to overlap be added, instead of resorting to pragmas.  
This seems like an approach that could be useful in general and one could 
imagine moving past an extension to the core language at some point, 
potentially.

- -- 
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJT2DFBAAoJENEcKRHOUZzemmIQAJEbSjPyx745UI6mkuhBVhKl
LQWJlpu0/kzBHaFJl/mWcghKxoBFWwU+pCTh/Pr2oj0rp/KGskBLlplIqB4btZTA
ov2MpPrsHm1M37MuGyMtiBhs57UJE+saKKuvcH3qzLZyBCHorE3lFcKAFbNupBrL
e/vgNblQ70KGmDRAKqbAQHm9anoGeZUJPgQ9ylVEH4nBYLDo0YSNo/zTeB7fK2yv
xBE+Ul3YGfhzf82cLJhYNQOpi5wJ3JEDBevKXcGRzr4Mhzn2Lke+26tu0tx6sOSN
snPX2REoeQD1AfXvuNKSxV7BL+CQeyAOOmm2Isj3vW/oO3gkqpfRjCFc+ZSPEjlG
XQ3S7L7cgNB34rd6sOFzTv83PXvsH0a0d5RqKUM2kN/qGEjSbAQ1FVyJEUcaEmzr
jBnVnWq+abCOSOBg4joGfTxjq0zufdjxkzScEJVDVZ4pIXoxej7HJBi8UfIvo3Jo
EDMGGsLSedt4tR2LzYf/5up7GPfuBsFQQzuIcdgMG8/zYca7zWPJgyunlXAPcbzr
RvM/gf63SCBuVaQjrtv2Zhzp3PucWOL94NEmLYONU3uuEmo6bq1VO42fOUcl7X/1
UyhFbtoV7s/7PVClxdD4Ag9PumtSfl/CSvN0BA8AzDwTuHWNOPdThAHFqfAtRsD0
GyNzVRNOGuze9SqkLc4T
=YeKu
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Stephen Paul Weber]

Somebody signing messages as Felipe Lessa wrote:

OTOH, the pragma is mostly harmless for older GHC versions, while the
keyword approach needs a preprocessor.


Only if *both* the old LANGUAGE pragma and the new pragma were employed, 
which will generate a deprecation warning for awhile and then eventually 
(likely) be rejected by newer GHCs, thus requiring a prepropcessor in either 
case.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Seeking Control.Lens Combinator

[Charlie Paul]

Hello,

I'm looking for a combinator along the lines of
() :: Lens' a b - Lens' a b' - Lens' a (b,b')
I can see how it could lead to lenses that don't follow the laws, but
for Lenses which are somehow independent (like _1 and _2), it works
perfectly well. Is there a way in lens to specify this independence?

Thank you,

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

Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

[Paul Liu]

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
installing libraries with --enable-shared and loading a GLFW program
into GHCi. Using ghci -fno-ghci-sandbox, everything works great
including closing and restarting GL window multiple times. Can't wait
for the  official release of GHC 7.8!

On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
 thats the linker bug.

 the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game
 in recent memory. GHCI + foreign libs should work fine now (modulo thread
 local storage related thing).

 the historical element doesn't matter any more.

 To the best of my knowledge, all such issues should be gone. Anyone who
 cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.

 the better this issue is properly tested (which i believe it has been), the
 more we can actually prevent it from happening. This requires people to test
 with HEAD GHCi now, rather than doing archaeology.

 anyone who cares, please play with GHCI in HEAD. If your lib doesn't work
 with ghci, please report a bug. It would be a new bug because it wont' be
 the previous reasons it hasnt' worked.


 tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD.
 Help us make sure it stays resolved by testing HEAD.

 thanks
 -Carter




 On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote:

 I reported a problem with statically linked GLFW library on Mac OS X
 Lion in this thread:

 http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html

 I do not know why this is broken on Mac OS X Lion, but not on Linux or
 Windows. There was an EnableGUI hack for GHC 7.2 (and previous
 versions) and OS X version before Lion, but it no longer works. So I'm
 not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them
 that caused this problem.

 Regards,
 Paul Liu

 On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald
 carter.schonw...@gmail.com wrote:
  Hey simon, the two issues that have recurrently bit ghci interaction
  with
  foreign GUI libs are
  1) the ghci linker.  This is fixed in head by now having ghci use the
  system
  linker
  2) some GUI libs require thread local state, and ghci has a flag for
  that
  3)  I'm not aware of anyone reporting newly broken libs wrt GUI bindings
  when 7.6 rolled out.  The only fix that's relevant to 7.8 is the
  dylinker
  bit, but that would have been a problem historically too.
 
  I believe a number of folks in #haskell-game have recently tested point
  one.
  (Though I should ask to double check)
 
  At the very least, I'm not aware of hearing of such a 7.6 specific ghci
  breakage before.
 
 
  On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:
 
  Dear GHC devs
 
 
 
  See below (in red).  I do not know the details of this, but it sounds
  like
  a pretty serious problem, and it used to work.  Is whatever-it-is
  confirmed
  fixed in 7.8?  Do we have a test that’ll trip if it breaks again?  (I’m
  guessing that the latter might be hard.)
 
 
 
  Thanks
 
 
 
  Simon
 
 
 
  -Original Message-
  From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf
  Of
  Paul Liu
  Sent: 30 September 2013 07:18
  To: Conal Elliott
  Cc: Haskell Cafe
  Subject: Re: [Haskell-cafe] Poll  plea: State of GUI  graphics
  libraries
  in Haskell
 
 
 
  Hi Conal,
 
 
 
  I wasn't able to make it to last Saturday's FARM track, but I think
 
  there was a good chance that Paul would have demonstrated his Euterpea
 
  music library, which includes a GUI interface (called MUI) written on
 
  top of GLFW. I wrote its initial implementation (around 2009?) with a
 
  monadic interface that let you wire together UI components with
 
  signals (I believe Dan later wrote an arrow interface, but I could be
 
  wrong). It was actually inspired by the ideas behind your Phooey UI
 
  library. It should be very easy to extract this part out as a
 
  standalone package if there is enough interest.
 
 
 
  The only issue with it (and all other UI libraries) is that it doesn't
 
  play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4
 
  on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke
 
  Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this
 
  problem.
 
 
 
  BTW, as also the author of the GLFW library on HackageDB, I've done
 
  barely minimal to keep this Haskell binding afloat. I'm actually
 
  leaning towards GLFW-b library, which is better maintained, and
 
  provides similar binding for GLFW C library but with a saner interface
 
  (no dependency on the OpenGL library, for example). If you don't need
 
  the two extra things that GLFW does (choice of either dynamic or
 
  static linking to GLFW C, and an embedded bitmap font), I suggest you
 
  try out GLFW-b if you are only looking for a think graphics layer with
 
  input+window+OpenGL.
 
 
 
  The only thing keeping GLFW-b from becoming a good

Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

[Paul Liu]

No. GLFW does not give you any UI elements, just basic windowing and
input handling.

Euterpea has a UI layer on top of GLFW that provides text boxes and
sliders, etc, entirely written in Haskell.

On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote:
 Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL
 display windows, e.g., text boxes and sliders?  -- Conal


 On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote:

 Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
 installing libraries with --enable-shared and loading a GLFW program
 into GHCi. Using ghci -fno-ghci-sandbox, everything works great
 including closing and restarting GL window multiple times. Can't wait
 for the  official release of GHC 7.8!

 On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
 carter.schonw...@gmail.com wrote:
  thats the linker bug.
 
  the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
  #haskell-game
  in recent memory. GHCI + foreign libs should work fine now (modulo
  thread
  local storage related thing).
 
  the historical element doesn't matter any more.
 
  To the best of my knowledge, all such issues should be gone. Anyone who
  cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.
 
  the better this issue is properly tested (which i believe it has been),
  the
  more we can actually prevent it from happening. This requires people to
  test
  with HEAD GHCi now, rather than doing archaeology.
 
  anyone who cares, please play with GHCI in HEAD. If your lib doesn't
  work
  with ghci, please report a bug. It would be a new bug because it wont'
  be
  the previous reasons it hasnt' worked.
 
 
  tl;dr to the best of my knowledge this issue is resolved in HEAD. Test
  HEAD.
  Help us make sure it stays resolved by testing HEAD.
 
  thanks
  -Carter
 
 
 
 
  On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote:
 
  I reported a problem with statically linked GLFW library on Mac OS X
  Lion in this thread:
 
  http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
 
  I do not know why this is broken on Mac OS X Lion, but not on Linux or
  Windows. There was an EnableGUI hack for GHC 7.2 (and previous
  versions) and OS X version before Lion, but it no longer works. So I'm
  not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them
  that caused this problem.
 
  Regards,
  Paul Liu
 
  On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald
  carter.schonw...@gmail.com wrote:
   Hey simon, the two issues that have recurrently bit ghci interaction
   with
   foreign GUI libs are
   1) the ghci linker.  This is fixed in head by now having ghci use the
   system
   linker
   2) some GUI libs require thread local state, and ghci has a flag for
   that
   3)  I'm not aware of anyone reporting newly broken libs wrt GUI
   bindings
   when 7.6 rolled out.  The only fix that's relevant to 7.8 is the
   dylinker
   bit, but that would have been a problem historically too.
  
   I believe a number of folks in #haskell-game have recently tested
   point
   one.
   (Though I should ask to double check)
  
   At the very least, I'm not aware of hearing of such a 7.6 specific
   ghci
   breakage before.
  
  
   On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:
  
   Dear GHC devs
  
  
  
   See below (in red).  I do not know the details of this, but it
   sounds
   like
   a pretty serious problem, and it used to work.  Is whatever-it-is
   confirmed
   fixed in 7.8?  Do we have a test that’ll trip if it breaks again?
   (I’m
   guessing that the latter might be hard.)
  
  
  
   Thanks
  
  
  
   Simon
  
  
  
   -Original Message-
   From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On
   Behalf
   Of
   Paul Liu
   Sent: 30 September 2013 07:18
   To: Conal Elliott
   Cc: Haskell Cafe
   Subject: Re: [Haskell-cafe] Poll  plea: State of GUI  graphics
   libraries
   in Haskell
  
  
  
   Hi Conal,
  
  
  
   I wasn't able to make it to last Saturday's FARM track, but I think
  
   there was a good chance that Paul would have demonstrated his
   Euterpea
  
   music library, which includes a GUI interface (called MUI) written
   on
  
   top of GLFW. I wrote its initial implementation (around 2009?) with
   a
  
   monadic interface that let you wire together UI components with
  
   signals (I believe Dan later wrote an arrow interface, but I could
   be
  
   wrong). It was actually inspired by the ideas behind your Phooey UI
  
   library. It should be very easy to extract this part out as a
  
   standalone package if there is enough interest.
  
  
  
   The only issue with it (and all other UI libraries) is that it
   doesn't
  
   play nicely in GHCi. It used to work pretty well with GHC 7.2 and
   7.4
  
   on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke
  
   Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this
  
   problem

Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

[Paul Liu]

I only managed to find some screenshots from Harley Trung's class
projects a few years ago:

https://github.com/harleyttd/keyboard-fretboard/blob/master/demo2.png

https://github.com/harleyttd/InstrVislizr/blob/master/stereo.png

It was nothing fancy, only basic widgets, single font, not skinnable.
The design was based on your Phooey work, monadic composition of UI
elements wired by signals. I deliberately made the layout not reactive
in order to simplify implementation.

Regards,
Paul Liu

On Wed, Oct 2, 2013 at 3:28 PM, Conal Elliott co...@conal.net wrote:
 Interesting. How are the aesthetics? Can you point me to screen shots?

 It'd be a lot of work, but one cool project would be to create *beautiful*
 GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we
 could afford to put a lot into visual details.

 A complementary project is designing a semantically precise and elegant
 (denotative/genuinely functional to use Peter Landin's terms) GUI DSEL
 that would be simpler and more powerful than the conventional OO-inspired
 libraries we have so much trouble getting to work in Haskell. I've thought
 about this sort of thing on and off for a very long time and would be happy
 to be involved if others are interested also.

 Together, these two efforts would yield an approach to GUIs that is
 beautiful inside and out.

 -- Conal



 On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu nine...@gmail.com wrote:

 No. GLFW does not give you any UI elements, just basic windowing and
 input handling.

 Euterpea has a UI layer on top of GLFW that provides text boxes and
 sliders, etc, entirely written in Haskell.

 On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote:
  Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL
  display windows, e.g., text boxes and sliders?  -- Conal
 
 
  On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote:
 
  Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by
  installing libraries with --enable-shared and loading a GLFW program
  into GHCi. Using ghci -fno-ghci-sandbox, everything works great
  including closing and restarting GL window multiple times. Can't wait
  for the  official release of GHC 7.8!
 
  On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald
  carter.schonw...@gmail.com wrote:
   thats the linker bug.
  
   the glfw stuff has been tested on ghc HEAD / 7.7 by folks on
   #haskell-game
   in recent memory. GHCI + foreign libs should work fine now (modulo
   thread
   local storage related thing).
  
   the historical element doesn't matter any more.
  
   To the best of my knowledge, all such issues should be gone. Anyone
   who
   cares about making sure GHCI+ gui libs play nice, PLEASE test with
   HEAD.
  
   the better this issue is properly tested (which i believe it has
   been),
   the
   more we can actually prevent it from happening. This requires people
   to
   test
   with HEAD GHCi now, rather than doing archaeology.
  
   anyone who cares, please play with GHCI in HEAD. If your lib doesn't
   work
   with ghci, please report a bug. It would be a new bug because it
   wont'
   be
   the previous reasons it hasnt' worked.
  
  
   tl;dr to the best of my knowledge this issue is resolved in HEAD.
   Test
   HEAD.
   Help us make sure it stays resolved by testing HEAD.
  
   thanks
   -Carter
  
  
  
  
   On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote:
  
   I reported a problem with statically linked GLFW library on Mac OS X
   Lion in this thread:
  
  
   http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html
  
   I do not know why this is broken on Mac OS X Lion, but not on Linux
   or
   Windows. There was an EnableGUI hack for GHC 7.2 (and previous
   versions) and OS X version before Lion, but it no longer works. So
   I'm
   not sure if it is OS X Lion, or GLFW, or GHC, or a combination of
   them
   that caused this problem.
  
   Regards,
   Paul Liu
  
   On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald
   carter.schonw...@gmail.com wrote:
Hey simon, the two issues that have recurrently bit ghci
interaction
with
foreign GUI libs are
1) the ghci linker.  This is fixed in head by now having ghci use
the
system
linker
2) some GUI libs require thread local state, and ghci has a flag
for
that
3)  I'm not aware of anyone reporting newly broken libs wrt GUI
bindings
when 7.6 rolled out.  The only fix that's relevant to 7.8 is the
dylinker
bit, but that would have been a problem historically too.
   
I believe a number of folks in #haskell-game have recently tested
point
one.
(Though I should ask to double check)
   
At the very least, I'm not aware of hearing of such a 7.6 specific
ghci
breakage before.
   
   
On Tuesday, October 1, 2013, Simon Peyton-Jones wrote:
   
Dear GHC devs
   
   
   
See below (in red).  I do not know the details

Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell

[Paul Liu]

Hi Conal,

I wasn't able to make it to last Saturday's FARM track, but I think
there was a good chance that Paul would have demonstrated his Euterpea
music library, which includes a GUI interface (called MUI) written on
top of GLFW. I wrote its initial implementation (around 2009?) with a
monadic interface that let you wire together UI components with
signals (I believe Dan later wrote an arrow interface, but I could be
wrong). It was actually inspired by the ideas behind your Phooey UI
library. It should be very easy to extract this part out as a
standalone package if there is enough interest.

The only issue with it (and all other UI libraries) is that it doesn't
play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4
on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke
Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this
problem.

BTW, as also the author of the GLFW library on HackageDB, I've done
barely minimal to keep this Haskell binding afloat. I'm actually
leaning towards GLFW-b library, which is better maintained, and
provides similar binding for GLFW C library but with a saner interface
(no dependency on the OpenGL library, for example). If you don't need
the two extra things that GLFW does (choice of either dynamic or
static linking to GLFW C, and an embedded bitmap font), I suggest you
try out GLFW-b if you are only looking for a think graphics layer with
input+window+OpenGL.

The only thing keeping GLFW-b from becoming a good foundation for a
pure Haskell UI lib is IMHO the lack of a light-weight,
cross-platform, and full-featured font rendering solution. I believe
many other libraries (including Diagram) are having the same problem.


On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote:
 I'm polling to see whether there are will and expertise to reboot graphics
 and GUIs work in Haskell. I miss working on functional graphics and GUIs in
 Haskell, as I've been blocked for several years (eight?) due to the absence
 of low-level foundation libraries having the following properties:

 * cross-platform,
 * easily buildable,
 * GHCi-friendly, and
 * OpenGL-compatible.

 The last several times I tried Gtk2hs, I was unable to compile it on my Mac.
 Years ago when I was able to compile, the GUIs looked and interacted like a
 Linux app, which made them awkward and upleasant to use. wxHaskell (whose
 API and visual appearance I prefered) has for years been incompatible with
 GHCi, in that the second time I open a top-level window, the host process
 (GHCi) dies abruptly. Since my GUI  graphics programs are often one-liners,
 and I tend to experiment a lot, using a full compilation greatly thwarts my
 flow. For many years, I've thought that the situation would eventually
 improve, since I'm far from the only person who wants GUIs or graphics from
 Haskell.

 About three years ago, I built a modern replacement of my old Pan and
 Vertigo systems (optimized high-level functional graphics in 2D and 3D),
 generating screamingly fast GPU rendering code. I'd love to share it with
 the community, but I'm unable to use it even myself.

 Two questions:

 * Am I mistaken about the current status? I.e., is there a solution for
 Haskell GUI  graphics programming that satisfies the properties I'm looking
 for (cross-platform, easily buildable, GHCi-friendly, and
 OpenGL-compatible)?
 * Are there people willing and able to fix this situation? My own
 contributions would be to test and to share high-level composable and
 efficient GUI and graphics libraries on top of a working foundation.

 Looking forward to replies. Thanks,

 -- Conal

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




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

[Haskell-cafe] Lenses: Should I declare Getters?

[Charlie Paul]

I've been looking through Edward Kmett's lens library, and I'm a bit
befuddled about Getters. In my own code, why would I want to have something
be a Getter instead of a plain function? As far as I can see, a plain
function is simpler to use, and can be converted to a Getter with to if
we want to use it as a Fold. Is there a situation where writing a Getter is
superior than writing a function, then lifting it as needed?

Thank you,

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

Re: bundled libraries in ghc

[Stephen Paul Weber]

Somebody claiming to be Jens Petersen wrote:

The libraries in question here are haskeline, terminfo, and xhtml.


Are those libraries needed by GHCI?  Could we just statically link those 
ones into GHC?


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Performance of delete-and-return-last-element

[Lucas Paul]

Suppose I need to get an element from a data structure, and also
modify the data structure. For example, I might need to get and delete
the last element of a list:

darle xs = ((last xs), (rmlast xs)) where
  rmlast [_] = []
  rmlast (y:ys) = y:(rmlast ys)

There are probably other and better ways to write rmlast, but I want
to focus on the fact that darle here, for lack of a better name off
the top of my head, appears to traverse the list twice. Once to get
the element, and once to remove it to produce a new list. This seems
bad. Especially for large data structures, I don't want to be
traversing twice to do what ought to be one operation. To fix it, I
might be tempted to write something like:

darle' [a] = (a, [])
darle' (x:xs) = let (a, ys) = darle' xs in (a, (x:ys))

But this version has lost its elegance. It was also kind of harder to
come up with, and for more complex data structures (like the binary
search tree) the simpler expression is really desirable. Can a really
smart compiler transform/optimize the first definition into something
that traverses the data structure only once? Can GHC?

- Lucas

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

[Haskell-cafe] haskell.org down?

[Paul Koerbitz]

Dear list,

I am not sure if this is the right place to post this, but I just went
to haskell.org and got a

Sorry! This site is experiencing technical difficulties.

error message.

cheers
Paul

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

Re: [Haskell-cafe] haskell.org down?

[Paul Koerbitz]

On Mon, Jul 29, 2013 at 7:45 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk wrote:
 Sit tight. I recommend using Google cached versions of
 the pages.

Thanks. I hope this didn't come of as complaint. I am thankful for the
work that goes into maintaining the site.

Cheers
Paul

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

Re: Installing GHC and libgmp.so

[Stephen Paul Weber]

Somebody claiming to be harry wrote:

all of this stems from GHC
looking for libgmp.so, instead of libgmp.so.3


Most systems symlink libgmp.so to the default version installed.  On Debian 
stable it's libgmp.so.10 ... so it may work for you, but you may want to 
upgrade.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Installing GHC and libgmp.so

[Stephen Paul Weber]

Somebody claiming to be harry wrote:

Stephen Paul Weber wrote

Somebody claiming to be harry wrote:

I also
need to install GHC on systems where I don't have root access, so I can't
create the link.


You can create the link somewhere else, and use LD_LIBRARY_PATH
I have done this before.  If your version of libgmp is compatible, it should 
work.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overloaded record fields

[Stephen Paul Weber]

Somebody claiming to be Simon Peyton-Jones wrote:

It is kind of weird that
f . g  means\x. f (g x)
but f.gmeansg f


Anything that makes f.g mean something different from f . g just makes the 
code soup.


F . g being different from F.g is already *very* unfortunate.  The 
capital-letter makes it normally not too crazy, but sometimes you want to 
compose data constructors, and then it's a big issue.


Making this issue worse in order to solve something else does not seem like 
a good trade-off.


Why not use a different character?  There are lots of them :)

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overloaded record fields

[Stephen Paul Weber]

Somebody claiming to be Dominique Devriese wrote:

I would prefer to have dot notation for a
general, very tightly-binding reverse application, and the type of the record
selector for a field f changed to forall r t. r { f :: t } = r - t
instead of
SomeRecordType - t.  Such a general reverse application dot would
allow things like string.toUpper


If that's even possible, then we do not need the `.` at all, and can just 
use perfectly normal function application.


If people want to create YetAnotherFunctionApplicationOperator, we can't 
stop them, but no reason to include one (especially that overlaps with an 
existing, more useful, operator)


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] %==%, :==: and type equality in the singletons library

[Paul Brauner]

Hello,

from the output of -ddump-splices I dont think it is the case but I'm
asking anyway: is there any way to deduce a ~ b from a :==: b?

Given

  data T = C1 | ... | Cn

I can easily derive

  data EqT :: T - T - * where
 EqT :: a ~ b = EqT a b

  eqT :: ST a - ST b - Maybe (EqT a b)
  eqT SC1 SC1 = Just EqT
  ...
  eqT SCn SCn = Just EqT
  eqT _ _ = Nothing

but this kind of replicates the boilerplate generated by the singletons
library for %==%. However I can't see how to leverage %==% to inhabit eqT
since I can't deduce a ~ b from a %==% b == STrue.

Any idea? If there's no way to write eqT using what singletons generates,
wouldn't it make sense for it to generate something that relates :==: and ~
?

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

Re: [Haskell-cafe] %==%, :==: and type equality in the singletons library

[Paul Brauner]

On Mon, Apr 8, 2013 at 9:59 PM, Richard Eisenberg e...@cis.upenn.edu wrote:



 On Apr 8, 2013, at 3:12 PM, Paul Brauner polux2...@gmail.com wrote:

  from the output of -ddump-splices I dont think it is the case but I'm
 asking anyway: is there any way to deduce a ~ b from a :==: b?

 Not easily. You would have to write a (potentially recursive) function
 that explicitly matches singleton constructors, similarly to what you
 wrote. (You could say that this function is a (potentially inductive) proof
 that the generated definition of :==: is correct.)


Ok.


 I agree that this is boilerplate and could easily be generated. I've added
 it to the list of features to be included in the next version of
 singletons. I'm surprised myself that it hasn't occurred to me to include
 this before.


Great!

Paul


  Richard



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

Re: [Haskell-cafe] Pattern matching with singletons

[Paul Brauner]

Very helpful, thanks! I may come back with more singleton/type families
questions :)


On Tue, Mar 26, 2013 at 6:41 PM, Richard Eisenberg e...@cis.upenn.eduwrote:

 Hello Paul,

  - Forwarded message from Paul Brauner polux2...@gmail.com -

 snip

- is a ~ ('CC ('Left 'CA)) a consequence of the definitions of SCC,
SLeft, ... (in which case GHC could infer it but for some reason can't)
- or are these pattern + definitions not sufficient to prove that a
~ ('CC ('Left 'CA)) no matter what?

 The first one. GHC can deduce that (a ~ ('CC ('Left b))), for some fresh
 variable (b :: TA), but it can't yet take the next step and decide that,
 because TA has only one constructor, b must in fact be 'CA. In type-theory
 lingo, this deduction is called eta-expansion. There have been on-and-off
 debates about how best to add this sort of eta-expansion into GHC, but all
 seem to agree that it's not totally straightforward. For example, see GHC
 bug #7259. There's a non-negligible chance I will be taking a closer look
 into this at some point, but not for a few months, so don't hold your
 breath. I'm not aware of anyone else currently focusing on this problem
 either, I'm afraid.

 I'm glad you're finding use in the singletons package! Let me know if I
 can be of further help.

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

[Haskell-cafe] Pattern matching with singletons

[Paul Brauner]

Hello,

the following programs seems to hit either some limitation of GHC or maybe
I'm just missing something and it behaves the intended way.

{-# LANGUAGE TemplateHaskell, TypeFamilies, DataKinds, GADTs #-}

module Test where

import Data.Singletons

data TA = CA
data TB = CB
data TC = CC (Either TA TB)

$(genSingletons [''TA, ''TB, ''TC])

type family Output (x :: TC) :: *
type instance Output ('CC ('Left  'CA)) = Int
type instance Output ('CC ('Right 'CB)) = String

f :: Sing (a :: TC) - Output a
f (SCC (SLeft SCA)) = 1

g :: Sing (a :: TC) - Output a
g (SCC (SLeft _)) = 1


Function f typechecks as expected. Function g fails to typecheck with the
following error.

Could not deduce (Num (Output ('CC ('Left TA TB n0
  arising from the literal `1'
from the context (a ~ 'CC n, SingRep (Either TA TB) n)
  bound by a pattern with constructor
 SCC :: forall (a_a37R :: TC) (n_a37S :: Either TA TB).
(a_a37R ~ 'CC n_a37S, SingRep (Either TA TB)
n_a37S) =
Sing (Either TA TB) n_a37S - Sing TC a_a37R,
   in an equation for `g'
  at Test.hs:21:4-16
or from (n ~ 'Left TA TB n0,
 SingRep TA n0,
 SingKind TA ('KindParam TA))
  bound by a pattern with constructor
 SLeft :: forall (a0 :: BOX)
 (b0 :: BOX)
 (a1 :: Either a0 b0)
 (n0 :: a0).
  (a1 ~ 'Left a0 b0 n0, SingRep a0 n0,
   SingKind a0 ('KindParam a0)) =
  Sing a0 n0 - Sing (Either a0 b0) a1,
   in an equation for `g'
  at Test.hs:21:9-15
Possible fix:
  add an instance declaration for
  (Num (Output ('CC ('Left TA TB n0
In the expression: 1
In an equation for `g': g (SCC (SLeft _)) = 1


I would expect that a ~ ('CC ('Left 'CA)) in the right hand-side of g (SCC
(SLeft _)) = 1 since SLeft's argument is necessarily of type STA, whose
sole inhabitant is SA.

Now I understand (looking at -ddump-slices, the singletons' library paper
and the error message) that the definition of SCC and SLeft
don't immediately imply what I just wrote above. So my question is: in the
right hand-side of g (SCC (SLeft _)) = 1,

   - is a ~ ('CC ('Left 'CA)) a consequence of the definitions of SCC,
   SLeft, ... (in which case GHC could infer it but for some reason can't)
   - or are these pattern + definitions not sufficient to prove that a
   ~ ('CC ('Left 'CA)) no matter what?

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

[Haskell-cafe] QuickCheck: Why are these instances of Testable?

[Paul Brenman]

Why does QuickCheck (2.6) list the following as instances of class Testable?

Testable Result
Testable Prop
Testable prop = Testable (Gen prop)

The Hughes/Claessen paper QuickCheck: A Lightweight Tool for Random
Testing of Haskell Programs mentions nesting property combinators on page
6, but I didn't understand this reference.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parser left recursion

[Paul Callaghan]

Hi

Another alternative is this Haskell library: https://github.com/paulcc/xsaiga

This is a combinator library which is suitable for mid-scale NLP work,
so handles left recursion and (high amounts of) ambiguity to produce a
packed result (which can be decoded to a list of results if required).
It uses a technique similar to Danielsson's for termination.

The technical details (incl papers) can be found on
http://cs.uwindsor.ca/~hafiz/xsaiga/pub.html, particularly in the IWPT
paper http://cs.uwindsor.ca/~hafiz/pub/iwpt-07.pdf

I'd be interested to see a  GLL impl for Haskell, particularly for
comparison with the above. Did Roman C. publish some code for this a
while back?

Paul

On Wed, Feb 27, 2013 at 9:50 AM, Paul Callaghan paulcc@gmail.com wrote:
 Another alternative is this Haskell library: https://github.com/paulcc/xsaiga

 This is a combinator library which is suitable for mid-scale NLP work,
 so handles left recursion and (high amounts of) ambiguity to produce a
 packed result (which can be decoded to a list of results if required).
 It uses a technique similar to Danielsson's for termination.

 The technical details (incl papers) can be found on
 http://cs.uwindsor.ca/~hafiz/xsaiga/pub.html, particularly in the IWPT
 paper http://cs.uwindsor.ca/~hafiz/pub/iwpt-07.pdf

 I'd be interested to see a  GLL impl for Haskell, particularly for
 comparison with the above. Did Roman C. publish some code for this a
 while back?

 Paul

 On Tue, Feb 26, 2013 at 7:43 PM, Dominique Devriese
 dominique.devri...@cs.kuleuven.be wrote:
 2013/2/26 Martin Drautzburg martin.drautzb...@web.de:
 I wonder if I can enforce the nonNr property somehow, i.e. enforce the rule
 will not consider the same nonterminal again without having consumed any
 input.

 You might be interested in this paper:

   Danielsson, Nils Anders. Total parser combinators. ACM Sigplan
 Notices. Vol. 45. No. 9. ACM, 2010.

 Regards,
 Dominique

 ___
 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: base package -- goals

[Stephen Paul Weber]

Somebody claiming to be Ian Lynagh wrote:

On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:

In any case there is still the problem: What and where is the Prelude...
but maybe let’s postpone this.


I'd put it in its own package for now, and then look at whether/what it
should be merged with later.


Why shouldn't Prelude (and other really stable, standard modules) just live 
in the `haskell2010` package?


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package -- goals

[Stephen Paul Weber]

Somebody claiming to be Roman Cheplyaka wrote:

* Stephen Paul Weber singpol...@singpolyma.net [2013-02-25 11:29:42-0500]

Why shouldn't Prelude (and other really stable, standard modules)
just live in the `haskell2010` package?


Because then we can't make changes to it without producing a new
language standard.


That sounds like a good thing.  Very in line with the goal of making stable 
modules more stable.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package (was: GHC 7.8 release?)

[Stephen Paul Weber]

Somebody claiming to be Roman Cheplyaka wrote:

* Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+]

It's feasible to split base, but to a first approximation what you
end up with is base renamed to ghc-base, and then the new base
contains just stub modules that re-export stuff from ghc-base.


It would be great to have a portable base, without any GHC-specific
stuff in it. After all, modules like Control.Monad or Data.Foldable are
pure Haskell2010.


+1

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base package (Was: GHC 7.8 release?)

[Stephen Paul Weber]

Somebody signing messages as Joachim Breitner wrote:

I have started a wikipage with the list of all modules from base, for a
first round of shuffling, grouping and brainstorming:

http://hackage.haskell.org/trac/ghc/wiki/SplitBase


Looks like a good start!

Here's an idea: why not use the `haskell2010` package as one of the 
groupings?  It seems like this sort of reorganisation could help solve the 
problem we currently have where one cannot using any of the features of 
`base` along with the `haskell2010` modules.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Size of crosscompiled exectuable

[Stephen Paul Weber]

Somebody claiming to be Simon Marlow wrote:

On 25/01/13 13:58, Nathan Hüsken wrote:

A simple hello world application has 1Mb in by 64 bit ubunut machine.
When I stript it, is has about 750kb.
When I build a cross compiler for android (arm), the executable has a
asize of about 10MB, stripped about 5MB.

That is huge, five times the size on my linux sysem.


Not sure what you mean by five times the size on my linux system. 
What is 5 times larger than what?


He's saying that the size of the android executable (made by his cross 
compiler) is five time the sive of the equivalent Ubuntu executable (made 
by, I assume, his system's GHC).


The problem is not the size, but the size ratio.

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

Hey,

For me thinks have changed.
With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!


Do you think it is specifically the 3.2 that made it work?

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

With the current ghc HEAD and llvm version 3.2 I am able to do a
registerised build for android!

Do you think it is specifically the 3.2 that made it work?


Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.


Did you have to hack the source ala 
http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch 
?



Stephen Blackheath found that out, see here:
http://www.haskell.org/pipermail/iphone/2013-January/000212.html


From that post, it seems like llvm-3.0 might also work?

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.

http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch
?


Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs


Oh, man, the fact that I don't have that setting for QNX is probably not 
doing me any favours...


How the heck am I supposed to figure out what that string should be? :(

That said... how did you get an unregisterised build to work with an LLVM 
backend?  Everything I've seen in the code implied that the moment you are 
unregisteried, it uses via-C...  Which is what my above patch is primarily 
about.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.

http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-llvm-hack.patch
?


Not exactly, see the patch here:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html
and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs


Oh, man, the fact that I don't have that setting for QNX is probably 
not doing me any favours...


I tried the following:

diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs 
b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
index 218870a..a583ffc 100644
--- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs
+++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs
@@ -58,6 +58,9 @@ moduleLayout = sdocWithPlatform $ \platform -
 Platform { platformArch = ArchARM {}, platformOS = OSLinux } -
 text target datalayout = 
\e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\
 $+$ text target triple = \arm-unknown-linux-gnueabi\
+Platform { platformArch = ArchARM {}, platformOS = OSQNXNTO } -
+text target datalayout = 
\e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\
+$+$ text target triple = \arm-unknown-nto-qnx8.0.0eabi\
 _ -
 -- FIX: Other targets
 empty

Doing a registered build with llvm-3.0 I eventually get:

inplace/bin/ghc-stage1 -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -static  -H64m -O0 -fllvm-hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0  -XHaskell98 -XCPP -XForeignFunctionInterface  -no-user-package-db -rtsopts  -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf  o -hcsuf hc   utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist-install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist-install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4Uj_info':

ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o):
 In function `c4XO_info':
ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o):
 In function `c2Xe_info':
/tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o):
 In function `c7HG_info':
/tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `base_GHCziIOziHandleziText_zdwccall_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c7s6_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c9cs_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):
 In function `c9nS_info':
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to 
`__aeabi_memcpy'
/tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to 
`__aeabi_memcpy'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec):
 more undefined references to `__aeabi_memcpy' follow
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o):
 In function `c1Uf_info':
/tmp/ghc20805_0/ghc20805_0.bc:(.text+0x5a8): undefined reference to 
`__aeabi_memmove'
/home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote:
(...)


So... it can't find memcpy for some reason?

I'm about to try with llvm-3.2 to see if that's different.



The solution for me was to wrap mkfifo (in a function I called __mkfifo)
and used that one from the ffi instead.


Right, I see things around on the web about people doing similar stuff.


But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?


I'm not sure.  Most curious is that this has not come up before in any of my 
other ARM-build attempts (which produced less-than-working code, but 
suceeded in compiling).


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some required library?


I'm not sure.  Most curious is that this has not come up before in 
any of my other ARM-build attempts (which produced less-than-working 
code, but suceeded in compiling).


This seems to be a general ARM thing: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 
... so not sure why I'm getting it and no one else is.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

Doing a registered build with llvm-3.0 I eventually get:
In function `c58Y_info':
/tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to
`__aeabi_memcpy'
collect2: ld returned 1 exit status
make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1
make: *** [all] Error 2

This is purely linker issue.  Somehow you link with different set of 
libraries probably.  Anyway it looks like: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 
-- this function is part of common ARM EABI so it should be implemented by 
your C compiler tool-chain. You just need to find out where it is and how 
you may use it.


So, not sure on the right solution, but when I add   -lcapsthen the 
linker errors go away and I can build executables.  Unfortunately, when I 
try to run any of them on a device, I get a segfault, just as I always did 
with registerised cross-builds for ARM... this with both llvm-3.0 and 
llvm-3.2


:(

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

:(


Can you run it in gdb and loock what the backtrace looks like?


I can maybe get a core file and load it into gdb.  I may try that soon.

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

Somebody claiming to be Karel Gardas wrote:

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

So, not sure on the right solution, but when I add   -lcapsthen the
linker errors go away and I can build executables.  Unfortunately, when
I try to run any of them on a device, I get a segfault, just as I always
did with registerised cross-builds for ARM... this with both llvm-3.0
and llvm-3.2

:(


Can you run it in gdb and loock what the backtrace looks like?


[New pid 14037182 tid 1]
Program terminated with signal 11, Segmentation fault.
#0  0x08502000 in ?? ()
(gdb) bt
#0  0x08502000 in ?? ()
#1  0x082ce4c4 in ?? ()
#2  0x082ce4c4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

Can you run it in gdb and loock what the backtrace looks like?

Did you compile with -debug?
I remember I got a stack trace with gdb like this (when doing remote
debugging) and got it cleaned up by loading the exectuable with file.
Maybe you have to do something like that to?


$ ntoarm-gdb --core=Main.core Main
... copyright and such ...

[New pid 14336138 tid 1]

warning: .dynamic section for 
/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1 
is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for 
/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1
 is not at the expected address (wrong library or version mismatch?)
Program terminated with signal 11, Segmentation fault.
#0  0x08402000 in ?? ()
(gdb) bt
#0  0x08402000 in ?? ()
#1  0x082de978 in stg_ap_p_fast ()
#2  0x082de978 in stg_ap_p_fast ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Cabal and cross compilation

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

For that I changed cabal so that it recognizes android as a OS.
But cabal seems to get its os information from System.Info.os, and from
what I can tell this always returns the host os and not the target os.


https://github.com/haskell/cabal/issues/1184

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Karel Gardas wrote:
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI 
distro. I used distro provided LLVM 3.0 and configured GHC with:


Please keep in mind that GHC HEAD is completely different beast as 
there is new codegen put on by defaul there and LLVM codegen is not working 
correctly with it yet.


Oh?  If LLVM codegen is broken in HEAD, that would explain why it's not 
working for ARM :)  Hopefully I can get it working soon with at least an 
unregistered build.  I have to build HEAD, since I'm doing cross-compiling.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Ben Gamari wrote:

Stephen Paul Weber singpol...@singpolyma.net writes:

Trying that gives me:

Warning: Couldn't figure out LLVM version!
  Make sure you have installed LLVM
ghc: could not execute: opt-3.0

I'm using LLVM 3.1.


Are you certain the opt-3.0 is in $PATH?


It isn't installed.  I'm using LLVM 3.1, and GHC correctly uses opt-3.1 when 
I try the registered build.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Nathan Hüsken wrote:

Was that an registerised or unregisterised build?
Did anyone succesfully build ghc on an arm system which produces non
crashing executables?


Just finally got a BB10 device set up so I can test my cross-compiler on the 
ARM and I get:


Process 26726597 (Main) terminated SIGSEGV code=2 fltno=11 
ip=08bbf4c0(/accounts/1000/appdata/net.singpolyma.haskades_headlines.testDev_s_headlinesc1f463d0/app/native/Main@MD5Update+0xcc8d7) 
ref=e59d0040
Memory fault (core dumped) 

This seems related.  I'm about to try a configuration with 
--enable-unregisterised to see if that helps.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

Was that an registerised or unregisterised build?
Did anyone succesfully build ghc on an arm system which produces non
crashing executables?


Just finally got a BB10 device set up so I can test my cross-compiler on 
the ARM


I'm about to try a configuration with --enable-unregisterised to see if 
that helps.


make -r --no-print-directory -f ghc.mk phase=final all
inplace/bin/ghc-stage1 -static  -H64m -O0 -fasm-package-name 
integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. 
-ilibraries/integer-simple/dist-install/build 
-ilibraries/integer-simple/dist-install/build/autogen 
-Ilibraries/integer-simple/dist-install/build 
-Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/.
-optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h 
-package ghc-prim-0.3.1.0  -package-name integer-simple -Wall -XHaskell98 -XCPP 
-XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes 
-XNoImplicitPrelude -O -fasm  -no-user-package-db -rtsopts  -odir 
libraries/integer-simple/dist-install/build -hidir 
libraries/integer-simple/dist-install/build -stubdir 
libraries/integer-simple/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c 
libraries/integer-simple/./GHC/Integer/Type.hs -o 
libraries/integer-simple/dist-install/build/GHC/Integer/Type.o

when making flags consistent: Warning:
Compiler unregisterised, so compiling via C
/tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry':

/tmp/ghc25891_0/ghc25891_0.hc:3691:1:
 warning: this decimal constant is unsigned only in ISO C90 [enabled by 
default]

/tmp/ghc25891_0/ghc25891_0.hc:3691:17:
 error: expected ')' before numeric constant
make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] 
Error 1
make: *** [all] Error 2

I think I can configure it to use unregistered LLVM, so I'm off to try that, 
but this seems like a bug.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Stephen Paul Weber wrote:

Somebody claiming to be Nathan Hüsken wrote:

Was that an registerised or unregisterised build?
Did anyone succesfully build ghc on an arm system which produces non
crashing executables?


Just finally got a BB10 device set up so I can test my 
cross-compiler on the ARM


I'm about to try a configuration with --enable-unregisterised to 
see if that helps.


I think I can configure it to use unregistered LLVM, so I'm off to 
try that, but this seems like a bug.


Trying that gives me:

[ 1 of 68] Compiling Distribution.Compat.Exception ( 
libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, 
bootstrapping/Distribution/Compat/Exception.o )
Warning: Couldn't figure out LLVM version!
 Make sure you have installed LLVM
ghc: could not execute: opt-3.0
make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1
make: *** [all] Error 2

I'm using LLVM 3.1.  This errors makes no sense to me, because when I just use quick 
and not unregistered, it falls back to LLVM and works fine, but now I've selected 
quick-llvm and unregistered and it can't find it?

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Stephen Paul Weber]

Somebody claiming to be Simon Peyton-Jones wrote:
I'd like to propose a way to promote newtypes over their enclosing type.  
Here's the writeup

 http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers


The high-level idea, I love.  I always wondered about `map MkAge blah`.


Any comments?  Below is the problem statement, taken from the above page.


-1 to the unsoundness, but as you say, this is an existing problem.

Also, instead of:

newtype wrap somefun :: [Int] - [Age]
foo = somefun [12,14]

Maybe:

foo = ([12, 14] :: newtype wrap [Age])

I don't know how feasible this syntax is, but I like it a lot better, and it 
makes it more clear (to me) that this is purely type-level syntax.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Stephen Paul Weber]

Somebody claiming to be Simon Peyton-Jones wrote:
 *   For x1 we can write map MkAge x1 :: [Age]. But this does not follow 
 the newtype cost model: there will be runtime overhead from executing the 
 map at runtime, and sharing will be lost too. Could GHC optimise the map 
 somehow?


My friend pointed out something interesting:

If GHC can know that MkAge is just id (in terms of code, not in terms of 
type), which seems possible, and if the only interesting case is a Functor, 
which seems possible, then a RULE fmap id = id would solve this.  No?


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

make install failing

[Stephen Paul Weber]

I just did a clean build of my cross-compiling GHC with --prefix set in the 
top-level ./configure call.


When I run `make install` I get:

/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg 
--force --global-package-db 
/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d
 update rts/package.conf.install
/bin/sh: 1: 
/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg:
 not found
make[1]: *** [install_packages] Error 127
make: *** [install] Error 2

Grepping the output for pkg:

$ make install 21 | grep pkg
rm -f /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg  
ln -s i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg

/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg 
--force --global-package-db 
/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d
 update rts/package.conf.install
/bin/sh: 1: 
/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg:
 not found

/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg is a 
symlink to i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 which does not exist 
(and I see no attempt to make it exist), and either way it seems that we are 
installing with a cross-compile prefix, but not invoking with that.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Environment variables in cabal config?

[Stephen Paul Weber]

Is there any way to set the paths in my cabal-install config relative to 
$HOME or similar?  I tried ~ and $HOME and neither of those worked.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: (mips64el) Cross-building GHC

[Stephen Paul Weber]

Somebody signing messages as Joachim Breitner wrote:
Awesome.  I have a MIPS-based netbook (lemote yeelong thing) and got the 
GHC port from Debian on it, but of course it's a just-barely-works build 
:)


What do you mean by barely-just-works? Anything besides:
* no GHCi support and
* bad performance due to the lack of a native code generator
is probably a bug that we (the GHC maintainers in Debian) would like to
know about.


Sorry, I did not mean that to sound so negative.  I'm really glad you guys 
have a build for my esoteric machine at all :)  I was, in fact, referring to 
the lack of GHCi/TH/DPH support, and IIRC it uses the old via-C instead of 
LLVM, but I could be wrong about that.  More eyeballs on porting to the 
architecture would certainly not be a bad thing.


I haven't experience any actual bugs yet in my yeeloong GHC.  Thanks for 
providing it.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: (mips64el) Cross-building GHC

[Stephen Paul Weber]

Somebody claiming to be jug...@lavabit.com wrote:

I would like to port GHC to mips64el. I have never tried
cross-building before. So I will probably post more questions later.


Awesome.  I have a MIPS-based netbook (lemote yeelong thing) and got the GHC 
port from Debian on it, but of course it's a just-barely-works build :)


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

cabal-install use multiple config files?

[Stephen Paul Weber]

I don't see a command-line switch to ask cabal-install to use a different 
config file.  Is there an environment variable for it or something?  I want 
to use the same cabal-install binary with three different installs of ghc 
and ghc-pkg to allow me to maintain my cross-compiler packages as well.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: cabal-install use multiple config files?

[Stephen Paul Weber]

Somebody claiming to be Roman Cheplyaka wrote:

* Stephen Paul Weber singpol...@singpolyma.net [2012-12-09 21:20:34+]

I don't see a command-line switch to ask cabal-install to use a
different config file.


There's a '--config-file' option, see 
https://github.com/haskell/cabal/issues/1113


Sweet!  I've got my environment working using this shell wrapper:

#!/bin/sh

export PATH=$HOME/src/ghc/inplace:$PATH

case $1 in
install)
shift
cabal --config-file=$HOME/.cabal-nto-qnx-i486/config install 
--with-gcc=i486-pc-nto-qnx8.0.0-gcc --configure-option=--target=i486-pc-nto-qnx8.0.0 
--configure-option=--build=i686-linux-gnu --configure-option=--host=i486-pc-nto-qnx8.0.0 
--hsc2hs-option=--cross-safe --hsc2hs-option=--cross-compile $@
;;
*)
cabal --config-file=$HOME/.cabal-nto-qnx-i486/config $@
;;
esac

Can I move any/all of those switches into the config file?  None of them 
really seem to fit in the listed config options.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter

[Stephen Paul Weber]

Somebody claiming to be Erik de Castro Lopo wrote:

This is a good idea, one that I have solved at my end using Procmail.


I was planning to do this soon (as I get deeper into GHC hacking because of 
my port, but don't want the high-email-volume of the comitt and build 
emails).  Procmail is awesome.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Dynamic libraries by default and GHC 7.8

[Stephen Paul Weber]

Somebody signing messages as Joachim Breitner wrote:

Given the current sensitivity of the ABI hashes we really do not want to
have Programs written in Haskell have a runtime dependency on all the
included Haskell libraries. So I believe we should still link Haskell
programs statically in Debian.


This is also a concern I have.


Hence, Debian will continue to provide its libraries built the static
way.


Right.


Building them also in the dynamic way for the sake of GHCi users seems
possible.


Perhaps Debian could just ship a GHCi that uses the RTS linker, as now?  The 
change is to be made for some platforms, we could opt to have Debian not 
be such a platform.


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Dynamic libraries by default and GHC 7.8

[Stephen Paul Weber]

Somebody claiming to be Ian Lynagh wrote:

GHC HEAD now has support for using dynamic libraries by default (and in
particular, using dynamic libraries and the system linker in GHCi) for a
number of platforms.

The various issues are described in a wiki page here:
   http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault


IIRC, one of the problems with dynamic linking in GHC is that when the GHC 
version is different, the ABI can often be different enough to making such 
shared libraries incompatible with each other / binaries made on different 
GHCs.  This makes distribution a potential nightmare (where you have to 
package all the *.so files and send them along with your binary, which is 
essentially the same as static linking, but more pain).  Is this no longer 
the case, or am I completely misremembering this?


Also, you say for a number of platforms and that wiki page says 
Currently, we don't know how to do dynamic-by-default on Windows in 
a satisfactory way.  So I assume Windows is not one of the platforms that 
would be seeing this change?


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Dynamic libraries by default and GHC 7.8

[Stephen Paul Weber]

Somebody claiming to be Ian Lynagh wrote:

On Tue, Nov 27, 2012 at 10:22:12AM -0500, Stephen Paul Weber wrote:

IIRC, one of the problems with dynamic linking in GHC is that when
the GHC version is different, the ABI can often be different enough
to making such shared libraries incompatible with each other /
binaries made on different GHCs.  This makes distribution a
potential nightmare (where you have to package all the *.so files
and send them along with your binary, which is essentially the same
as static linking, but more pain).


That is still the case. However, if you want to distribute binaries then
you will still be able to build with -static if you don't want to have
ot bundle a load of DLLs. It's only the default that will change.


If the default changes, though, that would mean that before distribution 
I would have to re-build all my cabal packages with -static?  And if 
I change my default so that cabal builds with -static GHCI would no longer 
work for me?


--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Building GHC for BB10 (QNX)

[Stephen Paul Weber]

Hey all,

I'm interesting in trying to get an initial port for BlackBerry 10 (QNX) 
going.  It's a POSIXish environment with primary interest in two 
architechtures: x86 (for simulator) and ARMv7 (for devices).


I'm wondering if http://hackage.haskell.org/trac/ghc/wiki/Building/Porting 
is fairly up-to-date or not?  Is there a better place I should be looking?


One big difference (which may turn out to be a problem) is that the 
readily-available QNX compilers (gcc ports) are cross-compilers.  I realise 
that GHC has no good support to act as a cross-compiler yet, and anticipate 
complications arising from trying to build GHC using a cross-compiler for 
bootstrapping (since that implies GHC acting as a cross-compiler at some 
point in the bootstrapping).


Any suggestions would be very welcome.

--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Type-directed functions with data kinds

[Paul Visschers]

Thanks for all the replies. I guess I'll keep using my type class for now.

Paul

On Fri, Oct 26, 2012 at 9:25 AM, Adam Gundry adam.gun...@strath.ac.ukwrote:

 Hi Paul,

 On 25/10/12 16:22, Paul Visschers wrote:
  Hello everyone,
 
  I've been playing around with the data kinds extension to implement
  vectors that have a known length at compile time. Some simple code to
  illustrate:
  [...]
  In this code I have defined a repeat function that works in a similar
  way to the one in the prelude, except that the length of the resulting
  vector is determined by the type of the result. I would have hoped that
  its type would become 'repeat :: a - Vector n a', yet it is 'repeat ::
  VectorRepeat n = a - Vector n a'. As far as I can tell, this class
  constraint should no longer be necessary, as all possible values for 'n'
  are an instance of this class. I actually really just want to define a
  closed type-directed function and would rather not (ab)use the type
  class system at all.
 
  Is there a way to write the repeat function so that it has the type
  'repeat :: a - Vector n a' that I've missed? If not, is this just
  because it isn't implemented or are there conceptual caveats?

 As Iavor, Andres and Pedro have collectively pointed out, the type

 forall a (n :: Nat) . a - Vector n a

 is uninhabited, because there is no way for the function's runtime
 behaviour to depend on the value of `n', and hence produce a vector of
 the correct length.

 Morally, this function requires a dependent product (Pi-type), rather
 than an intersection (forall), so we would like to write something like
 this:

 repeat :: forall a . pi (n :: Nat) . a - Vector n a
 repeat Zero  _ = Nil
 repeat (Succ n)  x = Cons x (repeat n x)

 Notice that Pi-types bind a type variable (like forall) but also allow
 pattern-matching at the term level.

 Your `VectorRepeat' type class and Iavor's `SNat' singleton family are
 both ways of encoding Pi-types, at the cost of duplicated definitions,
 by linking a term-level witness (the dictionary or singleton data
 constructor) with a type-level Nat.

 As you can see, things get a lot neater with proper Pi; unfortunately it
 is not yet implemented in GHC, and it's probably still a way off. I'm
 working on a story about adding Pi to System FC, which hopefully might
 bring it closer. (Shameless plug: for an unprincipled hack that does
 some of this, check out https://github.com/adamgundry/inch/.)

 Cheers,

 Adam

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

[Haskell-cafe] Type-directed functions with data kinds

[Paul Visschers]

Hello everyone,

I've been playing around with the data kinds extension to implement vectors
that have a known length at compile time. Some simple code to illustrate:
 {-# LANGUAGE DataKinds, GADTs, KindSignatures #-}

 import Prelude hiding (repeat)

 data Nat = Zero | Succ Nat
 data Vector (n :: Nat) a where
   Nil :: Vector Zero a
   Cons :: a - Vector n a - Vector (Succ n) a

 class VectorRepeat (n :: Nat) where
   repeat :: a - Vector n a

 instance VectorRepeat Zero where
   repeat _ = Nil

 instance VectorRepeat n = VectorRepeat (Succ n) where
   repeat x = Cons x (repeat x)

In this code I have defined a repeat function that works in a similar way
to the one in the prelude, except that the length of the resulting vector
is determined by the type of the result. I would have hoped that its type
would become 'repeat :: a - Vector n a', yet it is 'repeat :: VectorRepeat
n = a - Vector n a'. As far as I can tell, this class constraint should
no longer be necessary, as all possible values for 'n' are an instance of
this class. I actually really just want to define a closed type-directed
function and would rather not (ab)use the type class system at all.

Is there a way to write the repeat function so that it has the type 'repeat
:: a - Vector n a' that I've missed? If not, is this just because it isn't
implemented or are there conceptual caveats?

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

Re: [Haskell-cafe] Call for discussion: OverloadedLists extension

[Paul Visschers]

Would that also work for vectors that have their length in their type? And
while we are at it, how about overloaded tuples?

Paul

On Mon, Sep 24, 2012 at 7:19 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:

 |  I remember a similar discussion a few years ago. The question of whether
 |  or not overloading list literals a good idea notwithstanding, the
 problem
 |  with this is that fromList for vectors is highly inefficient. So if
 |  something like this gets implemented and if vector/array literals are
 one
 |  of the main motivations then I really hope there will be no lists
 |  involved.

 Would you like to remind us why it is so inefficient?  Can't the vector
 construction be a fold over the list?  Ah... you need to know the *length*
 of the list, don't you?  So that you can allocate a suitably-sized vector.
  Which of course we do for literal lists.

 So what if fromList went
 fromList :: Int - [b] - a b
 where the Int is the length of the list?

 Simon


 ___
 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] ANNOUNCE: grid-1.1

[Paul Visschers]

Looks nice. Does it scale well to millions of elements, and can it handle
3D?

On Thu, Sep 6, 2012 at 12:37 PM, Alfredo Di Napoli 
alfredo.dinap...@gmail.com wrote:

 It seems cool, looking forward to play with it!


 On 6 September 2012 09:42, Amy de Buitléir a...@nualeargais.ie wrote:

 I'm happy to announce a new package called grid:

 http://hackage.haskell.org/package/grid
 https://github.com/mhwombat/grid/wiki (wiki)

 Grid provides tools for working with regular arrangements of tiles, such
 as
 might be used in a board game or self-organising map (SOM). Grid currently
 supports triangular, square, and hexagonal tiles, with various 2D and
 toroidal
 layouts. If you need a tile shape or layout that isn't currently provided,
 please let me know. See Math.Geometry.Grid for an example of how to use
 the
 package. Suggestions for improvement are welcome.


 ___
 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] ANNOUCE: monad-task-0.1.0, GLFW-task-0.1.0 and a tutorial on invert the inversion of control

[Paul Liu]

Graphics program often relies on system frameworks such as GLUT or
GLFW to handle window and user input. But such frameworks often impose
a rigid style of callback programming, or inversion of control. It is
no secret that continuation monad can deal with this issue [1]. It is
also known that concurrency can be naturally expressed as continuation
monads [2], and a hybrid model of event and threads [3] brings the
best of both worlds.

But then I'm a bit surprised to find no single library on HackageDB
that can deal with this issue. Further more, I wanted something that
can escape the IO monad imposed by callbacks (and FFI) and be
flexible. (no, monad-control is not a solution here).

So I wrote a monad-task library to handle both co-operative threads
(or co-routines) and event processing in a TaskT transformer. To
demonstrate its usage, I also uploaded a GLFW-task library that helps
to program task monad with GLFW, which contains a sample application
if you unpack its source.

I documented the rationales behind this work in a (rather length but
runnable literal Haskell) tutorial Invert the Inversion of Control,
and welcome any suggestions and feedbacks.

monad-task:http://hackage.haskell.org/package/monad-task
GLFW-task:http://hackage.haskell.org/package/GLFW-task
tutorial:  http://www.thev.net/PaulLiu/invert-inversion.html

[1]: Quick and dirty reinversion of control, Dan Piponi.
http://blog.sigfpe.com/2011/10/quick-and-dirty-reinversion-of-control.html
[2]: Functional Pearls: A Poor Man's Concurrency Monad, Koen Claessen, 1999
[3]: Combining Events And Threads For Scalable Network Services. Peng
Li and Steve Zdancewic. PLDI, 2007.

-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] why do I need class context in declaring data constructor?

[Paul Liu]

Thanks, Simon! I'll be looking forward to its resolution.

On Fri, Aug 31, 2012 at 4:37 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 Aha.  See http://hackage.haskell.org/trac/ghc/ticket/7205.

 I don't think there's a workaround, I'm afraid

 Simon

 | -Original Message-
 | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-
 | boun...@haskell.org] On Behalf Of Paul Liu
 | Sent: 30 August 2012 20:52
 | To: Haskell Cafe
 | Subject: [Haskell-cafe] why do I need class context in declaring data
 | constructor?
 |
 | I had a toy program that encodes simply typed lambda in types. It used
 | to work fine with GHC prior to 7.2. But now it no longer compiles.
 | Here is a minimal fragment that demonstrates this problem.
 |
 |  {-# LANGUAGE GADTs,
 |  MultiParamTypeClasses,
 |  FlexibleInstances,
 |  FlexibleContexts #-}
 | 
 |  data Abs env t v where
 |Abs :: g (a, env) h v - Abs env (g (a, env) h v) (a - v)
 | 
 |  class Eval g env t v where
 |eval :: env - g env t v - v
 | 
 |  instance Eval g (a, env) h v =
 |   Eval Abs env (g (a, env) h v) (a - v) where
 |eval env (Abs e) = \x - eval (x, env) e
 |
 | The type Abs has 3 parameters: its environment, sub term (encoded in
 | types), and type. The constructor Abs has 1 parameter: its sub term.
 | The code loads fine in GHC 7.0.3.
 |
 | Here is the error reported by GHC 7.2.2 (and later):
 |
 | test.lhs:14:30:
 | Could not deduce (Eval g1 (a1, env) h1 v1)
 |   arising from a use of `eval'
 | from the context (Eval g (a, env) h v)
 |   bound by the instance declaration at test.lhs:(12,12)-(13,49)
 | or from (g (a, env) h v ~ g1 (a1, env) h1 v1,
 |  (a - v) ~ (a1 - v1))
 |   bound by a pattern with constructor
 |  Abs :: forall env (g :: * - * - * - *) a h v.
 | g (a, env) h v - Abs env (g (a, env) h v) (a -
 | v),
 |in an equation for `eval'
 |   at test.lhs:14:15-19
 | Possible fix:
 |   add (Eval g1 (a1, env) h1 v1) to the context of
 | the data constructor `Abs'
 | or the instance declaration
 |   or add an instance declaration for (Eval g1 (a1, env) h1 v1)
 | In the expression: eval (x, env) e
 | In the expression: \ x - eval (x, env) e
 | In an equation for `eval':
 | eval env (Abs e) = \ x - eval (x, env) e
 |
 | However, if I move the class context to the data constructor of
 | definition, then it compiles fine in GHC 7.2.2 (and later):
 |
 |  data Abs env t v where
 |Abs :: Eval g (a, env) h v = g (a, env) h v - Abs env (g (a, env)
 |  h v) (a - v)
 |
 | But this is very troublesome because for every new class instance I want
 | to make Abs of, I have to make a new class context to the data
 | constructor. It totally defeats the purpose of making class instances to
 | extend usage of data types.
 |
 | Did I missed a language extension when moving code from GHC 7.0.3 to GHC
 | 7.2.2? What can I do to fix it for newer GHCs?
 |
 | --
 | Regards,
 | Paul Liu
 |
 | ___
 | Haskell-Cafe mailing list
 | Haskell-Cafe@haskell.org
 | http://www.haskell.org/mailman/listinfo/haskell-cafe

-- 
Regards,
Paul Liu

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

[Haskell-cafe] why do I need class context in declaring data constructor?

[Paul Liu]

I had a toy program that encodes simply typed lambda in types. It used
to work fine with GHC prior to 7.2. But now it no longer compiles.
Here is a minimal fragment that demonstrates this problem.

 {-# LANGUAGE GADTs,
 MultiParamTypeClasses,
 FlexibleInstances,
 FlexibleContexts #-}

 data Abs env t v where
   Abs :: g (a, env) h v - Abs env (g (a, env) h v) (a - v)

 class Eval g env t v where
   eval :: env - g env t v - v

 instance Eval g (a, env) h v =
  Eval Abs env (g (a, env) h v) (a - v) where
   eval env (Abs e) = \x - eval (x, env) e

The type Abs has 3 parameters: its environment, sub term (encoded in
types), and type. The constructor Abs has 1 parameter: its sub term.
The code loads fine in GHC 7.0.3.

Here is the error reported by GHC 7.2.2 (and later):

test.lhs:14:30:
Could not deduce (Eval g1 (a1, env) h1 v1)
  arising from a use of `eval'
from the context (Eval g (a, env) h v)
  bound by the instance declaration at test.lhs:(12,12)-(13,49)
or from (g (a, env) h v ~ g1 (a1, env) h1 v1,
 (a - v) ~ (a1 - v1))
  bound by a pattern with constructor
 Abs :: forall env (g :: * - * - * - *) a h v.
g (a, env) h v - Abs env (g (a, env) h v) (a - v),
   in an equation for `eval'
  at test.lhs:14:15-19
Possible fix:
  add (Eval g1 (a1, env) h1 v1) to the context of
the data constructor `Abs'
or the instance declaration
  or add an instance declaration for (Eval g1 (a1, env) h1 v1)
In the expression: eval (x, env) e
In the expression: \ x - eval (x, env) e
In an equation for `eval':
eval env (Abs e) = \ x - eval (x, env) e

However, if I move the class context to the data constructor of
definition, then it compiles fine in GHC 7.2.2 (and later):

 data Abs env t v where
   Abs :: Eval g (a, env) h v = g (a, env) h v - Abs env (g (a, env) h v) (a 
 - v)

But this is very troublesome because for every new class instance I
want to make Abs of, I have to make a new class context to the data
constructor. It totally defeats the purpose of making class instances
to extend usage of data types.

Did I missed a language extension when moving code from GHC 7.0.3 to
GHC 7.2.2? What can I do to fix it for newer GHCs?

-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] Relational Algebra library: first version on GitHub

[Paul Visschers]

Hey Ertugrul,

You are absolutely right and the first item on my todo list is to add
better examples.

Paul

On Sun, Jul 22, 2012 at 5:24 AM, Ertugrul Söylemez e...@ertes.de wrote:

 Hello there Paul,

 Paul Visschers m...@paulvisschers.net wrote:

  A couple of weeks ago I asked if there was interest in a library that
  implements a type-safe relational algebra. The response was positive,
  so I have spruced up the code I had a bit and created a repository on
  GitHub at:
 
  https://github.com/PaulVisschers/relational-algebra
 
  It is a very rudimentary version. The code is not documented and there
  is only a very basic example database in Test.hs. It might be helpful
  to look at HaskellDB's PrimQuery and PrimExpr, as this library is
  mostly a direct copy from that (but typed). I will add some decent
  examples of expressions and queries shortly.
 
  If you check it out, please comment on it and let me know if you want
  to contribute. Since this is going to be my first release, any
  feedback is welcome.

 Well, the demonstration could be a bit more comprehensive.  I would be
 very interested in seeing queries, especially nontrivial ones with joins
 and such.

 Would you mind writing a more comprehensive demonstration?


 Greets,
 Ertugrul

 --
 Not to be or to be and (not to be or to be and (not to be or to be and
 (not to be or to be and ... that is the list monad.

 ___
 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] Relational Algebra library: first version on GitHub

[Paul Visschers]

Hello,

A couple of weeks ago I asked if there was interest in a library that
implements a type-safe relational algebra. The response was positive, so I
have spruced up the code I had a bit and created a repository on GitHub at:

https://github.com/PaulVisschers/relational-algebra

It is a very rudimentary version. The code is not documented and there is
only a very basic example database in Test.hs. It might be helpful to look
at HaskellDB's PrimQuery and PrimExpr, as this library is mostly a direct
copy from that (but typed). I will add some decent examples of expressions
and queries shortly.

If you check it out, please comment on it and let me know if you want to
contribute. Since this is going to be my first release, any feedback is
welcome.

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

[Haskell-cafe] Interest in typed relational algebra library?

[Paul Visschers]

Hello,

I've been out of the Haskell game for a bit, but now I'm back. A couple of
years ago I made a small library that implements relational algebra with
types so that malformed queries and other operations are caught at compile
time. It is heavily based off of the internals of HaskellDB (see
http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html),
but types so that it can actually be used directly instead of having to use
HaskellDB's query monad. Besides the joy of using relational algebra
directly in your code, this also means that you can make query-optimizing
code in a type-safe way, you can subquery results returned by the database
directly without accessing the database again and you have more options
when converting from relation algebra to SQL or another query language. The
library isn't quite ready for release, but I might want to work on it a bit
and then release it. Is anyone interested in such a library?

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

[Haskell-cafe] Data.Binary hanging when used with socket - feature?

[Paul Brenman]

I'm using the 0.5.1.0 binary package (i.e. Data.Binary/Data.Binary.Get) to
encode/decode a lazy bytestring. Unfortunately, decode/get are hanging,
possibly due to the underlying chunking logic in Data.Binary.Get.

The lazy bytestring is being populated from a socket (via socketTohandle
sock ReadWriteMode . hGetContents). Periodically, encoded data structures
are received from the socket. When the encoded data structure happens to
end exactly on a chunk boundary, and in my specific case the final encoded
item is an Int(64), the Data.Binary.Get.getBytes function wants to force
the next chunk to be read into the lazy bytestring before returning the
decoded item (see comment in file at line 333 that reads forces the next
chunk before this one is returned). Unfortunately, since the socket is not
yet ready to send anything the call to decode/get hangs. The assumption
seems to be that the lazy bytestring isn't populated from a source that can
potentially block.

Is this reading correct?

If so, are there any workarounds?

Appreciate any advice - production code.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] AI - machine learning

[Paul Graphov]

Hi Miro!

I have no useful information for you. Few weeks ago I also checked for
any AI (machine learning first of all) related packages exist and
found nothing satisfactory except for some quite small packages
implementing a single algorithm (like NN-back-propagation). So there
is a lot to do :)

If you are going to do something in this area please let me know, I'll
be glad to collaborate!

p.s. Now I'm taking Machine Learning course at Coursera.org and
looking forward to apply this knowledge with Haskell.

On Tue, May 15, 2012 at 3:02 AM, miro miroslav.kar...@gmail.com wrote:
 Hi All, recently I started to take a look at haskell, especially at AI. I
 can see some email addresses of interested people there but not so much of
 other activity behind. Does it exist some mailing group especially for AI?

 Basically I'm interested in trying some machine learning algorithms. Start
 with reinforcement learning and value-based), and go towards AGI (Artificial
 General Intelligence). Does anybody know about some already existing haskell
 approaches, or is there anybody working on this?

 Cheers,
 m.

 ___
 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] anyone else driven mad by trying to setup a gmp free version of haskell platform?

[Paul Graphov]

I had no problems building gmp-free GHC 7.4.1 for x86 Solaris
(Openindiana to be precise) and Mac OS X. Not as a part of Haskell
Platform, just compiler itself.
To be precise, there was a little problem under Solaris: make failed
complaining about loop in compilation. I removed this check from
Makefile and it finished successfully.

On Tue, May 8, 2012 at 7:07 PM, Anatoly Yakovenko aeyakove...@gmail.com wrote:
 i would really like to be able to ship haskell based linux binaries,
 but the gmp dependency makes it virtually impossible.  so what version
 of host os, host ghc, and haskell-platform sources are known to build
 a working compiler?

 any reason why the dependency on gmp is static?  are the interfaces
 between versions actually different?  or can we build a version fo the
 compiler that loads the library via dlopen on demand?

 Thanks,
 Anatoly

 ___
 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] Darcs home page updated

[Paul R]

Simon It does discuss both camp and darcs. I meant to say the following:
Simon I was happy to be able to use Ian Lynagh's video, which I have always
Simon felt strikes a very good tone - technical, concise, grounded and
Simon energising. I like listening to it. Thanks Ian!

Indeed, the form, duration and pace are all very good in this video.
However, if I understand correctly, your initiative mainly targets
potential newcomers. I am not sure they will understand the connection
here, and they will quickly ask how to display the patches DAG in darcs.
Also, from a communication POV, the title of the video does not match
well with the date of the video ( we are on darcs.net and the video is
why we continue to develop Camp and is from 2008 :] )

I don't dismiss the great work on this camp video itself. It is just
that if some darcs user has time to make a 2012 darcs video (name hit :
darcs vs git), based on the same idea, that would probably be more
suited for darcs website.

regards,


-- 
  Paul

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

Re: [Haskell-cafe] Darcs home page updated

[Paul R]

On Mon, 30 Apr 2012 12:27:57 -0700, Simon Michael si...@joyful.com said:

Simon With 2.8 released, I felt Darcs deserves better presentation. After
Simon surveying other VCS sites I worked on an update to our home page
Simon layout and content over the last few days, with review and input from
Simon #darcs, and it went live last night. It's far from perfect but I hope
Simon it's a good step forward. Thanks for the input, and have at it:

Simon http://darcs.net


Hi, that looks good, thanks. Here are some ideas :

 - The purple color of titles is not very attractive, changing it to
   something more saturated would make it look fresher.

 - the purple color rounded box is not very attractive either :)

 - there is a video right on the first page, good ! Unfortunatly, it is
   not showing darcs but its cousin. Also, the title is why do we
   continue to develop ... [camp], which isn't the most positive
   approach one can expect on a start page

 - the compact tutorial is great, I love it. It deserves more poish. For
   inspiration, one can have a look at this website for example :
 
 http://gembundler.com/

 - underlined links looks a bit 90's. You can add a simple css rule to
   choose an other color and remove the underline (though it is good
   practice to set it on mouseover)

cheers,

-- 
  Paul

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

[Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Paul Graphov]

Hello Cafe!

I am using protocol-buffers and hprotoc packages but they fail to
compile with recent GHC due to trivial errors. Hackage names
Christopher Edward Kuklewicz as their maintainer. I've sent him
patches more than a month ago but neiter they were applied nor I got
any response. It's quite inconvenient to keep patched versions all the
time. Does anybody know if he is still interested in maintaining those
packages? Is it possible to contact him? And what should I do if he is
unreachable?

Thanks!

Links:

http://hackage.haskell.org/package/protocol-buffers
http://hackage.haskell.org/package/hprotoc

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

Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?

[Paul Graphov]

I'm not sure about being a maintainer - I don't even know how those
packages work and have no experience in preparing package for hackage.
But fixes are really trivial - maybe I'll just upload patched versions
if it is possible?

Is it possible to contact StackOverflow user?

On Mon, Apr 23, 2012 at 7:26 PM, Vo Minh Thu not...@gmail.com wrote:
 For what it's worth, I think he is active on stackoverflow.

 Thu

 Le 23 avril 2012 17:13, Johan Tibell johan.tib...@gmail.com a écrit :
 On Mon, Apr 23, 2012 at 7:53 AM, Max Rabkin max.rab...@gmail.com wrote:
 On Mon, Apr 23, 2012 at 15:01, Paul Graphov grap...@gmail.com wrote:
 And what should I do if he is
 unreachable?

 My feeling is that if you are willing to take it on, you should ask
 this list if anybody objects to your taking over the maintainership,
 and if they do not, take it over (on Hackage, this just means
 uploading a new version of the package).

 If Chris is indeed out of the loop we should find a new maintainer.
 Mark and I are also interested in the future of protocol buffers in
 Haskell.

 -- Johan

 ___
 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] Is this a correct explanation of FRP?

[Paul Liu]

On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez e...@ertes.de wrote:
 Paul Liu nine...@gmail.com wrote:

  This isn't switching.  It's selection.  If fullTime decides to be
  productive, then alterTime acts like fullTime.  Otherwise it acts
  like halfTime.  If both inhibit, then alterTime inhibits.  This
  allows for a much more algebraic description of reactive systems.

 AFRP can do this through ArrowChoice. Maybe you can explain the
 concept of inhibition in more detail?

 I fail to grasp why this is making switches obsolete. The idea of
 switch is to completely abandoning the old state. See the broken
 pendulum example.

 Some of this can be done through ArrowChoice.  The difference is
 comparable to why server parts form a monoid in Happstack.  You don't
 have to decide when a server part reaches a request.  You let the server
 part decide itself.  In other words ArrowChoice forces you to deal with
 events in the application itself:

    -- Library code:
    x = x'
    y = y'

    -- Application code:
    proc inp - do
        r - request - ()
        if p r
          then x - inp
          else y - inp

 Signal inhibition allows the component wires themselves to deal with the
 events and you as the higher level programmer to just stick the wires
 together:

    -- Library code:
    x = proc inp - do requireReq - (); x' - inp
    y = y'

    -- Application code:
    x | y

I'm curious as to how this plays out with the usual arrow
compositions. How does x *** y behave when x inhibits? what about z
 x?

This cannot replace switching though, since the structure of your
arrows cannot change dynamically, while with switches it can.

-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] I Need a Better Functional Language!

[Paul R]

Grigory So now I wonder, what are the languages that are functional in
Grigory the sense above? With a reasonable syntax and semantics, thus
Grigory no assembler. I guess Lisp might be of this kind, but I'm not
Grigory sure. In addition, I'm not a fan of parentheses. What else?
Grigory Pure? Mathematica? Maxima?


Indeed you want a *different* programming language. But it won't be
*better*, just different. Indeed, as soon as your program react to the
implementation of its functions, you will be in a land where you lose
a fundamental abstraction, so you won't be able to change implementation
anymore whithout changing callers as well.

I am curious what are interesting use-cases for that ? Symbolic
analysis ? self-compilers ?


-- 
  Paul

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

Re: [Haskell-cafe] Conduits: Is Source a valid instance of Monad?

[Paul Liu]

Thanks! I failed to notice this instance declaration in the document.

But I'm still curious as to whether a Monad instance for Source makes
any sense, since in 4.0 all of Source/Conduit/Sink would share the
same implementation.

Regards,
Paul Liu

On Tue, Apr 3, 2012 at 6:25 PM, yi huang yi.codepla...@gmail.com wrote:
 On Wed, Apr 4, 2012 at 4:48 AM, Paul Liu nine...@gmail.com wrote:

 Is there any follow up on this?

 I was wondering what is the best way to sequence a number of sources
 together. Anybody gave a further thought on this?


 I believe sequence sources together can already be done by `Monoid`
 instance.



 Regards,
 Paul Liu

 On Tue, Dec 27, 2011 at 3:45 PM, Aristid Breitkreuz
 arist...@googlemail.com wrote:
  Hi all,
 
  As you may have noticed, Michael Snoyman has been working on an
  alternative approach to I/O, called conduits. You can find it here:
 
  https://github.com/snoyberg/conduit
 
  When looking at the Source type (explained here:
  http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
  seem to behave like lists, and naturally wondered if I could write a
  Monad instance for them. But first, let's have a brief look at the
  definition of Source:
 
  data SourceResult a = Open a | Closed
 
  data PreparedSource m a = PreparedSource
  { sourcePull :: ResourceT m (SourceResult a)
  , sourceClose :: ResourceT m ()
  }
 
  newtype Source m a = Source { prepareSource :: ResourceT m
  (PreparedSource m a) }
 
  ResourceT deals with resource acquisition and releasing (making sure
  that all resources are released), and provides a an abstraction over
  IORef/STRef. For our purposes here, ResourceT is probably close enough
  to IO.
 
 
  So now the question again is, can we write a Monad instance for this?
  I have been able to write join (concatenate) and return (a source with
  a single non-repeated) element.
 
  https://gist.github.com/1525471
 
  I _think_ it behaves properly like a Monad, but I'm not quite sure,
  and neither was Michael. Greg Weber then suggested bringing the
  question to this forum. What made the question difficult for me is
  that this would be a stateful Monad transformer, so I'm not quite sure
  how to test the Monad laws properly.
 
 
  There's a second part to this question: If Source turns out not to be
  a Monad, is it possibly a ZipList-like Applicative? And either way,
  which is more useful: The list-like or the ziplist-like instances (of
  Applicative/Monad)?
 
 
 
  Thank you,
 
  Aristid
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Regards,
 Paul Liu

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




 --
 http://yi-programmer.com/



-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] Is this a correct explanation of FRP?

[Paul Liu]

On Sun, Apr 1, 2012 at 7:03 PM, Ertugrul Söylemez e...@ertes.de wrote:
 No, Netwire does things very differently.  Note the total absence of
 switching combinators.  Where in traditional FRP and regular AFRP you
 have events and switching in Netwire you have signal inhibition and
 selection.  AFRP is really just changes the theory to establish some
 invariants.  Netwire changes the whole paradigm.  Review alterTime as
 expressed in the Netwire framework:

    alterTime = fullTime | halfTime

 This isn't switching.  It's selection.  If fullTime decides to be
 productive, then alterTime acts like fullTime.  Otherwise it acts like
 halfTime.  If both inhibit, then alterTime inhibits.  This allows for a
 much more algebraic description of reactive systems.

AFRP can do this through ArrowChoice. Maybe you can explain the
concept of inhibition in more detail?

I fail to grasp why this is making switches obsolete. The idea of
switch is to completely abandoning the old state. See the broken
pendulum example.

-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] Conduits: Is Source a valid instance of Monad?

[Paul Liu]

Is there any follow up on this?

I was wondering what is the best way to sequence a number of sources
together. Anybody gave a further thought on this?

Regards,
Paul Liu

On Tue, Dec 27, 2011 at 3:45 PM, Aristid Breitkreuz
arist...@googlemail.com wrote:
 Hi all,

 As you may have noticed, Michael Snoyman has been working on an
 alternative approach to I/O, called conduits. You can find it here:

 https://github.com/snoyberg/conduit

 When looking at the Source type (explained here:
 http://www.yesodweb.com/blog/2011/12/conduits), I noticed that they
 seem to behave like lists, and naturally wondered if I could write a
 Monad instance for them. But first, let's have a brief look at the
 definition of Source:

 data SourceResult a = Open a | Closed

 data PreparedSource m a = PreparedSource
 { sourcePull :: ResourceT m (SourceResult a)
 , sourceClose :: ResourceT m ()
 }

 newtype Source m a = Source { prepareSource :: ResourceT m
 (PreparedSource m a) }

 ResourceT deals with resource acquisition and releasing (making sure
 that all resources are released), and provides a an abstraction over
 IORef/STRef. For our purposes here, ResourceT is probably close enough
 to IO.


 So now the question again is, can we write a Monad instance for this?
 I have been able to write join (concatenate) and return (a source with
 a single non-repeated) element.

 https://gist.github.com/1525471

 I _think_ it behaves properly like a Monad, but I'm not quite sure,
 and neither was Michael. Greg Weber then suggested bringing the
 question to this forum. What made the question difficult for me is
 that this would be a stateful Monad transformer, so I'm not quite sure
 how to test the Monad laws properly.


 There's a second part to this question: If Source turns out not to be
 a Monad, is it possibly a ZipList-like Applicative? And either way,
 which is more useful: The list-like or the ziplist-like instances (of
 Applicative/Monad)?



 Thank you,

 Aristid

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



-- 
Regards,
Paul Liu

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

Re: [Haskell-cafe] New in haskell for old-timers?

[Paul R]

John 0.8.1 is almost due to be put out, it will be the first to be 100%
John haskell 2010 (and haskell 98) compliant and has a lot of other neat
John features over 0.8.0.

That's great ! I can't wait to put it into my toolbox. Haskell compilers
are all pieces of art, bringing beauty to our daily work. Thanks a lot
to everyone involved in them.


-- 
  Paul

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

Re: [Haskell-cafe] Open-source projects for beginning Haskell students?

[Paul R]

Chris * https://github.com/chrisdone/pgsql-simple The PostgreSQL library
Chris that amelie uses, it's a raw tcp/ip socket interface to the server,
Chris fairly trivial and yet interesting (to me) and useful. Needs more
Chris authentication methods, and I have some opportunities for optimizing
Chris some things. Tests and benchmarks for it would be good too, and
Chris probably easy to write.

For some reasons, I like very much this project. Beside being useful, it
has the potential to demonstrate a lot of the haskell power : easy
concurrency, good parsing, nice combinator-based interface.


-- 
  Paul

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

Re: What is a punctuation character?

[Colin Paul Adams]

Iavor report?  My understanding is that the intention is that the
Iavor alphabet is unicode codepoints (sometimes referred to as
Iavor unicode characters).

Unicode characters are not the same as Unicode codepoints. What we want
is Unicode characters.

We don't want to be able to write a Unicode codepoint, as that would
permit writing half of a surrogate pair, which is malformed Unicode.
-- 
Colin Adams
Preston Lancashire
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: [Haskell-cafe] Question about concurrency, threads and GC

[Paul Graphov]

Hi!

Thanks to all who responded! I got a lot of information to read and think about.
For now I decided to use stm-channelize as the simplest approach which
seem to be enough.

On Mon, Mar 5, 2012 at 9:50 PM, Alexander V Vershilov
alexander.vershi...@gmail.com wrote:
 Hello.

 I've also written simple chat server based on conduits and stm channels

 https://github.com/qnikst/chat-server/blob/master/src/Main.hs

 it has quite similar aproach and maybe this solution can be used together
 to have better results.

 --
 Alexander Vershilov

 Sat, Mar 03, 2012 at 02:05:17AM -0500, Joey Adams wrote
 On Fri, Mar 2, 2012 at 7:34 PM, Joey Adams joeyadams3.14...@gmail.com 
 wrote:
  I'll try to put together a simple chat server example, like the one I
  wrote for stm-channelize.

 Here it is:

     https://github.com/joeyadams/haskell-chat-server-example

 See, in particular, the serveLoop function.  When a message is
 received from the client, it is written to the send channel of every
 other client.  When a message is written on the client's own send
 channel, it is transmitted to the client.  The primary thread for the
 client waits until one of the worker threads signals completion, then
 kills both of the worker threads.

 I hope this example gives you some ideas.

 -Joey

 ___
 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: Unable to build GHC-7.4.1 on OpenIndiana

[Paul Graphov]

Thanks for your advice but that didn't help. Also GHC is build
successfully on my Ubuntu box with gnu make-3.81

But solution for my case was quite simple - I've commented out those
lines in ghc.mk that produced the error :) ghc binary-dist was built
successfully and run well on solaris-10 box.

On Wed, Mar 7, 2012 at 9:38 PM, Sergei Trofimovich sly...@inbox.ru wrote:
 On Wed, 7 Mar 2012 17:07:06 +0400
 Paul Graphov grap...@gmail.com wrote:

 Hello GHC-users!

 I'm trying to compile GHC-7.4.1 under OpenIndiana and get the
 following error all the time:

 ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile
 bug?.  Stop.

 I googled a bit and found that this can be a result of touching some
 files during build. But actually no files were touched, I've even
 restarted compilation from scratch to check it.

 Currently I have GHC-7.2.2. that was installed via
 http://pkg.openindiana.org/sfe, GNU Make 3.81

 I'd suggest you to try make-3.82. There were changes
 in laziness of macro expansion (ghc build system uses
 macros quite extensively).


 --

  Sergei

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Unable to build GHC-7.4.1 on OpenIndiana

[Paul Graphov]

Hello GHC-users!

I'm trying to compile GHC-7.4.1 under OpenIndiana and get the
following error all the time:

ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile
bug?.  Stop.

I googled a bit and found that this can be a result of touching some
files during build. But actually no files were touched, I've even
restarted compilation from scratch to check it.

Currently I have GHC-7.2.2. that was installed via
http://pkg.openindiana.org/sfe, GNU Make 3.81

I use quick build flavour in build/build.mk (but it doesn't seem to matter)

Also i've installed these packages to make it build:

pkg install gcc
pkg install system/header
pkg install developer/library/lint
pkg install header-math

Thanks.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Question about concurrency, threads and GC

[Paul Graphov]

Hello Cafe!

I am trying to implement networked application in Haskell. It should accept many
client connections and support bidirectional conversation, that is not
just loop with
Request - Response function but also sending notifications to clients etc.

NB: I came from C++ background and used to explicit asynchonous operations
and pools of OS threads. (Boost.Asio + Boost.Thread)

There seem to be lots of goodies around (green threads, STM). The
problem is that
I cannot figure out how to design such applications. First of all now
I have to start
some threads for each client. Client state and behaviour may change depending on
data that comes from it or other clients. So it seems that I have to
start at least three
threads: one that reads data from socket, one that sends queued messages to
the socket and one that represents clients main behaviour loop. The
last one will
supposedly read from some STM sources, one of them being TChan/TMVar filled
by thread that reads socket. Here I get stuck: how to manage that threads?

I tried to search STM examples at hackage and the most interesting
packages were:

1) combinatorrent - quite complex application, but it seem to be
highly Erlang-inspired,
so I am not sure that it is the simplest way of doing thing.

2) network-connection package - it is a library that wraps socket and
uses STM internally
but exposes almost the same interface with blocking operations. Thread
management is
quite explicit there. But this package is marked obsolete.

I wondered if one can rely upon garbage collector to reap dead threads
when using STM?
Or is it too error prone (accidental references to STM object that
prevent it from being
collected) and unpredictable?

I have read this post:
http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/

It shows that relying upon handling BlockedIndefinitelyOn* exceptions
is a bad idea but
is it OK just to rely upon that blocked forever thread will die and
not to kill it explicitly?

And also if it is really reliable, what are exact rules when some
object goes out of scope
and becomes collectable? For example in blog post mentioned above in
main1 example
lock variable is accessible until the end of do-block, i.e. if I add
takeMVar lock line to
its end, it will compile. But it is not used actually. Is it
guaranteed that explicit performGC
will reap it?

Possibly the best answer would be just pointing me to some recent
examples of concurrent
network applications.

Thanks!

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

Re: [Haskell-cafe] Finally, a pure iteratee library that deals with errors

[Paul R]

Nice, thank you. I was wondering recently what was the current state of
Gabriel's pipes and Paolo's guarded variant. IIRC, they were working on
a converging branch with good support at resources early termination.

On Sun, 26 Feb 2012 10:50:22 +, Daniel Waterworth da.waterwo...@gmail.com 
said:

Daniel Hi all,
Daniel There's seems to be a growing trend amongst the Haskell community for
Daniel writing replacements of enumerator. It's shortcomings are well
Daniel documented, but the solution is, IMO, undecided. This is my attempt:

Daniel https://gist.github.com/1915841

Daniel I have largely copied pipes' concept. The major difference is that
Daniel pipes are now able to push, pull, complete or throw an error. Errors
Daniel are propagated up and down a pipeline, triggering all of the error
Daniel handlers. The library is in a fairly unrefined state, but the core
Daniel functionality is there.

Daniel I look forward to your feedback,

Daniel Daniel

-- 
  Paul

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

[Haskell-cafe] Data.Array.Accelerate initialization timings

[Paul Sujkov]

Hi everyone,

since accelerate mail list seems to be defunct, I'm trying to ask specific
questions here. The problem is: array initialization in
Data.Array.Accelerate takes a 10x amount of time in contrast to both
Data.Array and bare C++ CUDA array initialization. This can be due to
Data.Array.Accelerate having two backends (however, it's own tests show
that my nVidia card is CUDA-capable), but I'm not aware of how can I
profile GPU to check whether it is used or not. Anyway, here's code:

http://hpaste.org/64036

both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of
time to initialize array. I'd say the problem is in GPU memory copying
time, but here's bare C++ code:

http://hpaste.org/64037

which does exactly the same, but 10 times faster. I'm wandering what am I
doing wrong and how to check if I really am. Thanks in advance if anyone
can point me on my mistakes!

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

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings

[Paul Sujkov]

Hi Alex,

I've seen that method, but I don't see how can I use it for initialization
purposes. It creates Acc (Array e i) from Array e i, but what should I do
while I don't have Array yet? And when Array is already initialized, 'use'
will transfer it to GPU memory which will add some extra timings, but won't
optimize what I have at the moment.

However, I'll try to use it somehow. Maybe I misunderstand the mechanics.
Thanks a lot!

On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote:

 Hi Paul,

 even though I just started reading about Accelerate, it seems to me that
 you didn't use the use method which according to [1] initiates
 asynchronous data transfer from host to GPU.


 Cheers,
 Alex

 [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf
 On 20/02/12 14:46, Paul Sujkov wrote:
  Hi everyone,
 
  since accelerate mail list seems to be defunct, I'm trying to ask
  specific questions here. The problem is: array initialization in
  Data.Array.Accelerate takes a 10x amount of time in contrast to both
  Data.Array and bare C++ CUDA array initialization. This can be due to
  Data.Array.Accelerate having two backends (however, it's own tests show
  that my nVidia card is CUDA-capable), but I'm not aware of how can I
  profile GPU to check whether it is used or not. Anyway, here's code:
 
  http://hpaste.org/64036
 
  both generateArray (DIM3) and generateArray1 (DIM1) take the same amount
  of time to initialize array. I'd say the problem is in GPU memory
  copying time, but here's bare C++ code:
 
  http://hpaste.org/64037
 
  which does exactly the same, but 10 times faster. I'm wandering what am
  I doing wrong and how to check if I really am. Thanks in advance if
  anyone can point me on my mistakes!
 
  --
  Regards, Paul Sujkov
 
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe




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

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings

[Paul Sujkov]

Yep. It doesn't help:

generateArray1 n = Acc.use $ Acc.fromList (Acc.Z Acc.:. n*n*n) [0..n*n*n]

still takes the same amount of time. I guess something's wrong elsewhere.

On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote:

 Hi Paul,

 even though I just started reading about Accelerate, it seems to me that
 you didn't use the use method which according to [1] initiates
 asynchronous data transfer from host to GPU.


 Cheers,
 Alex

 [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf
 On 20/02/12 14:46, Paul Sujkov wrote:
  Hi everyone,
 
  since accelerate mail list seems to be defunct, I'm trying to ask
  specific questions here. The problem is: array initialization in
  Data.Array.Accelerate takes a 10x amount of time in contrast to both
  Data.Array and bare C++ CUDA array initialization. This can be due to
  Data.Array.Accelerate having two backends (however, it's own tests show
  that my nVidia card is CUDA-capable), but I'm not aware of how can I
  profile GPU to check whether it is used or not. Anyway, here's code:
 
  http://hpaste.org/64036
 
  both generateArray (DIM3) and generateArray1 (DIM1) take the same amount
  of time to initialize array. I'd say the problem is in GPU memory
  copying time, but here's bare C++ code:
 
  http://hpaste.org/64037
 
  which does exactly the same, but 10 times faster. I'm wandering what am
  I doing wrong and how to check if I really am. Thanks in advance if
  anyone can point me on my mistakes!
 
  --
  Regards, Paul Sujkov
 
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe




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

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings

[Paul Sujkov]

Ah, it seems that I see now what's going wrong way. I'm not using the 'run'
function from the CUDA backend, and so by default I guess the code is
interpreted (the test backend used for semantics check). However, it's not
perfectly clear how to use CUDA backend explicitly.

If you have any suggestions, it would be a great help!

On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote:

 Hi Paul,

 even though I just started reading about Accelerate, it seems to me that
 you didn't use the use method which according to [1] initiates
 asynchronous data transfer from host to GPU.


 Cheers,
 Alex

 [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf
 On 20/02/12 14:46, Paul Sujkov wrote:
  Hi everyone,
 
  since accelerate mail list seems to be defunct, I'm trying to ask
  specific questions here. The problem is: array initialization in
  Data.Array.Accelerate takes a 10x amount of time in contrast to both
  Data.Array and bare C++ CUDA array initialization. This can be due to
  Data.Array.Accelerate having two backends (however, it's own tests show
  that my nVidia card is CUDA-capable), but I'm not aware of how can I
  profile GPU to check whether it is used or not. Anyway, here's code:
 
  http://hpaste.org/64036
 
  both generateArray (DIM3) and generateArray1 (DIM1) take the same amount
  of time to initialize array. I'd say the problem is in GPU memory
  copying time, but here's bare C++ code:
 
  http://hpaste.org/64037
 
  which does exactly the same, but 10 times faster. I'm wandering what am
  I doing wrong and how to check if I really am. Thanks in advance if
  anyone can point me on my mistakes!
 
  --
  Regards, Paul Sujkov
 
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe




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

[Haskell-cafe] Optimizations and parallel execution in the IO for a small spellchecker

[Paul Sujkov]

Hi everyone,

http://hpaste.org/63732

that's a very simple spellchecker application: it consumes standard Linux
dictionary, reads a file, and prints out words from that file that are not
on the dictionary. I have taken it from a little cross-language benchmark
and used to benchmark existing hash table implementations available on
Hackage (with one used in code being the best according to timings). The
question is: can I go further and effectively execute lookup and (maybe)
output (line 20 or line 26 in the snippet) in parallel?

I'm not good at all with Haskell parallel packages; I've tried
monad-parallel (naive implementation eats away all the memory available)
and parallel (haven't tried Par monad yet), but the last dosn't seem to fit
well with the IO operations. If anyone can give me any suggestions on how
can I implement parallel execution, or any thoughts on further sequential
optimizations, it would be deeply appreciated.

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

[Haskell-cafe] [Haskell-Cafe] Optimizations and parallel execution in the IO for a small spellchecker

[Paul Sujkov]

Sorry, I've forgotten to add a [Haskell-Cafe] tag for the message.

On 15 February 2012 19:33, Paul Sujkov psuj...@gmail.com wrote:

 Hi everyone,

 http://hpaste.org/63732

 that's a very simple spellchecker application: it consumes standard Linux
 dictionary, reads a file, and prints out words from that file that are not
 on the dictionary. I have taken it from a little cross-language benchmark
 and used to benchmark existing hash table implementations available on
 Hackage (with one used in code being the best according to timings). The
 question is: can I go further and effectively execute lookup and (maybe)
 output (line 20 or line 26 in the snippet) in parallel?

 I'm not good at all with Haskell parallel packages; I've tried
 monad-parallel (naive implementation eats away all the memory available)
 and parallel (haven't tried Par monad yet), but the last dosn't seem to fit
 well with the IO operations. If anyone can give me any suggestions on how
 can I implement parallel execution, or any thoughts on further sequential
 optimizations, it would be deeply appreciated.

 --
 Regards, Paul Sujkov




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