Re: [Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup

[Lyndon Maydwell]

Hi Michael,


The behaviour of my original code has now changed to output nothing
with no errors. I'm not sure of the significance of this as my code
was incorrect, however, using the code you demonstrated gives the
desired results.

Thanks for the blindingly quick response!


On Tue, Feb 21, 2012 at 3:30 PM, Michael Snoyman  wrote:
> On Tue, Feb 21, 2012 at 7:40 AM, Michael Snoyman  wrote:
>> On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell  wrote:
>>> Hi Michael, Café.
>>>
>>> I'm writing some code using the conduit library and am encountering
>>> the following error output (while the program appears to function
>>> correctly) when using Data.Conduit.Lazy.
>>>
>>> The error given is:
>>>
 profile_simple_test_data: Control.Monad.Trans.Resource.stateCleanup: There 
 is a bug in the implementation. The mutable state is being accessed after 
 cleanup. Please contact the maintainers.
>>>
>>> A reduced code snippet that generates this error is (also attached):
>>>
 import Control.Monad
 import System.Environment
 import Control.Monad.IO.Class (liftIO)
 import System.IO
 import Data.Conduit.Lazy
 import Data.List (sort)

 import Data.Conduit

 import Prelude hiding (map)

 main = getArgs >>= process

 process args = mapM_ sorted args

 sorted x = runResourceT (lazyConsume $ sourceFeed x) >>= (mapM_ print . id)

 sourceFeed :: ResourceIO m => FilePath -> Source m String
 sourceFeed file = sourceIO
     (openFile file ReadMode)
     hClose
     (\h -> liftIO $ do
         eof <- hIsEOF h
         if eof
             then return IOClosed
             else fmap IOOpen $ hGetLine h)
>>>
>>> when run over any text file.
>>>
>>> I may be doing something inconsistent with the correct use of sourceIO
>>> or lazyConsume, however, I tried to follow the example at
>>> http://www.yesodweb.com/home/snoyberg/blogs/conduit/conduit/source/source.ditamap?nav=nav-2
>>> as closely as possible.
>>>
>>> Is this a bug, or simply an incorrect use of Conduit?
>>
>> I haven't fully debugged this yet. There's certainly a bug in the
>> implementation of ResourceT, but the sample program is also wrong. You
>> can't pass the result from a call to lazyConsume outside the scope of
>> its ResourceT; the correct way to write sorted would be:
>>
>>    sorted x = runResourceT $ lazyConsume (sourceFeed x) >>= mapM_
>> (liftIO . print)
>>
>> My guess is that this is a fallout from the transition away from
>> mutable variables: lazyConsume no longer has any way of knowing that
>> its ResourceT has already been terminated. Perhaps a simple solution
>> would be to expose a primitive that checks if the ResourceT block has
>> already been finalized.
>>
>> Michael
>
> I've added a test case for this bug, and fixed it. The commit is:
>
> https://github.com/snoyberg/conduit/commit/87e890fe7ee58686d20cabba15dd37f18ba66620
>
> The basic idea is to add an extra constructor to represent when the
> ResourceT has already been closed, and expose a function
> resourceActive to check the state. Can you check if this solves your
> problem?
>
> Michael

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

[Haskell-cafe] Need Help.

[Manoj Chaudhari]

Hi,

We are looking for senior technical resources with skills in
Haskell/Functional programming.
Experience : 6 to 20 years,

Job Location : Pune (India).


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

Re: [Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup

[Michael Snoyman]

On Tue, Feb 21, 2012 at 7:40 AM, Michael Snoyman  wrote:
> On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell  wrote:
>> Hi Michael, Café.
>>
>> I'm writing some code using the conduit library and am encountering
>> the following error output (while the program appears to function
>> correctly) when using Data.Conduit.Lazy.
>>
>> The error given is:
>>
>>> profile_simple_test_data: Control.Monad.Trans.Resource.stateCleanup: There 
>>> is a bug in the implementation. The mutable state is being accessed after 
>>> cleanup. Please contact the maintainers.
>>
>> A reduced code snippet that generates this error is (also attached):
>>
>>> import Control.Monad
>>> import System.Environment
>>> import Control.Monad.IO.Class (liftIO)
>>> import System.IO
>>> import Data.Conduit.Lazy
>>> import Data.List (sort)
>>>
>>> import Data.Conduit
>>>
>>> import Prelude hiding (map)
>>>
>>> main = getArgs >>= process
>>>
>>> process args = mapM_ sorted args
>>>
>>> sorted x = runResourceT (lazyConsume $ sourceFeed x) >>= (mapM_ print . id)
>>>
>>> sourceFeed :: ResourceIO m => FilePath -> Source m String
>>> sourceFeed file = sourceIO
>>>     (openFile file ReadMode)
>>>     hClose
>>>     (\h -> liftIO $ do
>>>         eof <- hIsEOF h
>>>         if eof
>>>             then return IOClosed
>>>             else fmap IOOpen $ hGetLine h)
>>
>> when run over any text file.
>>
>> I may be doing something inconsistent with the correct use of sourceIO
>> or lazyConsume, however, I tried to follow the example at
>> http://www.yesodweb.com/home/snoyberg/blogs/conduit/conduit/source/source.ditamap?nav=nav-2
>> as closely as possible.
>>
>> Is this a bug, or simply an incorrect use of Conduit?
>
> I haven't fully debugged this yet. There's certainly a bug in the
> implementation of ResourceT, but the sample program is also wrong. You
> can't pass the result from a call to lazyConsume outside the scope of
> its ResourceT; the correct way to write sorted would be:
>
>    sorted x = runResourceT $ lazyConsume (sourceFeed x) >>= mapM_
> (liftIO . print)
>
> My guess is that this is a fallout from the transition away from
> mutable variables: lazyConsume no longer has any way of knowing that
> its ResourceT has already been terminated. Perhaps a simple solution
> would be to expose a primitive that checks if the ResourceT block has
> already been finalized.
>
> Michael

I've added a test case for this bug, and fixed it. The commit is:

https://github.com/snoyberg/conduit/commit/87e890fe7ee58686d20cabba15dd37f18ba66620

The basic idea is to add an extra constructor to represent when the
ResourceT has already been closed, and expose a function
resourceActive to check the state. Can you check if this solves your
problem?

Michael

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

Re: [Haskell-cafe] Monad laws in presence of bottoms

[Roman Cheplyaka]

* Sebastian Fischer  [2012-02-21 00:28:13+0100]
> On Mon, Feb 20, 2012 at 7:42 PM, Roman Cheplyaka  wrote:
> 
> > Is there any other interpretation in which the Reader monad obeys the
> > laws?
> 
> 
> If "selective strictness" (the  seq  combinator) would exclude function
> types, the difference between  undefined  and  \_ -> undefined  could not
> be observed. This reminds me of the different language levels used by the
> free theorem generator [1] and the discussions whether  seq  should have a
> type-class constraint..

It's not just about functions. The same holds for the lazy Writer monad,
for instance.

-- 
Roman I. Cheplyaka :: http://ro-che.info/

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

[Haskell-cafe] ANN: network-socket-options 0.1

[Joey Adams]

I added a new package containing wrappers for getsockopt and setsockopt:

http://hackage.haskell.org/package/network-socket-options

The network package already has getSocketOption and setSocketOption.
The problem is, these don't work for socket options that aren't
represented by integers, such as SO_LINGER:

http://trac.haskell.org/network/ticket/23

Another, less serious problem is that getSocketOption and
setSocketOption don't leverage the type system as well as they could.
Many options are boolean values; it'd be better to get and set them
with 'Bool's instead of 'Int's.

network-socket-options implements options using getter and setter
functions, e.g.:

getLinger :: HasSocket sock => sock -> IO (Maybe Seconds)

setLinger :: HasSocket sock => sock -> Maybe Seconds -> IO ()

type Seconds = Int

The HasSocket type class is defined to overload the getters and
setters to work on raw file descriptors, not just Socket objects.

This functionality should probably go in the network package itself.
However, I decided to release it as a separate package so I could
start using it sooner.  If people like it enough, perhaps the network
package can absorb it, as was done with network-bytestring.

-Joey Adams

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

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles

[Johan Tibell]

On Mon, Feb 20, 2012 at 9:23 PM, Iavor Diatchki
 wrote:
> I started with the legend but it was too big on the program that i was
> profiling, so i switched to the hovering mode. I agree that it is not
> optimal. Perhaps there's a way to instruct flot to show only some of the
> entries or, better, order them in some useful way.  I'm no flot expert, so
> ideas (or patches) on how to do it would be most appreciated!

Big in what sense? Area wise? You could perhaps put it outside the flot graph.

-- Johan

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

Re: [Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup

[Michael Snoyman]

On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell  wrote:
> Hi Michael, Café.
>
> I'm writing some code using the conduit library and am encountering
> the following error output (while the program appears to function
> correctly) when using Data.Conduit.Lazy.
>
> The error given is:
>
>> profile_simple_test_data: Control.Monad.Trans.Resource.stateCleanup: There 
>> is a bug in the implementation. The mutable state is being accessed after 
>> cleanup. Please contact the maintainers.
>
> A reduced code snippet that generates this error is (also attached):
>
>> import Control.Monad
>> import System.Environment
>> import Control.Monad.IO.Class (liftIO)
>> import System.IO
>> import Data.Conduit.Lazy
>> import Data.List (sort)
>>
>> import Data.Conduit
>>
>> import Prelude hiding (map)
>>
>> main = getArgs >>= process
>>
>> process args = mapM_ sorted args
>>
>> sorted x = runResourceT (lazyConsume $ sourceFeed x) >>= (mapM_ print . id)
>>
>> sourceFeed :: ResourceIO m => FilePath -> Source m String
>> sourceFeed file = sourceIO
>>     (openFile file ReadMode)
>>     hClose
>>     (\h -> liftIO $ do
>>         eof <- hIsEOF h
>>         if eof
>>             then return IOClosed
>>             else fmap IOOpen $ hGetLine h)
>
> when run over any text file.
>
> I may be doing something inconsistent with the correct use of sourceIO
> or lazyConsume, however, I tried to follow the example at
> http://www.yesodweb.com/home/snoyberg/blogs/conduit/conduit/source/source.ditamap?nav=nav-2
> as closely as possible.
>
> Is this a bug, or simply an incorrect use of Conduit?

I haven't fully debugged this yet. There's certainly a bug in the
implementation of ResourceT, but the sample program is also wrong. You
can't pass the result from a call to lazyConsume outside the scope of
its ResourceT; the correct way to write sorted would be:

sorted x = runResourceT $ lazyConsume (sourceFeed x) >>= mapM_
(liftIO . print)

My guess is that this is a fallout from the transition away from
mutable variables: lazyConsume no longer has any way of knowing that
its ResourceT has already been terminated. Perhaps a simple solution
would be to expose a primitive that checks if the ResourceT block has
already been finalized.

Michael

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

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles

[Iavor Diatchki]

Hello,

On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell wrote:

>
> Looks really nice.

Thanks!


> The hovering behavior is nice, but I'd like to see
> the legend as well. It makes it quicker when you want to get a quick
> overview of what types there are, as the eye can travel back-and-forth
> between the graph and the legend.


I started with the legend but it was too big on the program that i was
profiling, so i switched to the hovering mode. I agree that it is not
optimal. Perhaps there's a way to instruct flot to show only some of the
entries or, better, order them in some useful way.  I'm no flot expert, so
ideas (or patches) on how to do it would be most appreciated!

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

Re: [Haskell-cafe] Streaming to JuicyPixels

[Myles C. Maxfield]

Hello, and thanks for the quick reply.

You're right that using (remaining >> getBytes) won't work for streaming,
as it would pull the rest of the stream into a buffer, thereby delaying
further processing until the image is completely downloaded. :-(

I'm a little unclear about what you mean about the use of the ST monad.
There is an 
STT
monad
transformer, so you could wrap that around Get. Is that what you're
referring to?

As an aside: I didn't realize that JuicyPixels existed, so I wrote a JPEG
decoder specifically designed for streaming - it doesn't request a byte of
input unless it has to, uses a StateT (wrapped around Attoparsec) to keep
track of which bit in the current byte is "next", and does the Huffman
decoding in-line. However, I didn't use ST for the IDCT, so my own decoder
has serious performance problems. This prompted me to start searching
around for a solution, and I came across JuicyPixels, which already exists
and is much faster than my own implementation. I'm hoping to get rid of my
own decoder and just use JuicyPixels. If you're curious, my own code is
here: https://github.com/litherum/jpeg.

Is it reasonable to extend JuicyPixels to fit my use case? It sounds like
JuicyPixels wouldn't work so well as it stands. I'd be happy to do whatever
work is necessary to help out and get JuicyPixels usable for me. However,
if that would require a full (or near-full) rewrite, it might make more
sense for me to use my own implementation with your IDCT. Is there a way we
can share just the IDCT between our two repositories? Perhaps making a new
IDCT8 library that we can both depend on?

As for what API I'd like to be able to use, just a "Get DynamicImage"
should suffice (assuming it has streaming semantics as described above). It
would be really nice if it was possible to get at the incomplete image
before the stream is completed (so the image could slowly update as more
data arrives from the network), but I'm not quite sure how to elegantly
express that. Do you have any ideas?

I think that having 2 native jpeg decoders (Actually 3, because of this
package ) is detrimental to the
Haskell community, and I would really like to use JuicyPixels :D

Thanks,
Myles C. Maxfield

On Mon, Feb 20, 2012 at 3:01 PM, Vincent Berthoux <
vincent.berth...@gmail.com> wrote:

> Hi,
>
>  I can expose the low level parsing, but you would only get the
> chunks/frames/sections of the image, Cereal is mainly used to parse the
> structure of the image, not to do the raw processing. For the raw
> processing, I rely on `remaining >> getBytes` to be able to manipulate data
> at bit level or to feed it to zlib, and the documentation clearly state
> that remaining doesn't work well with runGetPartial, so no read ahead, but
> even worse for streaming :).
>
> To be fair, I never thought of this use case, and exposing a partially
> decoded image would impose the use of the ST Monad somehow, and Serialize
> is not a monad transformer, making it a bit hard to implement.
>
> By curiosity what kind of API would you hope for this kind of
> functionality?
>
> Regards
>
> Vincent Berthoux
>
> Le 20 février 2012 22:08, Myles C. Maxfield  a
> écrit :
>
> Hello,
>> I am interested in the possibility of using JuicyPixels for streaming
>> images from the web. It doesn't appear to expose any of its internally-used
>> Serialize.Get functionality, which is problematic for streaming - I would
>> not like to have to stream the whole image into a buffer before the decoder
>> can start decoding. Are there any plans on exposing this API, so I can use
>> the runGetPartial function to facilitate streaming?
>>
>> In addition, does the library do much readahead? There's no point in
>> exposing a Get interface if it's just going to wait until the stream is
>> done to start decoding anyway.
>>
>>  Thanks,
>> Myles C. Maxfield
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup

[Lyndon Maydwell]

Hi Michael, Café.

I'm writing some code using the conduit library and am encountering
the following error output (while the program appears to function
correctly) when using Data.Conduit.Lazy.

The error given is:

> profile_simple_test_data: Control.Monad.Trans.Resource.stateCleanup: There is 
> a bug in the implementation. The mutable state is being accessed after 
> cleanup. Please contact the maintainers.

A reduced code snippet that generates this error is (also attached):

> import Control.Monad
> import System.Environment
> import Control.Monad.IO.Class (liftIO)
> import System.IO
> import Data.Conduit.Lazy
> import Data.List (sort)
>
> import Data.Conduit
>
> import Prelude hiding (map)
>
> main = getArgs >>= process
>
> process args = mapM_ sorted args
>
> sorted x = runResourceT (lazyConsume $ sourceFeed x) >>= (mapM_ print . id)
>
> sourceFeed :: ResourceIO m => FilePath -> Source m String
> sourceFeed file = sourceIO
> (openFile file ReadMode)
> hClose
> (\h -> liftIO $ do
> eof <- hIsEOF h
> if eof
> then return IOClosed
> else fmap IOOpen $ hGetLine h)

when run over any text file.

I may be doing something inconsistent with the correct use of sourceIO
or lazyConsume, however, I tried to follow the example at
http://www.yesodweb.com/home/snoyberg/blogs/conduit/conduit/source/source.ditamap?nav=nav-2
as closely as possible.

Is this a bug, or simply an incorrect use of Conduit?


conduit_error.hs
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles

[Johan Tibell]

Hi Iavor,

On Mon, Feb 20, 2012 at 6:45 PM, Iavor Diatchki
 wrote:
> Hello,
>
> I am happy to announce the availability of a little tool that I wrote while
> I was doing some Haskell profiling.  It converts GHC's heap-profiles into
> HTML, and renders them nicely using the flot library.  Its functionality is
> similar to `hp2ps`.  I wrote it because I find the HTML output easier to
> work with and, also, because it can cope with partial profiles, so one can
> refresh the profile while the program is running.  The tool is a very short
> Haskell program, so it should be quite easy to modify and improve (and there
> is a lot that can be improved in it! :-).

Looks really nice. The hovering behavior is nice, but I'd like to see
the legend as well. It makes it quicker when you want to get a quick
overview of what types there are, as the eye can travel back-and-forth
between the graph and the legend.

-- Johan

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

Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[AntC]

Gábor Lehel  gmail.com> writes:

> 
> On Mon, Feb 20, 2012 at 4:41 AM, AntC  clear.net.nz> 
wrote:
> > Folks, I've put my 'Record in Haskell' proposal on the wiki
> > http://hackage.haskell.org/trac/ghc/wiki/Records  as suggestion 5 Declared
> > Overloaded Record Fields.
> >
> > Feedback welcome.
> 
> 
> I was wondering whether it wouldn't make sense to have some syntax
> within the record itself, instead of at the top level, to declare,
> "I'm definitely declaring a new record field", versus "I'm definitely
> re-using an existing record field", versus "If this record field
> already exists I'm re-using it, otherwise I'm declaring it". ...
> 

We're trying to minimise the changes (and be backward compatible, if 
possible), so I think a single compiler option at module level is enough, 
without introducing tricky syntax in the record decls.

Option absent means H98 behaviour.
Option present means _all_ my record decls are using pre-defined record fields.

Note that this only affects the modules where the records (and fieldLabels) 
are declared.

In the application code which uses the records, just apply the field selector 
function to the record, or use familiar record update syntax. You don't have 
to know how the record or fields were declared. (That is, you can import H98 
style records and DORF style records quite happily.)

That suggests the best way to organise the database definitions/decls is:
- base module: data dictionary (fieldLabels only)
- record/structures module(s) grouped by application areas: records only
 plus interface to your data store; plus validation and manip utilities
- application modules: business code
 possibly plus ad-hoc records (may be decl'd H98 style)

Well stap me if that way of organising isn't best practice anyway!



> 
> Regarding the polymorphic update / higher-rank fields issues, I'm not
> competent to address them in earnest, but: isn't this primarily an
> ImpredicativeTypes issue? If GHC had full support for
> ImpredicativeTypes (whatever that means), would it work?
> 
> ~g
> 

Thanks Gábor, neither am I really competent, which is why I asked SPJ to look 
at an early prototype. Since he says it's an unscalable hack, I'll stop there.

At least my proposal uses Has/get/set (with its type-level sugar) and supports 
type-changing update. So (I reckon) it's equal to or ahead of any other 
proposal -- except for those which need whole-scale syntax re-engineering and 
breaking a whole heap of code.

AntC



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

Re: [Haskell-cafe] Monad laws in presence of bottoms

[Sebastian Fischer]

On Mon, Feb 20, 2012 at 7:42 PM, Roman Cheplyaka  wrote:

> Is there any other interpretation in which the Reader monad obeys the
> laws?


If "selective strictness" (the  seq  combinator) would exclude function
types, the difference between  undefined  and  \_ -> undefined  could not
be observed. This reminds me of the different language levels used by the
free theorem generator [1] and the discussions whether  seq  should have a
type-class constraint..

Sebastian

[1]: http://www-ps.iai.uni-bonn.de/cgi-bin/free-theorems-webui.cgi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Streaming to JuicyPixels

[Vincent Berthoux]

Hi,

 I can expose the low level parsing, but you would only get the
chunks/frames/sections of the image, Cereal is mainly used to parse the
structure of the image, not to do the raw processing. For the raw
processing, I rely on `remaining >> getBytes` to be able to manipulate data
at bit level or to feed it to zlib, and the documentation clearly state
that remaining doesn't work well with runGetPartial, so no read ahead, but
even worse for streaming :).

To be fair, I never thought of this use case, and exposing a partially
decoded image would impose the use of the ST Monad somehow, and Serialize
is not a monad transformer, making it a bit hard to implement.

By curiosity what kind of API would you hope for this kind of functionality?

Regards

Vincent Berthoux

Le 20 février 2012 22:08, Myles C. Maxfield  a
écrit :

> Hello,
> I am interested in the possibility of using JuicyPixels for streaming
> images from the web. It doesn't appear to expose any of its internally-used
> Serialize.Get functionality, which is problematic for streaming - I would
> not like to have to stream the whole image into a buffer before the decoder
> can start decoding. Are there any plans on exposing this API, so I can use
> the runGetPartial function to facilitate streaming?
>
> In addition, does the library do much readahead? There's no point in
> exposing a Get interface if it's just going to wait until the stream is
> done to start decoding anyway.
>
>  Thanks,
> Myles C. Maxfield
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper

[Richard O'Keefe]

On 20/02/2012, at 5:53 PM, Brandon Allbery wrote:

> On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe  wrote:
> Now *that's* annoying.  It turns out that the xattr command is *there*,
> but 'man xattr' is completely silent.  There is nothing for it in
> /usr/share/man/man1 .  I had been using my own command to do the
> equivalent of xattr -d.
> 
> Bzuh?
> 
> haral:23276 Z$ pkgutil --file-info /usr/share/man/man1/xattr.1
> volume: /
> path: /usr/share/man/man1/xattr.1
> 
> pkgid: com.apple.pkg.BSD
> pkg-version: 10.7.0.1.1.1293150744
> install-time: 1310114676
> uid: 0
> gid: 0
> mode: 644

m% uname -a
Darwin  10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 
2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
m% ls -l /usr/share/man/man1/xa*
-rw-r--r--  1 root  wheel  5427 14 Jul  2009 /usr/share/man/man1/xar.1
-r--r--r--  1 root  wheel  3759 19 May  2009 /usr/share/man/man1/xargs.1.gz
m% pkgutil --file-info /usr/share/man/man1/xattr.1
2012-02-21 10:25:36.201 pkgutil[7023:903] PackageKit: *** Missing bundle 
identifier: /Library/Receipts/NeoOffice-2.2.2-Intel.pkg
2012-02-21 10:25:36.222 pkgutil[7023:903] PackageKit: *** Missing bundle 
identifier: /Library/Receipts/NeoOffice-3.0.1-Intel.pkg
volume: /
path: /usr/share/man/man1/xattr.1
m%

Since you are running Lion and I am not, it isn't _that_ surprising that we
see different things.  It remains surprising that in 10.6.8 the xattr
command is there but its manual page is not.

I've also checked a laptop running the same release of Mac OS X.



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

[Haskell-cafe] Streaming to JuicyPixels

[Myles C. Maxfield]

Hello,
I am interested in the possibility of using JuicyPixels for streaming
images from the web. It doesn't appear to expose any of its internally-used
Serialize.Get functionality, which is problematic for streaming - I would
not like to have to stream the whole image into a buffer before the decoder
can start decoding. Are there any plans on exposing this API, so I can use
the runGetPartial function to facilitate streaming?

In addition, does the library do much readahead? There's no point in
exposing a Get interface if it's just going to wait until the stream is
done to start decoding anyway.

Thanks,
Myles C. Maxfield
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Simple GUI library to view JSON?

[Clark Gaebel]

Not that I've tried it, but I doubt you need to save objects to disk to
serve them with Yesod. Just serialize them to JSON in memory and serve that.

On Mon, Feb 20, 2012 at 2:55 PM, dokondr  wrote:

> Thanks, it is a good idea to use JSONView. Yet I also want to reuse this
> code to view lists of objects in MongoDB collection. MongoDB objects are in
> fact JSON, so the same code should work. I am not sure though that saving
> MongoDB objects in intermediate JSON and then displaying them in JSONView
> would be the best way to go.
>
> On Mon, Feb 20, 2012 at 10:24 PM, Clark Gaebel <
> cgae...@csclub.uwaterloo.ca> wrote:
>
>> You could set up a simple web server (with, for example, Yesod [1])
>> serving up your JSON data, and then just connect to it with Firefox and use
>> JSONView.
>>
>> [1] http://www.yesodweb.com/
>>
>> On Mon, Feb 20, 2012 at 2:01 PM, dokondr  wrote:
>>
>>> Please advise on a simple GUI library to display JSON data. A library
>>> that is easy to build both on Win, Linux and OsX. I need a scrollable view
>>> to show a list of JSON objects. Every object may contain other objects
>>> (recursively). List may have thousands of objects. Fields may have very
>>> long text values, so the view must also be scrollable in horizontal
>>> dimension.
>>> JSON object view should be click-able and look like on this example:
>>> {
>>> hey: "guy",
>>> anumber: 243,
>>> - anobject: {
>>> whoa: "nuts",
>>> - anarray: [
>>> 1,
>>> 2,
>>> "three"
>>> ],
>>> more: "stuff"
>>> },
>>> awesome: true,
>>> bogus: false,
>>> meaning: null,
>>> link: "http://jsonview.com";,
>>> }
>>>
>>> Where '-' before the field object indicates that object was expanded and
>>> '+' means collapsed object.
>>> Clicking on expanded fields should collapse them and vice verse. So for
>>> this example, clicking on 'anobject' should result in:
>>> {
>>> hey: "guy",
>>> anumber: 243,
>>> anobject: {... }
>>> awesome: true,
>>> bogus: false,
>>> meaning: null,
>>> link: "http://jsonview.com";,
>>> }
>>>
>>> In short I need a view similar to the one provided by JSONView plugin
>>> for Firefox:
>>> https://addons.mozilla.org/en-US/firefox/addon/jsonview/
>>>
>>> Thanks a lot for any info, comments and ideas about this project!
>>>
>>>
>>> ___
>>> 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] Simple GUI library to view JSON?

[dokondr]

Thanks, it is a good idea to use JSONView. Yet I also want to reuse this
code to view lists of objects in MongoDB collection. MongoDB objects are in
fact JSON, so the same code should work. I am not sure though that saving
MongoDB objects in intermediate JSON and then displaying them in JSONView
would be the best way to go.

On Mon, Feb 20, 2012 at 10:24 PM, Clark Gaebel
wrote:

> You could set up a simple web server (with, for example, Yesod [1])
> serving up your JSON data, and then just connect to it with Firefox and use
> JSONView.
>
> [1] http://www.yesodweb.com/
>
> On Mon, Feb 20, 2012 at 2:01 PM, dokondr  wrote:
>
>> Please advise on a simple GUI library to display JSON data. A library
>> that is easy to build both on Win, Linux and OsX. I need a scrollable view
>> to show a list of JSON objects. Every object may contain other objects
>> (recursively). List may have thousands of objects. Fields may have very
>> long text values, so the view must also be scrollable in horizontal
>> dimension.
>> JSON object view should be click-able and look like on this example:
>> {
>> hey: "guy",
>> anumber: 243,
>> - anobject: {
>> whoa: "nuts",
>> - anarray: [
>> 1,
>> 2,
>> "three"
>> ],
>> more: "stuff"
>> },
>> awesome: true,
>> bogus: false,
>> meaning: null,
>> link: "http://jsonview.com";,
>> }
>>
>> Where '-' before the field object indicates that object was expanded and
>> '+' means collapsed object.
>> Clicking on expanded fields should collapse them and vice verse. So for
>> this example, clicking on 'anobject' should result in:
>> {
>> hey: "guy",
>> anumber: 243,
>> anobject: {... }
>> awesome: true,
>> bogus: false,
>> meaning: null,
>> link: "http://jsonview.com";,
>> }
>>
>> In short I need a view similar to the one provided by JSONView plugin for
>> Firefox:
>> https://addons.mozilla.org/en-US/firefox/addon/jsonview/
>>
>> Thanks a lot for any info, comments and ideas about this project!
>>
>>
>> ___
>> 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] Simple GUI library to view JSON?

[Michael Snoyman]

An extra step beyond that could be launching the application with
wai-handler-launch[1], so that the user's default browser is
automatically opened.

[1] http://hackage.haskell.org/package/wai-handler-launch

On Mon, Feb 20, 2012 at 9:24 PM, Clark Gaebel
 wrote:
> You could set up a simple web server (with, for example, Yesod [1]) serving
> up your JSON data, and then just connect to it with Firefox and use
> JSONView.
>
> [1] http://www.yesodweb.com/
>
> On Mon, Feb 20, 2012 at 2:01 PM, dokondr  wrote:
>>
>> Please advise on a simple GUI library to display JSON data. A library that
>> is easy to build both on Win, Linux and OsX. I need a scrollable view to
>> show a list of JSON objects. Every object may contain other objects
>> (recursively). List may have thousands of objects. Fields may have very long
>> text values, so the view must also be scrollable in horizontal dimension.
>> JSON object view should be click-able and look like on this example:
>> {
>>     hey: "guy",
>>     anumber: 243,
>>     - anobject: {
>>     whoa: "nuts",
>>     - anarray: [
>>     1,
>>     2,
>>     "three"
>>     ],
>>     more: "stuff"
>>     },
>>     awesome: true,
>>     bogus: false,
>>     meaning: null,
>>     link: "http://jsonview.com";,
>> }
>>
>> Where '-' before the field object indicates that object was expanded and
>> '+' means collapsed object.
>> Clicking on expanded fields should collapse them and vice verse. So for
>> this example, clicking on 'anobject' should result in:
>> {
>>     hey: "guy",
>>     anumber: 243,
>>     anobject: {    ... }
>>     awesome: true,
>>     bogus: false,
>>     meaning: null,
>>     link: "http://jsonview.com";,
>> }
>>
>> In short I need a view similar to the one provided by JSONView plugin for
>> Firefox:
>> https://addons.mozilla.org/en-US/firefox/addon/jsonview/
>>
>> Thanks a lot for any info, comments and ideas about this project!
>>
>>
>> ___
>> 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] Simple GUI library to view JSON?

