Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
2012/2/20 José Pedro Magalhães j...@cs.uu.nl: 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
Re: [Haskell-cafe] ANN: generic-deepseq 1.0.0.0
Bas van Dijk v.dijk@gmail.com 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] Some thoughts on Type-Directed Name Resolution
On Mon, Feb 20, 2012 at 4:41 AM, AntC anthony_clay...@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.
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
[Haskell-cafe] 11th GhentFPG meeting: Tuesday 20th of March at 19:30h. Location and program TBA shortly.
(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
[Haskell-cafe] Data.Array.Accelerate initialization timings
Hi everyone, since accelerate mail list seems to be defunct, I'm trying to ask specific questions here. The problem is: array initialization in Data.Array.Accelerate takes a 10x amount of time in contrast to both Data.Array and bare C++ CUDA array initialization. This can be due to Data.Array.Accelerate having two backends (however, it's own tests show that my nVidia card is CUDA-capable), but I'm not aware of how can I profile GPU to check whether it is used or not. Anyway, here's code: http://hpaste.org/64036 both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of time to initialize array. I'd say the problem is in GPU memory copying time, but here's bare C++ code: http://hpaste.org/64037 which does exactly the same, but 10 times faster. I'm wandering what am I doing wrong and how to check if I really am. Thanks in advance if anyone can point me on my mistakes! -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Array.Accelerate initialization timings
Hi Alex, I've seen that method, but I don't see how can I use it for initialization purposes. It creates Acc (Array e i) from Array e i, but what should I do while I don't have Array yet? And when Array is already initialized, 'use' will transfer it to GPU memory which will add some extra timings, but won't optimize what I have at the moment. However, I'll try to use it somehow. Maybe I misunderstand the mechanics. Thanks a lot! On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote: Hi Paul, even though I just started reading about Accelerate, it seems to me that you didn't use the use method which according to [1] initiates asynchronous data transfer from host to GPU. Cheers, Alex [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf On 20/02/12 14:46, Paul Sujkov wrote: Hi everyone, since accelerate mail list seems to be defunct, I'm trying to ask specific questions here. The problem is: array initialization in Data.Array.Accelerate takes a 10x amount of time in contrast to both Data.Array and bare C++ CUDA array initialization. This can be due to Data.Array.Accelerate having two backends (however, it's own tests show that my nVidia card is CUDA-capable), but I'm not aware of how can I profile GPU to check whether it is used or not. Anyway, here's code: http://hpaste.org/64036 both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of time to initialize array. I'd say the problem is in GPU memory copying time, but here's bare C++ code: http://hpaste.org/64037 which does exactly the same, but 10 times faster. I'm wandering what am I doing wrong and how to check if I really am. Thanks in advance if anyone can point me on my mistakes! -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Array.Accelerate initialization timings
Yep. It doesn't help: generateArray1 n = Acc.use $ Acc.fromList (Acc.Z Acc.:. n*n*n) [0..n*n*n] still takes the same amount of time. I guess something's wrong elsewhere. On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote: Hi Paul, even though I just started reading about Accelerate, it seems to me that you didn't use the use method which according to [1] initiates asynchronous data transfer from host to GPU. Cheers, Alex [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf On 20/02/12 14:46, Paul Sujkov wrote: Hi everyone, since accelerate mail list seems to be defunct, I'm trying to ask specific questions here. The problem is: array initialization in Data.Array.Accelerate takes a 10x amount of time in contrast to both Data.Array and bare C++ CUDA array initialization. This can be due to Data.Array.Accelerate having two backends (however, it's own tests show that my nVidia card is CUDA-capable), but I'm not aware of how can I profile GPU to check whether it is used or not. Anyway, here's code: http://hpaste.org/64036 both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of time to initialize array. I'd say the problem is in GPU memory copying time, but here's bare C++ code: http://hpaste.org/64037 which does exactly the same, but 10 times faster. I'm wandering what am I doing wrong and how to check if I really am. Thanks in advance if anyone can point me on my mistakes! -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Nico de Bruijn dies at 93
More: http://translate.google.com/translate?sl=nltl=enu=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
[Haskell-cafe] [ANNOUNCE] HaTeX 3.2
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] Data.Array.Accelerate initialization timings
Ah, it seems that I see now what's going wrong way. I'm not using the 'run' function from the CUDA backend, and so by default I guess the code is interpreted (the test backend used for semantics check). However, it's not perfectly clear how to use CUDA backend explicitly. If you have any suggestions, it would be a great help! On 20 February 2012 16:06, Alex Gremm algr...@googlemail.com wrote: Hi Paul, even though I just started reading about Accelerate, it seems to me that you didn't use the use method which according to [1] initiates asynchronous data transfer from host to GPU. Cheers, Alex [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf On 20/02/12 14:46, Paul Sujkov wrote: Hi everyone, since accelerate mail list seems to be defunct, I'm trying to ask specific questions here. The problem is: array initialization in Data.Array.Accelerate takes a 10x amount of time in contrast to both Data.Array and bare C++ CUDA array initialization. This can be due to Data.Array.Accelerate having two backends (however, it's own tests show that my nVidia card is CUDA-capable), but I'm not aware of how can I profile GPU to check whether it is used or not. Anyway, here's code: http://hpaste.org/64036 both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of time to initialize array. I'd say the problem is in GPU memory copying time, but here's bare C++ code: http://hpaste.org/64037 which does exactly the same, but 10 times faster. I'm wandering what am I doing wrong and how to check if I really am. Thanks in advance if anyone can point me on my mistakes! -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Sujkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad laws in presence of bottoms
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
[Haskell-cafe] Simple GUI library to view JSON?
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,
thrh1ee
],
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
Re: [Haskell-cafe] Simple GUI library to view JSON?
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 doko...@gmail.com 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,
thrh1ee
],
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?
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
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 doko...@gmail.com 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,
thrh1ee
],
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?
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.cawrote:
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 doko...@gmail.com 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,
thrh1ee
],
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?
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 doko...@gmail.com 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 doko...@gmail.com 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,
thrh1ee
],
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
[Haskell-cafe] Streaming to JuicyPixels
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
On 20/02/2012, at 5:53 PM, Brandon Allbery wrote: On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe o...@cs.otago.ac.nz 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 deleted 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
Re: [Haskell-cafe] Streaming to JuicyPixels
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 myles.maxfi...@gmail.com 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] Monad laws in presence of bottoms
On Mon, Feb 20, 2012 at 7:42 PM, Roman Cheplyaka r...@ro-che.info 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] Some thoughts on Type-Directed Name Resolution
Gábor Lehel illissius at gmail.com writes: On Mon, Feb 20, 2012 at 4:41 AM, AntC anthony_clayden at 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] ANN: hp2html, a tool for viewing GHC heap-profiles
Hi Iavor, On Mon, Feb 20, 2012 at 6:45 PM, Iavor Diatchki iavor.diatc...@gmail.com 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
[Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup
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] Streaming to JuicyPixels
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 STThttp://hackage.haskell.org/packages/archive/STMonadTrans/0.2/doc/html/Control-Monad-ST-Trans.html 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 http://hackage.haskell.org/package/jpeg) 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 myles.maxfi...@gmail.com 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] ANN: hp2html, a tool for viewing GHC heap-profiles
Hello, On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell johan.tib...@gmail.comwrote: 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] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup
On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell maydw...@gmail.com 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
On Mon, Feb 20, 2012 at 9:23 PM, Iavor Diatchki iavor.diatc...@gmail.com 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
[Haskell-cafe] ANN: network-socket-options 0.1
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] Monad laws in presence of bottoms
* Sebastian Fischer fisc...@nii.ac.jp [2012-02-21 00:28:13+0100] On Mon, Feb 20, 2012 at 7:42 PM, Roman Cheplyaka r...@ro-che.info 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
Re: [Haskell-cafe] Conduit Error Output: Control.Monad.Trans.Resource.stateCleanup
On Tue, Feb 21, 2012 at 7:40 AM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell maydw...@gmail.com 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.
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
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 mich...@snoyman.com wrote: On Tue, Feb 21, 2012 at 7:40 AM, Michael Snoyman mich...@snoyman.com wrote: On Tue, Feb 21, 2012 at 5:46 AM, Lyndon Maydwell maydw...@gmail.com 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
