[Haskell-cafe] Help me understand general recursion from cata- and anamorphism
In an attempt to understand why cata- and anamorphisms are considered so important, I found multiple implications that you can write any recursive functions in terms of nonrecursive functions and ana, cata (am I right here?) so I'm trying to practice the rewrite by a few functions. I'm following a recipe found here: http://lambda-the-ultimate.org/node/4290 ~~~ Given a function that recurses on itself, do a partial CPS transform so that it only ever recurses on itself with tail calls. Then, convert the recursive calls to codata returns, so that the function either returns TheAnswer or StillWorking with enough parameters to describe the recursive call / continuation state. This codata can be built with an unfold and can be collapsed back down to the final answer with a fold. ~~~ https://github.com/nushio3/practice/blob/master/lens/banana/CollatzTest.hs https://github.com/nushio3/practice/blob/master/lens/banana/FibTest.hs I find it difficult to understand the terminology, and the above attempts are only halfway done. I guess ( TheAnswer or StillWorking ) structure is the one found in iteratee/enumeratee. But I don't know how to build a codata with unfold. I'd appreciate any advice. Best, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with GHC API and error handling
OK, thanks to Luite Stegeman I've found the solution and I think I'll
post it here in case someone else stumbles upon the same problem.
The solution is the following: you have to change 'log_action'
parameter in dynFlags. For example, one can do this:
---
initGhc = do
..
ref - liftIO $ newIORef
dfs - getSessionDynFlags
setSessionDynFlags $ dfs { hscTarget = HscInterpreted
, ghcLink = LinkInMemory
, log_action = logHandler ref}
logHandler :: IORef String - LogAction
logHandler ref dflags severity srcSpan style msg =
case severity of
SevError - modifyIORef' ref (++ printDoc)
SevFatal - modifyIORef' ref (++ printDoc)
_ - return ()
where cntx = initSDocContext dflags style
locMsg = mkLocMessage severity srcSpan msg
printDoc = show (runSDoc locMsg cntx)
-- LogAction == DynFlags - Severity - SrcSpan - PprStyle - MsgDoc - IO ()
---
On Sat, Jun 15, 2013 at 1:26 PM, Daniel F difru...@gmail.com wrote:
Hello, everyone.
I am in need of setting up custom exception handlers when using GHC
API to compile modules. Right now I have the following piece of code:
* Main.hs:
--
import GHC
import GHC.Paths
import MonadUtils
import Exception
import Panic
import Unsafe.Coerce
import System.IO.Unsafe
handleException :: (ExceptionMonad m, MonadIO m)
= m a - m (Either String a)
handleException m =
ghandle (\(ex :: SomeException) - return (Left (show ex))) $
handleGhcException (\ge - return (Left (showGhcException ge ))) $
flip gfinally (liftIO restoreHandlers) $
m = return . Right
initGhc :: Ghc ()
initGhc = do
dfs - getSessionDynFlags
setSessionDynFlags $ dfs { hscTarget = HscInterpreted
, ghcLink = LinkInMemory }
return ()
test :: IO (Either String Int)
test = handleException $ runGhc (Just libdir) $ do
initGhc
setTargets = sequence [ guessTarget ./test/file1.hs Nothing ]
graph - depanal [] False
loaded - load LoadAllTargets
-- when (failed loaded) $ throw LoadingException
setContext (map (IIModule . moduleName . ms_mod) graph)
let expr = main
ty - exprType expr -- throws exception if doesn't typecheck
output ty
res - unsafePerformIO . unsafeCoerce $ compileExpr expr
return res
--
* file1.hs:
module Main where
main = do
return x
The problem is when I run the 'test' function above I receive the
following output:
h test
test/file1.hs:4:10: Not in scope: `x'
Left Cannot add module Main to context: not a home module
it :: Either String Int
So, if I understand this correctly, my exception handler does indeed
catch an exception correctly,
however, I still receive some output which I want to be captured.
Is there a way to do this?
--
Sincerely yours,
-- Daniil Frumin
--
Sincerely yours,
-- Daniil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: custom-hackage
On 13-06-13 11:09 AM, Niklas Hambüchen wrote: https://github.com/nh2/custom-hackage An (almost trivial) script to generate 00-index.tar.gz which is necessary to run your own `remote-repo`. I write the following critique with much reluctance, since I will be saying a lot of this cannot possibly work, here is why, but I would also like to think that it had worked for you before you published it. Assume the remote-repo line goes like remote-repo: custom:http://127.0.0.1:8080/packages/archive And assume it has just one package, formula-1.1 Then your scheme uses this layout: http://127.0.0.1:8080/00-index.tar.gz http://127.0.0.1:8080/packages/archive/formula/1.1/formula-1.1.tar.gz However, cabal-install expects this layout: http://127.0.0.1:8080/packages/archive/00-index.tar.gz http://127.0.0.1:8080/packages/archive/package/formula-1.1.tar.gz I know this by both reading cabal-install source code and empirical tests, both 0.14 and 1.16. I have a working example at http://www.vex.net/~trebla/haskell/conrepo Lastly, I want to emphasize these points: The layout is different from Hackage's; cabal-install source code hardcodes treating Hackage differently. Yes, it goes out of its way to detect http://hackage.haskell.org/packages/archive; and do a different thing. Mimicking Hackage is futile, unless you go out of your way to also mimic the host name hackage.haskell.org. And the layout is different from local-repo's; local-repo's is in fact close to Hackage's. See my http://www.vex.net/~trebla/haskell/cabal-cabal.xhtml#remote-repo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Papers IFL 2013
Hello, Please, find below the second call for papers for IFL 2013. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL CALL FOR PAPERS 25th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2013 RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS ACM In-Cooperation / ACM SIGPLAN AUGUST 28 - 30 2013 Landgoed Holthurnsche Hof http://ifl2013.cs.ru.nl We are proud to announce that the 25th edition of the IFL series returns to its roots at the Radboud University Nijmegen in the Netherlands. The symposium is held from 28th to 30th of August 2013. Scope - The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2013 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2013 will use a post-symposium review process to produce the formal proceedings which will be published in the ACM Digital Library. All participants of IFL 2013 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Invited Speaker --- Lennart Augustsson, currently employed by the Standard Chartered Bank, well-known for his work on Haskell, parallel Haskell, Cayenne, and Bluespec, is the invited speaker of IFL 2013. He will be talking about practical applications of functional programming. Submission Details -- Submission deadline draft papers: July 31 Notification of acceptance for presentation: August 2 Early registration deadline: August 7 Late registration deadline:August 14 Submission deadline for pre-symposium proceedings: August 21 25th IFL Symposium:August 28-30 Submission deadline for post-symposium proceedings:November 11 Notification of acceptance for post-symposium proceedings: December 18 Camera-ready version for post-symposium proceedings: February 3 2014 Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Papers are to be submitted via the conference's EasyChair submission page: https://www.easychair.org/conferences/?conf=ifl2013 Topics -- IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2013, please contact the PC chair at ri...@cs.ru.nl. Topics of interest include, but are not limited to: language concepts type systems, type checking, type inferencing compilation techniques staged compilation run-time function specialization run-time code generation partial evaluation (abstract) interpretation metaprogramming generic programming automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution embedded systems web applications (embedded) domain specific languages security novel memory management techniques run-time
[Haskell-cafe] opengl type confusion
This,
wireframe :: Double - Double - Double - IO ()
wireframe wx wy wz = do
-- yz plane
renderPrimitive LineLoop $ do
vertex $ Vertex3 0.0 0.0 0.0
vertex $ Vertex3 0.0 wy 0.0
vertex $ Vertex3 0.0 wy wz
vertex $ Vertex3 0.0 0.0 wz
produces this:
No instance for (VertexComponent Double)
arising from a use of `vertex'
Possible fix:
add an instance declaration for (VertexComponent Double)
In the expression: vertex
In a stmt of a 'do' block: vertex $ Vertex3 0.0 wy 0.0
In the second argument of `($)', namely
`do { vertex $ Vertex3 0.0 0.0 0.0;
vertex $ Vertex3 0.0 wy 0.0;
vertex $ Vertex3 0.0 wy wz;
vertex $ Vertex3 0.0 0.0 wz }'
and thusly this :-(
Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There
are many times I see the compiler doing type conversion an numerican arguments
although sometimes the occasional fracSomethingIntegralorOther is required.
I was hoping for some enlightenment.
Thank you.
Brian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote: Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There are many times I see the Haskell never automagics types in that context; if it expects GLdouble, it expects GLdouble. Pretending it's Double will not work. It would in the specific case that GLdouble were actually a type synonym for Double; however, for performance reasons it is not. Haskell Double is not directly usable from the C-based API used by OpenGL, so GLdouble is a type synonym for CDouble which is. compiler doing type conversion an numerican arguments although sometimes the occasional fracSomethingIntegralorOther is required. I presume the reason the type specification for numeric literals is because there is no defaulting (and probably can't be without introducing other strange type issues) for GLdouble. In any case, the very fact that you refer to automagic and type conversion indicates that you don't really have an understanding of how Haskell's numeric types work; this will lead you into not only this kind of confusion, but worse problems later. In particular, you're going to get into dreadful messes where you expect Haskell to transparently deal with strange combinations of numeric types as if Haskell were (almost-typeless) Perl or something, and you'll have real trouble getting that code to work until you sit down and figure out how strong typing and Haskell's numeric typeclasses interact. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
On Sun, 16 Jun 2013 16:15:25 -0400 Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote: Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There are many times I see the Haskell never automagics types in that context; if it expects GLdouble, it expects GLdouble. Pretending it's Double will not work. It would in the specific case that GLdouble were actually a type synonym for Double; however, for performance reasons it is not. Haskell Double is not directly usable from the C-based API used by OpenGL, so GLdouble is a type synonym for CDouble which is. compiler doing type conversion an numerican arguments although sometimes the occasional fracSomethingIntegralorOther is required. I presume the reason the type specification for numeric literals is because there is no defaulting (and probably can't be without introducing other strange type issues) for GLdouble. What I was thinking about, using a very poor choice of words, was this : *Main let a = 1 *Main :t a a :: Integer *Main let a = 1::Double *Main a 1.0 *Main :t a a :: Double *Main so normally 1 would be interpreted as an int, but if I declare 'a' a Double then it gets promoted to a Double without me having to call a conversion routine explicitly. That seems automagic to me. (0.0::GLdouble) works to make the compiler happy. So it appears to be taking care of the conversion automagically. So maybe a better question, I hope, is: How can I simply declare 0.0 to be (0.0::GLdouble) and have the functional call work. Doesn't a conversion have to be happening, i.e. shouldn't I really have to do (realToFrac 0.0) ? Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote: On Sun, 16 Jun 2013 16:15:25 -0400 Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote: Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There are many times I see the Haskell never automagics types in that context; if it expects GLdouble, it expects GLdouble. Pretending it's Double will not work. It would in the specific case that GLdouble were actually a type synonym for Double; however, for performance reasons it is not. Haskell Double is not directly usable from the C-based API used by OpenGL, so GLdouble is a type synonym for CDouble which is. compiler doing type conversion an numerican arguments although sometimes the occasional fracSomethingIntegralorOther is required. I presume the reason the type specification for numeric literals is because there is no defaulting (and probably can't be without introducing other strange type issues) for GLdouble. What I was thinking about, using a very poor choice of words, was this : *Main let a = 1 *Main :t a a :: Integer *Main let a = 1::Double *Main a 1.0 *Main :t a a :: Double *Main so normally 1 would be interpreted as an int, but if I declare 'a' a Double then it gets promoted to a Double without me having to call a conversion routine explicitly. That seems automagic to me. (0.0::GLdouble) works to make the compiler happy. So it appears to be taking care of the conversion automagically. So maybe a better question, I hope, is: How can I simply declare 0.0 to be (0.0::GLdouble) and have the functional call work. Doesn't a conversion have to be happening, i.e. shouldn't I really have to do (realToFrac 0.0) ? Brian ___ 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] opengl type confusion
On Sun, Jun 16, 2013 at 01:03:48PM -0700, bri...@aracnet.com wrote: wireframe :: Double - Double - Double - IO () wireframe wx wy wz = do -- yz plane renderPrimitive LineLoop $ do vertex $ Vertex3 0.0 0.0 0.0 vertex $ Vertex3 0.0 wy 0.0 vertex $ Vertex3 0.0 wy wz vertex $ Vertex3 0.0 0.0 wz [...] No instance for (VertexComponent Double) arising from a use of `vertex' [...] Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it Vertex3 takes three arguments, all of which must be of the same instance of VertexComponent. Specifying GLdoubles in the signature of wireframe specifies the types in the last three calls to Vertex3, but (0.0 :: GLdouble) is still requried on the first to fix the type there. How else could the compiler know that you mean 0.0 to be a GLdouble and not a GLfloat? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
On Sun, Jun 16, 2013 at 4:42 PM, bri...@aracnet.com wrote: On Sun, 16 Jun 2013 16:15:25 -0400 Brandon Allbery allber...@gmail.com wrote: On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote: Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There are many times I see the I presume the reason the type specification for numeric literals is because there is no defaulting (and probably can't be without introducing other strange type issues) for GLdouble. What I was thinking about, using a very poor choice of words, was this : *Main let a = 1 *Main :t a a :: Integer *Main let a = 1::Double *Main a 1.0 *Main :t a a :: Double *Main so normally 1 would be interpreted as an int, but if I declare 'a' a Double then it gets promoted to a Double without me having to call a conversion routine explicitly. That seems automagic to me. No magic involved, although some automation is. Take a look at the `default` keyword in the Haskell Report (this is the defaulting I mentioned earlier). http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4 The default `default` is `default (Integer, Double)` which means that it will try to resolve a numeric literal as type Integer, and if it gets a type error it will try again with type Double. You should use this same mechanism to make numeric literals work with OpenGL code: neither Integer nor Double will produce a valid type for the expression, but at the same time the compiler cannot infer a type because there are two possibilities (GLfloat and GLdouble). You could therefore add a declaration `default (Integer, Double, GLdouble)` so that it will try GLdouble to resolve numeric literals when neither Integer nor Double will work. How can I simply declare 0.0 to be (0.0::GLdouble) and have the functional call work. Doesn't a conversion have to be happening, i.e. shouldn't I really have to do (realToFrac 0.0) ? The first part I just answered. As to the second, a conversion *is* happening, implicitly as defined by the language; the question being, to what type. A numeric literal has type (Num a = a), implemented by inserting a call to `fromIntegral` for literals without decimal points and `fromRational` for others. But the compiler can't always work out what `a` is in (Num a = a) without some help (the aforementioned `default` declaration). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] opengl type confusion
I seem to making a mess of it, first accidentally posting an empty message
and then forgetting to reply to the list. Thirdly I forgot to mention that
my message only describes the 'GHCi magic'.
Lars
P.S. Conclusion, I shouldn't write complicated email this late on the
evening.
-- Forwarded message --
From: L Corbijn aspergesoe...@gmail.com
Date: Mon, Jun 17, 2013 at 12:07 AM
Subject: Re: [Haskell-cafe] opengl type confusion
To: bri...@aracnet.com
On Sun, Jun 16, 2013 at 11:10 PM, L Corbijn aspergesoe...@gmail.com wrote:
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote:
On Sun, 16 Jun 2013 16:15:25 -0400
Brandon Allbery allber...@gmail.com wrote:
On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote:
Changing the declaration to GLdouble - GLdouble - GLdouble - IO()
and
using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic.
There are many times I see the
Haskell never automagics types in that context; if it expects
GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not
directly
usable from the C-based API used by OpenGL, so GLdouble is a type
synonym
for CDouble which is.
compiler doing type conversion an numerican arguments although sometimes
the occasional fracSomethingIntegralorOther is required.
I presume the reason the type specification for numeric literals is
because
there is no defaulting (and probably can't be without introducing other
strange type issues) for GLdouble.
What I was thinking about, using a very poor choice of words, was this :
*Main let a = 1
*Main :t a
a :: Integer
*Main let a = 1::Double
*Main a
1.0
*Main :t a
a :: Double
*Main
so normally 1 would be interpreted as an int, but if I declare 'a' a
Double then it gets promoted to a Double without me having to call a
conversion routine explicitly.
That seems automagic to me.
(0.0::GLdouble) works to make the compiler happy. So it appears to be
taking care of the conversion automagically.
So maybe a better question, I hope, is:
How can I simply declare 0.0 to be (0.0::GLdouble) and have the
functional call work. Doesn't a conversion have to be happening, i.e.
shouldn't I really have to do (realToFrac 0.0) ?
Brian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Oops sorry for the empty reply, I accidentally hit the sent button.
What you are seeing is the defaulting (see
http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4).
Which roughly speaking means that if you need a specific instance of a
number first try Integer then Double and as a last resort fail.
Prelude :t 1
1 :: Num a = a
Prelude :t 1.0
1.0 :: Fractional a = a
So normally a number can be just any instance of the Num class, and any
number with a decimal can be any Fractional instance. And now with let
bindings
The need for defaulting is caused by the monomorphism restriction (
http://www.haskell.org/haskellwiki/Monomorphism_restriction), which states
that let binds should be monomorphic, or roughly speaking it should contain
no type variables (unless of course you provide a type signature).
Prelude let b = 1
Prelude :t b
b :: Integer
Prelude let c = 1.0
Prelude :t c
c :: Double
So here you see the result of the combination. The monomorphism restriction
doesn't allow 'Num a = a' as type for 'b'. So the defaulting kicks in and
finds that its first guess 'Integer' fits. Therefore 'b' gets type
Integer. Though for 'c' the guess 'Integer' fails as it isn't a Fractional.
Its second guess, Double, is a fractional so 'c' gets type Double.
You can see that the monomorphism restriction is to blame by disabling it
Prelude :set -XNoMonomorphismRestriction
Prelude let b = 1
Prelude :t b
b :: Num a = a
But you shouldn't normally need to do this, as you can provide a specific
type signature.
(in a fresh GHCi session)
Prelude let {b :: Num a = a; b = 1}
Prelude :t b
b :: Num a = a
On Sun, Jun 16, 2013 at 10:42 PM, bri...@aracnet.com wrote:
On Sun, 16 Jun 2013 16:15:25 -0400
Brandon Allbery allber...@gmail.com wrote:
On Sun, Jun 16, 2013 at 4:03 PM, bri...@aracnet.com wrote:
Changing the declaration to GLdouble - GLdouble - GLdouble - IO()
and
using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic.
There are many times I see the
Haskell never automagics types in that context; if it expects GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not
directly
usable from the C-based API used by OpenGL, so GLdouble
Re: [Haskell-cafe] opengl type confusion
On Sun, 16 Jun 2013 22:19:22 +0100 Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: On Sun, Jun 16, 2013 at 01:03:48PM -0700, bri...@aracnet.com wrote: wireframe :: Double - Double - Double - IO () wireframe wx wy wz = do -- yz plane renderPrimitive LineLoop $ do vertex $ Vertex3 0.0 0.0 0.0 vertex $ Vertex3 0.0 wy 0.0 vertex $ Vertex3 0.0 wy wz vertex $ Vertex3 0.0 0.0 wz [...] No instance for (VertexComponent Double) arising from a use of `vertex' [...] Changing the declaration to GLdouble - GLdouble - GLdouble - IO() and using (0.0::GLdouble) fixes it Vertex3 takes three arguments, all of which must be of the same instance of VertexComponent. Specifying GLdoubles in the signature of wireframe specifies the types in the last three calls to Vertex3, but (0.0 :: GLdouble) is still requried on the first to fix the type there. How else could the compiler know that you mean 0.0 to be a GLdouble and not a GLfloat? Tom it's curious that (0.0::GLdouble) 0.0 0.0 is good enough and that (0.0::GLdouble) (0.0::GLdouble) (0.0::GLdouble) is not required. I suspect that's because, as you point out, they all have to be the same argument and ghc is being smart and saying if the first arg _must_ be GLdouble (because I'm explicitly forcing the type), then the rest must be too. Meanwhile 4.3.4 about the default is quite interesting. Didn't know about that :-) Thanks very much for the responses ! Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: som-4.0 (for data analysis and visualisation)
This sounds really cool! I'm going to have to read up on SOMs. On Fri, Jun 7, 2013 at 9:30 AM, Amy de Buitléir a...@nualeargais.ie wrote: Do you have some data that you'd like to understand better? I'm happy to announce a new release of a package called som that may help: http://hackage.haskell.org/package/som https://github.com/mhwombat/som/wiki (wiki) A Kohonen Self-organising Map (SOM) maps input patterns onto a regular grid (usually two-dimensional) where each node in the grid is a model of the input data, and does so using a method which ensures that any topological relationships within the input data are also represented in the grid. This implementation supports the use of non-numeric patterns. In layman's terms, a SOM can be useful when you want to discover the underlying structure of some data. I have a brief tutorial in the wiki, which I hope to expand over the next few weeks. WHAT'S NEW - It is now easier to for non-math types to create a SOM (see defaultSOM) - Added another example to the wiki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- adit.io ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: custom-hackage
Hello Albert, thanks for this! Please don't be reluctant with this, it is very appreciated. I have updated the script to use the paths as you described, and it seems to work quite well. The fact that all tars land under package/ even makes is easier to use. It would be great if you could give it another try. Niklas On 17/06/13 02:42, Albert Y. C. Lai wrote: On 13-06-13 11:09 AM, Niklas Hambüchen wrote: https://github.com/nh2/custom-hackage An (almost trivial) script to generate 00-index.tar.gz which is necessary to run your own `remote-repo`. I write the following critique with much reluctance, since I will be saying a lot of this cannot possibly work, here is why, but I would also like to think that it had worked for you before you published it. Assume the remote-repo line goes like remote-repo: custom:http://127.0.0.1:8080/packages/archive And assume it has just one package, formula-1.1 Then your scheme uses this layout: http://127.0.0.1:8080/00-index.tar.gz http://127.0.0.1:8080/packages/archive/formula/1.1/formula-1.1.tar.gz However, cabal-install expects this layout: http://127.0.0.1:8080/packages/archive/00-index.tar.gz http://127.0.0.1:8080/packages/archive/package/formula-1.1.tar.gz I know this by both reading cabal-install source code and empirical tests, both 0.14 and 1.16. I have a working example at http://www.vex.net/~trebla/haskell/conrepo Lastly, I want to emphasize these points: The layout is different from Hackage's; cabal-install source code hardcodes treating Hackage differently. Yes, it goes out of its way to detect http://hackage.haskell.org/packages/archive; and do a different thing. Mimicking Hackage is futile, unless you go out of your way to also mimic the host name hackage.haskell.org. And the layout is different from local-repo's; local-repo's is in fact close to Hackage's. See my http://www.vex.net/~trebla/haskell/cabal-cabal.xhtml#remote-repo ___ 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