[Clark Gaebel]

You could set up a simple web server (with, for example, Yesod [1]) serving
up your JSON data, and then just connect to it with Firefox and use
JSONView.

[1] http://www.yesodweb.com/

On Mon, Feb 20, 2012 at 2:01 PM, dokondr  wrote:

> Please advise on a simple GUI library to display JSON data. A library that
> is easy to build both on Win, Linux and OsX. I need a scrollable view to
> show a list of JSON objects. Every object may contain other objects
> (recursively). List may have thousands of objects. Fields may have very
> long text values, so the view must also be scrollable in horizontal
> dimension.
> JSON object view should be click-able and look like on this example:
> {
> hey: "guy",
> anumber: 243,
> - anobject: {
> whoa: "nuts",
> - anarray: [
> 1,
> 2,
> "three"
> ],
> more: "stuff"
> },
> awesome: true,
> bogus: false,
> meaning: null,
> link: "http://jsonview.com";,
> }
>
> Where '-' before the field object indicates that object was expanded and
> '+' means collapsed object.
> Clicking on expanded fields should collapse them and vice verse. So for
> this example, clicking on 'anobject' should result in:
> {
> hey: "guy",
> anumber: 243,
> anobject: {... }
> awesome: true,
> bogus: false,
> meaning: null,
> link: "http://jsonview.com";,
> }
>
> In short I need a view similar to the one provided by JSONView plugin for
> Firefox:
> https://addons.mozilla.org/en-US/firefox/addon/jsonview/
>
> Thanks a lot for any info, comments and ideas about this project!
>
>
> ___
> 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] Simple GUI library to view JSON?

