Hi,
We use the Haskell Logo in Fedora OS installer for the Haskell packages group:
http://git.fedorahosted.org/git/?p=comps-extras.git;a=tree
I trying to get the logo updated to the nice new logo designed by
Jeff Wheeler:
http://haskell.org/sitewiki/images/a/a8/Haskell-logo-60.png
To do that we
It was posted to the Wiki, IIUC. Anything posted to the wiki is
implicitly licensed by the wiki license:
http://haskell.org/haskellwiki/HaskellWiki:Copyrights
On 23 April 2010 07:10, Jens Petersen peter...@haskell.org wrote:
Hi,
We use the Haskell Logo in Fedora OS installer for the Haskell
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf
Of Denys Rtveliashvili
On the side note, is London HUG still active? The website
seems to be down...
Looks like the London HUG domain (londonhug.net) registration has
expired.
David Anderson wrote:
So, it seems that I am reinventing wheels that others have generalized
better :-). That's fine, it's the expected result of launching and
iterating, especially given my current command of Haskell. So I should
now focus on reducing the reinvention.
No worries, this
All,
c2hs version 0.16.2 is out and is available from hackage
http://hackage.haskell.org/package/c2hs
The only significant change in this release is that it works with
ghc-6.12.
Note that it is not currently possible to bind to C functions that use
long double as the corresponding Haskell type
I don't think you can:
http://www.mail-archive.com/haskell-cafe@haskell.org/msg13057.html
I've also looked at the reify function in the latest version of TH and
there seems to be no way of reifying instances.
/Jonas
On 22 April 2010 22:33, Dmitry Olshansky olshansk...@gmail.com wrote:
Hello
John Lato wrote:
Another (additional) approach would be to encapsulate unsafeInterleaveIO
within some routine and not let it go out into the wild.
lazilyDoWithIO :: IO a - (a - b) - IO b
It would use unsafeInterleave internally but catch all IO errors within
itself.
I wonder if this is a
В сообщении от 23 апреля 2010 02:36:07 Rickard Karlsson написал:
Hi,
I'm trying to download a file in UTF-8 with libcurl(1.3.5) and GHC 6.12:
import Network.Curl
u = http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt;
main = curlGetString u [] = putStrLn . snd
Which doesn't
(changed the thread title hoping to get some others to weigh in on the
recursive I/O scheme presented here)
From: Daniil Elovkov daniil.elov...@googlemail.com
John Lato wrote:
Another (additional) approach would be to encapsulate unsafeInterleaveIO
within some routine and not let it go out
From: Barak A. Pearlmutter ba...@cs.nuim.ie
... An invalid comparison evaluating to _|_ is arguably more
correct, but I personally find the idea of introducing more bottoms
rather distasteful.
Too late! NaN is pretty much the _|_ of IEEE Floating Point.
That was certainly the intent of
On 23/04/2010, at 01:34, Barak A. Pearlmutter wrote:
I'd suggest that compare involving a NaN should yield
error violation of the law of the excluded middle
Please think of the poor guys trying to write high-performance code in Haskell!
Roman
On Fri, Apr 23, 2010 at 3:21 AM, Barak A. Pearlmutter ba...@cs.nuim.ie wrote:
... An invalid comparison evaluating to _|_ is arguably more
correct, but I personally find the idea of introducing more bottoms
rather distasteful.
Too late! NaN is pretty much the _|_ of IEEE Floating Point.
Here is a very interesting little problem.
ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m System.Process
Prelude
It is somewhat of a surprise to me that I'm making this post, given that
there was a day when I thought Haskell was moving too slow ;-)
My problem here is that it has become rather difficult to write software
in Haskell that will still work with newer compiler and library versions
in future
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated tools -- no one wants
to have to resolve
Don Stewart wrote:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated tools -- no one wants
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.org wrote:
Out of those 2023, there are certain libraries where small changes impact a
lot of people (say base, time, etc.) I certainly don't expect all 2023 to
be held to the same standard as base and time. We certainly need
On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen jgoer...@complete.orgwrote:
A one-character change. Harmless? No. It entirely changes what the
function does. Virtually any existing user of that function will be
entirely broken. Of particular note, it caused significant breakage in the
Out of curiousity, I downloaded a binary distribution for GHC-6.12.2,
and tried compressing and recompressing it with bzip2 and lzma
compression, using no command line arguments (all default parameters)
file:
http://haskell.org/ghc/dist/6.12.2/ghc-6.12.2-x86_64-unknown-linux-n.tar.bz2
1) Folks, what exactly is the situation with buildbots?
2) Easily available images for installing virtualized environments
could also ameliorate the pain, no?
wrt 1) It seems to me that in an ideal world you could have a
candidate for uploading to hackage, but before uploading you could
push a
Thanks, i just used decodeString.
import Network.Curl
import Codec.Binary.UTF8.String
u = http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt;
main = curlGetString u [] = putStrLn . decodeString . snd
2010/4/23 Khudyakov Alexey alexey.sklad...@gmail.com:
В сообщении от 23 апреля 2010
Please think of the poor guys trying to write high-performance code in
Haskell!
Like me? (Well, not in Haskell per-se, but in a pure functional context.)
In all seriousness, I think it is reasonable when isNaN x for
x C
x == C
x C
C x
C == x
C x
to all be False, for all floats C,
Thomas Hartman wrote:
1) Folks, what exactly is the situation with buildbots?
If that's going to happen, then ideally we would have a way to run tests
as part of the hackage acceptance process. For instance, the change to
a time format string wouldn't break anything at compile time, but my
jgoerzen:
Don Stewart wrote:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023
(literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated tools --
В сообщении от 23 апреля 2010 21:44:29 John Goerzen написал:
Here is a very interesting little problem.
ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base
On 23 April 2010 21:14, Jason Dagit da...@codersbase.com wrote:
[Snip]
We don't (yet), have a tool to help detect when
a change in version number is needed or what the next version should be. We
leave this up to humans and it turns out, humans make mistakes :)
Hi All,
Did anyone sign up to
I've had this problem too.
I believe trhsx is installed by
http://hackage.haskell.org/package/hsx
So, you might need to
-- upgrade hsx
-- make sure that the upgraded trhsx executable is the one being
executed by cabal install hsx (maybe deleting/temporarily moving other
trhsx exes)
thomas.
Thomas Hartman wrote:
1) Folks, what exactly is the situation with buildbots?
If I'm not mistaken, the buildbots run *after* the package has been
pushed to hackage. Thats already too too late.
Erik
--
--
Erik de Castro Lopo
So the situation is
1) The buildbot will catch dependencies with compile errors, but only
after the package has been pushed, and there is no easy way for
packagers to check that this won't happen
2) There are many important packages that will pass a compile check
but not a runtime check.
Well,
Don Stewart d...@galois.com writes:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023
(literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated
Thomas Hartman tphya...@gmail.com writes:
1) The buildbot will catch dependencies with compile errors, but only
after the package has been pushed, and there is no easy way for
packagers to check that this won't happen
Don't forget, there are valid reasons why hackage will sometimes fail to
John Goerzen jgoer...@complete.org writes:
ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m System.Process
Prelude
1) The buildbot will catch dependencies with compile errors, but only
after the package has been pushed, and there is no easy way for
packagers to check that this won't happen
An alternate solution that can be done completely outside the hackage loop:
Set up a server to poll the
Sorry, rerun the build means rebuild my package and all of my
package's dependencies...
On Fri, Apr 23, 2010 at 7:11 PM, Keith Sheppard keiths...@gmail.com wrote:
1) The buildbot will catch dependencies with compile errors, but only
after the package has been pushed, and there is no easy way
Keith Sheppard keiths...@gmail.com writes:
Set up a server to poll the Source-Repository head of every hackage
package that includes one in it's cabal file, then rerun the build any
time a change is detected. This may be a good excuse to implement a
pluggable continuous integration server in
ivan.miljenovic:
Don Stewart d...@galois.com writes:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023
(literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA
Ivan Lazar Miljenovic wrote:
John Goerzen jgoer...@complete.org writes:
ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m
On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
Keith Sheppard keiths...@gmail.com writes:
Set up a server to poll the Source-Repository head of every hackage
package that includes one in it's cabal file, then rerun the build any
time a change is
stephen.tetley:
On 23 April 2010 21:14, Jason Dagit da...@codersbase.com wrote:
[Snip]
We don't (yet), have a tool to help detect when
a change in version number is needed or what the next version should be. We
leave this up to humans and it turns out, humans make mistakes :)
Hi All,
What Gwern said for 1) and 3)
2) Not all head repositories are kept stable/buildable at all times.
Isn't it bad practice to not have a buildable repo? In any case
package owners would be free to use or ignore the data as they like,
but I'm pretty sure it would be useful to many.
Best, Keith
On Fri, Apr 23, 2010 at 4:49 PM, Don Stewart d...@galois.com wrote:
ivan.miljenovic:
Don Stewart d...@galois.com writes:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023
(literally!)
That is a massive
dagit:
Hmm...But who would be willing to take on the hard, tedious, and time
consuming
work of maintaining the CI build system? I think for this build system effort
to really take off a group of a few deadicated volunteers would be necessary.
CI for the HP would be really easy, and
В сообщении от 24 апреля 2010 03:50:54 John Goerzen написал:
Ivan Lazar Miljenovic wrote:
John Goerzen jgoer...@complete.org writes:
ghci
GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking
Keith Sheppard keiths...@gmail.com writes:
What Gwern said for 1) and 3)
2) Not all head repositories are kept stable/buildable at all times.
Isn't it bad practice to not have a buildable repo? In any case
package owners would be free to use or ignore the data as they like,
but I'm pretty
Gwern Branwen gwe...@gmail.com writes:
On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
2) Not all head repositories are kept stable/buildable at all times.
Perfect, meet better. Wait, no no - aw goddammit Perfect! Why do you
do this every single time?
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.orgwrote:
Don Stewart wrote:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023
(literally!)
That is a massive API to try to manage, hence the continuing
Peter Gammie wrote:
Alice/ML is the place to look for this technology.
http://www.ps.uni-saarland.de/alice/
The project may be dead (I don't know), but they did have the most
sophisticated take on pickling that I've seen. It's an ML variant,
with futures, running on top of the same platform
Casey McCann wrote:
The only correct solution would be to strip floating point types of
their instances for Ord, Eq, and--therefore, by extension--Num. For
some reason, no one else seems to like that idea. I can't imagine
why...
I'm not terribly opposed to it. But then, I've also defined
David Leimbach wrote:
I think managers expect magic bullets and holy grails... sometimes they
just end up with holy cow's (or other more interesting 4 letter words)
instead.
The good news for me, at least, is that *I* am the manager. (Yep, the
company is small enough for that.) Actually,
Ivan Lazar Miljenovic wrote:
I think the release early, release often slogan is an affect on this
as well: we encourage library writers to release once they have
something that _works_ rather than waiting until it is perfect. The
fact that we encourage smaller, more modular libraries over large
On 24/04/2010, at 07:15, Barak A. Pearlmutter wrote:
In all seriousness, I think it is reasonable when isNaN x for
x C
x == C
x C
C x
C == x
C x
to all be False, for all floats C, even C=x, as a sort of efficient
weak Bool bottom. This is what the FP hardware does --- so it is very
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like a very solid document. Does it also apply when
considering upgrading a package already in the
Khudyakov Alexey wrote:
Actually, the behavior of openFile when given a String with characters
0xFF is also completely undocumented. I am not sure what it does with
that. It should probably be the same as runCommand, whatever it is.
Under unices file names are just array of bytes. There is
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote:
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like a very solid document. Does it
David Menendez wrote:
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote:
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like a very
jgoerzen:
David Menendez wrote:
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote:
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like
56 matches
Mail list logo
