Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?

[Joey Adams]

I uploaded a package that creates an STM layer over a network connection:

http://hackage.haskell.org/package/stm-channelize

I haven't used it in anger yet, but I hope it's a step in the right
direction.  I included a sample chat client and server.  The client is
pretty cute:

main =
let connect = connectTo "localhost" (PortNumber 1234) >>= connectHandle
 in channelize connect  $ \conn ->
channelize connectStdio $ \stdio ->
forever $ atomically $
(recv conn >>= send stdio) `orElse`
(recv stdio >>= send conn)

I use channelize on both the network connection, and on stdin/stdout.

The server is much longer, but shouldn't be terribly confusing.  It
demonstrates kicking out a client without a dangerous asynchronous
exception, something we can't do easily without waiting on
alternatives (i.e. orElse).

-Joey

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

Re: [Haskell-cafe] Conduit versions of wai and warp?

[Michael Snoyman]

On Wed, Jan 18, 2012 at 2:22 AM, Erik de Castro Lopo
 wrote:
> Hi Michael,
>
> The current versions of wai and warp:
>
>    http://hackage.haskell.org/package/wai
>    http://hackage.haskell.org/package/warp
>
> still seem to be the versions that use enumerator.
>
> Any idea when the Conduit versions might show up on Hackage?
>
> Until then, should I be grabbing these packages from Github?
>
> Cheers,
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/

Funny, I just got a similar question on the Yesod mailing list.
Currently, the plan is to release WAI/Warp 1.0 and Yesod 0.10 towards
the end of the month. However, WAI and Warp are mostly ready now, just
needing a bit more testing. If people want to give me some feedback on
the readiness of them, and would like them released earlier, I'm
definitely flexible.

Meanwhile: yes, the Github version is conduit-based.

Michael

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

Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?

[Joey Adams]

On Tue, Jan 17, 2012 at 3:20 PM, David Barbour  wrote:
> I'd say use of asynchronous exceptions should be a last resort. ...

I agree.  However, network libraries in Haskell (e.g. Handle,
Network.TLS) generally don't provide the primitives needed to do that
on the receiving end.  For example, if a thread is blocked on hGetBuf,
it cannot also wait on a signal telling it to stop.  Since hClose on
the same handle will block until the hGetBuf is done, the only way to
stop reading from the handle is to throw an asynchronous exception at
the hGetBuf thread.

Worse, since there is no threadWaitReadHandle :: Handle -> IO (),
there's no way to guarantee that hGetBuf will not be interrupted in
the middle of receiving a packet.  From an application perspective,
this invalidates subsequent retrievals unless the protocol is
self-synchronizing.

-Joey

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

Re: [Haskell-cafe] implementing a text editor swap file

[Erik de Castro Lopo]

Martin DeMello wrote:

> Just plain String, mostly because it's what Gtk.Entry works with. I'll
> take a look at Text.

Ah, maybe not. If your output representation *has* to be String its
probably not worth using Text as an internal representation.

I suspect that Gtk should really be updated to allow the use of Text
instead of String.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] implementing a text editor swap file

[Martin DeMello]

On Tue, Jan 17, 2012 at 6:24 PM, Erik de Castro Lopo
 wrote:
> Martin DeMello wrote:
>
>> Further question - my internal data representation is a vector of
>> strings (it's a line-based editor).
>
> String or ByteString or Text?
>
> If its either of the first two, I think you should definitely look at
> Text.

Just plain String, mostly because it's what Gtk.Entry works with. I'll
take a look at Text.

martin

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

Re: [Haskell-cafe] implementing a text editor swap file

[Erik de Castro Lopo]

Martin DeMello wrote:

> Further question - my internal data representation is a vector of
> strings (it's a line-based editor).

String or ByteString or Text?

If its either of the first two, I think you should definitely look at
Text.

> Is there a more efficient strategy
> to keep an mmap buffer in sync with the vector than simply allocating
> some large fixed size per line?

Very much dependent on whether you are using String or one of the
other two I would think.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] implementing a text editor swap file

[Martin DeMello]

On Tue, Jan 17, 2012 at 5:49 PM, Erik de Castro Lopo
 wrote:
> Matthew Farkas-Dyck wrote:
>
>> http://hackage.haskell.org/package/bytestring-mmap
>
> Since he's editing text, its a pity there isn't a text-mmap
> package :-).

Further question - my internal data representation is a vector of
strings (it's a line-based editor). Is there a more efficient strategy
to keep an mmap buffer in sync with the vector than simply allocating
some large fixed size per line?

martin

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

Re: [Haskell-cafe] implementing a text editor swap file

[Matthew Farkas-Dyck]

On 17/01/2012, Erik de Castro Lopo  wrote:
> Matthew Farkas-Dyck wrote:
>
>> http://hackage.haskell.org/package/bytestring-mmap
>
> Since he's editing text, its a pity there isn't a text-mmap
> package :-).