[dokondr]

Please advise on a simple GUI library to display JSON data. A library that
is easy to build both on Win, Linux and OsX. I need a scrollable view to
show a list of JSON objects. Every object may contain other objects
(recursively). List may have thousands of objects. Fields may have very
long text values, so the view must also be scrollable in horizontal
dimension.
JSON object view should be click-able and look like on this example:
{
hey: "guy",
anumber: 243,
- anobject: {
whoa: "nuts",
- anarray: [
1,
2,
"three"
],
more: "stuff"
},
awesome: true,
bogus: false,
meaning: null,
link: "http://jsonview.com";,
}

Where '-' before the field object indicates that object was expanded and
'+' means collapsed object.
Clicking on expanded fields should collapse them and vice verse. So for
this example, clicking on 'anobject' should result in:
{
hey: "guy",
anumber: 243,
anobject: {... }
awesome: true,
bogus: false,
meaning: null,
link: "http://jsonview.com";,
}

In short I need a view similar to the one provided by JSONView plugin for
Firefox:
https://addons.mozilla.org/en-US/firefox/addon/jsonview/

Thanks a lot for any info, comments and ideas about this project!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Monad laws in presence of bottoms

[Roman Cheplyaka]

I just realised that many common monads do not obey the monad laws when
it comes to bottoms.

