gmane.comp.lang.haskell.libraries

Re: hackage vector-space-opengl

Nikolay Orlyuk — 2012-05-21T08:27:27

Hello again,

Please see my comments below

On Sun, May 20, 2012 at 9:35 PM, Adam Foltzer <acfoltzer< at >gmail.com> wrote:

That useful. But I'd prefer that for Data.Tensor either vector-space would
define instances or Tensor would do that. Have you tried to push instances
for Vertex* and Vector* to vector-space or Tensor?

I must admit that I do also spend not so much time for that, so
I believe there is much better solution. Maybe some Data.Derive or DRifT.
Also there is another idea in my mind: use dummy types to mark appropriate
places and than just replace them with ones that is needed (kind of
template for template-haskell :) ).

Yep... Normal - should be treated as a vector I guess. I'd suggest OpenGL
to make a type wrapper around (similar to Data.VectorSpace.Point). About
the Color - I doubt that vector-space semantic for the is useful. Moreover
I think that OpenGL should provide a bit more information in their classes
ColorComponent to allow users to get value range. Also that would be nice
if they would provide Monoid instances for different  datatypes (i.e. data
AlphaBlend a = AlphaBlend { alphaBlendColorSum :: Color4 a, alphaChannel ::
a } etc).

I'm quite from a different editors camp :) Vim - that's what I prefer ;)

Unfortunately newtype deriving is too weak to get instances with
TypeFamilies. In the patch I've sent to you there is only two samples for
Vector1 and TexCoord1 in AdditiveGroup. For me that's strange because as I
can  see that deriving is pretty clear. Maybe someday I'll look into the
code for that GeneralizedNewtypeDeriving.


Cheers
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: hackage vector-space-opengl

Adam Foltzer — 2012-05-20T18:35:58

Hi Nikolay,

I am glad you found my work helpful, and thank you for the suggestions!
Please find my responses interspersed below.

On Sun, May 20, 2012 at 5:59 AM, Nikolay Orlyuk <virkony< at >gmail.com> wrote:

While looking into OpenGL/TH.hs I found that it quite incomplete and I
course that motivated its creation, but would be happy to take your
modifications as a github pull request (
https://github.com/acfoltzer/vector-space-opengl). I just couldn't justify
the time getting the TH to work fully when I was chasing a deadline on a
semester project.



Regarding the dependency on OpenGL vs. OpenGLRaw, some of the semantic
versions of the Data.Tensor types (Normal*, Color*) are defined in the full
OpenGL package, so I will keep the dependency because of that.

While scalar types doesn't differ whether they are absolute whether they

Regarding whether vertices and vectors should be treated uniformly, I
particularly would appreciate corrections here. The original file was made
by Emacs keyboard macro when the more sophisticated bits of Template
Haskell failed to be straightforward, so I'm sure there's plenty that one
could do to improve the correctness vs. nearly-blind copypasta :)



This, or use of GeneralizedNewtypeDeriving + StandAloneDeriving would be
great to see.



Thank you too!

Cheers,
Adam
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

hackage vector-space-opengl

Nikolay Orlyuk — 2012-05-20T09:59:47

Hello

First of all I'd like to say that I like vector-space and
vector-space-opengl is something that I'd like to use together with OpenGL.
So while using that library I found some things that can be useful for
others, I think.

While looking into OpenGL/TH.hs I found that it quite incomplete and I
understand why. That suggestion at stackoverflow results in a bit
boilerplate code:

deriveScalar, deriveScalarAdditiveGroup, deriveScalarVectorSpace,
deriveScalarAffineSpace :: [Name] -> Q [Dec]
deriveScalar ts = concat <$> forM decls (\qf -> qf ts)
    where decls = [ deriveScalarAdditiveGroup
                  , deriveScalarVectorSpace
                  , deriveScalarAffineSpace
                  , deriveScalarInnerSpace
                  ]
deriveScalarVectorSpace ts = concat <$> mapM f ts where
    f tn = do
        t <- [t| $(conT tn) |]
        vs <- [t| VectorSpace |]
        (AppT (ConT s) _) <- [t| Scalar () |] -- dummy type to extract
Scalar name
        (VarE h) <- [e| (*^) |] -- refer to actual (*^) from VectorSpace
        e <- [e| (*) |] -- (*) from Num
        return [
            InstanceD [] (AppT vs t) [
                TySynInstD s [t] t,
                ValD (VarP h) (NormalB e) []
            ]]

