Re: [Haskell-cafe] "plugins" fails on a simple example

[Jeremy Shaw]

this should be fixed in plugins 1.5.4.0 which is now on hackage.

Thanks!
- jeremy

On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák  wrote:
> Hi,
>
> I'm playing with “plugins”, trying to evaluate a simple expression:
>
> import Control.Monad
> import System.Eval.Haskell
>
> main = do
> let fExpr = "1 + 2 :: Int"
> r <- eval_ fExpr ["Prelude"] [] [] []
> :: IO (Either [String] (Maybe Int))
> case r of
> Right (Just f)  -> do
> print $ f
> Left err -> putStrLn $ "Error: " ++ unlines err
> _ -> putStrLn $ "Unknown error."
>
> However, it fails with
>
> Error:
> on the commandline: Warning:
> -fglasgow-exts is deprecated: Use individual extensions instead
>
> Am I doing something wrong? How can I turn off the flag?
>
> I'm using GHC 7.6.3.
>
> Thanks,
> Petr
>
>
> ___
> 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] "plugins" fails on a simple example

[Jeremy Shaw]

Probably just what it says -- plugins is calling ghc and passing the
-fglasgow-exts flag. I would try just removing that flag.

- jeremy


On Tue, Sep 17, 2013 at 2:08 AM, Petr Pudlák  wrote:

>  Any ideas what could be causing the problem? I could try creating a
> patch, but I have no clue where to start.
>
>   Best regards,
>   Petr
>
> Dne 09/16/2013 11:12 PM, Jeremy Shaw napsal(a):
>
> plugins probably needs to be patched[1]. I'll happily apply such a patch.
>
>  - jeremy
> [1] or rewritten from the ground up
>
>
>  On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák  wrote:
>
>>  Hi,
>>
>> I'm playing with “plugins”, trying to evaluate a simple expression:
>>
>> import Control.Monadimport System.Eval.Haskell
>> main = do
>> let fExpr = "1 + 2 :: Int"
>> r <- eval_ fExpr ["Prelude"] [] [] []
>> :: IO (Either [String] (Maybe Int))
>> case r of
>> Right (Just f)  -> do
>> print $ f
>> Left err -> putStrLn $ "Error: " ++ unlines err
>> _ -> putStrLn $ "Unknown error."
>>
>> However, it fails with
>>
>> Error:
>> on the commandline: Warning:
>> -fglasgow-exts is deprecated: Use individual extensions instead
>>
>> Am I doing something wrong? How can I turn off the flag?
>>
>> I'm using GHC 7.6.3.
>>
>> Thanks,
>> Petr
>>
>> ___
>> 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] "plugins" fails on a simple example

[Jeremy Shaw]

plugins probably needs to be patched[1]. I'll happily apply such a patch.

- jeremy
[1] or rewritten from the ground up


On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák  wrote:

>  Hi,
>
> I'm playing with “plugins”, trying to evaluate a simple expression:
>
> import Control.Monadimport System.Eval.Haskell
> main = do
> let fExpr = "1 + 2 :: Int"
> r <- eval_ fExpr ["Prelude"] [] [] []
> :: IO (Either [String] (Maybe Int))
> case r of
> Right (Just f)  -> do
> print $ f
> Left err -> putStrLn $ "Error: " ++ unlines err
> _ -> putStrLn $ "Unknown error."
>
> However, it fails with
>
> Error:
> on the commandline: Warning:
> -fglasgow-exts is deprecated: Use individual extensions instead
>
> Am I doing something wrong? How can I turn off the flag?
>
> I'm using GHC 7.6.3.
>
> Thanks,
> Petr
>
> ___
> 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: Ajhc Haskell Compiler 0.8.0.7 Release

[Jeremy Shaw]

Any plans on supporting the popular Raspberry Pi platform? I poked at the
source code a bit, but I didn't even know where to begin.

- jeremy


On Fri, Jul 5, 2013 at 11:01 PM, Kiwamu Okabe  wrote:

> We are happy to announce Ajhc 0.8.0.7.
> You can program interrupt handler with Haskell language on this release.
> But not yet collect (big) patch sets, the changes will be merged to jhc.
>
> You can get Ajhc using "cabal install ajhc" command.
> The usage is found at Ajhc's project web site http://ajhc.metasepi.org/.
> The source code at https://github.com/ajhc/ajhc/tags.
>
> Welcome sending any bugs or your ideas to
> https://github.com/ajhc/ajhc/issues.
>
> ## An example of interrupt handler written with Haskell
>
> 
>
> The demo for Cortex-M4 has main context and intrrupt context.
> The main context waits time expire with polling counter.
> <
> https://github.com/ajhc/demo-cortex-m3/blob/master/stm32f3-discovery/hs_src/Intr.hs#L17
> >
>
> The interrupt context is called from clock exception, and decrement
> counter.
> <
> https://github.com/ajhc/demo-cortex-m3/blob/master/stm32f3-discovery/hs_src/Intr.hs#L9
> >
>
> ## Other changes
>
> * Guard StablePtr critical section.
> * Add _JHC_JGC_SAVING_MALLOC_HEAP option for getting smaller malloc heap.
> * Link forkIO to forkOS.
>
> Enjoy! :)
> - - -
> Metasepi team
>
> ___
> 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] Open Source project suitable for 2-3 persons this fall?

[Jeremy Shaw]

I'm still interested in getting the scoutess project pushed the last 10% of
the way to being useable:

http://hub.darcs.net/alp/scoutess

http://alpmestan.wordpress.com/2012/03/21/scoutess-continuous-integration-cabal-and-the-google-summer-of-code/

http://projectscoutess.blogspot.com/

The code does mostly work -- but it doesn't quite actually do anything
useful yet :-/

A next good step would be to get the haddock doc building working. cabal
now has sandboxes, and someone recently released a tool to make it easier
to do standalone building of haddock documentation.

One nice that about the scoutess project is that it is designed to be
extensible through a lot of small modules. So that makes it easy to bite
off a small portion to work on rather than trying to dive into some huge
complex beast.

- jeremy


On Thu, Jul 4, 2013 at 10:26 AM, Anders Bech Mellson  wrote:

> Is there any project that needs working this fall which could be used as a
> university project?
>
> I am in the university (M.Sc. in software development),
> so I am mainly looking for project ideas (preferably concrete ones).
>
> We are 2-3 students that have ~10 hours pr week for 3 months to work on a
> project.
>
> Is there a listing somewhere with project ideas for contributing to the
> Haskell community?
>
> Thanks in advance,
> Anders
>
> ___
> 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] Automating Hackage accounts

[Jeremy Shaw]

No idea, But if not, it should be trivial to add support. The two main
issues would be getting an SSL certificate (if one does not already exist)
and then making sure that the links do not hardcode the schema. So //
hackage.haskell.org/foo instead of http://hackage.haskell.org/.

Then the site can be served using simpleHTTPS instead of simpleHTTP.

- jeremy


On Thu, Jun 13, 2013 at 9:48 AM, Niklas Hambüchen  wrote:

> > As for the user account creation and uploading packages you don't own,
> > Hackage 2 (any day now) has fixes for both.
>
> Does Hackage 2 have SSL at least for the web interface?
>
> ___
> 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: standalone-haddock-1.0

[Jeremy Shaw]

Awesome! I have been wanting to use scoutess to automatically build
and upload haddock docs, but getting it to build the docs in an
uploadable fashion was so painful! I had crazy code that was rewriting
the package database and stuff.

This seems like exactly what I need!

- jeremy

On Fri, Jun 7, 2013 at 7:15 AM, Roman Cheplyaka  wrote:
> I am happy to announce the first release of standalone-haddock.
>
>   http://feuerbach.github.io/standalone-haddock/
>
> standalone-haddock generates standalone haddock Haskell documentation.
>
> When you simply run `cabal haddock`, the resulting HTML documentation contains
> hyperlinks to other packages on your system. As a result, you cannot publish 
> it
> on the internet (well, you can, but the links will be broken).
>
> standalone-haddock takes several packages for which you want to publish
> documentation. It generates documentation for them with proper links:
>
> * links to identifiers inside this package set are relative
> * links to identifiers from external packages lead to hackage
>
> Thus the resulting directory with HTML is relocatable and publishable.
>
> **TL;DR**: it just works. See the [haskell-suite][] documentation for an 
> example
> output.
>
> [haskell-suite]: http://haskell-suite.github.io/docs
>
> Usage
> -
>
> Usage: standalone-haddock [--package-db DB-PATH] -o OUTPUT-PATH 
> [PACKAGE-PATH]
>
> Available options:
>   -h,--helpShow this help text
>   --package-db DB-PATH Additional package database
>   -o OUTPUT-PATH   Directory where html files will be placed
>
> `PACKAGE-PATH` is the path to the (unpacked) package — i.e. a directory with a
> `.cabal` file.
>
> For example:
>
> standalone-haddock -o doc haskell-names haskell-packages haskell-src-exts 
> hse-cpp cabal/Cabal
>
> **NOTE**: dependencies of every package need to be already installed in the
> system with documentation (even those dependencies that themselves belong to 
> the
> current package set). If they are installed in a non-standard package database
> (e.g. if you use sandboxes), use the `--package-db` option.
>
> Cabal dependency
> 
>
> The program only builds with (unreleased) Cabal 1.17 which you can get from
> [github](https://github.com/haskell/cabal).
>
> I spent some time trying to make it compatible with Cabal 1.16 (see
> [Cabal-1.16][] branch), but the API seems to have changed too much.
>
> If you seriously care about this, feel free to send a patch, but it's really
> easier just to install Cabal HEAD.
>
> [Cabal-1.16]: https://github.com/feuerbach/standalone-haddock/tree/Cabal-1.16
>
> Roman
>
> ___
> 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] Why isn't hsc2hs functionality provided by ghc?

[Jeremy Shaw]

While hsc2hs is a popular FFI preprocessor, it is not the only one.
There is also greencard and a few others.

While hsc2hs can usually get the job done -- it's not clear that it is
really the best choice. I think the Haskell FFI got to the point that
it was 'just good enough' and then people lost interest in doing
anything more. Let's face it -- working on the FFI is just not that
exciting :)

So, basically, we are stuck with stuff that is 'good enough' but no so
great that we want to make it official.

We can bind to C fairly easily, but for C++, Python, Ruby, Javascript,
Java, etc, we have never really made much headway.

I think the efforts to make cabal-ghci work nicely could really be the
best solution for now. That is more extensible, and makes it easy to
solve the problem you actually care about (being able to easily
load/compile .hs files) with out giving priority to any particular FFI
system.

- jeremy

On Tue, Jun 4, 2013 at 9:02 PM, silly  wrote:
> I was wondering today, why hasn't hsc2hs been merged with ghc so that
> it would be possible to add a
>
> {-# LANGUAGE ForeignFunctionInterface #-}
>
> at the top of a source file and then load it with ghci or compile it,
> without the intermediate step of calling hsc2hs? This would be exactly
> like the CPP extension. I don't have to call cpp manually. All I have
> to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
> the rest. This would also mean that there would be no need to have a
> separate file extension. Surely I must not be the first person to have
> that thought, so there must be a good reason why this hasn't happen
> yet, but what is it?
>
> ___
> 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] voting sytem DSL

[Jeremy Shaw]

Hello,

The closest thing I know of is, https://github.com/whatgoodisaroad/surveyor

- jeremy


On Wed, Jun 5, 2013 at 4:22 PM, Corentin Dupont
 wrote:
> Hi haskellers!
> I am trying to make a DSL able to describe a voting system. That DSL should
> be able to describe many different voting procedures:
> unanimity or majority, open or secret ballot, one or two turns... It should
> also work for referendums (yes/no question) or elections (electing one or
> several people)...
> Are you aware of any such DSL? In Haskell I haven't see it, maybe in another
> language?
>
> Cheers,
> Corentin
>
> ___
> 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] DSL to English and back for game rule set?

[Jeremy Shaw]

This sounds like something you might use Grammatical Framework for,

http://www.grammaticalframework.org/doc/tutorial/gf-tutorial.html

- jeremy

On Sun, May 19, 2013 at 3:27 PM, Matthew O'Connor
 wrote:
> Hello all,
>
> I recognize this isn't directly a Haskell-related question, but as I'd like
> to solve this problem in Haskell & figured it's applicable. Let me know if
> there's a better place to ask.
>
> I am interested in creating a DSL (or set of types) for describing rules for
> a computer game. I'd like the language to be able to be written out to
> readable and clear English. I'd also like to be able to recreate the
> representation by reading the English back in. The idea is that the DSL will
> be unambiguous in either English or its internal representation. My thinking
> is that this will avoid inconsistencies between the game rules and the text
> describing those rules to the players.
>
> I want the ruleset to be able to describe type of heroes and monsters, their
> abilities, the effects of their attacks, how they use resources, etc.
>
> I realize this may not be an efficient way to go about writing a game, but
> it seems like an interesting project. Some of my concerns are at what level
> the DSL should be written to allow for extensions for new heroes, monsters,
> etc. without having to just add very specific extensions every time a new
> hero or item is created.
>
> Does anyone have thoughts on how to proceed on this, previous work, and/or
> ways to investigate it?
>
> Thanks,
> Matthew
>
> ___
> 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] Hackage checking maintainership of packages

[Jeremy Shaw]

Yes -- being maintained, and have a lot of commit activity are not the
same thing. There are many simple libraries which do not require much
ongoing develop. They are designed to do something of limited scope,
and they only need to be updated when something breaks.

I have thought that a more interesting metric might be to send the
maintainer an email when their package stops building automatically on
hackage. Then assign some weight based on whether or not they fix
things, and how often.

- jeremy

On Sun, May 5, 2013 at 10:34 PM, Niklas Hambüchen  wrote:
> I don't think that activity in the repo has too much to do with
> something being maintained.
>
> Maintainance is a thing humans commit to, so the question of whether
> something is maintained should be a question to a human.
>
> I often push a quick build failure fix for my packages, some of which I
> would still in not want to call "maintained".
>
> On Mon 06 May 2013 10:57:49 SGT, Clark Gaebel wrote:
>> If there's a github link in the package url, it could check the last
>> update to the default branch. If it's more than 6 months ago, an email
>> to the maintainer of "is this package maintained?" can be sent. If
>> there's no reply in 3 months, the package is marked as unmaintained.
>> If the email is ever responded to or a new version is uploaded, the
>> package can be un-marked.
>>   - Clark
>> On Sunday, May 5, 2013, Lyndon Maydwell wrote:
>>
>> I've got it!
>>
>> The answer was staring us in the face all along... We can just
>> introduce backwards-compatibility breaking changes into GHC-head
>> and see if the project fails to compile for x-time! That way we're
>> SURE it's unmaintained.
>>
>> I'll stop sending emails now.
>>
>>
>> On Mon, May 6, 2013 at 10:44 AM, Clark Gaebel
>>  wrote:
>>
>> If there's a github link in the package url, it could check
>> the last update to the default branch. If it's more than 6
>> months ago, an email to the maintainer of "is this package
>> maintained?" can be sent. If there's no reply in 3 months, the
>> package is marked as unmaintained. If the email is ever
>> responded to or a new version is uploaded, the package can be
>> un-marked.
>>
>>   - Clark
>>
>>
>> On Sunday, May 5, 2013, Lyndon Maydwell wrote:
>>
>> But what if the package is already perfect?
>>
>> Jokes aside, I think that activity alone wouldn't be a
>> good indicator.
>>
>>
>> On Mon, May 6, 2013 at 9:59 AM, Conrad Parker
>>  wrote:
>>
>> On 6 May 2013 09:42, Felipe Almeida Lessa
>>  wrote:
>> > Just checking the repo wouldn't work.  It may still
>> have some activity
>> > but not be maintained and vice-versa.
>>
>> ok, how about this: if the maintainer feels that their
>> repo and
>> maintenance activities are non-injective they can
>> additionally provide
>> an http-accessible URL for the maintenance activity.
>> Hackage can then
>> do an HTTP HEAD request on that URL and use the
>> Last-Modified response
>> header as an indication of the last time of
>> maintenance activity. I'm
>> being a bit tongue-in-cheek, but actually this would
>> allow you to
>> point hackage to a blog as evidence of maintenance
>> activity.
>>
>> I like the idea of just pinging the code repo.
>>
>> Conrad.
>>
>> > On Sun, May 5, 2013 at 2:19 PM, Doug Burke
>>  wrote:
>> >>
>> >> On May 5, 2013 7:25 AM, "Petr Pudlák"
>>  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> on another thread there was a suggestion which
>> perhaps went unnoticed by
>> >>> most:
>> >>>
>>  -- Forwarded message --
>>  From: Niklas Hambüchen 
>>  Date: 2013/5/4
>>  ...
>>  I would even be happy with newhackage sending
>> every package maintainer a
>>  quarterly question "Would you still call your
>> project X 'maintained'?"
>>  for each package they maintain; Hackage could
>> really give us better
>>  indications concerning this.
>> >>>
>> >>>
>> >>> This sounds to me like a very good idea. It could
>> be as simple as "If you
>> >>> consider yourself to be the maintainer of package
>> X please just hit reply

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Jeremy Shaw]

Have you considered installing on older version of GHC? Such as GHC
6.10.4 or GHC 6.8.3?

http://www.haskell.org/ghc/download_ghc_6_10_4
http://www.haskell.org/ghc/download_ghc_683

They won't have all the latest extensions.. but they still have more
features than any other alternative.

Also, once you have a version installed, you can, with enough
patience, upgrade to the latest version if you really need some
feature.

- jeremy

On Sat, Apr 27, 2013 at 12:21 AM, Christopher Howard
 wrote:
> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
>
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.
>
> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.
>
> --
> frigidcode.com
>
>
> ___
> 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] Web servers: Running them multiple times in a ghci session

[Jeremy Shaw]

The problem is that ^C only kills the main thread, but does not kill
any child threads that have been spawned.

In happstack the Conf has an optional field where you can supply a
ThreadGroup. When threads are forked they will be registered with the
ThreadGroup, and when you ^C, all those threads can be killed. That
obviously has overhead, so by default we do not use it. But for
development in GHCi it can be a huge time saver.

http://hackage.haskell.org/packages/archive/happstack-server/7.1.7/doc/html/Happstack-Server-Internal-Types.html#t:Conf

Perhaps you can do something similar..

- jeremy

On Thu, Apr 11, 2013 at 12:03 AM, Niklas Hambüchen  wrote:
> I'm writing a web server app, which I run in ghci:
>
> :main localhost 8000
>
> Unfortunately, after Ctrl-C and :reload, running it again:
>
> ** Exception: bind: resource busy (Address already in use)
>
> This is pretty annoying, because quitting-and-restarting takes a lot of
> time since I have many dependencies.
>
> How do you deal with this? Can you propose some working code that can be
> wrapped around my main function to make it work?
>
> My first idea is running main in a separate process.
>
> If you have a working idea, please also post it as an answer on
> http://stackoverflow.com/questions/15890912/how-do-i-terminate-a-socket-server-in-ghci
>
> Thanks
>
> ___
> 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] [Haskell] ANN: adobe-swatch-exchange-0.1.0.0

[Jeremy Shaw]

On Thu, Apr 4, 2013 at 1:46 PM, Brent Yorgey  wrote:
> (Redirecting follow-up to haskell-cafe)
>
> Very cool!  I have been hoping someone will find a way to integrate
> kuler.adobe.com with diagrams, and this will help a lot. =)
>
>   https://github.com/diagrams/diagrams-lib/issues/77

Nice! One thing I would love to see added is a way to directly fetch
the .ase files from kuler. Unfortunately, I think you have to be
logged in in order to get the download option. But, we should be able
to do that using one of the HTTP client libraries -- it will just
require a bit of extra code to do the authentication steps.

 - jeremy

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

[Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

[Jeremy Shaw]

There have been at least a couple projects, such as hOp and HaLVM
which attempt to run GHC on the bare metal or something similar.

Both these projects required a substantial set of patches against GHC
to remove dependencies things like POSIX/libc. Due to the highly
invasive nature, they are also highly prone to bitrot.

With GHC 7.8, I believe we will be able to cross-compile to the
Raspberry Pi platform. But, what really appeals to me is going that
extra step and avoiding the OS entirely and running on the bare metal.
Obviously, you give up a lot -- such as drivers, network stacks, etc.
But, there is also a lot of potential to do neat things, and not have
to worry about properly shutting down an embedded linux box.

Also, since the raspberry pi is a very limited, uniform platform,
(compared to general purpose PCs) it is feasible to create network
drivers, etc, because only one chipset needs to be supported.
(Ignoring issues regarding binary blobs, undocumented chipsets, usb
WIFI, etc).

I'm wondering if things are any easier with cross-compilation support
improving. My thought is that less of GHC needs to be tweaked?

- jeremy

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

Re: [Haskell-cafe] monadic DSL for compile-time parser generator, not possible?

[Jeremy Shaw]

Mostly, because I want to do other sorts of compile-time inspections
on the parser. Being able to generate the parser is just the easiest
part to get started with.

- jeremy

On Tue, Mar 12, 2013 at 3:36 PM, dag.odenh...@gmail.com
 wrote:
> Why not the parsers package [1]? Write the parser against the Parsing class
> and then use trifecta or write instances for attoparsec or parsec. With
> enough inlining perhaps the overhead of the class gets optimized away?
>
> [1] http://hackage.haskell.org/package/parsers
>
>
> On Tue, Mar 12, 2013 at 9:06 PM, Jeremy Shaw  wrote:
>>
>> It would be pretty damn cool if you could create a data type for
>> generically describing a monadic parser, and then use template haskell
>> to generate a concrete parser from that data type. That would allow
>> you to create your specification in a generic way and then target
>> different parsers like parsec, attoparsec, etc. There is some code
>> coming up in a few paragraphs that should describe this idea more
>> clearly.
>>
>> I would like to suggest that while it would be cool, it is
>> impossible. As proof, I will attempt to create a simple monadic parser
>> that has only one combinator:
>>
>> anyChar :: ParserSpec Char
>>
>> We need the GADTs extension and some imports:
>>
>> > {-# LANGUAGE GADTs, TemplateHaskell #-}
>> > import Control.Monad  (join)
>> > import qualified Text.Parsec.Char as P
>> > import Language.Haskell.TH(ExpQ, appE)
>> > import Language.Haskell.TH.Syntax (Lift(lift))
>> > import Text.Parsec(parseTest)
>> > import qualified Text.Parsec.Char as P
>> > import Text.Parsec.String (Parser)
>>
>> Next we define a type that has a constructor for each of the different
>> combinators we want to support, plus constructors for the functor and
>> monad methods:
>>
>> > data ParserSpec a where
>> > AnyChar :: ParserSpec Char
>> > Return  :: a -> ParserSpec a
>> > Join:: ParserSpec (ParserSpec a) -> ParserSpec a
>> > FMap:: (a -> b) -> ParserSpec a -> ParserSpec b
>> >
>> > instance Lift (ParserSpec a) where
>> > lift _ = error "not defined because we are screwed later anyway."
>>
>> In theory, we would extend that type with things like `Many`, `Some`,
>> `Choice`, etc.
>>
>> In Haskell, we are used to seeing a `Monad` defined in terms of
>> `return` and `>>=`. But, we can also define a monad in terms of
>> `fmap`, `return` and `join`. We will do that in `ParserSpec`, because
>> it makes the fatal flaw more obvious.
>>
>> Now we can define the `Functor` and `Monad` instances:
>>
>> > instance Functor ParserSpec where
>> > fmap f p = FMap f p
>>
>> > instance Monad ParserSpec where
>> > return a = Return a
>> > m >>= f  = Join ((FMap f) m)
>>
>> and the `anyChar` combinator:
>>
>> > anyChar :: ParserSpec Char
>> > anyChar = AnyChar
>>
>> And now we can define a simple parser that parses two characters and
>> returns them:
>>
>> > charPair :: ParserSpec (Char, Char)
>> > charPair =
>> > do a <- anyChar
>> >b <- anyChar
>> >return (a, b)
>>
>> Now, we just need to define a template haskell function that generates
>> a `Parser` from a `ParserSpec`:
>>
>> > genParsec :: (Lift a) => ParserSpec a -> ExpQ
>> > genParsec AnyChar= [| anyChar |]
>> > genParsec (Return a) = [| return a |]
>> > genParsec (Join p)   = genParsec p
>> > -- genParsec (FMap f p) = appE [| f |] (genParsec p) -- uh-oh
>>
>> Looking at the `FMap` case we see the fatal flaw. In order to
>> generate the parser we would need some way to transform any arbitrary
>> Haskell function of type `a -> b` into Template Haskell. Obviously,
>> that is impossible (for some definition of obvious).
>>
>> Therefore, we can assume that it is not possible to use Template
>> Haskell to generate a monadic parser from a monadic specification.
>>
>> We can also assume that `Applicative` is not available either. Seems
>> likely that `Category` based parsers would also be out.
>>
>> Now, we can, of course, do the transformation at runtime:
>>
>> > interpretParsec :: ParserSpec a -> Parser a
>> > interpretParsec AnyChar= P.anyChar
>> > interpretParsec (Return a) = return a
>> &

Re: [Haskell-cafe] monadic DSL for compile-time parser generator, not possible?

[Jeremy Shaw]

On Tue, Mar 12, 2013 at 3:32 PM, Jacques Carette  wrote:
> On 13-03-12 04:06 PM, Jeremy Shaw wrote:

>>> data ParserSpec a where
>>>  AnyChar :: ParserSpec Char
>>>  Return  :: a -> ParserSpec a
>>>  Join:: ParserSpec (ParserSpec a) -> ParserSpec a
>>>  FMap:: (a -> b) -> ParserSpec a -> ParserSpec b
>
>
> does not work.  The flaw is indeed in FMap.  It should not take a function
> as first argument, but rather a *description* of a function (the same way
> ParserSpec gives you a description of a parser).  Then you can make it work,
> if your 'description' language is adequate.

Right. But, then I would not be able to use Haskell's existing do
notation -- and I would have to poorly recreate a subset of Haskell.
And, I think, ParsecSpec would not be a real monad. But.. that is sort
of the conclusion -- if you want to do compile-time generation, then
the data-type can not contain any function values -- at least none
that would need to be lifted into the generated code. And, there is no
way to make a type with a real Monad instance which does not contain
such a function.

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

[Haskell-cafe] monadic DSL for compile-time parser generator, not possible?

[Jeremy Shaw]

It would be pretty damn cool if you could create a data type for
generically describing a monadic parser, and then use template haskell
to generate a concrete parser from that data type. That would allow
you to create your specification in a generic way and then target
different parsers like parsec, attoparsec, etc. There is some code
coming up in a few paragraphs that should describe this idea more
clearly.

I would like to suggest that while it would be cool, it is
impossible. As proof, I will attempt to create a simple monadic parser
that has only one combinator:

anyChar :: ParserSpec Char

We need the GADTs extension and some imports:

> {-# LANGUAGE GADTs, TemplateHaskell #-}
> import Control.Monad  (join)
> import qualified Text.Parsec.Char as P
> import Language.Haskell.TH(ExpQ, appE)
> import Language.Haskell.TH.Syntax (Lift(lift))
> import Text.Parsec(parseTest)
> import qualified Text.Parsec.Char as P
> import Text.Parsec.String (Parser)

Next we define a type that has a constructor for each of the different
combinators we want to support, plus constructors for the functor and
monad methods:

> data ParserSpec a where
> AnyChar :: ParserSpec Char
> Return  :: a -> ParserSpec a
> Join:: ParserSpec (ParserSpec a) -> ParserSpec a
> FMap:: (a -> b) -> ParserSpec a -> ParserSpec b
>
> instance Lift (ParserSpec a) where
> lift _ = error "not defined because we are screwed later anyway."

In theory, we would extend that type with things like `Many`, `Some`,
`Choice`, etc.

In Haskell, we are used to seeing a `Monad` defined in terms of
`return` and `>>=`. But, we can also define a monad in terms of
`fmap`, `return` and `join`. We will do that in `ParserSpec`, because
it makes the fatal flaw more obvious.

Now we can define the `Functor` and `Monad` instances:

> instance Functor ParserSpec where
> fmap f p = FMap f p

> instance Monad ParserSpec where
> return a = Return a
> m >>= f  = Join ((FMap f) m)

and the `anyChar` combinator:

> anyChar :: ParserSpec Char
> anyChar = AnyChar

And now we can define a simple parser that parses two characters and
returns them:

> charPair :: ParserSpec (Char, Char)
> charPair =
> do a <- anyChar
>b <- anyChar
>return (a, b)

Now, we just need to define a template haskell function that generates
a `Parser` from a `ParserSpec`:

> genParsec :: (Lift a) => ParserSpec a -> ExpQ
> genParsec AnyChar= [| anyChar |]
> genParsec (Return a) = [| return a |]
> genParsec (Join p)   = genParsec p
> -- genParsec (FMap f p) = appE [| f |] (genParsec p) -- uh-oh

Looking at the `FMap` case we see the fatal flaw. In order to
generate the parser we would need some way to transform any arbitrary
Haskell function of type `a -> b` into Template Haskell. Obviously,
that is impossible (for some definition of obvious).

Therefore, we can assume that it is not possible to use Template
Haskell to generate a monadic parser from a monadic specification.

We can also assume that `Applicative` is not available either. Seems
likely that `Category` based parsers would also be out.

Now, we can, of course, do the transformation at runtime:

> interpretParsec :: ParserSpec a -> Parser a
> interpretParsec AnyChar= P.anyChar
> interpretParsec (Return a) = return a
> interpretParsec (FMap f a) = fmap f (interpretParsec a)
> interpretParsec (Join mm)  = join (fmap interpretParsec (interpretParsec mm))

> test = parseTest (interpretParsec charPair) "ab"

My fear is that doing that will result in added runtime overhead. One
reason for wanting to create a compile-time parser generator is to have
the opportunity to generate very fast parsing code. It seems like here
we can only be slower than the parser we are targeting? Though..
perhaps not? Perhaps the parser returned by `interpretParsec` has all
the interpret stuff removed and is as fast as if we have constructed
it by hand? I don't have an intuitive feel for it.. I guess criterion
would know..

Any thoughts?

- jeremy

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

Re: [Haskell-cafe] Embedded haskell?

[Jeremy Shaw]

Ah, nice. Building Haskell applications on the Raspberry Pi which is a
32-bit 700 Mhz CPU with 512MB of RAM is still pretty painful. So, I
think that running GHC on something even less powerful is probably not
going to work well. But, handling a subset of Haskell for onsite
programming could work. Using Haskell Source Extensions and the new
Haskell Type Extensions should be enough to allow you to create an
onboard mini-Haskell interpreter? It would actually be pretty neat to
be able to extend all sorts of Haskell applications with a
Haskell-subset scripting language..

I'd definitely be interested in exploring this more. I recently got
into multirotors and I am also working on a semi-autonomous rover
project -- plus I just want to see Haskell used more in educational
robotics (http://www.haskell.org/haskellwiki/RoboticOverlords).

- jeremy

On Wed, Feb 20, 2013 at 4:28 PM, Mike Meyer  wrote:
> On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw  wrote:
>> Another option would be to use Atom. I have successfully used it to
>> target the arduino platform before. Running the entire OS on the
>> embedded system seems dubious. Assuming you are using something the 9x
>> family of transmitters -- they are slow and have very little internal
>> memory. Plus trying to programming using a 6 buttons would be a royal
>> pain. If you really want in-field programming, then you might at least
>> using a raspberry pi with a small bluetooth keyboard and have it
>> upload to the transmitter.
>
> Atom does look interesting. Thanks for the pointer.
>
> The target transmitter is the Walkera Devo line.  These have much more
> capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with
> comparable amounts of storage.  Some have 9x-like screen/button
> combos, others have touch screens. The deviationTx software runs on
> all of them.
>
> Settings are stored in a FAT file system that can be accessed as a USB
> drive. I'm thinking that a traditional configuration interface on the
> transmitter, storing the config information as program text. The only
> actual programming would be done by replacing the virtual
> channel/switch feature with expressions or short programs.

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

Re: [Haskell-cafe] Embedded haskell?

[Jeremy Shaw]

Another option would be to use Atom. I have successfully used it to
target the arduino platform before. Running the entire OS on the
embedded system seems dubious. Assuming you are using something the 9x
family of transmitters -- they are slow and have very little internal
memory. Plus trying to programming using a 6 buttons would be a royal
pain. If you really want in-field programming, then you might at least
using a raspberry pi with a small bluetooth keyboard and have it
upload to the transmitter.

- jeremy

On Wed, Feb 20, 2013 at 1:33 PM, Mike Meyer  wrote:
> I've been working with open source rc aircraft transmitter software,
> and in looking at the shortcomings of one of them, started thinking
> about embedding a language. There are a number of options that can
> work here, like FORTH or a basic. But then I realized that Haskell -
> or  similar functional language - could well be a good fit.
>
> The software is meant to let the end user express how the various
> inputs - joysticks, switches, trims, knobs - are mapped to values the
> radio sends on the various control channels. All the key values are
> immutable - you either read them from hardware once in the process of
> building a frame to transmit, or you fill them into a frame and
> transmit it, then start over for the next frame. You just need to let
> the end user express the functions to go from one to the other.
>
> The other restraint is that you need to be able to change the code in
> the field, with the only computer available being the embedded one.
> You might have a touch-screen, or you might just have cursor  keys.
> Either way, actually inputting a program could be interesting.
> Similarly, the entire system: compiler, interpreter, whatever - needs
> to run on the embedded computer.
>
> A quick google turns up Hume, which seems to be designed for this kind
> of thing, though not with the "in the field" restrictions.
>
> Anyone have any other suggestions of software that might fit here?
> Experience with any of that software? Other suggestions?
>
>Thanks,
> 
> ___
> 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] [Security] Put haskell.org on https

[Jeremy Shaw]

On Sun, Oct 28, 2012 at 1:45 PM, Patrick Hurst
 wrote:

> On the other hand, with PGP, any user who wants to be secure but doesn't use 
> GPG would have to verify the identity of whoever signed the Cabal GPG key, 
> and most non-Linux operating systems don't come with a list of trusted GPG 
> keys. So how do they get them without using HTTPS (since if you use HTTPS to 
> figure out what keys you trust, your scheme is no more secure than HTTPS)?

Well.. my dumb idea is that you include some trusted GPG keys with the
cabal client itself? Obviously you must be getting cabal-install from
a trusted source, or all the HTTPS in the world can't help you?

I'm sure this idea is wrong somehow, but someone had to mention it ;)

- jeremy

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

Re: [Haskell-cafe] acid-state audit trail

[Jeremy Shaw]

Right now acid-state always tries to restore everything up through the
latest events.

The long term plan is to create an acid-state tool that would allow
you to rollback the event log, list and examine specific events, etc.

So, it is possible in theory, and not even that hard, but no one has
done the work yet.

- jeremy

On Fri, Oct 19, 2012 at 10:38 AM, Richard Wallace
 wrote:
> Ok, cool. Any idea if you can get a list of events, or can you just get the
> latest state?
>
> Thanks,
> Rich
>
> On Oct 19, 2012 3:53 AM, "Neil Davies" 
> wrote:
>>
>> The history is there until you "archive" (move a checkpoint out into a
>> separate directory) it and then delete the archive yourself.
>>
>> the checkpointing just reduces the recovery time (i.e creates a fixed
>> point in time), if you were to keep all the checkpoint/archives then you
>> would have the complete history
>>
>> Neil
>>
>> On 19 Oct 2012, at 06:18, Richard Wallace 
>> wrote:
>>
>> > Hey all,
>> >
>> > I've been looking at acid-state as a possible storage backend for an
>> > application.  It looks like it fits my needs pretty damn well, but one
>> > thing that I'm curious about is if it is possible to get a list of
>> > "update events".  You can obviously query for the current state, but
>> > it's not immediately apparent if you can see the history of your
>> > values state.  This is useful in some things, like providing audit
>> > trails and debugging.  As well as being able to re-create state in a
>> > different form.
>> >
>> > I was also curious if the createCheckpoint function eliminates the
>> > state history or does it just create a snapshot, it's not apparent
>> > from the docs.
>> >
>> > Thanks,
>> > Rich
>> >
>> > ___
>> > 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] Hackage 2 maintainership

[Jeremy Shaw]

On Wed, Jun 20, 2012 at 11:06 AM, Ben Gamari  wrote:

> This list is definitely a start. One of the issues that was also
> realized is the size of the server's memory footprint. Unfortunately
> acid-state's requirement that all data either be in memory or have no
> ACID guarantees was found to be a bit of a limitation. If I recall
> correctly some folks were playing around with restructuring the data
> structures a bit to reduce memory usage. I really don't know what
> happened to these efforts.

I am one of those people, but as I (hopefully) mentioned at the time,
I had some other tasks I had to address first (namely, the release of
Happstack 7 and clckwrks). However,  starting this week I am finally
looking at some acid-state related issues. Part of this will be
building some tools to help analyze where all your RAM is going.

My current hypothesis is that for hackage 2, we should be able to
reduce RAM usage by 10 to 100 fold. The size of the data on disk is
only a few MB.. I currently can not think of any good reason why it
should take anywhere as much RAM as it currently does. So, it must be
doing it for some bad reason :) Though, I won't know until I do the
analysis. You'll probably see some blog articles as I work out the
process.

- jeremy

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

Re: [Haskell-cafe] Problem with plugins

[Jeremy Shaw]

I really have no idea. I am the new plugins maintainer -- but so far
that mostly means I am willing to apply darcs patches and uploading
things to hackage. I have not had a chance to really dig into plugins.

I will now make some wild guesses.

 1. does it matter if you compile with -O2 vs -O0 ?

 2. do those .o  files actually exist?

 3. Are there perhaps .o and .hi files in your project directory that
were compiled with GHC 7.0 but now you are trying to load them with >=
7.0?

- jeremy

On Tue, Jun 19, 2012 at 10:30 AM, Timo von Holtz
 wrote:
> Hi,
>
> I'm currently working on extending the hascat Server. My problem is, that
> for whatever odd reason it will only work on GHC < 7.0 or alternatively if I
> execute it with runghc or in ghci.
> If I compile it with GHC>=7.0 and execute it, then I get this:
>
> $ ~/.cabal/bin/hascat config.xml
> Installing "Root" at /
> hascat: /home/tvh/.cabal/lib/plugins-1.5.2.1/ghc-7.4.1/HSplugins-1.5.2.1.o:
> unknown symbol `ghczm7zi4zi1_ErrUtils_zdsinsertzugo3_info'
> hascat: unloadObj: can't find
> `/usr/lib/ghc/binary-0.5.1.0/HSbinary-0.5.1.0.o' to unload
> user error (unloadObj: failed)
> Installing "Hascat Server Info" at /ServerInfo/
> hascat:
> /home/tvh/.cabal/lib/hascat-system-0.2/ghc-7.4.1/HShascat-system-0.2.o:
> unknown symbol `base_DataziMaybe_Nothing_closure'
> hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o'
> to unload
> user error (unloadObj: failed)
> Installing "Hascat Application Manager" at /Manager/
> hascat:
> /home/tvh/.cabal/lib/hascat-system-0.2/ghc-7.4.1/HShascat-system-0.2.o:
> unknown symbol `base_DataziMaybe_Nothing_closure'
> hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o'
> to unload
> user error (unloadObj: failed)
> Installing "Hascat Application Deployer" at /Deployer/
> hascat:
> /usr/lib/haskell-packages/ghc/lib/zlib-0.5.3.3/ghc-7.4.1/HSzlib-0.5.3.3.o:
> unknown symbol `base_GHCziForeignPtr_ForeignPtr_con_info'
> hascat: unloadObj: can't find `/usr/lib/ghc/Cabal-1.14.0/HSCabal-1.14.0.o'
> to unload
> user error (unloadObj: failed)
> Waiting for connections on port 8012
>
> Is there a way to make this work?
>
> Greetings
> Timo
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

[Haskell-cafe] ANN: clckwrks - a Haskell blogging and CMS framework

[Jeremy Shaw]

Hello!

I am pleased to announce the launch of clckwrks.com. clckwrks
(pronounced, 'clockworks') is a new Haskell-based content management
(CMS) and blogging framework:

http://www.clckwrks.com/

It is freely available under the BSD3 license.

clckwrks is still in early alpha development. We are looking for
developers who want to contribute or just like to try bleeding edge
software. clckwrks is already being used to power happstack.com and
clckwrks.com -- so it is already useful. There are a lot of things we
are not happy with yet ranging from code formatting to design issues.
But, at the same time, there are a lot of things we are very happy
with.

If you would like to help get us to clckwrks 1.0, we'd love to have your help!

For more information, check out the website and consider joining the
mailing list.

Thanks!
- jeremy

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

Re: [Haskell-cafe] ANN: reform - a type-safe form generation and validation library in the spirit of formlets and digestive-functors < 0.2

[Jeremy Shaw]

Sounds great!

I have some vague ideas about what the comparison might reveal -- but
I expect to learn quite a bit in the process, and use that to improve
reform. There is definitely room for more than one form validation
library. They all have shortcomings, and I am hoping something even
better will come along some day :)

- jeremy

On Tue, May 22, 2012 at 4:31 AM, Jasper Van der Jeugt  wrote:
> Congrats on the release!
>
> I would like to help out with the full comparison since I have some
> knowledge and experience on the subject. Because of the different
> approach, I think there's definitely room for two libraries.
>
> Cheers,
> Jasper
>
> On Tue, May 22, 2012 at 2:23 AM, Felipe Almeida Lessa
>  wrote:
>> On Mon, May 21, 2012 at 7:18 PM, Jeremy Shaw  wrote:
>>> I hope to do a full comparison of reform vs digestive-functors 0.3 vs
>>> yesod forms in a few weeks.
>>
>> That would be awesome!  Just sayin' =).
>>
>> Cheers,
>>
>> --
>> Felipe.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "HAppS" group.
>> To post to this group, send email to ha...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> happs+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/happs?hl=en.
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Haskell-cafe] ANN: reform - a type-safe form generation and validation library in the spirit of formlets and digestive-functors < 0.2

[Jeremy Shaw]

I am pleased to annouce the release of 'reform'. A full tutorial is
available here:

http://www.happstack.com/docs/crashcourse/Reform.html

Reform is an HTML form generation and validation library. It follows
in the footsteps of formlets and digestive-functors <= 0.2. In fact,
much of the code in reform comes from the digestive-functors-0.2 code
base.

Reform is designed to be usuable with a wide variety of Haskell web
servers and templating libraries. You can find the following packages
on hackage:

 * reform   - the core library
 * reform-happstack - support for using reform with the Happstack server
 * reform-blaze - support for creating forms for blaze-html
 * reform-hsp   - support for creating forms for HSP (another
xml/html template library)

The source code is available via darcs:

darcs get http://patch-tag.com/r/stepcut/reform

The darcs repo also includes proof-of-concept support for 'Heist'.

Reform will feel very familiar to formlets and digestive-functors <=
0.2 users.

The primary motivation behind this library is to provide a supported
alternative to digestive-functors 0.2 for users that prefer 0.2 over
0.3.

The key new feature in reform is the ability to separate the
validation code from the view generation code. This allows library
authors to provide validators (known as Proofs) which the users can
use when constructing their forms. The proof names appear in the
type-signatures. This allows the library author to ensure that the
value returned by a user created form is not merely the correct type,
but has also passed validation.

The reform-happstack package also provides simple and transparent
Cross-Site Request Forgery (CSRF) protection, using the double-submit
method. This method has some weaknesses. For example, I believe it can
be circumvented if your site is vulnerable to cross-site scripting
(XSS) attacks. If you have suggestions on how to improve the CSRF
protection -- please let us know!

I hope to do a full comparison of reform vs digestive-functors 0.3 vs
yesod forms in a few weeks.

- jeremy

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

Re: [Haskell-cafe] How to use Plugins package?

[Jeremy Shaw]

plugins-auto has a demo in the darcs repo:

http://www.patch-tag.com/r/facundo/plugins-auto/snapshot/current/content/pretty/demo

Does that work for you ?

- jeremy

On Wed, May 16, 2012 at 9:46 AM, Андрей Янкин  wrote:
> Hi,
>
> I'm newbie and I've got a problem.
>
> I'm trying to get example programs from plugins-auto [1] or hotswap [2] to 
> work.
> I think question on stackoverflow [3] somewhat related to my problem.
>
> They are compiled well, but in runtime I get either
> segfault
> or Prelude.undefined
> or internal error: PAP object entered!
>
> I use GHC 7.4.1. x86_64 Ubuntu
>
> I've read "Plugging Haskell In" and would like to make some fun with
> plugins, but alas...
>
> Maybe -dynamic flag is what I seek? Or maybe I need to know something else?
> Maybe I needn't use Plugins package like in gitit?
>
> Please, could you explain how to compile plugins in haskell correctly?
> Where should I start?
>
>
> [1] http://hackage.haskell.org/package/plugins-auto
> [2] http://hackage.haskell.org/package/hotswap
> [3] 
> http://stackoverflow.com/questions/542/help-with-haskell-dynamic-plugin-load
>
> ___
> 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] Generalizing (++) for monoids instead of using (<>)

[Jeremy Shaw]

In the context of string-like types ++ seems quite sensible because
the Monoid instances concat the strings.

However, not all Monoid instances imply concatenation. A Monoid
instance might provide choice. For example, we could define a parser,

> module Main where
>
> import Data.Monoid
>
> newtype Parser a = Parser { parse :: [Char] -> Maybe (a, [Char]) }

and create a Monoid instance like:

> instance Monoid (Parser a) where
> mempty = Parser $ const Nothing
> (Parser p1) `mappend` (Parser p2) =
> Parser $ \str ->
> case p1 str of
>   (Just (a, cs)) -> Just (a, cs)
>   Nothing  -> p2 str

And then create some simply parser combinators:

> satisfy :: (Char -> Bool) -> Parser Char
> satisfy p =
> Parser $ \str ->
> case str of
>   (c:cs) | p c -> Just (c, cs)
>   _-> Nothing