E.g. for the Reader monad:

  undefined >>= return /= undefined
  return () >>= undefined /= undefined
  return () >>= const undefined /= undefined
  return undefined >>= \x -> case x of () -> return () /= undefined

Not a long time ago David Barbour argued on this list that bottoms
should be ignored when checking the monad laws.

Is that the commonly accepted interpretation of the laws?
Is there any other interpretation in which the Reader monad obeys the
laws?

-- 
Roman I. Cheplyaka :: http://ro-che.info/

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

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

[Paul Sujkov]

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

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

On 20 February 2012 16:06, Alex Gremm  wrote:

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


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

[Haskell-cafe] [ANNOUNCE] HaTeX 3.2

[Daniel Díaz Casanueva]

Hello,

A new version (3.2) of HaTeX has been released today to Hackage:

http://hackage.haskell.org/package/HaTeX-3.2

HaTeX is the LaTeX language syntax implementation done in Haskell. Key
changes in this version are:

+ LaTeX parser implemented (so new dependency on parsec).
+ Greek alphabet added to AMSMath module.
+ New LaTeX package implemented: graphicx.
+ Function 'documentclass' changed.

Further information on this release:

http://deltadiaz.blogspot.com/2012/02/hatex-chapter-32.html

Library homepage:

http://dhelta.net/hprojects/HaTeX