It's kinda partially checked and partially constructed. BTW, rather than
depending on OpenGL its better to use Graphics.Rendering.OpenGL.Raw I
think. Also there is types GLclampd and GLclampf (I suspect that they
somehow related with OpenCL).

While scalar types doesn't differ whether they are absolute whether they
are not. Data.Tensor makes difference between Vertex and Vector. I suspect
that made especially for this case: instance AffineSpace a => AffineSpace
(Vertex2 a) where type Diff (Vertex2 a) = Vector2 (Diff a)
I.e. Diff Vertex shouldn't be Vertex and Vertex a should not belong to
AdditiveGroup

If anyone knows how to walk through the whole module in monad Q that might
bring more power to this library. I.e. walk through OpenGL.Raw and make
declarations  for all its scalar types.

Thank you
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Protocol Buffers 2.0.7

Chris Kuklewicz — 2012-05-19T15:51:53

I have returned from the shadows of the intenet to maintain some packages!

Version 2.0.7 of protocol-buffers (3 packages) has been uploaded to hackage.
This makes it compile with
ghc-7.4.1 and handle missing package names better.

Thanks to everyone who sent email and patches, including Nathan Howell, Alexey
Khudyakov, Howard
B. Golden, Bryan O'Sullivan, Michael Stone, Daniel Rebelo de Oliveira, Paul
Graphov, Tsurann, Sergei
Trofimovich, Yitzchak Gale.

The usual hackage links:

http://hackage.haskell.org/package/hprotoc
http://hackage.haskell.org/package/protocol-buffers-descriptor
http://hackage.haskell.org/package/protocol-buffers

And the darcs repo is at:

http://code.haskell.org/protocol-buffers/

Q: What is protocol-buffers?
A: It is a Haskell version of Google's protocol buffer wire protocol, see
http://code.google.com/p/protobuf/ for a full description.

Q: What does the hprotoc executable do?
A: It convers "protocol-buffer descriptor files" into Haskell code to implement
those data messages.

Q: What does the protocol-buffers library do?
A: It is the runtime API for using the binary protocol, serializing and
deserializing the data types generated by hprotoc.

Q: What is the protocol-buffers-descriptor library do?
A: It is the support library for parsing "protocol-buffer descriptor files" into
data structures.  Most of this code is generated by hprotoc from a
"protocol-buffer descriptor file" for "protocol-buffer descriptor files".  Yes,
it had to be bootstrapped.

Re: Safe Haskell at the export symbol granularity?

David Terei — 2012-05-17T19:14:16

Sure, the proposed syntax wasn't a serious proposal as it has
backwards compatibility issues so pragmas are the better choice. It's
just a clearer syntax when discussing the semantics of the idea.


Thanks, I'll keep that in mind. Let me know how Antoine's suggestion
works out for you and any other feedback you have please.


I think so. I'm not very familiar with the type checker in GHC or
typechecking in general but looking through the code just then it
seems doable. There doesn't seem anything other than maybe some hard
engineering work that would prevent this.

~ David

Re: Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-17T14:53:23

Good point, Antoine!

I think that does the trick.

On Thu, May 17, 2012 at 10:48 AM, Antoine Latter <aslatter< at >gmail.com> wrote:

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Safe Haskell at the export symbol granularity?

Antoine Latter — 2012-05-17T14:48:45

You can still do this at the module level, with the down-side of
potentially not being able to implement a class with the safe version:




I think this works.

Antoine

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-17T13:50:59

Thanks David.

I'm glad to see it was discussed in the wiki.  (Btw, my 2 cents is that I
like the comment pragmas more than new keywords.)

The issue that I think doesn't make it into the wiki is of splitting, not
modules, but* type-classes*. That's where I think it becomes a more serious
issue.

Do you think a symbol-level Safe Haskell would be able to distinguish one
method of a type class as unsafe, while the others are safe?

  -Ryan

P.S. In my two examples --
   There's only one "Acc" type and Accelerate's "fold" can pretty easily be
moved into an .Unsafe module, though it breaks the
one-giant-module-for-the-whole-programming-model thing it has going now.
 In the Par example on the other hand type classes are used to abstract
over different implementations, so that's where we run into the safe/unsafe
factoring problem.
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: parallel containers dependency

Simon Marlow — 2012-05-16T15:30:57

I just uploaded 3.2.0.3 with the relaxed dep, thanks for the nudge.

Cheers,
Simon

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

Simon Marlow — 2012-05-16T15:23:58

These kinds of data structures are fiendishly hard to get right, as we 
know from bitter experience.  I'm not suggesting that your 
implementation is wrong in any way - but it's hard to tell whether it is 
right.  For instance, are you sure that it is robust to asynchronous 
exceptions?