> char :: Char -> Parser Char
> char c = satisfy (== c)

Now, imagine we want to write a parser that parses 'a' or 'b':

> ab :: Parser Char
> ab = char 'a' <> char 'b'

That will parse 'a' or 'b'. But what we had used ++ for mappend instead:

> ab :: Parser Char
> ab = char 'a' ++ char 'b'

You are much more likely to assume that parses 'a' followed by 'b'.
(Even though that doesn't really make sense when you consider the
return type -- you would expect, Parser String, if that was the case).

For the same reason, many people feel that mappend was a bad choice of
name in the first place, (and that (++) = mappend just makes a bad
thing worse).

Or maybe I am totally confused and am thinking about something else..

Anyway, the subject was certainly beaten to death quite a bit over the
last couple years. I think another reason why <> was chosen is that a
number of libraries were already defining (<>) = mappend locally? (not
positive about that).

- jeremy



On Sun, Apr 1, 2012 at 3:58 PM, aditya bhargava
 wrote:
> After asking this question:
> http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend
>
> I found out that the new infix operator for `mappend` is (<>). I'm wondering
> why ghc 7.4 didn't generalize (++) to work on monoids instead. To me, (++)
> is much more clear. (<>) means "not equal to" for me. Can anyone shed light
> on this decision?
>
>
> Adit
>
> --
> adit.io
>
> ___
> 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] Specify compile error

[Jeremy Shaw]

This response is written in literal Haskell.

> {-# LANGUAGE DataKinds, KindSignatures, GADTs #-}

The key to getting the type checker involved is to put the information
where the type-checker can see it -- namely, the type signature.

So, let's change A so that the Safe/Unsafe information is in the type:

> data A safety = A Int

This is what is called a 'phantom type', because the 'safety' type
variable only appears on the left hand side. We can keep 'B' the same:

> data B= B Int

Now, we need some way to represent 'Safe' and 'Unsafe':

> data Safe
> data Unsafe

Normally data declarations have 1 or more data constructors. Here we
have data-types with 0 constructors. We don't need to actually create
any 'Safe' or 'Unsafe' values, because we are only going to be using
them as the phantom arguments. We need two separate types, because we
want to be able to tell the difference at compile time. As you saw,
having a single type with two different constructors does not give you
enough power to constrain things at compile time.

Now we can make two helper functions which mark a value as 'Safe' or 'Unsafe':

> unsafe :: A safety -> A Unsafe
> unsafe  (A x) = (A x)

> safe :: A safety -> A Safe
> safe(A x) = (A x)

And now we can make 'createB' only accept safe values:

> createB :: A Safe -> B
> createB (A x) = B x

We can apply createB to 'Safe' values:

> b :: B
> b = createB (safe (A 1))

but not 'Unsafe' values:

> {-

> b2 :: B
> b2 = createB (unsafe (A 1))

Results in:

Couldn't match expected type `Safe' with actual type `Unsafe'
Expected type: A Safe
  Actual type: A Unsafe

> -}

Alas, we can also apply 'createB' to values that are untagged:

> b3 :: B
> b3 = createB (A 1)

Sometimes that is a good thing -- but in this case, it is not likely
to be. A work around is to not export the 'A' constructor. Instead we
could export:

> unsafeA :: Int -> A Unsafe
> unsafeA  x = (A x)

> safeA :: Int -> A Safe
> safeAx = (A x)

If that is the only way to create values of type 'A', then we won't
have any untagged 'A' values.

With our current definition for 'A' we can mark values as 'Safe' or
'Unsafe' and prevent functions from being applied at compile time.
However, this provides no easy way to write a function that behaves
one way for 'Safe' values and a different way for 'Unsafe' values. If
we wanted to do that, we would need to create a type class.

We might try to fix this by changing A to have two constructors again:

] data A' safety = SafeA' Int | UnsafeA' Int

But, now we have a very difficult problem of ensuring that values
which use SafeA' always have the phantom type 'Safe' and that UnsafeA'
values always have the phantom type 'Unsafe'. That is rather tricky.

The solution here is the GADTs type extension. We can instead write:

> data A' safety where
> UnsafeInt :: Int -> A' Unsafe
> SafeInt   :: Int -> A' Safe

This declaration is similar to the normal data declaration:

] data A' safety
] = UnsafeInt Int
] | SafeInt Int

But in the GADT version, we can specify that when we use the
'UnsafeInt' constructor the phantom type variable *must* be 'Unsafe'
and when using 'SafeInt' the phantom parameter *must* be 'Safe'.

This solves both 'issues' that we described. We can now match on safe
vs unsafe construtors *and* we can be sure that values of type A' are
*always* marked as 'Safe' or 'Unsafe'. If we wanted to have an
untagged version we could explicitly add a third constructor:

> UnknownInt   :: Int -> A' safety


We can now write 'createB' as:

> createB' :: A' Safe -> B
> createB' (SafeInt i) = B i

In this case createB' is total. The compiler knows that createB' could
never be called with 'UnsafeInt' value. In fact, if you added:

] createB' (UnsafeInt i) = B i

you would get the error:

Couldn't match type `Safe' with `Unsafe'
Inaccessible code in
  a pattern with constructor
UnsafeInt :: Int -> A' Unsafe,

One issue with both A and A' is that the phantom variable parameter
can be any type at all. For example we could write:

> nonsense :: A' Char
> nonsense = UnknownInt 1

But, the only types we want to support are 'Safe' and 'Unsafe'. A'
Char is a legal -- but meaningless type.

In GHC 7.4 we can use Datatype promotion to make the acceptable types
for the phantom parameter more restrictive.

First we declare a normal Haskell type with constructors for safe and unsafe:

> data Safety = IsSafe | IsUnsafe

But, with the 'DataKind' extension enabled, we can now use this type
to provide a signature for the the phantom type. The data type
'Safety' automatically becomes a kind type 'Safety' and the data
constructors 'IsSafe' and 'IsUnsafe' automatically become type
constructors. Now we can write:

> data Alpha (safetype :: Safety) where
> SafeThing:: Int -> Alpha IsSafe
> UnsafeThing  :: Int -> Alpha IsUnsafe
> UnknownThing :: Int -> Alpha safetype

Now we can write:

> foo :: Alpha IsUnsafe
> foo  = UnknownThing 1

But i

Re: [Haskell-cafe] JSON library suggestions?

[Jeremy Shaw]

Hello,

Have you emailed Bryan O'Sullivan and explained your problem? It
sounds to me like choosing Double was just the wrong choice and is a
design flaw that should be fixed in Aeson?

There are far too many JSON libraries on hackage already, and what
would be really useful (to me) is for the community to standardize on
one. I maintain a number of libraries that need some sort of JSON
library, and supporting all of them is not practical. So far aeson
seems like the best choice for the 'one true Haskell JSON library'. I
would be happy to invest effort in trying to address the shortcomings
so that we can try to get some sort of consensus. Usually I like
choice and flexibility.. but in terms of JSON libraries.. it seems
like the design space for a good JSON library is pretty small.

- jeremy


On Tue, Apr 24, 2012 at 4:51 PM, Jeff Shaw  wrote:
> Hi Jeremy,
> Sorry if I was unclear. Rational is acceptable to me as the result of a JSON
> parse, but Double (which Aeson uses), is not. Also acceptable would be
> Data.Decimal.Decimal, or maybe one of the types from Data.Fixed.
>
> JSON doesn't specify a data type for numbers, only a format.
>
> Jeff

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

Re: [Haskell-cafe] JSON library suggestions?

[Jeremy Shaw]

Hello,

I could be wrong, but I think the only real numeric type in javascript
is 'Number' which is a floating point number? Which is why Aeson and
others insist on converting everything to a Double or other Rational
number?

- jeremy

On Tue, Apr 24, 2012 at 3:46 PM, Jeff Shaw  wrote:
> Hello,
> Up until now I've been using Aeson, but I've found that its number type
> isn't going to work for me. I need to use decimal numbers while avoiding
> conversions from and to Double, which Aeson doesn't allow. There are quite a
> few more JSON libraries for Haskell, which all appear to use Rational for
> numbers, so I'm wondering if anyone can recommend one.
>
> Thanks,
> Jeff
>
> ___
> 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] ANN: plugins-1.5.2.1

[Jeremy Shaw]

Hello,

I will update the description. The documentation is not on hackage yet
because the haddock builder only runs a few times a day. That should
correct itself in a few hours -- unless the build fails for some
reason.

However, the API has not changed from the previous version, so these
docs are still valid:

http://hackage.haskell.org/package/plugins-1.5.1.4

- jeremy



On Mon, Apr 9, 2012 at 1:21 PM, Jeremy Shaw  wrote:
> Hello!
>
> I am pleased to announce the release of plugins-1.5.2.1:
>
> http://hackage.haskell.org/package/plugins
>
> The plugins library provides facilities to compile and dynamically
> load/link Haskell code into a running Haskell application. (The
> related, plugins-auto package adds support for file watching via
> inontify and automatic recompilation and reloading,
> http://hackage.haskell.org/package/plugins).
>
> There are three important changes in this release:
>
>  1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped
> support for GHC 6.12. So, if you still use an older compiler and we
> broke it.. we might be willing to fix it still :)
>
>  2. New maintainer: Don Stewart has graciously allowed me to take over
> the project. I do not have any immediate plans for big changes. But I
> do plan to: keep it compiling, apply patches in a timely manner, and
> deal with other minor bug fixes. I would certainly love to see some
> major improvements. I believe plugins predates the GHC API and,
> accordingly, does not use it as well as it could. If someone wanted to
> give plugins some major love, that would be awesome. While plugins has
> not much recent development, there are still a lot of people that are
> using it, or would like to.
>
>  3. the source has moved to patch-tag and darcs 2,
>
>    http://patch-tag.com/r/stepcut/plugins
>
>   patch-tag only supports darcs 2 format repositories, so this forced
> me to run darcs convert to switch from darcs 1 to darcs 2 format. In
> the end that is a good thing. The only downside is that I can not
> directly apply any darcs 1 patches to the repo now. But I doubt there
> are many floating around anyway. And I can still apply them the hard
> way.
>
> - jeremy

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

[Haskell-cafe] ANN: plugins-1.5.2.1

[Jeremy Shaw]

Hello!

I am pleased to announce the release of plugins-1.5.2.1:

http://hackage.haskell.org/package/plugins

The plugins library provides facilities to compile and dynamically
load/link Haskell code into a running Haskell application. (The
related, plugins-auto package adds support for file watching via
inontify and automatic recompilation and reloading,
http://hackage.haskell.org/package/plugins).

There are three important changes in this release:

 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped
support for GHC 6.12. So, if you still use an older compiler and we
broke it.. we might be willing to fix it still :)

 2. New maintainer: Don Stewart has graciously allowed me to take over
the project. I do not have any immediate plans for big changes. But I
do plan to: keep it compiling, apply patches in a timely manner, and
deal with other minor bug fixes. I would certainly love to see some
major improvements. I believe plugins predates the GHC API and,
accordingly, does not use it as well as it could. If someone wanted to
give plugins some major love, that would be awesome. While plugins has
not much recent development, there are still a lot of people that are
using it, or would like to.

 3. the source has moved to patch-tag and darcs 2,

http://patch-tag.com/r/stepcut/plugins

   patch-tag only supports darcs 2 format repositories, so this forced
me to run darcs convert to switch from darcs 1 to darcs 2 format. In
the end that is a good thing. The only downside is that I can not
directly apply any darcs 1 patches to the repo now. But I doubt there
are many floating around anyway. And I can still apply them the hard
way.

- jeremy

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

Re: [Haskell-cafe] ANN: acme-http

[Jeremy Shaw]

On Sun, Apr 1, 2012 at 12:48 PM, Michael Snoyman  wrote:

> That's awesome! I think you should pair this up with the /dev/null
> datastore and then you'll be truly webscale!

Well, acid-state does have a backend that skips writing any
transaction logs to disk making it pure memory based:

http://hackage.haskell.org/packages/archive/acid-state/0.6.3/doc/html/Data-Acid-Memory.html

So, that is a bit like a /dev/null data store. It works really great
as long as your app never restarts :)

- jeremy

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

[Haskell-cafe] ANN: acme-http

[Jeremy Shaw]

Hello,

As we all know, the true measure of performance for a web server is
the classic PONG test. And, so the Happstack team is pleased to
announce the release of the new acme-http server!

hackage:
  http://hackage.haskell.org/package/acme-http

source:
  http://patch-tag.com/r/stepcut/acme-http

When testing on my laptop with +RTS -N4 using the classic PONG test:

 $ httperf --hog -v --server 127.0.0.1 --port 8000 --uri /
--num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000

acme-http delivered  221,693.0 req/s, making it the fastest Haskell
web server on the planet.

By comparison, warp delivered 51,346.6 req/s on this machine.

The secret to acme-http's success is that it large avoids doing
anything not required to win the PONG benchmark. It does not support
timeouts, it does not check quotas, it assumes the client is HTTP 1.1,
it does not catch exceptions, and it responds to every single request
with PONG.

The goal of acme-http is two fold:

 1. determine the upper-bound on Haskell  web-server performance
 2. push that upper bound even higher

In regards to #1, we have now established the current upper limit at
221,693.0 req/s.

In regards to #2, I believe acme-http will be useful as a place to
investigate performance bottlenecks. It is very small, only 250 lines
of code or so. And many of those lines deal with pretty-printing, and
other non-performance related tasks. Additionally, it works in the
plain IO monad. It does not use conduits, enumerators, pipes, or even
lazy IO. As, a result, it should be very easy to understand, profile,
and benchmark.

In providing such a simple environment and avoiding as much extra work
as possible we should be able to more easily answer questions like
"Why is so much RAM required?", "What is limiting the number of
connections per second", etc.

As we address these issues in acme-http, we can hopefully bring
solutions back to practical frameworks, or to the underlying GHC
implementation itself.

If performance tuning is your thing, I invite you to check out
acme-http and see if you can raise the limit even higher!

- jeremy

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

Re: [Haskell-cafe] ANN: Happstack 7

[Jeremy Shaw]

On Fri, Mar 30, 2012 at 4:36 AM, Lennart Kolmodin wrote:


> Congratulations to the new release, and may I say that the homepage looks
> smashing! :D
>

Thanks!


> Before I saw happstack-wai I had a quick look at the happstack API and saw
> that the Request keeps the request body as a (lazy?) String.
>

Hmm. I am not sure what you are referring to.

Looking a the Request type:

http://www.happstack.com/docs/happstack-server-7.0.0/doc/html/happstack-server/Happstack-Server-Types.html#t:Request

we see that the rqBody as the type:

rqBody :: MVar RqBody

and RqBody is defined as:

newtype RqBody = Body { unBody :: L.ByteString } deriving
(Read,Show,Typeable)

So, it is, as you would expect, a lazy ByteString. RqData is defined as a
ByteString in HAppS as well.. so it is always been that way in Happstack.

The MVar is there so that you can process the request body as it streams
over the network and have it garbage collected as you go. For example, when
saving a file upload to disk, the whole file does not get sucked into RAM.

There are other places in happstack-server where we use String instead of
ByteString or Text. That is mostly because happstack was started back in
2004. So, I am pretty sure it predates the existence of ByteString, and it
is definitely older than Text.

Most places that should be a ByteString have been updated. Not all places
that could be Text are yet. We will see more modernization in that area in
Happstack 8.

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

[Haskell-cafe] ANN: Happstack 7

[Jeremy Shaw]

We are pleased to announce the  release of Happstack 7!

Happstack is a fast, modern, web application framework written in Haskell.
Please check out the brand new happstack.com website to read about what is
new in Happstack 7, and what we are planning for Happstack 8, and what
makes Happstack great!

http://www.happstack.com/

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

Re: [Haskell-cafe] Happstack routing + boomerang + non-ascii urls

[Jeremy Shaw]

This should be fixed in happstack-server-6.6.5. You will need to rebuild
web-routes-happstack as well to get the changes.

Let me know if it works for you! Here is my test app:

http://hpaste.org/66072

- jeremy

On Tue, Mar 27, 2012 at 8:17 AM, Semen Trygubenko  wrote:

> Dear Haskell-Cafe,
>
> Last weekend I was test driving Web.Routes.Boomerang. A
> great package … Is there any way I could make it work with
> urls containing non-ASCII characters?
>
> Happstack.Server routing using "path" handles non-ASCII,
> as in, for instance,
>
> dir "work" $ path $ workHandler ,
>
> where workHandler gets a correctly decoded path segment
> passed in as a String. The following, however,
>
> sitemap :: Router Sitemap
> sitemap = (
>rWork . anyString
> )
>
> passes to Work constructor an incorrectly decoded String.
>
> All the plumbing re embedding boomerang route into a normal
> Happstack one, etc. is done as per example from crash course
> here:
>
> http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang
>
> Many thanks,
>
> Sem
>
> --
> Семен Тригубенко
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk9xvgEACgkQ3zbainCY8elq4QCeKIM8I3YDCIAKqWgMPtlRkO8W
> NuYAnjTVpzUSdHwUKNLzczuo4yAPGi1H
> =iQjy
> -END PGP SIGNATURE-
>
> ___
> 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] Happstack routing + boomerang + non-ascii urls

[Jeremy Shaw]

That is concerning and mysterious.

In Web.Routes.Happstack we do:

>let f   = runSite (domain `Text.append` approot) siteSpec (map
Text.pack $ rqPaths rq)

so, boomerang should be using the properly decoded rqPaths from the
Happstack Request. Not sure where things are going wrong. I'll look at it
soon, when I get a chance.

- jeremy

On Tue, Mar 27, 2012 at 8:17 AM, Semen Trygubenko  wrote:

> Dear Haskell-Cafe,
>
> Last weekend I was test driving Web.Routes.Boomerang. A
> great package … Is there any way I could make it work with
> urls containing non-ASCII characters?
>
> Happstack.Server routing using "path" handles non-ASCII,
> as in, for instance,
>
> dir "work" $ path $ workHandler ,
>
> where workHandler gets a correctly decoded path segment
> passed in as a String. The following, however,
>
> sitemap :: Router Sitemap
> sitemap = (
>rWork . anyString
> )
>
> passes to Work constructor an incorrectly decoded String.
>
> All the plumbing re embedding boomerang route into a normal
> Happstack one, etc. is done as per example from crash course
> here:
>
> http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang
>
> Many thanks,
>
> Sem
>
> --
> Семен Тригубенко
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk9xvgEACgkQ3zbainCY8elq4QCeKIM8I3YDCIAKqWgMPtlRkO8W
> NuYAnjTVpzUSdHwUKNLzczuo4yAPGi1H
> =iQjy
> -END PGP SIGNATURE-
>
> ___
> 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] GSoC project ideas for web technology

[Jeremy Shaw]

Hello,

If you are looking for some ideas for a GSoC project, I have written down
some web technology related projects I would like to see.

So far I mostly have ideas for improvements to HSX (a templating solution)
and acid-state (a pure, haskell persistent datastore). Both these
technologies can be used with any Haskell web framework (though they are
embraced most fully by Happstack).

http://code.google.com/p/happstack/wiki/GoogleSummerOfCode

I am an officially registered Haskell GSoC mentor. I am happy to help
expand any of these ideas into a genuine GSoC proposal and to act as a
mentor on the project. If you have other ideas you wish to pitch, I am
happy to hear those as well.

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

Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?

[Jeremy Shaw]

Argh. Email fail.

Hopefully this time I have managed to reply-all to the list *and* keep the
unicode properly intact.

Sorry about any duplicates you may have received.

On Sun, Mar 11, 2012 at 1:33 PM, Jason Dusek  wrote:

> 2012/3/11 Jeremy Shaw :
> > Also, URIs are not defined in terms of octets.. but in terms
> > of characters.  If you write a URI down on a piece of paper --
> > what octets are you using?  None.. it's some scribbles on a
> > paper. It is the characters that are important, not the bit
> > representation.
>


To quote RFC1738:

   URLs are sequences of characters, i.e., letters, digits, and special
   characters. A URLs may be represented in a variety of ways: e.g., ink
   on paper, or a sequence of octets in a coded character set. The
   interpretation of a URL depends only on the identity of the
   characters used.


Well, to quote one example from RFC 3986:
>
>  2.1.  Percent-Encoding
>
>   A percent-encoding mechanism is used to represent a data octet in a
>   component when that octet's corresponding character is outside the
>   allowed set or is being used as a delimiter of, or within, the
>   component.
>

Right. This describes how to convert an octet into a sequence of
characters, since the only thing that can appear in a URI is sequences of
characters.


> The syntax of URIs is a mechanism for describing data octets,
> not Unicode code points. It is at variance to describe URIs in
> terms of Unicode code points.


Not sure what you mean by this. As the RFC says, a URI is defined entirely
by the identity of the characters that are used. There is definitely no
single, correct byte sequence for representing a URI. If I give you a
sequence of bytes and tell you it is a URI, the only way to decode it is to
first know what encoding the byte sequence represents.. ascii, utf-16, etc.
Once you have decoded the byte sequence into a sequence of characters, only
then can you parse the URI.


> > If you render a URI in a utf-8 encoded document versus a
> > utf-16 encoded document.. the octets will be diffiFor example, let's say
> that we have a unicode string and we want to use it in the URI path.
>
> > the meaning will be the same. Because it is the characters
> > that are important. For a URI Text would be a more compact
> > representation than String.. but ByteString is a bit dodgy
> > since it is not well defined what those bytes represent.
> > (though if you use a newtype wrapper around ByteString to
> > declare that it is Ascii, then that would be fine).
>
> This is all fine well and good for what a URI is parsed from
> and what it is serialized too; but once parsed, the major
> components of a URI are all octets, pure and simple.
>

Not quite. We can not, for example, change uriPath to be a ByteString and
decode any percent encoded characters for the user, because that would
change the meaning of the path and break applications.

For example, let's say we have the path segments ["foo", "bar/baz"] and we
wish to use them in the path info of a URI. Because / is a special
character it must be percent encoded as %2F. So, the path info for the url
would be:

 foo/bar%2Fbaz

If we had the path segments, ["foo","bar","baz"], however that would be
encoded as:

 foo/bar/baz

Now let's look at decoding the path. If we simple decode the percent
encoded characters and give the user a ByteString then both urls will
decode to:

 pack "foo/bar/baz"

Which is incorrect. ["foo", "bar/baz"] and ["foo","bar","baz"] represent
different paths. The percent encoding there is required to distinguish
between to two unique paths.

Let's look at another example, Let's say we want to encode the path
segments:

 ["I❤λ"]

How do we do that?

Well.. the RFCs do not mandate a specific way. While a URL is a sequence of
characters -- the set of allow characters in pretty restricted. So, we must
use some application specific way to transform that string into something
that is allowed in a uri path. We could do it by converting all characters
to their unicode character numbers like:

 "u73u2764u03BB"

Since the string now only contains acceptable characters, we can easily
convert it to a valid uri path. Later when someone requests that url, our
application can convert it back to a unicode character sequence.