Thanks for reading,
Daniel Díaz.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Nico de Bruijn dies at 93

[Sean Leather]

More:
http://translate.google.com/translate?sl=nl&tl=en&u=http%3A%2F%2Fweb.tue.nl%2Fcursor%2Finternet%2Fjaargang54%2Fcursor11%2Fnieuws%2Findex.php%3Fpage%3Dx34

Background:
http://en.wikipedia.org/wiki/Nicolaas_Govert_de_Bruijn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Paul Sujkov]

Yep. It doesn't help:

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

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

On 20 February 2012 16:06, Alex Gremm  wrote:

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


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

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

[Paul Sujkov]

Hi Alex,

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

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

On 20 February 2012 16:06, Alex Gremm  wrote:

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


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

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

[Paul Sujkov]

Hi everyone,

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

http://hpaste.org/64036

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

http://hpaste.org/64037

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

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

[Haskell-cafe] 11th GhentFPG meeting: Tuesday 20th of March at 19:30h. Location and program TBA shortly.

[Jeroen Janssen]

(apologies if you receive multiple postings)

Dear all,

The date has been decided and the 11th GhentFPG meeting will take place on
Tuesday, the 20th of March at 19:30h. Note that due to organizational
issues, we will be moving to a different location (still in Ghent though!).
The program and exact location will be communicated shortly. We have two
talks lined up and thus have room for one extra lightning talk, so if you
have something to talk about do not hesitate to contact one of the
organizers!