I think to replace Chan we would need at the very least plenty of tests. 
  I realise this might sound a bit hypocritical given that we never had 
many tests for Chan, and we've discovered a number of bugs in it over 
the years, but it's a "devil you know" argument.  Let's be sure we're 
not making anything worse.

Personally speaking, I'm not keen on the overly point-free style in your 
code, which I find hard to read.

Again you can take this as my opinion if you want, but I think STM is 
the way forward.  Correctness is *far* easier, and performance is 
surprisingly good (and we could improve it if necessary).  If you're 
avoiding STM for performance reasons, show me the numbers.

Cheers,
Simon

Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-14T15:18:20

Separate from whether or not we actually want this -- is it feasible?

Here's my situation.  When working on parallel programming libraries in
Haskell there are very often unsafe operations one wants to do within an
otherwise pure model.  For example, Accelerate currently violates safe
haskell because it trusts the user to provide an associative function to
parallel "fold".  No associativity, no referential transparency.

The solution is to put fold in a separate namespace and mark that module as
Unsafe.  Likewise for certain monad-par operations that are unsafe.  But
this factoring can have a serious impact.  Not only are extra modules
required, but extra type classes as well.  For example, if Accelerate is
ever refactored for "Safe Haskell" then the following ParAccelerate type
class probably should be as well:

https://github.com/simonmar/monad-par/blob/5cc656bc45dc473d7a185ec99bb156192f54d520/abstract-par-accelerate/Control/Monad/Par/Accelerate.hs#L75

I.e. ParAccelerate & ParAccelerateUnsafe for the "unsafeHybrid" operation.

But this starts to be death by a thousand organizational factorings!

   - The package, abstract-par-accelerate, is already factored out from
   abstract-par just to avoid an unnecessary Accelerate dependency (which
   used to mean CUDA errors).  (And *another* factoring is possibly warranted
   for whether or not the module depends on accelerate-io.)
   - The file would be separate to mark it as Safe Haskell.
   - The type class ParAccelerateUnsafe would be separate so as to put it
   in a separate file.

What's a possible solution?  If, in addition to "Safe" and "Unsafe"
modules, there were "Partially Safe" modules, which exported a mix of safe
and unsafe identifiers, then this could all be much cleaner.

The simple rule is that any reference whatsoever to an unsafe identifier
disqualifies the client code.  For example, in the above ParAccelerate type
class we would mark the unsafeHybrid binding with something like {-# UNSAFE
unsafeHybrid #-}.  We wouldn't even have to factor it out of the type class.

Likewise, Accelerate could mark "fold" as unsafe (providing safe variants
as well) without introducing module namespace bloat and confusion.

What do you think?

   -Ryan
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: On the Haskell Platform

Magnus Therning — 2012-05-13T21:24:27

[...]

This is exactly what I try to do with the few packages I've written
and put on Hackage.

[...]

Luckily I've never had to deal with the first issue.  The second on
the other hand I have a rather lazy process for: *I* release packages
with the dependencies that I've tested, then I'm happy to accept
patches that relax the dependencies downwards (and sometimes upwards,
when I'm slow) from users, as long as they claim to have run the test
suites.

/M

Re: On the Haskell Platform

Henning Thielemann — 2012-05-13T20:52:19

On Sun, 13 May 2012, Joachim Breitner wrote:


Defending myself: I had already updated my packages to transformers-0.3 in 
the repositories, but I have not released all of them to Hackage 
immediately. Updating a dependency in 30 packages needs some time although 
I did even not need to alter any code.

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: On the Haskell Platform

Joachim Breitner — 2012-05-13T20:04:40

Hi,

Am Sonntag, den 13.05.2012, 21:36 +0200 schrieb Heinrich Apfelmus:

yes, always supporting the latest version available on hackage is a good
idea. If everyone would be doing that I would not have to send „please
upgrade your package to mtl-2.1 / transformers-0.3“ mails now.

Having the lower version include other common versions (i.e. the latest
platform release and/or versions found in distribution releases you care
about) is a good idea as well.


Well, for a distro package user, he is expected to first blame the
distro (unless he is knowledgable enough to know that a certain
bug/problem is caused by upstream). Not all users know that, though, and
it does not help if there is a conflict between a distribution-provided
package and code taken from somewhere else.


I would suggest to exclude the broken versions from your dependency.
cabal-install users will then hopefully get your package built against
an older, non-buggy version.


This is a general problem in the Haskell ecosystem that not all
build-dependencies combinations can be tested. For a few targets, you
can test it using different ~/.cabal directories or probably some of the
recent cabal-enhancing tools (cabal-dev et. al.), which I don’t know
myself.

Or just do the RERO-principle and assume things work until someone
complains.


But you are right in that things are not so easy to get perfectly
right :-)

Greetings,
Joachim

Re: On the Haskell Platform

Heinrich Apfelmus — 2012-05-13T19:36:40

