On 04/25/2010 03:47 PM, Ivan Lazar Miljenovic wrote:
So you recommend having packages specifically for instances?
My main problem with this is if you want a custom variant of that
instance. Let's take FGL graphs for example with instances for
QuickCheck's Arbitrary class. Maybe you want
On Apr 26, 2010, at 09:33 , John Goerzen wrote:
It would, however, be nice if the language allowed you to override
default instances with the code in your own package.
Many other languages refer to this kind of thing as monkey patching
and warn against it because of the problems it causes.
John Goerzen schrieb:
My second example was the addition of instances to time.
My conclusion was: Never define orphan instances privately. If an
instance cannot be added to the packages that provide the associated
type or the class, then discuss the orphan instance with the maintainers
of the
Henning Thielemann schlepp...@henning-thielemann.de writes:
My conclusion was: Never define orphan instances privately. If an
instance cannot be added to the packages that provide the associated
type or the class, then discuss the orphan instance with the maintainers
of the type and the class
Ivan Lazar Miljenovic schrieb:
Henning Thielemann schlepp...@henning-thielemann.de writes:
My conclusion was: Never define orphan instances privately. If an
instance cannot be added to the packages that provide the associated
type or the class, then discuss the orphan instance with the
On Mon, Apr 26, 2010 at 06:47:27AM +1000, Ivan Lazar Miljenovic wrote:
My main problem with this is if you want a custom variant of that
instance. Let's take FGL graphs for example with instances for
QuickCheck's Arbitrary class. Maybe you want arbitrary graphs that are
simple, or maybe
On 24/04/10 01:34, Ivan Lazar Miljenovic wrote:
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
On 24/04/2010, at 07:29, Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about types
and function signatures. John's old-locale example shows that this is not
enough.
Would it perhaps make sense for at
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 07:29, Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about
types and function signatures. John's old-locale example shows that
this
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 07:29, Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about
types and
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
I would think that the API is all the
functions/classes/datatypes/instances/etc. exported from the library in
combination with their types.
So the semantics of those functions doesn't
On 24/04/2010, at 18:54, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
I would think that the API is all the
functions/classes/datatypes/instances/etc. exported from the library in
combination with their
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
John Goerzen gave one in the very first post of this thread: the fix
to old-locale which didn't change any types but apparently changed the
behaviour of a function quite drastically. Another example would be a
change to the Ord instances for
Hi
On Sat, 2010-04-24 at 19:25 +1000, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
John Goerzen gave one in the very first post of this thread: the fix
to old-locale which didn't change any types but apparently changed the
behaviour of a function quite
Mads Lindstrøm mads.lindstr...@gmail.com writes:
You could automatically generate QuickCheck tests for many pure
functions. It will not catch every API change, but it would catch some.
It would have caught the API change that John mentioned.
As in comparing the old and the new functions?
But
Hi
On Sat, 2010-04-24 at 19:47 +1000, Ivan Lazar Miljenovic wrote:
Mads Lindstrøm mads.lindstr...@gmail.com writes:
You could automatically generate QuickCheck tests for many pure
functions. It will not catch every API change, but it would catch some.
It would have caught the API change
Mads Lindstrøm mads.lindstr...@gmail.com writes:
But that would be an API change. It is of cause a question of how strict
we want to be. I have seen several times that commercial software
developers denies changes bugs, as the fix would constitute API changes.
We obviously do not want to go
On Sat, Apr 24, 2010 at 08:21:04PM +1000, Ivan Lazar Miljenovic wrote:
Mads Lindstrøm mads.lindstr...@gmail.com writes:
But that would be an API change. It is of cause a question of how strict
we want to be. I have seen several times that commercial software
developers denies changes bugs,
Ross Paterson r...@soi.city.ac.uk writes:
Same major version: any code using fully explicit imports that worked
with the old version will work with the new version, in the same way.
By this you mean that additions have been made?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
On Sat, Apr 24, 2010 at 08:48:07PM +1000, Ivan Lazar Miljenovic wrote:
Ross Paterson r...@soi.city.ac.uk writes:
Same major version: any code using fully explicit imports that worked
with the old version will work with the new version, in the same way.
By this you mean that additions have
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
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
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 --
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
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
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
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
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
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
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
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
51 matches
Mail list logo