Kind Regards,
The GhentFPG organizing committee.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[Gábor Lehel]

On Mon, Feb 20, 2012 at 4:41 AM, AntC  wrote:
> Folks, I've put my 'Record in Haskell' proposal on the wiki
> http://hackage.haskell.org/trac/ghc/wiki/Records  as suggestion 5 Declared
> Overloaded Record Fields.
>
> Thanks to the voiciferousness on this thread, dot notation is completely
> optional.
>
> Feedback welcome.

Thanks for writing it up, I admit I was having trouble following
across the various email threads.

Surprisingly, your ideas are very similar to my own. I'm not sure if
this is a good thing or a bad sign, but naturally I'm in favor.

I was wondering whether it wouldn't make sense to have some syntax
within the record itself, instead of at the top level, to declare,
"I'm definitely declaring a new record field", versus "I'm definitely
re-using an existing record field", versus "If this record field
already exists I'm re-using it, otherwise I'm declaring it". (It
doesn't necessarily make sense to have all three - the second one
might be cumbersome, or the third one might be error-prone - but they
seem like the options.)

The existing, unadorned record syntax would mean "I'm definitely
declaring a new record field", because that's what it already means.
Simply leaving off the type annotation to indicate otherwise sadly
wouldn't work because, as you mention, that means that it's the same
type as the next field.