Of course, no one actually uses that method. The commonly used (and I
believe, officially endorsed, but not required) method is a bit more
complicated.

 1. first we take the string "I❤λ" and utf-8 encoded it to get a octet
sequence:

   49 e2 9d a4 ce bb

 2. next we percent encode the bytes to get *back* to a character sequence
(such as a String, Text, or Ascii)

 "I%E2%9D%A4%CE%BB"

So, that i

Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?

[Jeremy Shaw]

On Sun, Mar 11, 2012 at 1:33 PM, Jason Dusek  wrote:

> 2012/3/11 Jeremy Shaw :
> > Also, URIs are not defined in terms of octets.. but in terms
> > of characters.  If you write a URI down on a piece of paper --
> > what octets are you using?  None.. it's some scribbles on a
> > paper. It is the characters that are important, not the bit
> > representation.
>


To quote RFC1738:

   URLs are sequences of characters, i.e., letters, digits, and special
   characters. A URLs may be represented in a variety of ways: e.g., ink
   on paper, or a sequence of octets in a coded character set. The
   interpretation of a URL depends only on the identity of the
   characters used.


Well, to quote one example from RFC 3986:
>
>  2.1.  Percent-Encoding
>
>   A percent-encoding mechanism is used to represent a data octet in a
>   component when that octet's corresponding character is outside the
>   allowed set or is being used as a delimiter of, or within, the
>   component.
>

Right. This describes how to convert an octet into a sequence of
characters, since the only thing that can appear in a URI is sequences of
characters.


> The syntax of URIs is a mechanism for describing data octets,
> not Unicode code points. It is at variance to describe URIs in
> terms of Unicode code points.


Not sure what you mean by this. As the RFC says, a URI is defined entirely
by the identity of the characters that are used. There is definitely no
single, correct byte sequence for representing a URI. If I give you a
sequence of bytes and tell you it is a URI, the only way to decode it is to
first know what encoding the byte sequence represents.. ascii, utf-16, etc.
Once you have decoded the byte sequence into a sequence of characters, only
then can you parse the URI.


> > If you render a URI in a utf-8 encoded document versus a
> > utf-16 encoded document.. the octets will be diffiFor example, let's sa=
y
> that we have a unicode string and we want to use it in the URI path.
>
> > the meaning will be the same. Because it is the characters
> > that are important. For a URI Text would be a more compact
> > representation than String.. but ByteString is a bit dodgy
> > since it is not well defined what those bytes represent.
> > (though if you use a newtype wrapper around ByteString to
> > declare that it is Ascii, then that would be fine).
>
> This is all fine well and good for what a URI is parsed from
> and what it is serialized too; but once parsed, the major
> components of a URI are all octets, pure and simple.


Not quite. We can not, for example, change uriPath to be a ByteString and
decode any percent encoded characters for the user, because that would
change the meaning of the path and break applications.

For example, let's say we have the path segments ["foo", "bar/baz"] and we
wish to use them in the path info of a URI. Because / is a special
character it must be percent encoded as %2F. So, the path info for the url
would be:

 foo/bar%2Fbaz

If we had the path segments, ["foo","bar","baz"], however that would be
encoded as:

 foo/bar/baz

Now let's look at decoding the path. If we simple decode the percent
encoded characters and give the user a ByteString then both urls will
decode to:

 pack "foo/bar/baz"

Which is incorrect. ["foo", "bar/baz"] and ["foo","bar","baz"] represent
different paths. The percent encoding there is required to distinguish
between to two unique paths.

Let's look at another example, Let's say we want to encode the path
segments:

 ["I=E2=9D=A4=CE=BB"]

How do we do that?

Well.. the RFCs do not mandate a specific way. While a URL is a sequence of
characters -- the set of allow characters in pretty restricted. So, we must
use some application specific way to transform that string into something
that is allowed in a uri path. We could do it by converting all characters
to their unicode character numbers like:

 "u73u2764u03BB"

Since the string now only contains acceptable characters, we can easily
convert it to a valid uri path. Later when someone requests that url, our
application can convert it back to a unicode character sequence.

Of course, no one actually uses that method. The commonly used (and I
believe, officially endorsed, but not required) method is a bit more
complicated.

 1. first we take the string "I=E2=9D=A4=CE=BB" and utf-8 encoded it to get=
 a octet
sequence:

   49 e2 9d a4 ce bb

 2. next we percent encode the bytes to get *back* to a character sequence
(such as a String, Text, or Ascii)

 "I%E2%9D%A4%CE%BB"

So, that is character sequence that would appear in the URI. *But* we do
not yet have octets that we can transmit over the internet. We only have a
sequenc

Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?

[Jeremy Shaw]

It is mostly because those libraries are far older than Text and
ByteString, so String was the only choice at the time. Modernizing them is
good.. but would also break a lot of code. And in many core libraries, the
functions are required to have String types in order to be Haskell 98
compliant.

So, modernization is good. But also requires significant effort, and
someone willing to make that effort.

Also, URIs are not defined in terms of octets.. but in terms of characters.
If you write a URI down on a piece of paper -- what octets are you using?
None.. it's some scribbles on a paper. It is the characters that are
important, not the bit representation. If you render a URI in a utf-8
encoded document versus a utf-16 encoded document.. the octets will be
different, but the meaning will be the same. Because it is the characters
that are important. For a URI Text would be a more compact representation
than String.. but ByteString is a bit dodgy since it is not well defined
what those bytes represent. (though if you use a newtype wrapper around
ByteString to declare that it is Ascii, then that would be fine).

- jeremy

On Sat, Mar 10, 2012 at 9:24 PM, Jason Dusek  wrote:

> The content of URIs is defined in terms of octets in the RFC,
> and all Posix interfaces are byte streams and C strings, not
> character strings. Yet in Haskell, we find these objects exposed
> with String interfaces:
>
> > :info Network.URI.URI
> data URI
>  = URI {uriScheme :: String,
> uriAuthority :: Maybe URIAuth,
> uriPath :: String,
> uriQuery :: String,
> uriFragment :: String}
>-- Defined in Network.URI
>
> > :info System.Posix.Env.getEnvironment
> System.Posix.Env.getEnvironment :: IO [(String, String)]
>-- Defined in System.Posix.Env
>
> But there is no law that environment variables must be made of
> characters:
>
>  :; export x=$'\xFF' ; echo -n $x | xxd -p
>  ff
>  :; locale
>  LANG="en_US.UTF-8"
>
> That the relationship between bytes and characters can be
> confusing, both in working with UNIX and in dealing with web
> protocols, is undeniable -- but it seems unwise to limit the
> options available to Haskell programmers in dealing with these
> systems.
>
> --
> Jason Dusek
> pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
>
> ___
> 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] Compressed Data.Map for more efficient RAM usage?

[Jeremy Shaw]

Sometimes we  want to store very large collection types in RAM -- such as a
Data.Map or Data.IxSet.

It seems like we could trade-off some speed for space savings by
compressing the values in RAM.

Lemmih has previously created compact-map:

 http://hackage.haskell.org/package/compact-map

which mightybyte used to create:

https://github.com/mightybyte/compact-ixset

compact-map converts the Haskell values to a more compact binary
representation. But could we do even better by compressing the bytestrings?

Here is a useless implementation:

http://hpaste.org/63836

That version compresses each value by itself. But, that is probably going
to be worse RAM usage, not better. I think what we really need to do is to
store a dictionary in CMap that is used to compress all the ByteString
values. That way if the same string appears in 1 entries, they can all
be compressed using the same compression code.

One question is, how much would this benefit us?

As an experiment I tried compressing one checkpoint file for real world
acid-state app that I am involved with. A checkpoint file contains binary
data that is serialized by the SafeCopy library. And it is data that is
currently store in an IxSet in RAM.

The uncompressed checkpoint file is 115MB. The compressed checkpoint file
is 26MB.

A checkpoint file probably contains more redundancy than an equivalent
compressed IxSet because in addition to the values it also includes version
tags and other easily compressed data. But, those numbers do look
promising. At the very least, they do not rule out the possibility of some
big savings.

I do not have time to explore this anymore. But I think it could be a fun
project for someone to work on. ;)

I imagine a prototype with a shared dictionary could be hacked up in a few
days. A bit more work would be required to document it, memory profile it,
etc.

If done well, we should be able to reuse the incremental compression code
in Data.Map, Data.Set, Data.IxSet, HiggsSet, and other places. But, just
focusing on Data.Map is a good start. I will create a bug in this bug
tracker that links back to this message,

http://code.google.com/p/happstack/issues/list

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

Re: [Haskell-cafe] Hackage 2 maintainership

[Jeremy Shaw]

Awesome!

I am willing to assist with any Happstack related technical problems or
questions that arise in trying to get this deployed.

- jeremy


On Mon, Feb 13, 2012 at 5:44 PM, Ben Gamari  wrote:

> Hey all,
>
> Those of you who follow the Haskell subreddit no doubt saw today's post
> regarding the status of Hackage 2. As has been said many times in the
> past, the primary blocker at this point to the adoption of Hackage 2
> appears to be the lack of an administrator.
>
> It seems to me this is a poor reason for this effort to be held
> up. Having taken a bit of time to consider, I would be willing to put in
> some effort to get things moving and would be willing to maintain the
> haskell.org Hackage 2.0 instance going forward if necessary.
>
> I currently have a running installation on my personal machine and
> things seem to be working as they should. On the whole, installation was
> quite trivial, so it seems likely that the project is indeed at a point
> where it can take real use (although a "logout" option in the web
> interface would make testing a bit easier).
>
> That being said, it would in my opinion be silly to proceed without
> fixing the Hackage trac. It was taken down earlier this year due to
> spamming[1] and it seems the recovery project has been orphaned. I would
> be willing to help with this effort, but it seems like the someone more
> familiar with the haskel.org infrastructure might be better equipped to
> handle the situation.
>
> It seems that this process will go something like this,
>  1) Bring Hackage trac back from the dead
>  2) Bring up a Hackage 2 instance along-side the existing
> hackage.haskell.org
>  3) Enlist testers
>  4) Let things simmer for a few weeks/months ensuring nothing explodes
>  5) After it's agreed that things are stable, eventually swap the
> Hackage 1 and 2 instances
>
> This will surely be a non-trivial process but I would be willing to move
> things forward.
>
> Cheers,
>
> - Ben
>
>
> [1] http://www.haskell.org/pipermail/cabal-devel/2012-January/008427.html
>
> ___
> 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] Adding Html formatting to formlets

[Jeremy Shaw]

Hello,

Formlets is deprecated in favor of digestive functors. If you have not looked 
at the digestive-functors package I highly recommend that you do. It fixes a 
lot of little issues that formlets had -- but is basically the same thing. 

The (<<<) operator is a already a standard operator in Control.Category / 
Control.Arrow. So, it is probably confusing to reuse that symbol for something 
else…

The digestive functors library defines two new operators (++>) and (<++) which 
are somewhat related to what you are trying to do. 

In HTML, the  tag is supposed to reference the 'id' of the field is it 
labeling. For example, you might have:

 Username: 

In formlets, there was no way to do that because the 'ids' are not accessible 
to the user. In digestive functors you can use the ++> operator to 'share' an 
id between to elements. That allows you to write:

label "Username :" ++>  inputText Nothing

Anyway, I would  love to see:

 a) your new combinators renamed and reimplemented for digestive-functors
 b) the type signatures of these new operators

With out the type signatures it is a bit hard to decipher what your new 
operators are actually doing..

But, I love seeing any new improvements to the formlets/digestive-functors 
concept! 

- jeremy



On Feb 2, 2012, at 6:50 PM, Alberto G. Corona wrote:

> I came across the idea that is easy to define additional operators to
> Text.FormLets for adding custom HTML formatting.
> Had anyone tried that?
> 
> 
> For example to enclose the Prod formulary in a Table using Text.XHtml
> tags. I defined additional operators <<< and <++ for enclosing and
> prepending
> Html to a formLet, respectively:
> 
>> data Prod= Prod{pname :: String, pprice :: Int}
> 
>> getProd= table <<< (
>>  Prod <$> tr <<< (td << "enter the name"  <++ td <<< getString (pname 
>> <$> mp))
>><*> tr <<< (td << "enter the price"   <++ td <<< getInt ( 
>> pprice <$> mp)))
> 
> 
> even:
> 
>> p << "paragraph" <++ getProd   ++> (more Html stuff)
> 
>  is possible
> 
> or even it is possible an operator <+>
> 
>> getProd <+> someOtherStuff
> 
> to return  Either Prod OtherStuff
> 
> 
> I did it in my own version of FormLets. So It is too heavy to put
> here a running example. It is part of a package that I will upload
> soon to hackage.
> 
> 
> 
> This also may work for embedding formLets in other haskell HTML
> formats besides Text.XHtml.
> 
> ___
> 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] Hackage down!

[Jeremy Shaw]

Mirroring is a key feature of Hackage 2. But, Hackage 2 needs more
love before it can be released. More lovers would make it go faster
though!

- jeremy

On Thu, Dec 1, 2011 at 1:36 PM, Michael Litchard  wrote:
> Does anyone know of a hackage mirror? It now occurs to me I should
> have a local mirror, it's that essential.
>
> On Thu, Dec 1, 2011 at 9:24 AM, Malcolm Wallace  
> wrote:
>> And, amusingly,  http://downforeveryoneorjustme.com/ is also down, having 
>> exceeded its Google App Engine quota.
>>
>> [ But the similarly named .org site still works, and confirms that hackage 
>> is down. ]
>>
>> Regards,
>>    Malcolm
>>
>> ___
>> 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] A Mascot

[Jeremy Shaw]

I think the artwork is nice, but I am not sure that a lamb is an
appropriate mascot for Haskell.

A mascot is supposed to represent characteristics, emotions, or
desires that a particular group of people aspire to have, be like,
etc. To outsiders, it provides a quick way to see if it might be a
group they would like to belong to, and for insiders, it helps
strengthen the bond and group identity by reminding them what they
stand for.

So far, the only justification I have noticed for why a lamb would
represent Haskell users is that there is a pun about lambda's -- which
only makes sense if you know English. Sheep are generally thought of
as:

 - weak and needing protection
 - easily lead astray
 - being lead to the slaughter
 - dumb and easily lost

Not sure those are traits that Haskeller's generally aspire to have.

I think Haskeller's like Haskell because it is:

 - elegant
 - sophisticated
 - reliable
 - robust

Haskeller's tend to be people who are curious. Pioneers who are
willing to go off the beaten path in search of something better.
People who are willing to evaluate something based on its merits
rather than the mere approval of the mainstream. People who aspire to
create elegant, beautiful code. People looking to better their skills,
even if they don't use Haskell for most of their coding. And there is
definitely a pragmatic aspect. Part of the appeal of Haskell is that
it can actually be used for many real world applications and can often
do the job better. The fact that you can use it to deliver more
reliable and robust code in less time, is a very real and tangible
benefit.

Here are some suggestions of my own. I am not really excited about any
of them either -- but they give some examples of how I think a mascot
might work:

 - owl: traditionally thought of as 'wise'. Known for their keen
(in)sight. Of course, some cultures believe they are a bad omen and a
sign of impending death..

 - honey badger - can't beat that for 'robust' and 'fearless',
http://www.youtube.com/watch?v=wPKlryXwmXk

 - james bond - he's sophisticated, reliable, and he does it with
'class'. hahah, more silly puns :p Of course, he is also not public
domain :) Plus, it is too male oriented.

In summary, a mascot is supposed to elicit an emotional response from
people and help create a bond. To do that, it needs to provide
emotional leadership and say that, "if you use Haskell, you can be
like X". That doesn't it mean it can't be cute. People do tend to bond
easily to cute things (like kittens!). But I don't think cute is
enough. I also don't think that representing 'features' of Haskell,
like 'laziness' or 'higher order' is the right core appeal either.
That is too mental -- not enough emotion. Those things can, of course,
be represented in the depiction of the mascot. Nothing wrong with
cleverly hiding lamba's and _|_ in the picture. But, for example,
saying that Haskell is 'lazy' so we should pick a sloth, is not really
a good choice, IMO.

- jeremy



On Tue, Nov 15, 2011 at 7:01 PM, heathmatlock  wrote:
> I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent
> the past hour making this:
> http://i.imgur.com/Mib6Q.png
>
> What do you think?
>
> --
> Heath Matlock
> +1 256 274 4225
>
> ___
> 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] A Mascot

[Jeremy Shaw]

I thought we already had a mascot?

http://www.haskell.org/pipermail/haskell/attachments/20090401/9fb8fa05/haskell-mascot.jpg

:p

- jeremy

On Tue, Nov 15, 2011 at 7:01 PM, heathmatlock  wrote:
> I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent
> the past hour making this:
> http://i.imgur.com/Mib6Q.png
>
> What do you think?
>
> --
> Heath Matlock
> +1 256 274 4225
>
> ___
> 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] happstack file serving

[Jeremy Shaw]

On Tue, Nov 1, 2011 at 9:48 AM, Gary Klindt  wrote:
> Hello all,
>
> I want to have a web application using one 'index.html' file with ajax
> requests and a happstack web server which response to server requests.
> For that purpose I need to use some javascript libraries in my directory
> tree. I tried:
>
> main = simpleHTTP nullConf $ msum [ serveFile (asContentType "text/html")
> "index.html"
>                                  , serveFile (asContentType
> "text/javascript") "javascript/js.js" ]

As you discovered, serveDirectory is what you probably want. But,
let's say you really want to use serveFile for some reason.

The problem with  your code is that each of those lines will response
to *any* incoming request. You really want the first line to only
respond to requests for /index.html and the second to only respond to
requests for "/javascript/js.js". So you would need to rewrite you
code like:

 simpleHTTP nullConf msum $
   [ dir "index.html" $ serveFile (asContentType "text/html;
charset=UTF-8") "index.html"
   , dir "javascript" $ dir "js.js" $ serveFile (asContentType
"text/javascript") "javascript/js.js"
   ]

That would allow you to request /index.html vs javascript/js.js. Now,
obviously it is annoying to have to specify the names of the files
twice. But that is because serveFile is not really intended to be used
that way.

serveFile is typically used when the name of the file in the request
is different from the name of the file on the disk. For example, let's
say we have an image gallery. When people upload images, they might
have very common names like DSC_0123.jpg. So, we might get file
collisions if we tried to use the original file name to store the
file. Instead, we might rename the file to same unique name that we
know won't have any collisions. But, we might have the url be
something like, /image/theuniqueid/DSC_0123.jpg. That way when someone
downloads the file, their original file name is still intact. That
means we need some way to serve a file from the disk where the name of
the file on the disk is not the same of the name of the file in the
URL.

For that scheme we would have something like:

dir "image" $
 path $ \uniqueid ->
  anyPath $
do locationOnDisk <- lookupDiskLocation uniqueId
serveFile guessContentTypeM locationOnDisk

where "lookDiskLocation" is some application specific function.

- jeremy

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

Re: [Haskell-cafe] Persistent Concurrent Data Structures

[Jeremy Shaw]

If I have a list [a], and I want to make that persistence, then I have
to have some way to serialize values of type 'a'. If I then modify my
type, then the serialized structure will be out of sync with the new
version of the type -- so I will need some sort of migration feature.

safecopy addresses both the issues of serializing the data and
migrating it when the datastructure changes:

http://hackage.haskell.org/package/safecopy

You should definitely consider using that.

When it comes to concurrency.. my big question is how do you plan to
deal with transaction boundaries / atomicness.

For example, if each function (like, filter, map, etc) is atomic. That
doesn't mean you have something atomic when you do:

 filter pred =<< map f l

something could sneak in between the 'map' and the 'filter'.

An obviously solution would be to do something like:

 transaction $ filter pred =<< map f l

Which could mean that the datastore would have to be locked until that
entire operation is done?

Also.. what does it mean to have a 'persistent list'. In that example,
is map destructive? Does it modify the list ? Or does it produce a new
list?

A somewhat related system is, of course, acid-state (formerly happstack-state).

The solution there is pretty simple, and somewhat more flexible. To
write code you basically just use the State monad. You can store just
about any types you want and use just about any functions you want. To
get and update the state you just use get/set.

simpleTransaction
  do l <- get
  let l' = filter pred (map f l)
  put l'
  return l'

That updates the list and returns the modified list as well.

To make that into a transaction we use a bit of template-haskell to
mark it is a transaction

$(makeAcidic ''MyDatabase ['simpleTransaction])

The appeal of this solution is that you are not limited to just a List
or Map or whatever types people have bother to import into the system.
If you decide you want to use Data.Tree you need only do:

$(deriveSafeCopy 1 'base ''Tree)

And now you can use it persistently and concurrently as well. You do
not have to recreate every function in Data.Tree.

Still, I can see the appeal of just being able to import NData.Map,
deriving a serialize instance for your data, and start writing very
normal looking code. There is something very nice about just being
able to use a function like 'transaction' to mark the boundaries of a
transaction rather than having to give the transaction and name and
call some template haskell function.

Using acid-state, it would be very easy to implement a persistent
version of Data.Map where each function is atomic. However, there is
currently no way to group multiple events into a single transaction.
Though I think I can imagine how to add such a feature. Of course, the
idea of having a big lock blocking everything is not very appealing.
But as an experimental fork it could be interesting..

But, first I would like to hear more about how you imagined
transactions would actually work in the first place..

The big issue I see is that transactions can be a real performance
problem. If I write code for a Map-like persistent structure:

 transaction $ do v <- lookup "key" pmap
 v' <- doSomethingExpensive v
 insert v pmap

That is going to really lock things up, since nothing else can happen
while that transaction is running?

Still, it sounds interesting.. just not easy :)

I would definitely encourage you to consider safecopy at the very
least. It is completely independent of acid-state. It is simply a fast
versioned data serialization library.

- jeremy



On Tue, Nov 1, 2011 at 5:31 PM, dokondr  wrote:
> Hi,
> Please comment on the idea and advise on steps to implement it.
> Real world applications need persistent data, that can be accessed and
> modified concurrently by several clients, in a way that preserves
> "happen-before" relationship.
> Idea: Design and implement Persistent Concurrent Data Types in Haskell.
> These data types should mirror existing Data.List , Data.Map and similar
> types but provide persistency and support consistent concurrent access and
> modification (or simply - "concurrency").
> Persistency and concurrency should be configurable through these type
> interfaces. Configuration should include:
> 1) Media to persist data, such as file, DBMS, external key-value store (for
> example Amazon SimpleDB, CouchDB, MongoDB, Redis, etc)
> 2) Caching policy - when (on what events) and how much data to read/write
> from/to persistent media. Media reads / writes can be done asynchronously in
> separate threads.
> 3) Concurrency configuration: optimistic or pessimistic data locking.
>
> One may ask why encapsulate persistency and concurrency in the data type
> instead of using "native" storage API, such as for example key-value /
> row-column API that  NoSQL databases provide?
> The answer is simple: APIs that your code use greatly influence the code
> itself. Using lo

[Haskell-cafe] ANN: ircbot 0.1.1

[Jeremy Shaw]

Hello,

I have just released a new library on hackage called ircbot. (Because  
that is what Haskell really needs -- another irc bot library).