 >

I see. Thinking about this, it appears to me that the only way to meet 
the "one-version-per-package" constraint is the following approach on my 
part:

A. Always support the latest version of a dependency (compiler, library, 
...), i.e. the upper bounds of my version constraints have to match the 
latest stuff.

B. If desired, support older versions of a dependency by adjusting the 
lower bounds of my version constraints.

This way, my package can never be blamed when it fails to install; 
rather, "the blame" falls on the user for not upgrading his system.

(Package management is probably best seen as a "blame game". Scenario: 
"This package fails to install, who is to blame?" Usually, the user can 
only assign responsibility to the author of the package, even though the 
latter may not have direct control over the problem. Of course, the 
overall goal of package management is to route responsibility to the 
right person who can fix it.)


However, this approach is not without problems.

The first problem is this: what happens if the newer version of my 
dependency has a bug? This happened to me in the case of GHC 7.2 and now 
also in the case of wx-0.90 . Unfortunately, neither waiting for an 
upstream fix (GHC-7.2) nor working on an upstream fix myself (wx-0.90) 
will help: I have to implement a workaround in my own package if I want 
to keep it usable for everyone who has already installed the buggy 
dependency. I tried to depend on an older version, but doesn't fly with 
the approach above.

The second problem is that the lower bounds will tend to be higher than 
necessary. The thing is that once I install the new dependency on my 
machine and develop a new feature in my package, I can no longer test 
whether my package still works with the old version. That would require 
me have both versions of my dependency installed at the same time, which 
is very tricky with the "one-version-per-package" assumption. Unable to 
test the old version, I cannot, in good conscience, include a dependency 
on the old version. (However, doing so is not too bad for me, because I 
can deflect "the blame" in case it doesn't work.)



That's a good idea. Unfortunately, it doesn't help with the issue at 
hand (new dependency has a bug, old dependency requires old Haskell 
Platform).


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: On the Haskell Platform

Joachim Breitner — 2012-05-13T17:35:06

[Re-Sending, the mailing list is picky about sender e-mail addresses.]

Hi Heinrich,


Am Freitag, den 11.05.2012, 10:23 +0200 schrieb Heinrich Apfelmus:

the problem with packaging the platform is that distributions have a
one-version-per-package policy, so we can not always have exactly the
version present in the latest platform, e.g. because other packages
require a newer version, or just because the old version is too old and
buggy and our users want newer versions. Therefore, we take the liberty
to diverge a bit. You can see the current status for Debian on 
http://people.debian.org/~nomeata/platform.html

Furthermore, in the development brach of Debian, unstable, we prepare
the next releases and currently package the versions that we expect for
the platform 2012.2.0.0. You can see that the version you linked to is
such an prerelease by the version number (2012.1.0.0~debian1).

In Debian, we would avoid having such a prerelease in a stable release
(but might decide that it could still be better than having too old
versions of compiler and libraries). I can’t speak for Ubuntu in that
regard.


From a distro point of view I can only say: We made policies and
decisions that lead to us not being able to provide up-to-date libraries
_and_ the latest (or even all) platform versions, so this problem will
likely stay around for a while.

What we can offer, though, is to package your software. A „complete
Haskell beginner“ should maybe use distro-packaged libraries in the
first place, precisely because the distribution takes care of these
issues for him.

Greetings,
Joachim

Re: On the Haskell Platform

Yitzchak Gale — 2012-05-13T12:22:24

That Ubuntu package is just a direct port from Debian.
So I am adding a CC to Joachim, our resident Debian
packaging hero, hoping for comment on the issue.

Thanks,
Yitz

transforming xhtml attributes

Chris Dornan — 2012-05-11T20:49:53

Folks,
 
I am proposing to extend the xhtml package slightly to better support
attribute munging.
 
Currently you would use (!) to add a bunch of attributes to an element,
thus:
 
                b1 = button noHtml ! [name "go", value "go"]
 
The problem, as pointed out by mistuke[1]  is that there is no way to safely
add attributes as this could result in an attribute being bound ambiguously
and illegally [2] thus:
 
                b2 = b1 ! [value "oops"]
 
Apparently this can lead Haddock to generate illegal (X)HTML [1].
 
My proposed solution is to add a new CHANGEATTRS class with the overloaded
function:
 
                changeAttrs :: CHANGEATTRS a => a -> ([HtmlAttr] ->
[HtmlAttr]) -> a
 
and to export a function for analysing the (abstract) HtmlAttr type:
 
                htmlAttrPair :: HtmlAttr -> (String, String)
 
CHANGEATTRS/changeAttrs/htmlAttrPair works just like ADDATTRS/(!) except
that the attributes can be analysed and transformed. 
 
                extend_name :: Html -> Html
                extend_name h = h `changeAttrs` map f
                      where
                        f a  = case htmlAttrPair a of
                                 ("name",nm) -> name $ "foo_" ++ nm
                                 _           -> a
 
Finally, I have an embarrassing confession to make -- I forgot that I should
be getting the changes reviewed here -- even for such a modest widening of
the API -- and have already put out
3000.2.1 with these additions onto Hackage!
 
Comments and feedback welcome though,
 
Chris
 
[1] https://github.com/haskell/xhtml/issues/2
[2] http://www.w3.org/WAI/GL/WCAG20-TECHS/H94.html
 
 
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

On the Haskell Platform

Heinrich Apfelmus — 2012-05-11T08:23:21

Dear list,

I have written a package, reactive-banana-wx, which seems to be quite 
enticing to Haskell beginners. It's an implementation of the fabled 
functional reactive programming (FRP), so it's natural that people want 
to play around with it to see what it is all about. I imagine that the 
latest parallelism packages also serve a similar audience.

Of course, to play around with a package, you have to be able to install 
it, hopefully painlessly. As the maintainer, I have adopted the 
following principles as they appeared sound to me:

1. My package installs and works without any hitch on the latest Haskell 
Platform.

This is easier said than done, because one of my dependencies is 
wxHaskell, which tends to have hitches at times. Occasionally, I 
restrict the version number to a specific, older wxHaskell version that 
I know to be bug free.

In other words, the idea is that a complete Haskell beginner will be 
able to install my package with the standard setup even if he knows 
nothing about the Haskell ecosystem.

2. If the user has a setup that doesn't fit the dependencies I 
prescribe, then I expect him to change the version constraints himself 
(and hopefully tell me whether it works.)

The idea is that having a non-standard setup is an indication that the 
user is no longer a beginner, so I can expect him/her to know how to 
change version constraints.


With these principles in mind, imagine my surprise, then, to discover 
that the "Haskell Platform" on Ubuntu 12.04 includes GHC 7.4.1

   http://packages.ubuntu.com/precise/haskell-platform

Clearly, this must be a fake Haskell Platform, because the latest real 
Haskell Platform is still at GHC 7.0.4 at the time of this writing. 
Unfortunately, my principle 1 is now rendered moot.


I don't quite know what to do. I understand that there is a need to get 
the latest GHC into the standard setup, but creating a "fake" Haskell 
Platform seems like a mistake to me, as it contradicts the use case 
"complete Haskell beginner" I described above. Not to mention that I'm 
stuck with the "real" Haskell Platform on Mac OS X and would have to 
manage separate cabal installations if I want to thoroughly test my 
package for all compiler versions. Or is it my principles that need to 
change?


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

[PATCH] Fix typo in documentation of GHC.Exts.groupWith

Simon Hengel — 2012-05-10T08:44:36

---
 GHC/Exts.hs |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/GHC/Exts.hs b/GHC/Exts.hs
index 0bf8f7f..8281895 100755
--- a/GHC/Exts.hs
+++ b/GHC/Exts.hs
< at >< at > -102,7 +102,7 < at >< at > sortWith :: Ord b => (a -> b) -> [a] -> [a]
 sortWith f = sortBy (\x y -> compare (f x) (f y))
 
 -- | The 'groupWith' function uses the user supplied function which
--- projects an element out of every list element in order to to first sort the 
+-- projects an element out of every list element in order to first sort the
 -- input list and then to form groups by equality on these projected elements
 {-# INLINE groupWith #-}
 groupWith :: Ord b => (a -> b) -> [a] -> [[a]]

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

wren ng thornton — 2012-05-09T21:39:11

Sure. I was just pointing out the paranoia option ;)



I was meaning more that some folks might be concerned about the slowdown 
compared to the current implementation. Which we should really quantify 
before replacing the old implementation. If it's significant, I'm fine 
with having different implementations based on whether you're 
performance crazy vs need those features.


Sounds like a good plan. Let me know if you want any help with the 
bounded and closeable variants, or with benchmarking.