So something like:

data Rec1 = Rec1 { field1 :: Int, field2 :: Char } -- declare field1
:: Int and field2 :: Char fields

data Rec2 = Rec2 { import field1, field3 :: String } -- reuse field1
:: Int, declare field3 :: String

data Rec3 = Rec3 { field3 :: String } -- declare field3 :: String, but
error: already declared

Hopefully someone can think of better syntax than my "import field1" above.

Regarding the polymorphic update / higher-rank fields issues, I'm not
competent to address them in earnest, but: isn't this primarily an
ImpredicativeTypes issue? If GHC had full support for
ImpredicativeTypes (whatever that means), would it work?

~g

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

Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0

[Herbert Valerio Riedel]

Bas van Dijk  writes:

> Also in my experience (with generics support in aeson and cereal) it's
> a very good idea (performance-wise) to INLINE your methods like I did
> in my previous message. Of course the only way to know for sure is the
> create some (criterion) benchmarks.

btw, how much is GHC able to optimize the GHC.Generics based NFData
instance as e.g. compared to what GHC is able to optimize with
deepseq-th[1]?

> One last issue: Say I have a type like: "data T = C !Int"
> Currently GHC Generics can't express the strictness annotation. This
> means that your deepseq will unnecessarily evaluate the Int (since it
> will always be evaluated already). It would be nice if the strictness
> information could be added to the K1 type. (José, would it be hard to
> add this to GHC.Generics?)