http://hackage.haskell.org/package/ircbot

A demo app is here:

http://patch-tag.com/r/stepcut/ircbot/snapshot/current/content/pretty/demo.hs

The demo is pretty non-thrilling. 98% of it is parsing command-line  
arguments, and then it calls a simple bot with two parts:


 pingPart - part that handles server PING/PONG requests
 dicePart - a simple part that lets you roll dice

Here is an example session:

 synthea: dice 3d4+12
 You rolled 3 4-sided dice with a +12 modifier: [1,3,4] => 20

The primary reason this library exists is that a long time ago, I  
needed a way to log the #happs channel. So I coded up a little logging  
bot using the irc library from hackage.


Then later I decided to fork the irc logging out of the happstack.com  
server itself and into a resuable irc bot library.


The library has the following features:

 1. a reconnect loop that tries really hard to make sure the bot  
notices if it is disconnected and tries to reconnect.


 2. a channel logging facility that automatically rolls over to a new  
log file every day.


 3. a BotMonad class and BotPartT monad which make it easy to create  
handlers for incoming messages:


http://patch-tag.com/r/stepcut/ircbot/snapshot/current/content/pretty/Network/IRC/Bot/BotMonad.hs

Each bot part is run in its own thread. Incoming messages are  
delivered to all the parts. That is useful because some parts, like  
the seen command, need to see every incoming message, even if they do  
not actively respond to them. Because the parts are handled by  
different threads, they do not block each other.


By default, each part is single-threaded. That is because some parts  
may need to see multiple messages and see them in the order they  
originally arrived. However, a part can easily call forkIO to handle  
each incoming Message and avoid blocking when appropriate.


 4. a wrapper that let's you use Parsec to parse an incoming message.  
It is used by the dicePart:


http://patch-tag.com/r/stepcut/ircbot/snapshot/current/content/pretty/Network/IRC/Bot/Part/Dice.hs

Using parsec gives you an easy way to specify syntax errors:

  synthea: dice
 unexpected end of input; expecting dice dsides>[+]


Future work:

1. The library is based around the old String based irc library. Would  
be nice to upgrade to something that used ByteStrings+Text+Builder.  
Practically speaking.. it's IRC. The maximum line length is 510  
characters, and the bot typically needs to handle, at most, a few  
messages per second. So, space and time issues would only be a  
practical concern if your bot is joining hundreds of channels. But,  
that is no excused not to use Text :) Perhaps the fastirc library?


2. The channel logging feature needs some minor changes so that more  
than one channel at a time can be logged


3. the bot needs to do something sane if the nick it wants is already  
in use. It should also support nick registration.


4. needs automatic help text generation

5. documentation

6. It should be possible to support dynamically reloadable plugins.  
Most of the technology exists in happstack-plugins + plugins. We just  
need to finish splitting happstack-plugins into two packages.


7. clustering support. ircbot does not have any built-in persistent  
storage. It should work fine with acid-state, SQL, etc. When acid- 
state gets multimaster replication support, it would be nice if there  
was an automatic failover system. Basically, you could have two or  
more bots in the channel using acid-state replication. Queries would  
normally be answered by the primary bot, but if the primary bot goes  
offline, the secondary bot could answer the queries instead.


8. windows support - the channel logging feature uses the unix  
package, which is not supported on Windows. The rest of the code is  
already portable.


Anyway. Enjoy!

- Jeremy


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

[Haskell-cafe] I for one welcome our new Robotic Overlords

[Jeremy Shaw]

When the robots take over, do you want them to be developed using a  
sane language like Haskell or Agda? Or some dangerous untyped OO  
language? I think the answer is obvious.


The question is, "How?". The robots will not be developed by us, but  
by the children of today. So, we must reach their pure minds before  
they have been unsafely coerced by the evil unbelievers who do not  
worship the gods λ, Π, and ω.


My long term vision is:

A company which produces an extensible robotics platform for children  
and adults ages 8 and up. The platform would be very open, extensible,  
and hackable.


The robotic programming languages would be based around concepts like  
functional reactive programming, dependent types, etc.


Children would begin with a simple FRP language to control the robot.  
They would solve simple problems like "go forward until an object is  
encountered." As the young masters grow, they can tackle more  
difficult problems such as maze solving. Even later they can delve  
into more advanced subjects like computer vision, speech recognition  
and synthesis, or mind control rays.


The short term vision can be summarized in one word "leverage".

We need to find an existing robotic platform which can be easily  
targeted somehow using Haskell or Agda. Perhaps something that can be  
targeted using atom or lava? Maybe something Arduino based?


I have created a wiki page here to record your suggestions and ideas:

http://haskell.org/haskellwiki/RoboticOverlords

The requirements now are something that is:

 - hackable/open
 - easily obtained
 - reasonable in price
 - can easily be targeted via Haskell

The only candidate I know of so far is lego mindstorms via the NXT  
package on hackage, Though some could argue that lego mindstorms are  
not reasonably priced.


http://hackage.haskell.org/package/NXT

Let's here your ideas!
- jeremy



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

Re: [Haskell-cafe] New releases and BSD3 license

[Jeremy Shaw]

Awesome!

I believe MissingH includes some code that I contributed (or used to).
That can all be licensed BSD3.

- jeremy

On Wed, Aug 10, 2011 at 2:14 PM, John Goerzen  wrote:
> Hello,
>
> I would like to announce new versions of the following:
>
> hslogger
> convertible
> HDBC
> HDBC-odbc
> HDBC-postgresql
> HDBC-sqlite3
>
> By popular, insistent, persistent, and patient request , all have been
> relicensed under the 3-clause BSD license.  I am also working to make that
> happen with MissingH, but have to receive permission from a few third
> parties first.
>
> Additionally, this will be my last upload of the HDBC* packages. Nicolas Wu
> has kindly agreed to step in as HDBC maintainer.  Nicolas has recently
> contributed a lot of good things towards HDBC and has more time to maintain
> it than I do.
>
> Thanks,
>
> -- John Goerzen
>
> ___
> 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] [Haskell] ANN: boomerang and web-routes-boomerang

[Jeremy Shaw]

Nope. It is not related.

It is also not related to the GSM library:

http://www.programmersheaven.com/download/29760/download.aspx

or the decompiler:

http://boomerang.sourceforge.net/index.php

Perhaps picking an original name would have been a wise choice. But it
was the only I idea I had :)

I am only inclined to change it if there is a strong chance of people
wanting to use the boomerang name on hackage to refer to something
related to the harmony boomerang project..

- jeremy

On Thu, Jul 21, 2011 at 1:55 PM, Janis Voigtländer
 wrote:
> Am 21.07.2011 20:45, schrieb Jeremy Shaw:
>>
>> Hello,
>>
>> I am pleased to announce the release of two new libraries: boomerang
>> and web-routes-boomerang.
>
> Does this have anything to do with:
>
> "Boomerang: A bidirectional programming language for ad-hoc data"
> http://www.seas.upenn.edu/~harmony/
>
> ?
>
> If not, is it wise to name it thus?
>
> Wondering,
> Janis.
>
> --
> Jun.-Prof. Dr. Janis Voigtländer
> http://www.iai.uni-bonn.de/~jv/
> mailto:j...@iai.uni-bonn.de
>

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

[Haskell-cafe] ANN: boomerang and web-routes-boomerang

[Jeremy Shaw]

Hello,

I am pleased to announce the release of two new libraries: boomerang
and web-routes-boomerang.

boomerang is a library for general purpose, invertible parsing and
pretty printing. It provides combinators which allow you to specify a
grammar once and automatically extract a parser and pretty-printer
from it. This library was refactored, with permission, from the Zwaluw
library created by Sjoerd Visscher and Martijn van Steenbergen.

hackage: http://hackage.haskell.org/package/boomerang
quick intro: 
http://hackage.haskell.org/packages/archive/boomerang/1.0.0/doc/html/Text-Boomerang.html

web-route-boomerang provides glue code for using boomerang with
web-routes. web-routes is a framework-independent, type-safe, url
routing library.

hackage: http://hackage.haskell.org/package/web-routes-boomerang
tutorial: 
http://happstack.com/docs/crashcourse/WebRoutes.html#web-routes-boomerang

- jeremy

p.s. boomerang is similar in purpose to the inveritble-syntax library:

http://hackage.haskell.org/package/invertible-syntax

The libraries take different approaches and are both worth considering.

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

Re: [Haskell-cafe] Binary and Serialize classes

[Jeremy Shaw]

Hello,

You might consider using safecopy, which explicitly supports the case
where the serialization format or the datastructure itself changes and
the data needs to be migrated to the new format?

http://acid-state.seize.it/safecopy

- jeremy

On Thu, Apr 28, 2011 at 10:00 AM, Evan Laforge  wrote:
> It's been remarked to me that relying on the Binary and Serialize
> classes is dangerous, because there's no guarantee they won't maintain
> a consistent format.  So if my app uses the Serialize instances that
> come with cereal, it could suddenly fail to read old saves after an
> upgrade to cereal.
>
> However, neither binary nor cereal expose the underlying serialization
> algorithms for various types except through the instances, so I would
> have to copy and paste the code over if I want control over it.  If I
> don't trust 'instance Serialize String' to not change behind my back,
> maybe I could at least trust 'Data.Serialize.stringToUtf8' to not
> change since if it did the name would now be wrong.
>
> Are these fears justified?  I imagine if the Int instance for
> Serialize changed there would be an uproar and it would probably have
> to be changed back.  I sent a bug to the maintainers of data-binary a
> long time ago about the Double instance not serializing -0, and they
> ignored it, probably because it would be bad to change the instance.
> So can I use the included instances without fear of them changing
> between releases?  Of course I still run the risk of an instance from
> some other package changing, but I'm less likely to be using those.

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

Re: [Haskell-cafe] Light and fast http server

[Jeremy Shaw]

On Mar 11, 2011, at 4:39 PM, Victor Oliveira wrote:


Hi cafe,

There are a lot of http servers in hackage. I didn't have used none.
I would like to know if one of them is something closer of the nginx.
I need some light and fast. It don't need support all http, just the  
basics is fine.

Suggestions?


What do you mean by 'the basics'?

happstack, yesod, and snap are all frameworks for building web  
applications.


But it sounds like you are just looking for a web server to server  
static content for the disk? If so, what is the advantage you hope to  
get by using Haskell over nginx ?


Any of the high-level frameworks can server static content pretty  
trivially. For example in Happstack you would just do:


> module Main where
>
> import Happstack.Server (Browsing(EnableBrowsing), nullConf,  
serveDirectory, simpleHTTP)

>
> main :: IO ()
> main = simpleHTTP nullConf $ serveDirectory EnableBrowsing [] "."
To serve files from the current directly.
If that is all you really need, then I would probably recommend warp +  
wai-app-static,

http://hackage.haskell.org/package/wai-app-static
Warp is pretty darn fast. Though, in practice I think you will find  
that all of the frameworks/servers are going to have very similar  
results for serving static files since they all call sendfile() to do  
the bulk of the transfer.
If you are looking for other features, then you need to say what those  
features are..

- jeremy


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

[Haskell-cafe] Haskell Web Framework Happstack 6 Released

[Jeremy Shaw]

r-haskell-based-templates.html 
)

 - directory browsing when using serveDirectory

And numerous other improvements including enhancements to IxSet, file  
locking, and much more.


Bigger, Better Version Number
-

We have also upgraded our version numbers! We have decided to call  
this release Happstack 6.0 instead of Happstack 0.6. There are two  
reasons for this:


 1. the amount of changes we are making really do represent a new  
major release
 2. it will make it easier to comply with the Haskell package version  
policy.


Now that Happstack 6 is out, we plan to make more frequent releases.  
The new version scheme will allow us to talk about the next major  
release (Happstack 7), but still put out changes to Happstack 6 which  
change the API (aka, Happstack 6.2, etc).


GHC 7 - mostly
--

Happstack mostly works with GHC 7. Due to some compiler bugs, HSP does  
not work with GHC 7.0.1. These bugs were reported and are fixed in the  
upcoming GHC 7.0.2 release. If you are not using the optional  
happstack-hsp package, then GHC 7 is fine. If you are using happstack- 
hsp, then you will need to use GHC 6.12, a recent version of GHC from  
darcs, or wait until GHC 7.0.2 comes out.


The Future
==

The current future plan looks like this:

Happstack 7
---

The next major release of Happstack will be Happstack 7. The primary  
focus of Happstack 7 will be improving happstack-state (also known as  
MACID). Big features include:


 - sharding support
 - a rewrite of IxSet based on kdtrees with much better RAM and CPU  
performance

 - performance testing to show how awesome MACID is
 - much better documentation and examples
 - better tools for examining and modifying state in running  
applications


There are also a bunch of lower-level API improvements planned which  
should make it nicer to use happstack-state.


Happstack 8
---

Happstack 8 will finally feature an enumerator-based HTTP backend.  
This is a feature we have been hoping to add since January of 2009.


http://code.google.com/p/happstack/issues/detail?id=29

Rather than develop a competing HTTP backend, Happstack will put its  
efforts into improving an existing HTTP backend. We currently have our  
eye on WAI/warp. However, we will also consider snap and hyena when  
the time comes.


It should be noted that the current lazy I/O based backend is not the  
relentless nightmare of space leaks that some people might lead you to  
believe it is. The current happstack-server can easily handle uploads  
and downloads of large or streaming files with out leaks. But,  
enumerators *are* nice.


How You can Help


You are encouraged to get involved in Happstack. The easiest way to  
get involved is to complain about how horrible Happstack is. If you  
don't voice your complaints, then we might not know something things  
to be fixed.


If you are looking to make code contributions, please feel free to ask  
on #happs or the mailing list. There are tasks that are easy for  
novices, tasks that are worthy of a Ph.D, and everything in between.  
If you want to work, we can certainly find a way to use your talents!


There are also plenty of non-coding related tasks including  
documentation, graphic design, user surveys, etc.


You are also encouraged to blog about your Happstack projects!

Thanks!
- jeremy shaw

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

Re: [Haskell-cafe] Storing passwords securely

[Jeremy Shaw]

Have you seen the PBKDF2 library?

http://hackage.haskell.org/package/PBKDF2

 Does that look like a reasonable way to store passwords securely?

- jeremy

On Feb 5, 2011, at 8:12 PM, Peter Scott wrote:

The usual advice on how to store passwords securely is "use bcrypt",  
but since there seem to be no Haskell bindings for bcrypt, the other  
good option is to iterate a salted hash function at least 1000  
times. In order for people to get this right, there should be a  
library with a really simple API that makes it Just Work. I think I  
have such an API, but I'd like to hear if anybody else has  
suggestions before I go releasing it onto Hackage. The code is here:


https://github.com/PeterScott/pwstore

The part of the API that people have to care about is two functions.  
makePassword creates a hashed, salted password that you can store in  
a database. verifyPassword takes this hashed, salted password and a  
user's password input, and tells you if it matches. Like this:


>>> makePassword (B.pack "hunter2") 12
"sha256|12|lMzlNz0XK9eiPIYPY96QCQ==|1ZJ/ 
R3qLEF0oCBVNtvNKLwZLpXPM7bLEy/Nc6QBxWro="


>>> verifyPassword (B.pack "wrong guess") passwordHash
False
>>> verifyPassword (B.pack "hunter2") passwordHash
True

There's also a function for increasing the number of hash iterations  
on stored password hashes, to compensate for Moore's law.


Does this sound reasonable? Also, I have a pure-Haskell version and  
a version which depends on some C code, for speed (about 25x  
difference). Does anybody care about the pure Haskell version, or  
should I just drop it and require the faster C/Haskell mixed version?


Thanks,
-Peter
___
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] web-routes and forms

[Jeremy Shaw]

On Wed, Jan 26, 2011 at 4:33 PM, Corentin Dupont
 wrote:

> Now turning to digestive functors, I don't see where do goes the "A.action
> actionURL" part that was in traditionnal forms?
> It seems I need it for routing the result of the form.

I think you will find formHtml is returning you the stuff that goes
inside the  tag, but does not actually include the form tag
itself ?

I am not sure how to modify the attrs using blaze-html. I think that
is a missing feature of the digestive-functors-blaze package. In
digestive-functors-hsp there is a function:


setAttrs :: (EmbedAsAttr x attr, XMLGenerator x, Monad m, Functor m) =>
Form m i e [HSX.GenXML x] a
 -> attr
 -> Form m i e [HSX.GenXML x] a
setAttrs form attrs = mapView (map (`set` attrs)) form


You probably need something similar for blaze.

- jeremy

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

Re: [Haskell-cafe] web-routes and forms

[Jeremy Shaw]

Hello,

I think you should just be able to use showURL to convert the url type
into a String that you can use with blaze-html:

data SiteURL = Post_Login | etc

loginForm :: RoutedNomicServer Html
loginForm = do
   actionURL <- showURL Post_Login
   ok $ H.form ! A.method "POST" ! A.action actionURL ! enctype
"multipart/form-data;charset=UTF-8"  $ do
   H.label ! for "login" $ "Login"
   input ! type_ "text" ! name "login" ! A.id "login" ! tabindex
"1" !  accesskey "L"
   H.label ! for "password" $ "Password"
   input ! type_ "text" ! name "password" ! A.id "password" !
tabindex  "2" ! accesskey "P"
   input ! type_  "submit" ! tabindex "3" ! accesskey "S" ! value
"Enter Nomic!"

Using the HSP stuff you can avoid the explicit call to showURL and do:

 
... 

But HSP is a fair bit more complex than blaze-html.

If blaze-html provide an HtmlT monad that was a real monad transformer
then you could do something similar using blaze. But they decided to
trade-off functionality for speed.

- jeremy

On Sat, Jan 22, 2011 at 3:19 PM, Corentin Dupont
 wrote:
> Hello Jeremy,
> Yes it would be fine to use solution 1, but I just don't figured how to mix
> web routes and forms.
>
> My forms are like that:
> loginForm :: RoutedNomicServer Html
> loginForm = do
>    ok $ H.form ! A.method "POST" ! A.action "/postLogin" ! enctype
> "multipart/form-data;charset=UTF-8"  $ do
>    H.label ! for "login" $ "Login"
>    input ! type_ "text" ! name "login" ! A.id "login" ! tabindex "1" !
> accesskey "L"
>    H.label ! for "password" $ "Password"
>    input ! type_ "text" ! name "password" ! A.id "password" ! tabindex
> "2" ! accesskey "P"
>    input ! type_  "submit" ! tabindex "3" ! accesskey "S" ! value "Enter
> Nomic!"
>
> And are decoded using a FromData:
>
> instance FromData LoginPass where
>   fromData = do
>     login  <- look "login" `mplus` (error "need login")
>     password <- look "password" `mplus` (error "need password")
>     return $ LoginPass login password
>
> How this can go inside web routes? I cannot pass the parameters in the URL
> (here login and password), can I?
>
> Thanks,
> Corentin
>
> On Sat, Jan 22, 2011 at 9:49 PM, Jeremy Shaw  wrote:
>>
>> Hello,
>>
>> I believe you problem is because you are trying to use 'dir' inside
>> RouteT after you have already consumed and decode the path info using
>> implSite.
>>
>> There are two solutions here:
>>
>>  1. just use web-routes for all your URLs instead of using a mixture
>> of type-safe routes and 'dir'.
>>  2. put the calls to dir outside the call to implSite.
>>
>> For example, something like,
>>
>>   simpleHTTP nullConf $ msum [ dir "Login" $ loginPage,
>>                                                , dir "postLogin" $
>> postLogin
>>                                                , implSite
>> "http://localhost:8000/"; "" (nomicSite sh)
>>                                                ]
>>
>> You to do that, you would also need to modified loginPage and
>> postLogin to not be in the RoutedNomicServer monad. Since they do not
>> appear to use the RouteT stuff anyway, that should not be hard ?
>>
>> But, personally, I would just choose option #1. Can you explain why
>> you thought it was better to mix the web-routes stuff with the 'dir'
>> style guards? Maybe there is a short coming in web-routes that needs
>> to be addressed ?
>>
>> - jeremy
>>
>> On Fri, Jan 21, 2011 at 2:33 PM, Corentin Dupont
>>  wrote:
>> > Hello Jeremy,
>> > I'm still trying to integrate web routes, but there is one thing I don't
>> > understand:
>> > how to deal with multiple forms?
>> >
>> > In my former application, each forms used to redirect to a subdirectory
>> > of
>> > the web site, and an appropriate handler was waiting there.
>> > But now with web routes I don't see how to do that.
>> > I've tried to push down the decision over subdirectories (with the guard
>> > "dir") inside the RouteT monad:
>> >
>> > type NomicServer   = Serve

[Haskell-cafe] Chicago Haskell User Group Meetup this Thursday @ 8PM

[Jeremy Shaw]

Hello,

The Chicago Haskell User Group will be meeting at the Pumping Station
One hackerspace this Thursday @ 8PM. This meeting coincides with a
regularly scheduled Haskell class at PS:One.

Among other things, we will discuss how to grow the local Chicago
Haskell user community, and a possible group project.

Haskell users of all levels (including no experience at all) are
invited to come!

Facebook Invite: http://www.facebook.com/event.php?eid=158855480832147
Pumping Station One website: http://pumpingstationone.org/
Chicago Haskell User Group Facebook Group:
http://www.facebook.com/pages/Chicago-Haskell-User-Group/115989593098
Chicago Haskell User Group Mailing List:
http://groups.google.com/group/haskell-chicago

- jeremy

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

Re: [Haskell-cafe] web-routes and forms

[Jeremy Shaw]

   H.label ! for "password" $ "Password"