Yeah, I had the same thought.

> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.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] implementing a text editor swap file

[Martin DeMello]

Says posix only. But googling for it brought up System.IO.MMap, which
does seem to be cross-platform.

martin

On Tue, Jan 17, 2012 at 5:46 PM, Matthew Farkas-Dyck
 wrote:
> http://hackage.haskell.org/package/bytestring-mmap
>
>
> On 17/01/2012, Martin DeMello  wrote:
>> I'm writing a gtk2hs-based text editor, and would like to implement
>> continuous (swap-file based) autosave the way vim and emacs do it. Any
>> suggestions for how to implement this in a cross-platform manner?
>>
>> Also, is there a library that returns standard config file locations
>> on a per-platform basis?
>>
>> martin
>>
>> ___
>> 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] implementing a text editor swap file

[Erik de Castro Lopo]

Matthew Farkas-Dyck wrote:

> http://hackage.haskell.org/package/bytestring-mmap

Since he's editing text, its a pity there isn't a text-mmap
package :-).

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] implementing a text editor swap file

[Matthew Farkas-Dyck]

http://hackage.haskell.org/package/bytestring-mmap


On 17/01/2012, Martin DeMello  wrote:
> I'm writing a gtk2hs-based text editor, and would like to implement
> continuous (swap-file based) autosave the way vim and emacs do it. Any
> suggestions for how to implement this in a cross-platform manner?
>
> Also, is there a library that returns standard config file locations
> on a per-platform basis?
>
> martin
>
> ___
> 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] implementing a text editor swap file

[Martin DeMello]

I'm writing a gtk2hs-based text editor, and would like to implement
continuous (swap-file based) autosave the way vim and emacs do it. Any
suggestions for how to implement this in a cross-platform manner?

Also, is there a library that returns standard config file locations
on a per-platform basis?

martin

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

[Haskell-cafe] Conduit versions of wai and warp?

[Erik de Castro Lopo]

Hi Michael,

The current versions of wai and warp:

http://hackage.haskell.org/package/wai
http://hackage.haskell.org/package/warp

still seem to be the versions that use enumerator.

Any idea when the Conduit versions might show up on Hackage?

Until then, should I be grabbing these packages from Github?

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/

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

Re: [Haskell-cafe] Book?

[Thomas]

There is a web page for the book at
www.haskell.org/haskellwiki/Practica_interpretarii_monadice

The book itself is written in Romanian which explains your problems 
finding it.


HTH,
Thomas


On 17.01.2012 23:26, Gregory Guthrie wrote:

I've seen a book:
"The Practice Of Monadic Interpretation" Dan Popa Nov. 2008
Or
   "Practical Monadic Interpretation" Dan Popa
Which seem that they might be the same book?

As reported on Haskell Wiki/books as published in 2008, but Don't find it 
available anywhere under either title.
Any pointers or references?




___
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] Book?

[Gregory Guthrie]

I've seen a book:
   "The Practice Of Monadic Interpretation" Dan Popa Nov. 2008
Or
  "Practical Monadic Interpretation" Dan Popa
Which seem that they might be the same book?

As reported on Haskell Wiki/books as published in 2008, but Don't find it 
available anywhere under either title.
Any pointers or references?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?

[David Barbour]

I'd say use of asynchronous exceptions should be a last resort. Developers
should be encouraged to explicitly model any event notification system they
use.

Regards,

Dave

On Tue, Jan 17, 2012 at 1:42 AM, Simon Marlow  wrote:

> This is an interesting problem, I think I might incorporate parts of it
> into the next revision of my Concurrent Haskell tutorial.
>
> It sounds like you're getting overwhelmed by several different problems,
> and dealing with them separately would probably help.  e.g. you want some
> infrastructure to run two threads and send an exception to one whenever the
> other one dies.  You also want to be able to avoid a thread being
> interrupted while performing an operation that should be atomic, like
> sending a message - this is slightly tricky, because there's a tradeoff
> between keeping the thread responsive and not interrupting an operation.
>  The biggest hammer is maskUninterruptible, which can be used if all else
> fails.
>
> Whether Network.TLS supports simultaneous read and write I don't know, but
> you can examine the code or talk to the maintainer.  If it doesn't, adding
> a layer of locking is straightforward, and doesn't increase overall
> complexity (it's localised).
>
> Cheers,
>Simon
>
>
> On 14/01/2012 05:24, Joey Adams wrote:
>
>> I'm not happy with asynchronous I/O in Haskell.  It's hard to reason
>> about, and doesn't compose well.  At least in my code.
>>
>> I'm currently trying to build a networking layer for my application
>> using Network.TLS.  Here is a rather minimalist API:
>>
>>newtype Connection = Connection (TLSCtx Handle)
>>
>>connectClient :: Handle -- ^ Connection handle, as returned
>> by 'connectTo'
>>  ->  X509   -- ^ TLS certificate (i.e. public key)
>>  ->  IO Connection
>>
>>connectServer :: Handle -- ^ Connection handle, as returned
>> by 'accept'
>>  ->  X509   -- ^ TLS certificate (i.e. public key)
>>  ->  TLS.PrivateKey -- ^ TLS private key
>>  ->  IO Connection
>>
>>close :: Connection ->  IO ()
>>
>>sendMessage :: Connection ->  Message ->  IO ()
>>
>>recvMessage :: Connection ->  ByteString ->  IO (Message, ByteString)
>>
>> The module provides little more than connection initialization and
>> message serialization.  I don't try to use locks or STM to multiplex
>> the connection or, in the case of recvMessage, hide connection state.
>> I just be sure to only use sendMessage in one thread at a time, only
>> use recvMessage in one thread at a time, and marshal the "extra bytes"
>> parameter of recvMessage from call to call (with the help of StateT).
>>
>> I wrote a simple "chat server" to test it.  The client turned out okay:
>>
>>main :: IO ()
>>main = do
>>cert<- getCertificate
>>handle<- connectTo "localhost" (PortNumber 1337)
>>conn<- connectClient handle cert
>>_<- forkIO $ forever $ do
>>s<- getLine
>>sendMessage conn $ TestMessage s
>>forever $ flip runStateT B.empty $ do
>>msg<- StateT $ recvMessage conn
>>case msg of
>>TestMessage s ->
>>liftIO $ putStrLn s
>>_ ->
>>liftIO $ hPrintf stderr
>>"Warning: unrecognized message from server: %s\n"
>>(messageTypeName msg)
>>
>> The only glaring problem is that, if the user presses Ctrl+D, the
>> forked (sending) thread dies, but the main (receiving) thread lingers.
>>  I'd have to add exception handlers to ensure that when one thread
>> dies, the other thread dies too.
>>
>> However, the server is an abomination (see attachment).
>>
>> Unfortunately, it's not as simple as "spawn one thread per client".
>> We need at least two threads, one to listen for messages from the
>> client, and another to send messages to the client.  GHC won't let us
>> simultaneously, in the same thread, wait for input from a connection
>> and wait for an STM transaction to succeed.
>>
>> Another source of complexity is: what if we throw an exception at a
>> thread while it is in the middle of sending a packet?  Then we can't
>> shut down the connection properly (i.e. Network.TLS.bye), because the
>> receiver might think the close_notify packet is part of the
>> interrupted packet.
>>
>> Having a thread for each client is good, as it:
>>
>>  * Lets us think about each client separately.  No need to turn our
>> code inside out or write one big loop that juggles all the clients.
>>
>>  * Isolates exceptions.  If sendMessage or recvMessage throws an
>> exception, it doesn't bring the whole server down.
>>
>> On the other hand, having multiple threads interact with a single
>> client is hard to think about:
>>
>>  * We have to synchronize the threads (e.g. when one dies, kill the other
>> one)
>>
>>  * Multiple places where an exception can arise
>>
>>  * Can mult

Re: [Haskell-cafe] Monad-control rant

[Edward Z. Yang]

Excerpts from Mikhail Vorozhtsov's message of Tue Jan 17 06:29:12 -0500 2012:
> > The vehicle of implementation here is kind of important.  If they are 
> > implemented
> > as asynchronous exceptions, I can in fact still throw in this universe: I 
> > just
> > attempt to execute the equivalent of 'undefined :: m a'.  Since 
> > asynchronous exceptions
> > can always be thrown from pure code, I can /always/ do this, no matter how 
> > you
> > lock down the types.  Indeed, I think implementing this functionality on 
> > asynchronous
> > exceptions is a good idea, because it lets you handle nonterminating pure 
> > code nicely,
> > and allows you to bail out even when you're not doing monadic execution.
> I don't like there this is going. Arguments like this destroy the whole 
> point of having abstract interfaces. I took liftBase from you and now 
> you are picking lock on my back door with raise#. I can deny this by 
> hiding the constructor of the asynchronous exception I use for passing 
> `lavel` in my implementation. But seriously. Next thing I know you will 
> be sneaking down my chimney with `unsafePerformIO` in your hands. It is 
> no question that the type system cannot protect us from all the tricks 
> RTS provides, but we still can rely on conventions of use.
> 
> Personally I'm not a fan of exceptions in pure code. If something can 
> fail it should be reflected in its type, otherwise I consider it a bug. 
> The only scenario I'm comfortable with is using asynchronous exceptions 
> to interrupt some number crunching.

Well, that's the kind of language we live in.  The denotation of our language
always permits for bottom values, and it's not a terribly far jump from there
to undefined and error "foo".  I don't consider the use of these facilities
to be a trap door.

I like to think of this another way: because in Haskell actually contains pure 
code,
we should take advantage of this fact, and unceremoniously terminate pure code
when we like: while also having a nice semantics for what this means, to boot.

Hiding the constructor of your exception is clever, and means this argument is
nullified if your exception system (or at least bits of it: more on this later0
doesn't handle all exceptions.

> Hm, are you against splitting MonadPlus too?

The problem with MonadPlus is not the fact that it has mplus/mzero, but that
there are in fact multiple disjoint sets of laws that instances obey.  The only
other point of order is that MonadZero is a useful abstraction by itself,
and that's the point of debate.

> You are forgetting about `ST`. For example, in `ErrorT SomeException ST` 
> finalizers /do/ make sense. It's not about having IO, it is about having 
> some sort of state(fulness).

Conceded. Although there are several responses:

- We only have three magical base monads: IO, ST and STM.  In
ST we do not have any appreciable control over traditional IO exceptions,
so the discussion there is strictly limited to pure mechanisms of failure.

- Finalizing "mutable state" is a very limited use-case; unlike C++
we can't deallocate the state, unlike IO there are no external scarce
resources, so the only thing you really might see is rolling back the
state to some previous version, in which case you really ought not to
be using ST for that purpose.

> > I think that's incoherent. To draw out your MaybeT IO example to its 
> > logical conclusion,
> > you've just created two types of zeros, only one of which interacts with 
> > 'recover' but
> > both of which interact with 'finally'. Down this inconsistency lies 
> > madness!  Really,
> > we'd like 'recover' to handle Nothing's: and actually we can: introduce a 
> > distinguished
> > SomeException value that corresponds to nothings, and setup abort to 
> > transform that not
> > into an IO exception but a pure Nothing value. Then 'finally' as written 
> > works.
> I see no inconsistency here. I just give implementers an opportunity to 
> decide which failures are recoverable (with `recover`) and which are 
> not, without sacrificing proper resource/state management. You approach 
> rejects unrecoverable failures completely. Back to this particular case. 
> I implemented `MonadRecover e (MaybeT μ)` this way because that's how I 
> usually use `MaybeT IO`: `catch` for exceptions, `mplus` for `mzero`s. 
> BTW that is also how STM works: `catchSTM` for exceptions, `orElse` for 
> `retry`s. Ideally we should have different ways of recovering from 
> different kinds of failures (and some kinds should not be allowed to be 
> "thrown" by client code) in our abstract setting too. But I don't think 
> that's easily expressible in the type system we have today (at least 
> without confusing type inference). Injecting failures into exception 
> hierarchy is too value-level for me.

You are free to create another interface that supports "unrecoverable"
exceptions, and to supply appropriate semantics for this more complicated
interface. Howev

Re: [Haskell-cafe] Need advice: Haskell in Web Client

[dokondr]

On Tue, Jan 17, 2012 at 6:42 PM, John Lenz  wrote:

>
> HTML5 Canvas is great for charts.  If you go this route you might as well
> use a library which draws charts for you instead of writing all this code
> yourself.
>
> Personally, I use extjs version 4 which has some amazing charts, but there
> are other libraries out there.
>
> http://www.sencha.com/**products/extjs/examples/#**sample-3
>
> Essentially the server provides the data in JSON or XML some other format,
> and the extjs code draws the charts on the client side.
>
> If you go with extjs, then the server side I would suggest a small, simple
> yesod or snap server.   You could probably get the server under a hundred
> lines of code with yesod; see some of the examples in the yesod book.
>  yesod or snap would serve JSON of the statistics on request, and also
> serve the javascript files which draw the charts.
>

Yes, I was thinking about using Haskell to generate everything that
specific Javascript library needs to display charts in browser. Naturally
charts are to be displayed by this library itself. I also would like to
have Haskell tools to generate Web GUI in Javascript.
As for yesod, I am not sure that I like approach which mixes HTML with
code, or even worse - creates a new weird HTML-like language like  'whamlet
quasi-quotation', for example:



I prefer using Turing complete PL to program web client, like the one used
in GWT (Java) or Cappuccino  (Objective-J). http://cappuccino.org/learn/
In this case you /almost/ don't need to know  HTML, CSS, DOM, Ajax, etc. to
develop WebUI and good PL lets you concentrate on problem domain instead of
bothering about browser support.
It is a real pity that Haskell still has no such tools to generate Web GUI
in Javascript. (((
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad-control rant

[Brandon Allbery]

On Tue, Jan 17, 2012 at 06:29, Mikhail Vorozhtsov <
mikhail.vorozht...@gmail.com> wrote:

> I wouldn't be too optimistic about convincing GHC HQ. Even making
> Applicative a superclass of Monad can make Haskell98 nazis come after you
> in ninja suits.


What?!  The only significant complaint I've seen here is that the necessary
language support for doing so without breaking more or less every Haskell
program currently in existence is difficult to achieve.

On the other hand, I suppose if you're sufficiently fanatical, breaking
more or less every Haskell program currently in existence might be viewed
as a minor issue that you think nobody has any right to be upset about.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need advice: Haskell in Web Client

[Rogan Creswick]

On Tue, Jan 17, 2012 at 3:07 AM, C K Kashyap  wrote:
>
> Perhaps HTML5's canvas element would meet your requirement. There a few JS
> chart implementation for HTML5 floating on the internet.

The Google Charting API *might* be sufficient:

http://code.google.com/apis/chart/

--Rogan

> Regards,
> Kashap
>
> ___
> 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] Please upgrade http-enumerator and/or http-conduit

[Michael Snoyman]

Hi all,

Thanks to Felipe for catching this issue[1]. Both http-enumerator and
http-conduit will not properly reject invalid certificates. I've
released updated versions of both packages:

http-enumerator-0.7.2.4
http-conduit-1.1.2.2

All users are recommended to upgrade.

Michael

[1] https://github.com/snoyberg/http-conduit/pull/6

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

[Haskell-cafe] Pruned Sparks in Original Strategies

[Burak Ekici]

Dear List,

I am trying to parallelize some number of codes with
using Haskell's original and second generation strategies
in order to be able to compare them.

As far as I understood, in original strategies, ROOT
garbage collection mechanism is used which does
not allow any spark to be pruned. Since, they do not
return any information back to its caller. (a type of
void reference making fizzling of a spark impossible,
is returned), However, in most of my measurements,
spraks are being pruned.

I wonder the reasons why this incident occurs? Do you
have any idea?

Many thanks,
Burak.


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

Re: [Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4

[Nicolas Trangez]

On Tue, 2012-01-17 at 15:35 +0400, Eugene Kirpichov wrote:
> Hi,
> 
> I'm fixing a build error in a package that depends on the RTS API, which
> changed in 7.4, using #if __GLASGOW_HASKELL__ >= 740.
> 
> However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as
> I'd expect.
> 
> Is this a bug?

I don't think so. I recently came across [1]:

'''
Stable Releases
Stable branches are numbered x.y, where y is even. Releases on the
stable branch x.y are numbered x.y.z, where z (>= 1) is the patchlevel
number. Patchlevels are bug-fix releases only, and never change the
programmer interface to any system-supplied code. However, if you
install a new patchlevel over an old one you will need to recompile any
code that was compiled against the old libraries.

The value of __GLASGOW_HASKELL__ (see Section 4.11.3, “Options affecting
the C pre-processor”) for a major release x.y.z is the integer xyy (if y
is a single digit, then a leading zero is added, so for example in
version 6.8.2 of GHC we would have __GLASGOW_HASKELL__==608).
'''

As such, release 7.4.0 would yield __GLASGOW_HASKELL__ 704.

Nicolas

[1]
http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/version-numbering.html


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

Re: [Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4

[Eugene Kirpichov]

My bad, it *should* really be 704.
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor

On Tue, Jan 17, 2012 at 3:35 PM, Eugene Kirpichov wrote:

> Hi,
>
> I'm fixing a build error in a package that depends on the RTS API, which
> changed in 7.4, using #if __GLASGOW_HASKELL__ >= 740.
>
> However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as
> I'd expect.
>
> Is this a bug?
>
> --
> Eugene Kirpichov
> Principal Engineer, Mirantis Inc. http://www.mirantis.com/
> Editor, http://fprog.ru/
>



-- 
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] __GLASGOW_HASKELL__ for GHC 7.4

[Eugene Kirpichov]

Hi,

I'm fixing a build error in a package that depends on the RTS API, which
changed in 7.4, using #if __GLASGOW_HASKELL__ >= 740.

However, build log shows that __GLASGOW_HASKELL__ is still 704, not 740 as
I'd expect.

Is this a bug?

-- 
Eugene Kirpichov
Principal Engineer, Mirantis Inc. http://www.mirantis.com/
Editor, http://fprog.ru/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad-control rant

[Mikhail Vorozhtsov]

On 01/17/2012 03:00 AM, Edward Z. Yang wrote:
[snip]

I don't think it makes too much sense have thing pick off a menu of
Abort/Recover/Finally from a semantics perspective:


It's easy to imagine monads that have an instance of one of the classes but
not of the others


I'd like to see some examples.  I hypothesize that most of such monads are
incoherent, semantically speaking.  For example, what does it mean to have a
monad that can recover exceptions, but for which you can't throw exceptions?

Imagine a monad that disallows lifting of arbitrary IO actions, but can
receive asynchronous events (which would probably be /implemented/ on
top of asynchronous exceptions, but that's not important here) that
behave like runtime-inserted left zeros.

COMPUTATIONALLY_HEAVY_CODE `recover` \level →
GIVE_AN_APPROXIMATION_INSTEAD(level)


The vehicle of implementation here is kind of important.  If they are 
implemented
as asynchronous exceptions, I can in fact still throw in this universe: I just
attempt to execute the equivalent of 'undefined :: m a'.  Since asynchronous 
exceptions
can always be thrown from pure code, I can /always/ do this, no matter how you
lock down the types.  Indeed, I think implementing this functionality on 
asynchronous
exceptions is a good idea, because it lets you handle nonterminating pure code 
nicely,
and allows you to bail out even when you're not doing monadic execution.
I don't like there this is going. Arguments like this destroy the whole 
point of having abstract interfaces. I took liftBase from you and now 
you are picking lock on my back door with raise#. I can deny this by 
hiding the constructor of the asynchronous exception I use for passing 
`lavel` in my implementation. But seriously. Next thing I know you will 
be sneaking down my chimney with `unsafePerformIO` in your hands. It is 
no question that the type system cannot protect us from all the tricks 
RTS provides, but we still can rely on conventions of use.


Personally I'm not a fan of exceptions in pure code. If something can 
fail it should be reflected in its type, otherwise I consider it a bug. 
The only scenario I'm comfortable with is using asynchronous exceptions 
to interrupt some number crunching.


But, for the sake of argument, so let's suppose that they're not done as
asynchronous exceptions; essentially, you define some 'safe points' which have
the possibility to raise exceptions.  In this case, I claim there will never be
a *technical* difficulty against implementing manually thrown exceptions; the
concern here is "you don't want the user to do that."  With some sets of
operations, this isn't a very strong injunction; if there is a deterministic
set of operations that results in an error, the user can make a gadget which is
semantically equivalent to a thrown exception.  I don't think I can argue 
anything
stronger here, so I concede the rest of the point.

So, to summarize, such an interface (has recovery but not masking or throwing)
always has a trivial throw instance unless you are not implementing it on top
of asynchronous exceptions.

Your example reminds me of what happens in pure code. In this context, we have
the ability to throw errors and map over errors (although I'm not sure how 
people
feel about that, semantically), but not to catch them or mask them.  But I don't
think we need another typeclass for that.

Hm, are you against splitting MonadPlus too?

[snip]

The purpose of monad-abort-fd is to provide a generic API for handling errors
that have values attached to them and for guarding actions with finalizers
(as the notion of failure can include more things besides the errors).


Here's the reason I'm so fixated on IO: There is a very, /very/ bright line
between code that does IO, and pure code.  You can have arbitrary stacks of
monads, but at the end of the day, if IO is not at the end of the line, your
code is pure.

If your code is pure, you don't need finalizers. (Indeed, this is the point
of pure code...)  I can abort computations willy nilly.  I can redo them willy
nilly.  You get a lot of bang for your buck if you're pure.

I don't understand what the "too much IO" objection is about.  If there is no
IO (now, I don't mean a MonadIO instance, but I do mean, in order to interpret
the monad), it seems to me that this API is not so useful.
You are forgetting about `ST`. For example, in `ErrorT SomeException ST` 
finalizers /do/ make sense. It's not about having IO, it is about having 
some sort of state(fulness).



No, you can't. MonadFinally instances must (I really should write
documentation) handle /all/ possible failures, not just exceptions. The
naive

finally ∷ MonadRecover e μ ⇒ μ α → μ β → μ α
finally m f = do
a ← m `recover` \e → f>>  abort e
void $ f
return a

wouldn't work in `MaybeT IO`, just consider `finally mzero f`.


I think that's incoherent. To draw out your MaybeT IO example to its logical 
conclusion,
you've just created two types of zeros, on

Re: [Haskell-cafe] Need advice: Haskell in Web Client

[C K Kashyap]

On Tue, Jan 17, 2012 at 4:19 PM, dokondr  wrote:

> Hi all,
> I hope to use Haskell for graphics (charts) programming in Web client.
>
> My current implementation in brief:
> Server side, Haskell modules:
> 1) collecting various statistics from Twitter
> 2) generating text data for Gnuplot (http://www.gnuplot.info/)
> 3) Gnuplot creates png files with charts
>
> Web client:
> GWT (Google Web Toolkit) web UI that allows user to enter queries and see
> resulting charts  in Web browser. Charts are png files generated by Gnuplot
> on the server side.
>
> Ideally, on the server side  instead of using Gnuplot I would like Haskell
> to generate Javascript to be downloaded to Web client and draw charts in
> the browser. Something, very approximately, similar to what GWT does :)
> This code will be specific of course to plotting Javascript framework, no
> problem.
> Looking at "Haskell in web browser - HaskellWiki:"
>
> http://www.haskell.org/haskellwiki/Haskell_in_web_browser#Haskell_web_toolkit
> I feel a little confused about current state of the available Haskell
> tools for this task.
> Any ideas?
>
> Hi Dimitri,
Perhaps HTML5's canvas element would meet your requirement. There a few JS
chart implementation for HTML5 floating on the internet.
Regards,
Kashap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Need advice: Haskell in Web Client