that's btw one thing that I tried hard to avoid in deepseq-th[1], by
having a hacky predicate 

decWhnfIsNf :: Dec -> Q (Maybe Bool)

whis is able to detect whether WHNF is the same as NF for a given
declaration;

e.g. in the following case (see also the example in [1]):

data Foo = Foo !Int !Int !Int

data Bar = Bar !Foo !Foo

the instance generated would be:

instance NFData Foo
instance NFData Bar

since the WHNF=NF property holds for Foo as well as for Bar


 [1]: 
http://hackage.haskell.org/packages/archive/deepseq-th/0.1.0.2/doc/html/Control-DeepSeq-TH.html

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

Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0

[Gábor Lehel]

2012/2/20 José Pedro Magalhães :
>>
>>
>> One last issue: Say I have a type like: "data T = C !Int"
>> Currently GHC Generics can't express the strictness annotation. This
>> means that your deepseq will unnecessarily evaluate the Int (since it
>> will always be evaluated already). It would be nice if the strictness
>> information could be added to the K1 type. (José, would it be hard to
>> add this to GHC.Generics?)
>
>
> I don't think so; I think the right place to put it is as a method of the
> Selector class, though.
>
> But, I'm wondering, for your example, wouldn't/couldn't GHC optimize away
> `seq` calls to strict arguments?

Isn't it also an issue that bang patterns only guarantee WHNF, but
there might be unevaluated data "further inside"? Obviously not a
problem for !Int; I don't know if the logic is there to tell the
difference.

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