>   input ! type_ "text" ! name "password" ! A.id "password" ! tabindex
> "2" ! accesskey "P"
>   input ! type_  "submit" ! tabindex "3" ! accesskey "S" ! value "Enter
> Nomic!"
>
> postLogin :: RoutedNomicServer Html
> postLogin = do
>   methodM POST -- only accept a post method
>   mbEntry <- getData -- get the data
>   case mbEntry of
>     Nothing -> error $ "error: postLogin"
>     Just (LoginPass login password)  -> do
>   mpn <- liftRouteT $ liftIO $ newPlayerWeb login password
>   case mpn of
>  Just pn -> do
>     link <- showURL $ Noop pn
>     seeOther link $ string "Redirecting..."
>  Nothing -> seeOther ("/Login?status=fail" :: String) $ string
> "Redirecting..."
>
> launchWebServer :: ServerHandle -> IO ()
> launchWebServer sh = do
>    putStrLn "Starting web server...\nTo connect, drive your browser to
> \"http://localhost:8000/Login\"";
>    simpleHTTP nullConf $ implSite "http://localhost:8000/"; "" (nomicSite sh)
>
>
> But when I drive my browser to "http://localhost:8000/Login/";, happstack
> tell me there is nothing here.
> Am I doing it right? If yes, I must have made a mistake.
> (as you can see I'm still far from putting in disgestive functors ;)
>
> If you need, the complete application can be found here (see file Web.hs):
> https://github.com/cdupont/Nomic
>
> Thanks,
> Corentin
>
> On Wed, Jan 19, 2011 at 5:12 PM, Corentin Dupont 
> wrote:
>>
>> Thanks Jeremy.
>> I had it to work now ;)
>>
>> Corentin
>>
>> On Tue, Jan 18, 2011 at 6:01 PM, Jeremy Shaw  wrote:
>>>
>>> Hello,
>>>
>>> trhsx will be installed in ~/.cabal/bin, so you will need to add that
>>> to your PATH.
>>>
>>> In order to use the demo code I provided you would need the latest
>>> happstack from darcs because it contains a few differences in the API.
>>> The code can be made to work with what is on hackage though.
>>>
>>> The submit issue is actually a bug in digestive-functors-blaze. The
>>> return type should be, Form m i e BlazeFormHtml (). jaspervdj is going
>>> to patch it and upload a new version.
>>>
>>> - jeremy
>>>
>>>
>>> On Thu, Jan 13, 2011 at 2:40 PM, Corentin Dupont
>>>  wrote:
>>> > Hello,
>>> >
>>> > I'm using the combination happstack + digestive-functors + web-routes +
>>> > blazeHTML.
>>> > I'm not finding any examples on the net...
>>> >
>>> > I've tried to adapt your example (thanks):
>>> >
>>> > type NomicForm a = HappstackForm IO String BlazeFormHtml a
>>> >
>>> > demoForm :: NomicForm (Text, Text)
>>> > demoForm =
>>> >     (,) <$> ((TDB.label "greeting: " ++> inputNonEmpty Nothing) <* br)
>>> >     <*> ((TDB.label "noun: " ++> inputNonEmpty Nothing) <* br)
>>> >     <*  (submit "submit")
>>> >     where
>>> >   br :: NomicForm ()
>>> >   br = view H.br
>>> >   -- make sure the fields are not blank, show errors in line if
>>> > they are
>>> >   inputNonEmpty :: Maybe Text -> NomicForm Text
>>> >   inputNonEmpty v =
>>> >   (inputText v `validate` (TD.check "You can not leave this
>>> > field
>>> > blank." (not . T.null)) <++ errors)
>>> >
>>> >
>>> > But I've got a problem on submit and inputText. I don't see how they
>>> > are
>>> > compatible with HappstackForm.
>>> > NomicForm a reduces to:
>>> > Form (ServerPartT IO) Input String BlazeFormHtml a
>>> >
>>> > whereas the type of submit is:
>>> >
>>> > submit :: Monad m
>>> >
>>> >        => String                            -- ^ Text on the submit
>>> > button
>>> >
>>> >        -> Form m String e BlazeFormHtml ()  -- ^ Submit button
>>> >
>>> >
>>> > Maybe I miss some instance?
>>> >
>>> > BTW, I also tried to execute your exemple, but I can't install some
>>> > packages.
>>> >
&g

Re: [Haskell-cafe] web-routes and forms

[Jeremy Shaw]

Hello,

trhsx will be installed in ~/.cabal/bin, so you will need to add that
to your PATH.

In order to use the demo code I provided you would need the latest
happstack from darcs because it contains a few differences in the API.
The code can be made to work with what is on hackage though.

The submit issue is actually a bug in digestive-functors-blaze. The
return type should be, Form m i e BlazeFormHtml (). jaspervdj is going
to patch it and upload a new version.

- jeremy


On Thu, Jan 13, 2011 at 2:40 PM, Corentin Dupont
 wrote:
> Hello,
>
> I'm using the combination happstack + digestive-functors + web-routes +
> blazeHTML.
> I'm not finding any examples on the net...
>
> I've tried to adapt your example (thanks):
>
> type NomicForm a = HappstackForm IO String BlazeFormHtml a
>
> demoForm :: NomicForm (Text, Text)
> demoForm =
>     (,) <$> ((TDB.label "greeting: " ++> inputNonEmpty Nothing) <* br)
>     <*> ((TDB.label "noun: " ++> inputNonEmpty Nothing) <* br)
>     <*  (submit "submit")
>     where
>   br :: NomicForm ()
>   br = view H.br
>   -- make sure the fields are not blank, show errors in line if they are
>   inputNonEmpty :: Maybe Text -> NomicForm Text
>   inputNonEmpty v =
>   (inputText v `validate` (TD.check "You can not leave this field
> blank." (not . T.null)) <++ errors)
>
>
> But I've got a problem on submit and inputText. I don't see how they are
> compatible with HappstackForm.
> NomicForm a reduces to:
> Form (ServerPartT IO) Input String BlazeFormHtml a
>
> whereas the type of submit is:
>
> submit :: Monad m
>
>=> String-- ^ Text on the submit button
>
>-> Form m String e BlazeFormHtml ()  -- ^ Submit button
>
>
> Maybe I miss some instance?
>
> BTW, I also tried to execute your exemple, but I can't install some
> packages.
>
>> cabal install digestive-functors-hsp
>
> cabal: Unknown build tool trhsx
>
> Whereas trhsx is in my PATH (under linux).
>
> You said I need the latest happstack from darcs, why?
>
> Cheers,
> Corentin
>
> On Sun, Jan 9, 2011 at 8:36 PM, Jeremy Shaw  wrote:
>>
>> Hello,
>>
>> newRule also needs to have the type, RoutedNomicServer. The
>> transformation of RoutedNomicServer into NomicServer is done in the
>> handleSite function. Something like this:
>>
>>
>> nomicSpec :: ServerHandle -> Site Route (ServerPartT IO Response)
>> nomicSpec sh =
>>      Site { handleSite          = \f url -> unRouteT (nomicSite sh url) f
>>             ...
>>
>> main =
>>    do ...
>>      simpleHTTP nullConf $ siteImpl (nomicSpec sh)
>>
>> Or something like that -- it's hard to tell exactly what is going on
>> in your app based on the snippets you provided.
>>
>> Also, I highly recommend using digestive functors instead of formlets.
>> It is the successor to formlets. Same core idea, better implementation
>> and actively maintained.
>>
>> I have attached a quick demo of using:
>>
>> happstack+digestive-functors+web-routes+HSP
>>
>> To use it you will need the latest happstack from darcs plus:
>>
>>  hsp
>>  web-routes
>>  web-routes-hsp
>>  web-routes-happstack
>>  web-routes-mtl
>>  digestive-functors
>>  digestive-functors-hsp
>>
>> I plan to clean up this example and document it better in the crash
>> course for the upcoming release. Clearly things like the FormInput
>> instance and the formPart function belong a library.
>>
>> let me know if you have more questions.
>> - jeremy
>>
>> On Sat, Jan 8, 2011 at 6:44 PM, Corentin Dupont
>>  wrote:
>> > Hello,
>> >
>> > I have difficulties mixing web-routes and forms:
>> > I have put routes in all my site, except for forms which remains with
>> > the
>> > type ServerPartT IO Response.
>> > How to make them work together?
>> >
>> > I have:
>> > type NomicServer         = ServerPartT IO
>> > type RoutedNomicServer = RouteT PlayerCommand NomicServer
>> >
>> > newRule :: ServerHandle -> NomicServer Response
>> > newRule sh = do
>> >    methodM POST -- only accept a post method
>> >    mbEntry <- getData -- get the data
>> >    case mbEntry of
>> >   Nothing -> error $ "error: newRule"
>> >   Just (NewRule name text code pn) -> do
>> >  html <- nomicPageComm

Re: [Haskell-cafe] Happstack events and web page refreshing

[Jeremy Shaw]

On Jan 17, 2011, at 2:19 PM, Corentin Dupont wrote:


Indeed, I tried with  ?
and it's unusable.
It make blink the page, ungrey the "stop" button for a second and  
make the fields loose the focus

so it's impossible to type in.

I'll try with XMLHTTPRequest.



Right. Using the jQuery library should make it easier to do ajax  
requests and modify the DOM on the fly,


http://jquery.com/

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

Re: [Haskell-cafe] Browser Game Engine

[Jeremy Shaw]

On Jan 16, 2011, at 9:26 PM, Tom Hawkins wrote:


I want to create a simple browser game using Haskell.  It would be
nothing complicated: basic 2D graphics, limited sound, and minimal
network traffic.

What is the recommended medium?  Flash or JavaScript+SVG?


I think your options are: flash or html5+canvas+javascript.

The must be at least a million flash games, so clearly it can be used  
for that. If you create a flash game, nobody gets excited. But if you  
create an html5 based game, then people still get excited about that.  
So, I assume it must be hard :)


For flash, you can use the free flex SDK. Flash supports bitmap and  
vector graphics, network IO and realtime audio. The runtime it  
supported almost everywhere except iOS and you pretty much only have  
to worry about supporting one version of flash.


HTML5 is trendy and cool, and can be made to do what you want. It has  
less support than flash since you need to be running a modern browser  
-- which many people are not. And you have to deal with trying to  
support multiple browsers.


So you need to decide:

 1. what technology do you want to invest in learning
 2. how important is it that people can run your game with out having  
to install a new browser

 3. how much hackery are you willing to do


Any recommended Haskell libraries for the server-side logic or client
code generation?


I have not found any way to satisfyingly generate the client-side  
code. Ultimately, it has just turned out to be easiest to write the  
client-side code in javascript/actionscript by hand.


For the server-side, it would be useful to know what sort of game  
logic is going to be run in the server itself. For many browser based  
games, the server just needs to serve static files, and apache would  
be sufficient.


In other games some of the game logic does reside on the server.

The nice way to do that would be to have some nice Haskell datatypes  
to represent the game state and then functions that get called to  
update the game state and return values to the client.


The tricky party is that you don't really want to lose the whole game  
state every time you restart the server. You could try checkpointing  
the state now and then, but that still leaves things open to data  
loss. If someone finally defeats the big boss and then you lose the  
last few minutes of the game state, they are not going to be happy.


You could keep all your state stored in a SQL database. But that just  
does not sound like a good match for game logic ?


Personally, I would recommend checking out happstack-state.

happstack-state (also known as MACID), allows you to use normal  
haskell datatypes and functions for your game state and game logic.  
But it also uses write ahead logging to ensure that every update to  
the state is logged so that you can restart the server with the state  
intact (even if the server crashed). It also provides support for  
replication across multiple servers.


There is a short tutorial here that will help you get a feel for it,

http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/


You also need an API for talking to the server from the client.

You can probably make just about any of the Haskell web servers do the  
trick. But I think happstack-server is a fine choice. The darcs  
version of happstack-server is well documented, and provides a rich,  
complete API.


For example, let's say that an api call requires you to pass three key/ 
value pairs in via the QUERY_STRING. All the web frameworks have calls  
for looking up the key/value pairs. But happstack goes beyond that and  
provides an environment which can accumulate and report all the  
missing or incorrect query parameters at once, not just the first one.  
This makes it much easier to debug your client-side code since you get  
all the errors at once -- instead of just one at a time.


(http://happstack.com/docs/crashcourse/RqData.html#rqdataerror)

Check out the crash course to get a feel for the API coverage,

http://happstack.com/docs/crashcourse/index.html

the haddock documentation in the darcs code has very good coverage.

- jeremy

p.s. The darcs code is quite stable. The main holdup is just making  
the haddock docs even better.




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

Re: [Haskell-cafe] Happstack events and web page refreshing

[Jeremy Shaw]

Hello,

The problem is that clients are not 'connected' to the web server. The  
way it works (more or less) is:


 1. client connects to server and sends a Request
 2. server sends a Response
 3. connection is terminated.

So, once the page has been loaded there is no connection between the  
web-server and the client. Hence there is no way for the server to  
send anything to the clients.


In HTML 5, there is something known as web sockets with does allow you  
to have a persistent connection to the clients. However, it does not  
yet have broad browser support. In fact, some browsers have  
temporarily removed support due to a security flaw in the design  
specification.


There are a variety of hacks collectively known as 'comet' for trying  
to create a persistent connection on top of the existing HTTP 1.1  
standard:


http://en.wikipedia.org/wiki/Comet_(programming)

That deals with trying to have the server push updates to the client.

A different approach is to have the clients pull new data from the  
server by polling the server for changes every now and then. But that  
depends on how much latency you can afford for the updates. For  
example,  if updating only once a minute is fine versus must update  
every second.


Once you decide how to get the data to the client, then you can figure  
out how to track changes to the MACID database.


- jeremy

On Jan 17, 2011, at 4:58 AM, Corentin Dupont wrote:


Hello again,
I have another question for happstack users/experts:

I have a program with happstack-state and a web server with  
happstack-server.
What I'd like is, whenever the MACID state is changed, that the web  
page is refreshed for every clients

connected on the web server.

So I think the question is 2 fold:
- How to add an event handler on happstack-state for that?
- How to ask to the web server to refresh every clients?

I did not found infos about that in the API.

Thanks a lot,
Corentin



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

Re: [Haskell-cafe] web-routes and forms

[Jeremy Shaw]

Hello,

newRule also needs to have the type, RoutedNomicServer. The
transformation of RoutedNomicServer into NomicServer is done in the
handleSite function. Something like this:


nomicSpec :: ServerHandle -> Site Route (ServerPartT IO Response)
nomicSpec sh =
  Site { handleSite  = \f url -> unRouteT (nomicSite sh url) f
 ...

main =
do ...
  simpleHTTP nullConf $ siteImpl (nomicSpec sh)

Or something like that -- it's hard to tell exactly what is going on
in your app based on the snippets you provided.

Also, I highly recommend using digestive functors instead of formlets.
It is the successor to formlets. Same core idea, better implementation
and actively maintained.

I have attached a quick demo of using:

happstack+digestive-functors+web-routes+HSP

To use it you will need the latest happstack from darcs plus:

 hsp
 web-routes
 web-routes-hsp
 web-routes-happstack
 web-routes-mtl
 digestive-functors
 digestive-functors-hsp

I plan to clean up this example and document it better in the crash
course for the upcoming release. Clearly things like the FormInput
instance and the formPart function belong a library.

let me know if you have more questions.
- jeremy

On Sat, Jan 8, 2011 at 6:44 PM, Corentin Dupont
 wrote:
> Hello,
>
> I have difficulties mixing web-routes and forms:
> I have put routes in all my site, except for forms which remains with the
> type ServerPartT IO Response.
> How to make them work together?
>
> I have:
> type NomicServer         = ServerPartT IO
> type RoutedNomicServer = RouteT PlayerCommand NomicServer
>
> newRule :: ServerHandle -> NomicServer Response
> newRule sh = do
>    methodM POST -- only accept a post method
>    mbEntry <- getData -- get the data
>    case mbEntry of
>   Nothing -> error $ "error: newRule"
>   Just (NewRule name text code pn) -> do
>  html <- nomicPageComm pn sh (submitRule name text code pn))
>  ok $ toResponse html
>
>
> nomicPageComm :: PlayerNumber -> ServerHandle -> Comm () ->
> RoutedNomicServer Html
> nomicPageComm pn sh comm =
> (..)
>
>
> launchWebServer :: ServerHandle -> IO ()
> launchWebServer sh = do
>    putStrLn "Starting web server...\nTo connect, drive your browser to
> \"http://localhost:8000/Login\"";
>    d <- liftIO getDataDir
>    simpleHTTP nullConf $ mconcat [dir "postLogin" $ postLogin,
>   fileServe [] d,
>   dir "Login" $ ok $ toResponse $ loginPage,
>   dir "NewRule" $ newRule sh,
>   dir "NewGame" $ newGameWeb sh,
>   dir "Nomic" $ do
>  html <- implSite
> "http://localhost:8000/Nomic/"; "" (nomicSite sh)
>  ok $ toResponse html
>   ]
>
>
> The red line doesn't compile. I don't know how to transform a
> RoutedNomicServer into a NomicServer.
>
> For the future I intend to use formlets: is these some examples of programs
> using happstack + web-routes + formlets?
>
> Thanks,
> Corentin
>
>
>
>
> On Fri, Jan 7, 2011 at 5:10 PM, Jeremy Shaw  wrote:
>>
>> Hello,
>>
>> The [(String, String)] argument is for adding query parameters.
>>
>> > encodePathInfo ["foo", "bar", "baz"] [("key","value")]
>>
>> "foo/bar/baz?key=value"
>>
>> Instead of showURL you would use showURLParams.
>>
>> hope this helps!d
>> - jeremy
>>
>> On Fri, Jan 7, 2011 at 8:12 AM, Corentin Dupont
>>  wrote:
>> > Hello Jeremy,
>> > I'm using Web routes with happstack.
>> > I'm following this tutorial:
>> > http://tutorialpedia.org/tutorials/Happstack+type+safe+URLs.html
>> >
>> > But It seems out of synch with the latest version of web-routes: 0.23.2.
>> > The haddock documentation seems out of date also:
>> >
>> > encodePathInfo :: [String] -> [(String, String)] -> String
>> >
>> > For example:
>> >
>> >  encodePathInfo [\"foo\", \"bar\", \"baz\"]
>> >
>> > "foo/bar/baz"
>> >
>> > And I can't figure out what this [(String, String)] is for ;)
>> >
>> > Thanks,
>> >
>> > Corentin
>> >
>
>
{-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances, PackageImports, MultiPa

Re: [Haskell-cafe] handling multiple versions of a data structure

[Jeremy Shaw]

Hello,

I'm not sure off-hand.. I think it would involve some hackery. How
long do you want to keep support for the old Show format around? If
you just want to convert some data you have right now, then you could
write some code that uses the old Show based code to read in the old
data and write it out using Serialize in the new  format.

If you want to support Show based migration for a long time -- then
that could be trickier. While serialize does  give you complete
control over how the actual data is converted to a byte stream and
back, it also assumes that there is some other meta-data involved (the
Version stuff). So the problem I see is what happens if you try to
read data from the old format which does not have that meta data..

I think what you would need to do is have your own code which detects
if the saved data is in the Show format or the Serialize format. If it
is in the Serialize format, then you just call the normal
deserialization code.

If it is in the old Show format, then you call your code to read the
old Show format. That will give you data that is in the 'old' type
that was last supported by the Show code. You would then is migrate
function from the Migrate class to migrate it to the latest type.

Does that make sense?

- jeremy


On Sun, Dec 19, 2010 at 10:58 AM, Dmitry V'yal  wrote:
> On 17.12.2010 01:09, Jeremy Shaw wrote:
>>
>> Hello,
>>
>> You should use happstack-data for this (you do not need the other
>> happstack components to use happstack-data)*. It was created to solve
>> this exact problem.
>>
>> happstack-data builds on type of the 'binary' library and adds versioned
>> data types and automatic version migration.
>
> Thanks! Looks like what I need. There is a one problem, though. I don't have
> a time machine. I mean right now I have A primitive format based on Show
> instance and I'd like to maintain the compatibility with it.
>
> Is it possible to force a particular on-disk format for a particular version
> of data type? I guess I should write a Serialize instance myself. Are there
> any pitfalls awaiting me?
>
> Best wishes,
> Dmitry
>

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

Re: [Haskell-cafe] (re)newcomer

[Jeremy Shaw]

Hello,

It looks like you are using GHC 6.10, which is now a pretty old  
version of GHC.  The latest version of the unix package on hackage  
requires a more recent version of GHC. You could try to force an older  
version of the unix library:


 cabal install happstack-server --constraints 'unix < 2.4'

But you might be better off upgrading to a newer compiler. The easiest  
way would be to install the latest haskell platform for the mac which  
includes GHC 6.12.3,


http://hackage.haskell.org/platform/mac.html

Alternatively, you could install GHC 7, which is the latest stable  
version of the compiler. happstack-server from darcs compiles against  
GHC 7. In fact, if you are planning to start new development using  
happstack, I would recommend the darcs version as it is very closed to  
being released and the documentation reflects the darcs version of the  
code.


More information on installing from darcs (which is easy) is here:

http://happstack.com/download

Hope this helps! If you have more questions I am happy to answer them!
- jeremy

p.s. The version of happstack-server on hackage was actually tested  
using GHC 6.10 and OS X, so it should be possible to get it working  
with out too much hacking if you really need GHC 6.10 for some reason.


On Dec 18, 2010, at 2:40 AM, Matthew Fairtlough wrote:


Hello Haskell-cafers,

I used to teach Haskell (and Clean!) at University level but haven't  
touched Haskell in years and certainly never used it with a Mac.   
Now I work in publishing and want to experiment with Haskell's web  
services and see if I can help set up an open-source system for  
handling ONIX xml data.


So I tried to install happstack-server (among several other things)  
and this depends on unix but cabal can't install unix.  Error and  
diagnostics below as best as I could see to report them.  Any tips/ 
pointers much appreciated; I'm not sure if this is a bug or where to  
report it if it is one...


thanks for any help. Matthew.

bash-3.2# cabal install unix
Resolving dependencies...
cabal: cannot configure unix-2.4.1.0. It requires base >=4.2 && <4.4
For the dependency on base >=4.2 && <4.4 there are these packages:
base-4.2.0.0, base-4.2.0.1, base-4.2.0.2 and base-4.3.0.0. However  
none of

them are available.
base-4.2.0.0 was excluded because of the top level dependency base - 
any
base-4.2.0.1 was excluded because of the top level dependency base - 
any
base-4.2.0.2 was excluded because of the top level dependency base - 
any
base-4.3.0.0 was excluded because of the top level dependency base - 
any


bash-3.2# uname -a
Darwin Matthew-Fairtloughs-MacBook-Pro.local 10.5.0 Darwin Kernel  
Version 10.5.0: Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/ 
RELEASE_I386 i386

bash-3.2# port version
Version: 1.9.2
bash-3.2# port info haskell-platform
haskell-platform @2009.2.0.2 (devel, haskell)

Description:  This is the the Haskell Platform: a single,  
standard
 Haskell distribution for every system. The  
Haskell
 Platform is a blessed library and tool suite  
for Haskell

 distilled from Hackage.
Homepage: http://hackage.haskell.org/platform/

Runtime Dependencies: ghc, hs-platform-cgi, hs-platform-fgl,
 hs-platform-editline, hs-platform-GLUT,
 hs-platform-haskell-src, hs-platform-html,
 hs-platform-HUnit, hs-platform-mtl, hs-platform- 
network,

 hs-platform-OpenGL, hs-platform-parallel,
 hs-platform-parsec, hs-platform-QuickCheck,
 hs-platform-regex-base, hs-platform-regex-compat,
 hs-platform-regex-posix, hs-platform-stm,
 hs-platform-time, hs-platform-xhtml, hs- 
platform-zlib,
 hs-platform-HTTP, hs-platform-alex, hs-platform- 
happy,

 hs-platform-cabal
Platforms:darwin
License:  unknown
Maintainers:  gwri...@macports.org
bash-3.2# cabal -V
cabal-install version 0.6.2
using version 1.6.0.3 of the Cabal library
bash-3.2# cabal info base
* base (library)
   Synopsis:  Basic libraries
   Latest version available: 4.3.0.0
   Latest version installed: 4.1.0.0
   Homepage:  [ Not specified ]
   Bug reports:   
http://hackage.haskell.org/trac/ghc/newticket?component=libraries/base
   Description:   This package contains the Prelude and its support  
libraries,
  and a large collection of useful libraries ranging  
from data
  structures to parsing combinators and debugging  
utilities.

   License:   BSD3
   Maintainer:librar...@haskell.org
   Source repo:   http://darcs.haskell.org/packages/base/
   Flags: integer-simple
   Dependencies:  rts -any, ghc-prim -any, integer-simple -any,
  integer-gmp -any
   Documentation: /opt/local/share/ghc-6.10.4/doc/ghc/libraries/base
   Cached:  

Re: [Haskell-cafe] handling multiple versions of a data structure

[Jeremy Shaw]

Nice.

Do you think there is any reason we would not be able to / want to use  
it with happstack ? I would love happstack-data to 'go away' and just  
use some library from hackage which does the same thing.


- jeremy

On Dec 17, 2010, at 3:57 AM, Erik Hesselink wrote:


I've recently been playing with code for versioning data types. It's
based on happstacks implementation, but uses type families to make it
more modular. I've got some proof of concept code on github [1]. We're
also writing a small library based on this at typLAB, which we'll
probably release as well.

Erik

[1] https://gist.github.com/704109

On Thu, Dec 16, 2010 at 19:26, Dmitry V'yal  wrote:

Greetings,

while developing my neural net simulator I stumbled upon a problem.

I have a data type NeuralNet and use Show and Read instances for  
saving and
loading configurations. As time passed, I changed the data type, so  
the

program can no longer load files saved in previous versions.

I want fix it. My current idea looks as follows. I'm going to  
create a bunch
of types NN1, NN2, NN3..NNn for different versions and write  
converters c12

:: N1 -> N2, c23 :: N2 -> N3 and so on.

But how to organize the whole process of parsing String into NNn so  
it's

easy to change formats?
Something based on using a list of parsers
[read, c43 . read, c43 . c23 . read, c43, c23 . c12 . read, c43 .  
c32 . c21

. read]

looks rather verbose and grows quadratically with N.

I'm sure there must be a more elegant way. Any ideas?

Dmitry

___
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] handling multiple versions of a data structure

[Jeremy Shaw]

On Dec 16, 2010, at 4:48 PM, Daniel Peebles wrote:

Have you considered moving these packages that are unrelated to web  
development into a separate namespace? I know that I never  
considered looking under the happstack namespace simply because I  
never do webapps.


Yes. I have been wanting to do it for a while -- just have not had the  
time to do it myself. But I would certainly support an effort to do  
it. Something like, binary-versioned, maybe?


- jeremy 


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

Re: [Haskell-cafe] What is NoPush module?

[Jeremy Shaw]

oops. I got distracted when recording a patch and accidently recorded  
some extra stuff that was not ready yet.


I pushed another patch which rolls back the premature changes. Sorry  
about that :(


- jeremy


On Dec 16, 2010, at 8:02 PM, Magicloud Magiclouds wrote:


Hi,
 When I compiling happstack with ghc 7, I got an error:
src/Happstack/Server/Internal/Handler.hs:29:8:
   Could not find module `NoPush':
 Use -v to see a list of the files searched for.
 I looked around, there is no clue for the module NoPush, except it
has a function call withNoPush.
 What is it?
--
竹密岂妨流水过
山高哪阻野云飞

___
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] handling multiple versions of a data structure

[Jeremy Shaw]

Hello,

You should use happstack-data for this (you do not need the other  
happstack components to use happstack-data)*. It was created to solve  
this exact problem.


happstack-data builds on type of the 'binary' library and adds  
versioned  data types and automatic version migration.


You can get an idea as to how it works by reading this old blog post,

http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html

The modules names have changed from HAppS.* to Happstack.*, but  
otherwise it is still pretty accurate. The upcoming happstack 7  
release cycle will be focusing on this area of happstack. Especially  
improved documentation. But, it is quite usable right now.


If you have questions about happstack-data, feel free to ask on the  
happstack mailing list or irc channel. (http://happstack.com/community)


I am happy to answer any questions or concerns you may have.

- jeremy

* the version on hackage depends on happstack-util, but the darcs  
version does not.


On Dec 16, 2010, at 12:26 PM, Dmitry V'yal wrote:


Greetings,

while developing my neural net simulator I stumbled upon a problem.

I have a data type NeuralNet and use Show and Read instances for  
saving and loading configurations. As time passed, I changed the  
data type, so the program can no longer load files saved in previous  
versions.


I want fix it. My current idea looks as follows. I'm going to create  
a bunch of types NN1, NN2, NN3..NNn for different versions and write  
converters c12 :: N1 -> N2, c23 :: N2 -> N3 and so on.


But how to organize the whole process of parsing String into NNn so  
it's easy to change formats?

Something based on using a list of parsers
[read, c43 . read, c43 . c23 . read, c43, c23 . c12 . read, c43 .  
c32 . c21 . read]


looks rather verbose and grows quadratically with N.

I'm sure there must be a more elegant way. Any ideas?

Dmitry

___
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] Reply-To: Header in Mailinglists (was: About "Fun with type functions" example)

[Jeremy Shaw]

Reply-to munging  has come up many times on this list (and others).
See this page for information on why many people do not like Reply-to
munging:

http://marc.merlins.org/netrants/listreplyto.html

- jeremy

On Thu, Nov 18, 2010 at 9:55 PM, Bastian Erdnüß  wrote:
> Hi there,
>
> I just put an answer two this in beginn...@haskell.org.  It was not on 
> purpose to move the topic.  It's just that questions I feel I can answer are 
> usually beginner level questions and so I'm not often writing in the cafe 
> itself.
>
> It would make my life a little bit more easy if the mailing lists on 
> haskell.org would add a Reply-To: header automatically to each message 
> containing the address of the mailing list, the message was sent to.  Usually 
> that's the place where others would want to sent the answers to, I would 
> suppose.
>
> Is there a reason that that's not the case?  Am I missing something?  Or am I 
> supposed to install a more cleaver mail client which can do that for me?  Is 
> there one?  Probably written in Haskell ;-)
>
> Cheers,
> Bastian
>
> On Nov 19, 2010, at 1:07, Daniel Peebles wrote:
>
>> The best you can do with fromInt is something like Int -> (forall n. (Nat n)
>> => n -> r) -> r, since the type isn't known at compile time.
>>
>> On Thu, Nov 18, 2010 at 2:52 PM, Arnaud Bailly wrote:
>>
>>> Thanks a lot, that works perfectly fine!
>>> Did not know this one...
>>> BTW, I would be interested in the fromInt too.
>>>
>>> Arnaud
>>>
>>> On Thu, Nov 18, 2010 at 8:22 PM, Erik Hesselink 
>>> wrote:
 On Thu, Nov 18, 2010 at 20:17, Arnaud Bailly 
>>> wrote:
> Hello,
> I am trying to understand and use the Nat n type defined in the
> aforementioned article. Unfortunately, the given code does not compile
> properly:

 [snip]

> instance (Nat n) => Nat (Succ n) where
> toInt   _ = 1 + toInt (undefined :: n)

 [snip]

> And here is the error:
>
> Naturals.hs:16:18:
>   Ambiguous type variable `n' in the constraint:
>     `Nat n' arising from a use of `toInt' at Naturals.hs:16:18-39
>   Probable fix: add a type signature that fixes these type variable(s)

 You need to turn on the ScopedTypeVariables extension (using {-#
 LANGUAGE ScopedTypeVariables #-} at the top of your file, or
 -XScopedTypeVariables at the command line). Otherwise, the 'n' in the
 class declaration and in the function definition are different, and
 you want them to be the same 'n'.

 Erik

>>> ___
>>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ActionScript Byte Code backend ?

[Jeremy Shaw]

Hello,

I wrote the old backend. I have not (and will not) have the time to  
update to the newer SWF format. Unless things have changed, the format  
is well documented -- so you don't have to reverse engineer it if you  
want to make your own attempt.


That said, if you are trying to generate actionscript bytecode, a  
better approach may be to use LLVM. That is what adobe does for Alchemy:


http://labs.adobe.com/wiki/index.php/Alchemy:FAQ

if the LLVM -> actionscript code is public, then you can use the  
existing haskell->llvm bindings and get a bunch of optimizing for  
'free'.


- jeremy


On Nov 9, 2010, at 11:40 AM, Aaron Gray wrote:

Is there a Flash ActionScript Byte Code generating backend for  
Haskell ?


I know there was an older SWF 3 backend :-

http://www.n-heptane.com/nhlab/repos/haskell-swf/

But is there anything more up to date ?

Aaron

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


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

[Haskell-cafe] Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure

[Jeremy Shaw]

Hello,

I have narrowed this down further to a single file. And created a trac
bug for it:

http://hackage.haskell.org/trac/ghc/ticket/4485

This is (the only thing?) holding up HSP and happstack moving to GHC 7.

- jeremy

On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw  wrote:
> Hello,
>
> I have a module, XMLGenerator, which has some overlapping instances.
> I have a second module, Test, which imports that module and also adds
> some more overlapping instances.
>
> Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.
>
> Under some old version of 6.13 (and probably 6.12), if I put both
> modules in the same directory and try to load Test.hs, it gets the
> error:
>
> Test.hs:16:15:
>    Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
>      arising from a use of `asChild' at Test.hs:16:15-21
>    Matching instances:
>      instance (m1 ~ m, EmbedAsChild m c) =>
>               EmbedAsChild m (XMLGenT m1 c)
>        -- Defined at XMLGenerator.hs:16:10-68
>      instance (XML m ~ x, XMLGen m) => EmbedAsChild m x
>        -- Defined at XMLGenerator.hs:19:10-51
>    In the first argument of `($)', namely `asChild'
>    In the expression: asChild $ (genElement "foo")
>    In the definition of `asChild':
>        asChild b = asChild $ (genElement "foo")
>
> If I put the XMLGenerator module in a separate package, dummy-hsx, and
> the Test modules links against it, I still get the error.
>
> *but* if I add:
>
>  Extensions:      OverlappingInstances
>
> to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
> starters, I do not understand why that happens.
>
> Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
> always get the error:
>
> Test.hs:16:15:
>    Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
>      arising from a use of `asChild'
>    Matching instances:
>      instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =>
>                            EmbedAsChild m (XMLGenT m1 c)
>        -- Defined in XMLGenerator
>    (The choice depends on the instantiation of `m'
>     To pick the first instance above, use -XIncoherentInstances
>     when compiling the other instance declarations)
>
> Adding the IncoherentInstances flag does make it compile -- but I have
> never enabled that flag and not regretted it.
>
> What changed between GHC 6.12 and GHC 7.0? Is there a some solution
> besides using IncoherentInstances in every module that imports
> XMLGenerator?
>
> I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.
>
> thanks!
> - jeremy
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How can I use MACID in my existing application?

[Jeremy Shaw]

Hello,

Retrofitting MACID will not be trivial because it makes different  
assumptions that permeate your code.


It sounds like your game is possibly multithreaded / multiplayer. But,  
the Game is stored the StateT monad. So I assume only one thread  
updates the GameState ? Is the Game state per-player or is there only  
one global game state ?


In your current app, any code in the GameState monad can update the  
state at any time, and IO can be freely intermixed. There are no  
really boundaries separating one state update from another -- it is a  
continual process with no clear separate events.


MACID will be a lot closer to a traditional database where you perform  
a distinct 'query' operation which updates or reads the state.


Each update or query you wanted to perform on the state would become a  
separate isolated function which gets registered with the transaction  
system (using mkMethod). You would then perform those transactions  
using the update and query functions (which run in the IO monad). So  
you would get rid of the GameState monad, and just have Comm.


MACID also deals with the issue of multiple threads trying to update  
the state -- but that may not be a problem you care about if you only  
have one thread.


One question is, what exactly are you trying to achieve.

If you simple want to checkpoint your game state now and then, you  
could use just happstack-data. It provides versioned binary  
serialization and migration. That would allow you to save the entire  
state now and then, and migrate the data when the game state format  
changed.


MACID builds on that to add the ability to log every 'update' event  
that occurs so that you can replay the events if the server crashes  
between checkpoints. (It also allows for distributed state across  
multiple servers). But in order to log an event, the app has to first  
have things when can be clearly identified as a single 'event'. And  
you have to be able to replay those events later and arrive at the  
same final state you did the first time.


So, in MACID, your events are *written* in the Update and Query monads.

To specific where an 'event' begins and ends, you register some of  
those functions with MACID using the mkMethods function. The event  
starts when a registered function is called, and ends when that  
function returns a value.


In order to be sure that the events can be replayed later and arrive  
at the same result, those events can not perform any IO, because the  
IO might result in a different answer when replayed.


So, to answer your question: You will not directly call functions in  
the Update monad. And you will not integrated the Update monad into  
your other monads. Instead you will register the Update and Query  
functions via mkMethods, and call them in the IO monad via query and  
update. That is likely to be fairly disruptive to your current design.  
But it ensures that every event is saved.


If you merely want periodic checkpoints, you can use happstack-data  
and just write the state out periodically.


hope this helps!

If I have still not answered your question, or you have others, feel  
free to ask!


- jeremy


On Nov 7, 2010, at 10:02 AM, Corentin Dupont wrote:


Hello Jeremy,
thanks for your mail.

I am in despair on this problem since days, I would really help your  
help.

I can't figure out how I can add MACID into my program.
Here's the problem:
I already have monads in my program like that:

> type Comm = StateT Communication IO
>
> type GameState a = StateT Game Comm a

Many functions make use of GameState.
The only type that need to be serialized is Game.
The type Communication contains TChans used for players communication.
The IO in Comm is necessary to make some print outs and to use an  
interpretor when needed (Hint).


How can this match with the Update type in Happstack?

Thanks a lot for your help.
Corentin


On Fri, Nov 5, 2010 at 3:50 AM, Jeremy Shaw   
wrote:

Hello,

I added a brief section to the happstack crash course on using MACID:

http://www.happstack.com/docs/crashcourse/HappstackState.html

That should hopefully get you started.

The example uses happstack state with happstack server. But there is
really no connection between the two.

Hope this helps! If you have additional questions, feel free to ask!

- j


On Thu, Nov 4, 2010 at 12:48 PM, Dupont Corentin
 wrote:
> Hello,
> I'm wondering how can I use Happstack's MACID in my application  
without

> breaking everything.
>
> I have a monad like that:
>
> type Comm = StateT Communication IO
>
> type GameState a = StateT Game Comm a
>
> and many functions like:
> foo :: GameState ()
> foo = do
>lift $ putComm 
>modify 
>
> The state of the game is stored in Game.
> Comm is used as an abstraction to communicate over several  
channels with

> players.
>
> Whereas M

Re: [Haskell-cafe] How can I use MACID in my existing application?

[Jeremy Shaw]

Hello,

I added a brief section to the happstack crash course on using MACID:

http://www.happstack.com/docs/crashcourse/HappstackState.html

That should hopefully get you started.

The example uses happstack state with happstack server. But there is
really no connection between the two.

Hope this helps! If you have additional questions, feel free to ask!

- j


On Thu, Nov 4, 2010 at 12:48 PM, Dupont Corentin
 wrote:
> Hello,
> I'm wondering how can I use Happstack's MACID in my application without
> breaking everything.
>
> I have a monad like that:
>
> type Comm = StateT Communication IO
>
> type GameState a = StateT Game Comm a
>
> and many functions like:
> foo :: GameState ()
> foo = do
>    lift $ putComm 
>    modify 
>
> The state of the game is stored in Game.
> Comm is used as an abstraction to communicate over several channels with
> players.
>
> Whereas MACID asks to use:
>
> type Update state = Ev (StateT state STM)
>
> How can I use this without modifying everything??
> I understand that MACID must record the  from above but the
> message should not.
>
> Thanks for help!
>
> Corentin
>
>
>
>
> ___
> 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] change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure

[Jeremy Shaw]

Hello,

I have a module, XMLGenerator, which has some overlapping instances.
I have a second module, Test, which imports that module and also adds
some more overlapping instances.

Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.

Under some old version of 6.13 (and probably 6.12), if I put both
modules in the same directory and try to load Test.hs, it gets the
error:

Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
  arising from a use of `asChild' at Test.hs:16:15-21
Matching instances:
  instance (m1 ~ m, EmbedAsChild m c) =>
   EmbedAsChild m (XMLGenT m1 c)
-- Defined at XMLGenerator.hs:16:10-68
  instance (XML m ~ x, XMLGen m) => EmbedAsChild m x
-- Defined at XMLGenerator.hs:19:10-51
In the first argument of `($)', namely `asChild'
In the expression: asChild $ (genElement "foo")
In the definition of `asChild':
asChild b = asChild $ (genElement "foo")

If I put the XMLGenerator module in a separate package, dummy-hsx, and
the Test modules links against it, I still get the error.

*but* if I add:

  Extensions:  OverlappingInstances

to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
starters, I do not understand why that happens.

Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
always get the error:

Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
  arising from a use of `asChild'
Matching instances:
  instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =>
EmbedAsChild m (XMLGenT m1 c)
-- Defined in XMLGenerator
(The choice depends on the instantiation of `m'
 To pick the first instance above, use -XIncoherentInstances
 when compiling the other instance declarations)

Adding the IncoherentInstances flag does make it compile -- but I have
never enabled that flag and not regretted it.

What changed between GHC 6.12 and GHC 7.0? Is there a some solution
besides using IncoherentInstances in every module that imports
XMLGenerator?

I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.

thanks!
- jeremy


dummy-hsx.cabal
Description: Binary data
{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, FlexibleInstances, UndecidableInstances, TypeSynonymInstances, GeneralizedNewtypeDeriving  #-}
module Test where

-- import HSX.XMLGenerator
import XMLGenerator

data M t a = M (t a)
data X = X
instance Monad (M m)
instance XMLGen (M m) where
type XML (M m) = X

data FooBar = FooBar

instance EmbedAsChild (M IO) FooBar where
  asChild b = asChild $ (genElement "foo")

data I a = I a
instance Monad I

instance EmbedAsChild (M IO) (XMLGenT I ())




{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, FlexibleInstances, UndecidableInstances, TypeSynonymInstances, GeneralizedNewtypeDeriving  #-}
module XMLGenerator where

class Monad m => XMLGen m where
 type XML m
 data Child m
 genElement  :: String ->XMLGenT m (XML m)
 xmlToChild :: XML m -> Child m

newtype XMLGenT m a = XMLGenT (m a)
deriving (Monad, Functor)

class XMLGen m => EmbedAsChild m c where
 asChild :: c -> XMLGenT m [Child m]

instance (EmbedAsChild m c, m1 ~ m) => EmbedAsChild m (XMLGenT m1 c) where
 asChild m = asChild =<< m

instance (XMLGen m,  XML m ~ x) => EmbedAsChild m x where
 asChild = return . return . xmlToChild
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mysterious fact

[Jeremy Shaw]

Looks a lot like Church encoding to me:

http://en.wikipedia.org/wiki/Church_encoding

It was first discovered by the guy who invented lambda calculus :p

- jeremy

On Nov 1, 2010, at 5:28 PM, Andrew Coppin wrote:


The other day, I accidentally came up with this:

{-# LANGUAGE RankNTypes #-}

type Either x y = forall r. (x -> r) -> (y -> r) -> r

left :: x -> Either x y
left x f g = f x

right :: y -> Either x y
right y f g = g y

This is one example; it seems that just about any algebraic type can  
be encoded this way. I presume that somebody else has thought of  
this before. Does it have a name?


___
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] who's in charge?

[Jeremy Shaw]

On Oct 27, 2010, at 10:08 AM, Günther Schmidt wrote:


Dear Malcolm,

since there is no mail client library even after 10+ years I suggest  
to rethink the approach, because frankly, it's not working.


Hello!

I am in charge, sorry for the delay!

A number of years ago I tried to form a MIME strike force to create  a  
library that would be suitable for composing mail messages, decoding  
mail messages, or transforming mail messages. But received no real  
interest:


http://www.mail-archive.com/haskell-cafe@haskell.org/msg21872.html

The fact that it is now considered an oddity (by some) that there is  
no standard, well support mail library is a sign of great progress in  
my opinion.


The driving force is likely to be web development platforms such as  
happstack, snap, and yesod, because one often wants to integrate email  
with a web site. (such as send emails to members, etc).


That said, there have been many attempts at various portions of the  
mail infrastructure over the years.


As part of that strike force attempt I create this mime library (not  
on hackage):


http://src.seereason.com/haskell-mime/

It can parse and decode multipart messages. And it has the beginning  
of an interface for composing messages. One thing I attempted to do  
was create a mail composition DSL that only allowed you to construct  
valid messages. For example, some headers can only appear once, and  
others can appear multiple times. So I attempted to encode that into  
the DSL. I was successful to some degree.


There is also the mime-string library on hackage which does MIME  
parsing.


There is the new mime-mail library for creating and sending MIME  
messages.


happstack had the beginnings of a MTA at one point in time, but was  
removed until someone comes along with the desire and time to really  
implement it.


There is the Postmaster ESMTP server,

http://gitorious.org/postmaster

which acts as a MDA for receiving mail and filtering it into folders.  
It allows you to write your filtering rules in Haskell instead of some  
obtuse filter language (e.g., procmail).


And there are other projects I have not mentioned as well.

I guess part of the question is, do you specifically mean a 'mail  
client'. There are a lot of pieces to the mail puzzle including, MUA,  
MTA, MDA, MIME, etc.  And there is the reading of saved mail formats  
like mbox, Maildir, etc. And then there are the various protocols like  
SMTP, POP3,  IMAP4, etc. And things like GPG signatures and encryption.


Using the libraries that are available right now I can create a mime  
email and send it via sendmail or via an SMTP smart host. I can also  
use a well established program like dovecot to receive mail and then  
decode messages using mime-string on haskell-mime.  That gets me  
pretty far for what I need to do.


Writing a competitor to mutt or gmail would be more difficult due to  
some missing pieces. But, then again, I think most people are  
satisfied enough with mutt and gmail, so not many people have any  
motivation to replace them. Same thing with a competitor to qmail/ 
dovecot/etc. Those tools are in place and work pretty well. So,  
replacing any of those really only becomes interesting if you are  
going to do something really new -- not just implementing them in your  
favorite language.


Anyway, I do think there will be growth in the haskell mail library  
domain. Specifically the stuff that would be useful for integration  
with web applications.


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

Re: [Haskell-cafe] JavaScript in a browser as a Windows GUI?

[Jeremy Shaw]

On Fri, Oct 22, 2010 at 12:05 PM, Andrew Coppin
 wrote:
>  On 21/10/2010 07:00 PM, Jeremy Shaw wrote:
>>
>> But, you are correct that happstack does not currently have support
>> for running CGI executables. I imagine that you could write a CGI
>> handler (with out modifying the core code) in a few hours (maybe
>> less). Mostly just a matter of turning the values in the Request type
>> into a environment variables, and calling the executable?
>
> And writing a HTTP server is "mostly" a matter of parsing the request
> headers and constructing some response headers. However, this turns out to
> be significantly less easy to do properly than you'd first imagine. ;-)

True. Though I am basing my assumption on the fact that we have code
which goes the opposite way (allows happstack to run as a CGI
process), and those bindings are pretty short (less than 100 lines)
and simple looking.

>> That said, I am not sure why you want CGI.
>
> Because my hired web server runs Apache?
>
> Sure, if I'm only doing stuff on the local machine, I can use any kind of
> server/application linkage I like, because I can use any server I want. But
> if I ever decide to actually put this stuff on the web, for real, it'll have
> to be plain CGI. (Or maybe FastCGI is supported, I'm not actually sure...)
> That being the case, I might as well develop it as CGI to start with.

happstack-server has FastCGI support. Plain-old CGI support is no
great challenge either. Your web application is basically just a ,
ServerPart Response, value. Typically you would run that using
simpleHTTP

simpleHTTP :: (ToMessage a) => Conf -> ServerPart a -> IO ()

but you can just as easily run it as CGI using:

serverPartToCGI :: ToMessage a => ServerPart a -> CGI CGIResult

(from the happstack-fastcgi package).

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

Re: [Haskell-cafe] Haskellers.com skills list moderation?

[Jeremy Shaw]

On Thu, Oct 21, 2010 at 12:16 PM, Michael Snoyman  wrote:
> On this one you may call be biased, but I think keeping Happstack and
> Yesod on their own makes perfect sense. If I were an employer looking
> to hire someone to work on a project, I would be looking to see that
> they can use my tool of choice.

For the web development frameworks I think it makes sense to be able
to specify which ones you are comfortable with. It also seems like it
would make sense for them to be a sub-category of general web
development. A large portion of web develop knowledge is portable from
one framework to another. So, if you are hiring someone for a
full-time position, the amount of time it would take for them to learn
a different framework would be small in the big picture. But if you
want to hire someone to do a few hours of work, then already knowing
the framework could be critical.

But, I am not sure if sub-categories make sense for other skills. So,
adding that for sake of just one skill would be ugly.

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

Re: [Haskell-cafe] JavaScript in a browser as a Windows GUI?

[Jeremy Shaw]

On Thu, Oct 21, 2010 at 12:04 PM, Andrew Coppin
 wrote:

> My understanding is that Happstack is a very large, powerful and complex
> framework for writing Haskell web applications. I was under the impression
> that you use it by statically linking the HTTP server and the actual
> application together, rather than Happstack providing a standard CGI
> interface that an external application can then use.

powerful - yes! large and complex -- not so much. Though, the lower
bound on complexity is limited by the fundamental complexity of the
web itself.

But, you are correct that happstack does not currently have support
for running CGI executables. I imagine that you could write a CGI
handler (with out modifying the core code) in a few hours (maybe
less). Mostly just a matter of turning the values in the Request type
into a environment variables, and calling the executable?

That said, I am not sure why you want CGI. CGI is only simple in the
sense that it doesn't do anything for you. But that means you have to
handle all the complexity yourself. Perhaps it would be easier to just
learn happstack. It is much better documented now than it was a few
years ago (and some aspects have been simplified). And happstack-state
and happstack-server are now completely independent.

Here is a nice tutorial, http://happstack.com/docs/crashcourse/index.html
The darcs version (which will be released soon) has much better
haddock documentation as well. I would recommend the darcs version for
any new development.

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

Re: [Haskell-cafe] JavaScript in a browser as a Windows GUI?

[Jeremy Shaw]

On Oct 20, 2010, at 7:28 PM, Anton van Straaten wrote:


Andrew Coppin wrote:

I'd like to have a go at writing CGI in Haskell.

...

Does anybody know of a solution that works on Windows?


I've previously run Happstack on Windows.  That was a couple of  
years ago, though, so I don't know whether its Windows support is  
currently working.


It should work. Windows is an officially supported happstack platform.  
All releases are tested to ensure they work under Windows.


- jeremy

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

Re: [Haskell-cafe] Happstack, RqData: (How) can I extract multiple data from form?

[Jeremy Shaw]

2010/10/18 Никитин Лев :

> Well. Thanks. I've just have a look at formlets. I think is what i need.
> But I'm using now HSP. Are formlets integrated with HSP?
> (I saw olny using formlets with text.xhtml).

hsp support is in a separate package:

http://hackage.haskell.org/package/formlets-hsp

There is a demo of using HSP+Formlets+Happstack here:

http://src.seereason.com/formlets-hsp/examples/happs-hsp/

hope this helps!
- jeremy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Front Page Ideas

[Jeremy Shaw]

On Sun, Oct 17, 2010 at 3:11 PM, aditya siram  wrote:
> An honest list of cons mentioned up-front is a great idea and would attract
> me to a language. It shows me that the community is grounded, active ,
> pragmatic and helpful.

Yes. It's called "damaging admission", and generally works very well:

http://www.communemedia.com/blog/admit-weakness-to-strengthen-trust/

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

Re: [Haskell-cafe] A rant against the blurb on the Haskell front page

[Jeremy Shaw]

On Sat, Oct 16, 2010 at 3:02 AM, Stephen Tetley
 wrote:
>
> If a "functional language" doesn't mean anything significant then
> Haskell probably isn't the language you should be choosing.

People who don't know what 'functional language' means can still get
all the benefits of functional programming if they choose to learn
Haskell (and thereby learn what a functional language is).

The blurb on the homepage can not be all things to all men.

If the goal of the blurb is to get more people using Haskell then it
needs to be targeted towards the largest group of people who have a
need which can be fulfilled by Haskell, who are willing and able to
use Haskell if it can solve their problem, and who do not already know
how Haskell can help them.

Now, I am guessing that the group of people who:

 1. know what a lazy, statically type, functional program languages is
 2. do not already know about Haskell

is pretty small. So, targeting them seems rather futile.

There is also a large group of people who ought to be able to benefit
from Haskell, but for whatever reason, can't or won't use it. Clearly
they are not of interest either.

So, we are left with the (rather large?) group of people who do not
know what Haskell is and probably do not really know what 'statically
typed' or 'purely functional' really mean. In fact, I think that most
non-haskell/ocaml/etc programmers view 'statically typed' as meaning
'C/C++ / java' style type systems -- and that is often considered a
negative thing. You don't really know what it means to use Haskell's
static type system unless you have used one of the other languages
with a sane type system. And then, you are probably already in the
group who knows what Haskell is...

How can we present Haskell to these people in a way that they will
think it *might* provide a solution worth investigating to a problem
that is bothering them. The blurb is not going to completely enlighten
people. It just needs to convince them that Haskell is something worth
investigating, and get them to click the link that will get them
investigating the part that is potentially useful to them.

For some people the problem that pains them is the need to learn
"cool", "advanced" stuff that will make them feel "smarter" than their
peers. For these people, seeing unfamiliar terms like, "monads",
"lazy", "purely functional", etc. will be exciting -- because it
promises them the opportunity to learn something new, and potentially
interesting, that other people do not know. So, for those people,
those words are great! (I am one of those people -- perhaps many
current Haskeller's are?)

Other people may care about specific benefits of using Haskell which
can be applied to their particular needs. Someone frustrated with
parallel on concurrent programming might  be really interested to find
out that Haskell provides solutions in those domains that are
(hopefully) better than what they have been dealing with. But, the
claim that Haskell is better than what they already know needs to be
back up with something that will make them want to dig deeper. If we
simply say, "We do parallelism and concurrency better", people will
respond, "yeah whatever, I've heard that before." If we say, "Haskell
offers new and better ways of dealing with parallelism and concurrency
that are only possible because Haskell is purely functional and has an
advanced type system." -- then people might at least have the
question, "What does purely functional mean? How could that result in
better ways of writing parallel and concurrent code?" And, from there,
they would hopefully be able to click on links which would address
those questions in more detail, and convince them to invest the time
to learn Haskell.

I think value judgments are incredibly valuable. People are not going
to be interested in learning more about Haskell unless they believe it
is more valuable than what they are already using. I believe that is
the #1 question in people's mind when they visit the site is, "Is this
language in anyway more valuable to me than what I am already using."
And they want to spend as little time as possible making that initial
judgment. Once they have decided that it could be more valuable, then
they will be willing to invest more time to determine if it really is
or not.

I think the key is that we need to provide a reason for each value
judgment. In the blurb, the 'reason' does not need to be a proof, nor
does the reader need to be able to fully comprehend it. They initially
just want to see that we have some basis for making the claim. And,
having a link that can more fully explain the value judgment will add
further trust.

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

Re: [Haskell-cafe] Re: A rant against the blurb on the Haskell front page

[Jeremy Shaw]

On Sun, Oct 17, 2010 at 1:32 PM, Stefan Monnier
 wrote:

> AFAIK laziness is a property of the major implementations of Haskell,
> but not really of the language itself.  All I see in the Haskell report
> points at it being "applicative", "call by name", but nowhere does the
> report seem to mandate a lazy strategy.  It's just that being purely
> functional implies that the compiler is free to use laziness.

Yes. The rumor I heard is that Haskell is non-strict:

http://www.haskell.org/haskellwiki/Lazy_vs._non-strict

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

Re: [Haskell-cafe] Re: Should Yesod.Mail be a separate package?

[Jeremy Shaw]

On Sun, Oct 17, 2010 at 10:14 AM, Michael Snoyman  wrote:

> I'm sure people would love to see built-in support for serving over
> SMTP, but I think that's more appropriate for a different package.
> Proper SMTP support will also include SSL/TLS support, which will
> require even more dependencies.

SMTPClient,

http://hackage.haskell.org/package/SMTPClient-1.0.3

can be used to send mail via SMTP to a smart host. It is still based
on 'String', but it is a start. To send a simple message you can do:

 import Network.SMTP.Simple
 import System.IO

 main :: IO ()
 main = do
 sendSimpleMessages (hPutStrLn stderr) "10.2.23.11" "example.com" [message]
 where message = SimpleMessage
 [NameAddr (Just "John Doe") "jo...@example.com"]
 [NameAddr (Just "Team") "t...@exmaple.com"]
 "My test email using Network.SMTP.Simple"
 "Hi, this is a test email which uses SMTPClient."

I wonder what it would take to make it so that the message body could
be multipart mime...

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

Re: [Haskell-cafe] Re: Re: A rant against the blurb on the Haskell front page

[Jeremy Shaw]

On Oct 16, 2010, at 9:03 PM, Ben Franksen wrote:

Still, "Haskell is an open source product" doesn't sound right to me.
Even "Haskell is open source" (without the "product") has a bad ring
because "source" is short for "source code" and source code is not
something a programming language has.


How about something like,

Haskell has an open design and development model driven by commercial  
and academic research, industry users, hobbyists, and other members of  
the community.


Or something to that effect ? (I'm not wild about the word 'has'  
there...)


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

Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)

[Jeremy Shaw]

On Tue, Oct 12, 2010 at 8:03 AM, Brandon S Allbery KF8NH
 wrote:
>
> On the one hand, a professional organization will prefer to have real names,
> real pictures, etc.  On the other, if you want to be a central coordinating
> spot for the existing Haskell community, many of us are far better known by
> nicknames and identicons.

I would definitely like to see the option of adding your handle to
your profile. Even if it is a commercially oriented site. Otherwise I
won't be able to figure out who is who.

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

Re: happstack-ixset internals/performance (was Re: [Haskell-cafe] Inverse of HaskellDB)

[Jeremy Shaw]

Hello,

Check out these threads:

http://groups.google.com/group/happs/browse_thread/thread/23d92e45c99f88b1
http://groups.google.com/group/happs/browse_thread/thread/0b0d0a9158c3ad73

There is nothing inherently wrong with keeping 28GB of real data in
memory.  It depends largely on what you are trying to optimize for..

For personal hobby projects, the cost of hosting the project seems to
be the biggest expense that people are concerned worth. (Which is
quite reasonable). As a result people are willing to increase
development time, and sacrifice performance in order lower hosting
costs. (Also reasonable).

For commercial projects, the costs look different. For example, if
buying a server with 1TB of RAM (around $80,000 these days) means they
can hire one less developer (at $150,000/year when you look at total
cost of salary, benefits, etc), then that is a savings of $70,000.
Additionally, in RAM storage provides much more predictable
performance. If you have ever attempted to use a site like reddit
after its memcached servers have been reset, it is clear how bad the
penalties for hitting disk are. RAM is significantly faster and than
disk and has no seek time. RAM can achieve 100-1000x less latency and
higher throughput.

Facebook reportedly keeps as much as 80-90% of their working dataset
in memcached. In 2008 they had 28TB of memcached servers. No idea what
they are up to now
(http://www.facebook.com/note.php?note_id=39391378919).

Of course, there are datasets which are simply too big to be stored in
RAM. For example, google's search index. I am not that familiar with
their approach, but I believe they go the opposite extreme. They
likely assume that every query is going to hit the disk, and optimize
the system so that it can provide acceptable response even if nothing
is cached ? (I am totally guessing here).

The focus of the new IxSet internals is to help bring the indexing
overhead ratio down (and increase speed at the same time).

There are also some ideas, but not code, for how to build an
IxSet-like structure which stores the keys in RAM, but can store the
values of disk. That would, hopefully, give you the ease of use of
IxSet, but with lower memory requirements if your keys are
significantly smaller than the total value payload. The trade off
being that you get back into the ugly work of disk seeks :)

There was also some experimental work done where the values were
stored in RAM, but in their serialized byte format, under the
assumption that the serialized format is a lot more compact than the
normal representation. The trade off is that the values must be
deserialized everytime they are used, which requires more CPU. A more
complex version could be imagined, where the deserialized version is
cached for some period of time. Whether that is actually beneficial
can only be determined empirically I think...

So, clearly happstack-state is not the optimal choice for all haskell
web applications. And that is why it is a completely independent from
happstack-server. We do want to allow people to pick the best choice
for their application. Of course, if we want to provide off-the-shelf
components like a user account system -- then eventually we have to
nail down some specifics, such as the persistence layer. But those
choices would only apply to code that wants to use those optional
components.

At the same time, happstack-state is a very interesting and
challenging library to work on. The recent rise in popularity of
things like redis seems to validate happstack-state somewhat.

- jeremy


On Sat, Oct 2, 2010 at 3:09 PM, Thomas M. DuBuisson
 wrote:
> Thanks Jeremy, I just wrote up my own little analysis (below) while you
> were responding.  I'll look for the kd-tree work; if I see discussion
> (and am stupid enough to heap more work onto my plate) then I might get
> involved.
>
> Oops, didn't send...
>
> Cheers,
> Thomas
>
> -
>
> So another glance tells me there is a list of maps (one element for each
> index method) and it uses Data.Map under the hood.  So I have O(m lg n)
> where m is the number of index methods and n is the number of elements.
>
> Space wise, I think Data.Map takes up 6 words per Bin constructor (1 for
> the constructor, 1 for the 'Size' and one for the pointer indirection
> for each additional field), so the space is "6 * n * m * w" where w is
> the word size.  This means indexing by 5 methods for 1M entries takes
> about 256MB, assuming 28B per entry that's 28MB of data + 256 indexing ~
> 282MB needed.
>
> Indexing my imaginary 1B points by user,date,lat,lon is 6 * 2^30 * 4 * 8
> - or about 192 GB of indexing + 28GB of data for 220GB total.  Obviously
> I shouldn't be talking about keeping a live data set of 28GB in memory
> let alone indexing it all, but I was just curious about the ratio (220MB
> for 1M points, which is just one heavy user).

Re: happstack-ixset internals/performance (was Re: [Haskell-cafe] Inverse of HaskellDB)

[Jeremy Shaw]

In the current version of IxSet, the performance of querying on just
the Lon would be essentially the same as if you just had a "Data.Map
Lon Point". But the queries on the second index are current not so
great. There is work in progress to rewrite the internals of IxSet to
be based on a kd-tree, in which case your query should be pretty
efficient.

So, that answer is pretty vague :) I am in the process of wrapping up
happstack 0.6 which has focused on fixing some performance issues with
happstack-server, and refactoring the code so that user API and
internals are more clearly separated and better documented.

happstack 0.7 is all about happstack-state. A key aspect will be
nailing down some solid performance benchmarks instead of vague hand
waving :)

The numbers you give are certainly within the scope of what we would
like 0.7 to be able to handle. Also, I should note that
happstack-state and happstack-ixset are independent from each other.
You can easily use something other than IxSet to store your points and
still use happstack-state.

- jeremy

On Fri, Oct 1, 2010 at 1:53 PM, Thomas M. DuBuisson
 wrote:
>> That is pretty close to how it would look using happstack-state. Here
>> is a complete, runnable example which defines the types, a query,
>> creates/initializes the database, performs the query, and prints the
>> results.
> [snip]
>
> How is data stored in Happstack.State?  I see the "Component" instance
> uses "fromList" from happstack-ixset but can't find any information on
> the algorithm used or its efficiency (computationally or wrt space).
>
> If making this more concrete helps then here is a possible use:
>
> == GPS Points ==
> I have a GPS logger that logs every 10 seconds when I jog.  Jogging for
> an hour a day for the past 180 days has resulted in 64k points.
> Pretending I hosted a site for joggers (and all points were in the same
> DB) I could easily result in a billion points (< 20K users).  Would
> happstack-ixset code in the form "points @< (Lon -120) @> (Lon -125) @>
> (Lat 45) @< (Lat 50)" perform reasonably?
>
> Cheers,
> Thomas
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inverse of HaskellDB

[Jeremy Shaw]

On Wed, Sep 29, 2010 at 5:21 AM, Michael Snoyman  wrote:
> I think this approach is not possible without involving some fairly
> ugly unsafeInterleaveIO/unsafePerformIO calls. A simple example using
> a common web programming example: support I have a multi-user blog
> site, where each user can have multiple entries. I would model this
> using standard Haskell datatypes as:
>
> data Entry = Entry { title :: String, content :: String }
> data Blogger = Blogger { name :: String, entries :: [Entry] }
>
> Obviously we'll need some kind of blogger loading function:
>
> getBloggerByName :: String -> IO Blogger

That is pretty close to how it would look using happstack-state. Here
is a complete, runnable example which defines the types, a query,
creates/initializes the database, performs the query, and prints the
results.

> {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, MultiParamTypeClasses, 
> TemplateHaskell, TypeSynonymInstances, TypeFamilies #-}
> module Main where
>
> import Control.Exception (bracket)
> import Control.Monad.Reader (ask)
> import Data.Data
> import Happstack.Data
> import Happstack.Data.IxSet
> import Happstack.State

A simple type to identify a particular blogger:

> newtype Blogger = Blogger { name :: String }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Blogger)
> instance Version Blogger

The deriveSerialize instance automatically creates the instances for
serializing and deserializing to/from a binary representation for
storage, transmission, etc.

The Version instance is used for migration when the data type changes.
(Since there is no previous version of this type to migrate from, we
don't have to specify anything).

We create a similar type for the title of the blog post:

> newtype Title = Title { unTitle :: String }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Title)
> instance Version Title

And a simple record which actually contains a blog post:

> data Entry =
> Entry { title   :: Title
>   , blogger :: Blogger
>   , content :: String
>   }
> deriving (Eq, Ord, Read, Show, Data, Typeable)
> $(deriveSerialize ''Entry)
> instance Version Entry

Obviously, it could be expanded to support tags, posted date, whether
or not in is published, etc. Next we create an IxSet which holds all
the Entries that have been posted:

> $(inferIxSet "Entries" ''Entry 'noCalcs [''Blogger, ''Title])

An IxSet is a bit like a normal Set, except it has indexes, which you
can use for performing queries. In this case, we use Blogger and Title
as indexes.

Next we define a component that actually stores the Entries:

> instance Component Entries where
> type Dependencies Entries = End
> initialValue = fromList [ Entry { title   = Title "10 Reasons you should 
> use Happstack."
> , blogger = Blogger "stepcut"
>     , content = "..."
> }
> , Entry { title   = Title "Persistence made easy!"
> , blogger = Blogger "Jeremy Shaw"
> , content = "..."
> }
> ]

This component is prepopulated with 2 entries. Now we want to define a
query which retrieves all the entries by a particular Blogger:

> getEntriesByBlogger :: Blogger -> Query Entries Entries
> getEntriesByBlogger blogger =
> do e <- ask
>return (e @= blogger)

The Query monad is essentially a specialized version of the Reader
monad. So we use 'ask' to get the Entries from the Entries
component. (@=) is an IxSet function which selects all the Entries with
the specified blogger.

Next we 'register' all the functions we want to use as queries for the
Entries Component:

> $(mkMethods ''Entries ['getEntriesByBlogger])

And finally, here is a main function which initializes the transaction
system, performs a query, prints the results, and shuts the
transaction system down:

> main :: IO ()
> main =
> bracket (startSystemState (Proxy :: Proxy Entries)) shutdownSystem $ \_ ->
> do postsByStepcut <- query (GetEntriesByBlogger (Blogger "stepcut"))
>print postsByStepcut

Note that there is no outside or additional configuration which needs
to be done. If you have the happstack-state libraries installed on
your system, then you can simply run this program. You do not need to
configure or initialize any external database system.

The queries and updates are thread-safe, ACID-transacti

Re: [Haskell-cafe] Web application framework comparison?

[Jeremy Shaw]

On Tue, Sep 28, 2010 at 5:46 AM, Christopher Done
 wrote:
> http://haskell.org/haskellwiki/Applications_and_libraries/Web_programming
> for examples

If you search on google for 'haskell web framework' that link actually
comes up higher than any other wiki page.. and it does seem to have
more complete entries in many ways..

Not sure what that means. But I am only willing to maintain so many
wiki pages. So far at least three have come up in this thread.

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

Re: [Haskell-cafe] Inverse of HaskellDB

[Jeremy Shaw]

Do you need to persistently store your Haskell data types in tables ?
Or just persistently store them ?

happstack-state provides the latter for you. Your data-types are just
plain-old Haskell data types and your queries and updates are just
functions in the Reader or State monad. It provides ACID properties
with write-ahead logging to the disk, S3, or other backends. It also
includes data-type versioning and automatic migration. Although it is
associated with the happstack web application framework, there is
nothing web specific about it. It does not even require that you build
or install any of the web stuff in Happstack.

To get a quick feel for how it works, I recommend this tutorial:

http://nhlab.blogspot.com/2008/07/extending-asterisk-with-happs.html

It is a little out of date -- but mostly you just need to change the
imports from HAppS to Happstack.

 - jeremy

On Sat, Sep 25, 2010 at 2:31 PM, Jonathan Geddes
 wrote:
> Cafe,
>
> HaskellDB takes a database schema and produces Haskell data structures
> (plus some other query-related stuff for its EDSL query language).
>
> What I'm looking for is the inverse of this functionality. I want to
> create tables based on a Haskell data structure with a few simple
> rules. These rules include: if a field is not of the form `Maybe a'
> then it can't be nullable in the database. If a field is not a
> primitive (in the database) then it is actually stored in another
> table and a reference id is stored in the table. Tables are produced
> recursively, unless they already exist, etc.
>
> The HaskellDB approach is great for interfacing with existing tables,
> but in my case I already have data structures and now I would like a
> quick way to create tables to persist them.
>
> Does such a thing exist? If not, would you find it useful? I may take
> this up as a side project if it does not already exist and others
> would find it useful.
>
> Thanks,
>
> --Jonathan
> ___
> 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