[dokondr]

Hi all,
I hope to use Haskell for graphics (charts) programming in Web client.

My current implementation in brief:
Server side, Haskell modules:
1) collecting various statistics from Twitter
2) generating text data for Gnuplot (http://www.gnuplot.info/)
3) Gnuplot creates png files with charts

Web client:
GWT (Google Web Toolkit) web UI that allows user to enter queries and see
resulting charts  in Web browser. Charts are png files generated by Gnuplot
on the server side.

Ideally, on the server side  instead of using Gnuplot I would like Haskell
to generate Javascript to be downloaded to Web client and draw charts in
the browser. Something, very approximately, similar to what GWT does :)
This code will be specific of course to plotting Javascript framework, no
problem.
Looking at "Haskell in web browser - HaskellWiki:"
http://www.haskell.org/haskellwiki/Haskell_in_web_browser#Haskell_web_toolkit
I feel a little confused about current state of the available Haskell tools
for this task.
Any ideas?

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

Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?

[Simon Marlow]

This is an interesting problem, I think I might incorporate parts of it 
into the next revision of my Concurrent Haskell tutorial.


It sounds like you're getting overwhelmed by several different problems, 
and dealing with them separately would probably help.  e.g. you want 
some infrastructure to run two threads and send an exception to one 
whenever the other one dies.  You also want to be able to avoid a thread 
being interrupted while performing an operation that should be atomic, 
like sending a message - this is slightly tricky, because there's a 
tradeoff between keeping the thread responsive and not interrupting an 
operation.  The biggest hammer is maskUninterruptible, which can be used 
if all else fails.


Whether Network.TLS supports simultaneous read and write I don't know, 
but you can examine the code or talk to the maintainer.  If it doesn't, 
adding a layer of locking is straightforward, and doesn't increase 
overall complexity (it's localised).


Cheers,
Simon

On 14/01/2012 05:24, Joey Adams wrote:

I'm not happy with asynchronous I/O in Haskell.  It's hard to reason
about, and doesn't compose well.  At least in my code.

I'm currently trying to build a networking layer for my application
using Network.TLS.  Here is a rather minimalist API:

newtype Connection = Connection (TLSCtx Handle)

connectClient :: Handle -- ^ Connection handle, as returned
by 'connectTo'
  ->  X509   -- ^ TLS certificate (i.e. public key)
  ->  IO Connection

connectServer :: Handle -- ^ Connection handle, as returned
by 'accept'
  ->  X509   -- ^ TLS certificate (i.e. public key)
  ->  TLS.PrivateKey -- ^ TLS private key
  ->  IO Connection

close :: Connection ->  IO ()

sendMessage :: Connection ->  Message ->  IO ()

recvMessage :: Connection ->  ByteString ->  IO (Message, ByteString)

The module provides little more than connection initialization and
message serialization.  I don't try to use locks or STM to multiplex
the connection or, in the case of recvMessage, hide connection state.
I just be sure to only use sendMessage in one thread at a time, only
use recvMessage in one thread at a time, and marshal the "extra bytes"
parameter of recvMessage from call to call (with the help of StateT).

I wrote a simple "chat server" to test it.  The client turned out okay:

main :: IO ()
main = do
cert<- getCertificate
handle<- connectTo "localhost" (PortNumber 1337)
conn<- connectClient handle cert
_<- forkIO $ forever $ do
s<- getLine
sendMessage conn $ TestMessage s
forever $ flip runStateT B.empty $ do
msg<- StateT $ recvMessage conn
case msg of
TestMessage s ->
liftIO $ putStrLn s
_ ->
liftIO $ hPrintf stderr
"Warning: unrecognized message from server: %s\n"
(messageTypeName msg)

The only glaring problem is that, if the user presses Ctrl+D, the
forked (sending) thread dies, but the main (receiving) thread lingers.
  I'd have to add exception handlers to ensure that when one thread
dies, the other thread dies too.

However, the server is an abomination (see attachment).

Unfortunately, it's not as simple as "spawn one thread per client".
We need at least two threads, one to listen for messages from the
client, and another to send messages to the client.  GHC won't let us
simultaneously, in the same thread, wait for input from a connection
and wait for an STM transaction to succeed.

Another source of complexity is: what if we throw an exception at a
thread while it is in the middle of sending a packet?  Then we can't
shut down the connection properly (i.e. Network.TLS.bye), because the
receiver might think the close_notify packet is part of the
interrupted packet.

Having a thread for each client is good, as it:

  * Lets us think about each client separately.  No need to turn our
code inside out or write one big loop that juggles all the clients.

  * Isolates exceptions.  If sendMessage or recvMessage throws an
exception, it doesn't bring the whole server down.

On the other hand, having multiple threads interact with a single
client is hard to think about:

  * We have to synchronize the threads (e.g. when one dies, kill the other one)

  * Multiple places where an exception can arise

  * Can multiple threads interact with the connection handle simultaneously?

So why don't I make my connection API handle some of this?  Well, I
tried.  There are so many ways to do it, and I couldn't find a way
that simplified usage much.  The approach used by Handle and by
Network.TLS is to use MVars and IORefs to ensure that, if two threads
access the same connection, the connection doesn't become totally
corrupt.  If I do the same, then I'll have *three* layers of lo

[Haskell-cafe] Happy holidays Haskell

[R J]

hey Haskell I didn't believe this at all until I started 
http://www.news13wise.com

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

Re: [Haskell-cafe] decoupling type classes

[Dominique Devriese]

2012/1/16 Yin Wang :
 The typical example would be

 instance Eq a => Eq [a] where
  [] == [] = True
  (a : as) == (b : bs) = a == b && as == bs
  _ == _ = False
>>>
>>> It can handle this case, although it doesn't handle it as a parametric
>>> instance. I suspect that we don't need the concept of "parameter
>>> instances" at all. We just searches for instances recursively at the
>>> call site:
>>
>> That seems like it could work, but typically, one would like
>> termination guarantees for this search, to avoid the type-checker
>> getting stuck...
>
> Good point. Currently I'm guessing that we need to keep a stack of the
> traced calls. If a recursive call needs an implicit parameter X which
> is matched by one of the functions in the stack, we back up from the
> stack and resolve X to the function found on stack.

You may want to look at scala's approach for their implicit arguments.
They use a certain to conservatively detect infinite loops during the
instance search, but I don't remember the details off hand. While
talking about related work, you may also want to take a look at
Scala's implicit arguments, GHC implicit arguments and C++ concepts...

>
>>> foo x =
>>>   let overload bar (x:Int) = x + 1
>>>   in \() -> bar x
>>>
>>>
>>> baz =
>>>  in foo (1::Int)
>>>
>>> Even if we have only one definition of "bar" in the program, we should
>>> not resolve it to the definition of "bar" inside foo. Because that
>>> "bar" is not visible at the call site "foo (1::int)". We should report
>>> an error in this case. Think of "bar" as a "typed dynamically scoped
>>> variable" helps to justify this decision.
>>
>> So you're saying that any function that calls an overloaded function
>> should always allow its own callers to provide this, even if a correct
>> instance is in scope. Would that mean all instances have to be
>> resolved from main? This also strikes me as strange, since I gather
>> you would get something like "length :: Monoid Int => [a] -> Int",
>> which would break if you happen to have a multiplicative monoid in
>> scope at the call site?
>
> If you already have a correct instance in scope, then you should have
> no way defining another instance with the same name and type in the
> scope as the existing one. This is the case for Haskell.

Yes, but different ones may be in scope at different places in the code, right?

> But it may be useful to allow nested definitions (using let) to shadow
> the existing instances in the outer scope of the overloaded call.

I considered something like this for instance arguments in Agda, but
it was hard to make the instance resolution deterministic when
allowing such a form of prioritisation. The problem occurred if a
shadower and shadowee instance had slightly different types, such that
only the shadowee was actually type-valid for a certain instance
argument. However, the type information which caused the shadower to
become invalid only became available late in the type inference
process. In such a case, it is necessary to somehow ascertain that the
shadower instance is not chosen, but I did not manage to figure out
how to get this right.

Dominique

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