On 9/4/07, Sven Panne [EMAIL PROTECTED] wrote:
But coming to the main point: I can't see a reason why the GLUT package needs
to be rebuilt, it gets the freeglut-specific API entries dynamically (at
least, that was the plan ;-). Replacing the original GLUT DLL with the
freeglut DLL should work.
] wrote:
On Tuesday 04 September 2007 15:37, Paul L wrote:
The detection of freeglut or glut is at compile time by checking if
some function exists. Otherwise it's not able to link. So you'll have
to re-compile the Haskell GLUT package.
Show me the code where the alleged tests are made, please
I believe it's caused by the different versions of GLUT you have.
On 9/8/07, Ronald Guida [EMAIL PROTECTED] wrote:
[...]
Loading package OpenGL-2.2.1 ... linking ... done.
Loading package GLUT-2.1.1 ... linking ... done.
The above message was after you have installed GLUT-2.0, but GHC was
On 9/8/07, Ronald Guida [EMAIL PROTECTED] wrote:
Clearly, I'm missing something here. Where do I have to go to get the
latest version of GLUT?
You can get it using darcs:
darcs get http://darcs.haskell.org/packages/GLUT/
Also, after I built freeglut with VS-2003, I copied the include
On 9/9/07, Ronald Guida [EMAIL PROTECTED] wrote:
Good news:
I abandoned GLUT and looked at GLFW. I had similar problems getting
GLFW to work with GHC and GHCi. After a bunch of hacking, I got GLFW
to work for me.
Glad to hear it, but please let me know what problems you had.
GLFW doesn't
If you read the memo1 function carefully you'll notice that the cache
always contains just one pair. It's coincident that just memo-ing one
last function application is enough for the SOE examples. You could,
for example, make it memo-ing last two or more results.
The reason for this memoization
Here is a minimal answer using Yampa-like Signal Function and Arrow
notation. You have to load this using ghci -farrows.
import Control.Arrow
The differential equation you gave are indeed:
i = integral (cos i) + i0
c = integral (alpha * (i - c)) + c0
where i0 and c0 are the initial
On 9/29/07, Ryan Ingram [EMAIL PROTECTED] wrote:
first bc = SF sf where
sf dt ~(b,d) = ((c,d), sfFirst bc') where
(c, bc') = runSF bc dt b
One question I had was about the implementation of first. Is it
important that the pair match be lazy? Or is it safe to make
It seems like the GLFW C binaries wasn't included in your GLFW Haskell
module installed. Did you do the last step by running install.bat or
install.sh instead of runhaskell Setup install?
Regards,
Paul Liu
On 10/2/07, Immanuel Normann [EMAIL PROTECTED] wrote:
Hello,
I have just read the
Just to echo back to the question whether Yampa/AFRP is still being
developed, the answer is YES. We are working on an updated version at
Yale.
But really, we have many choices of doing reactive programming, and
AFRP is only one of them. And even for AFRP, there are many choices of
combinators
It sounds like the windowSizeCallback wasn't called when the app first
started up. You may try naming that callback function, and calling it
once during startup time.
I have not test it myself, but I don't recall this problem when I
previously worked on OS X 10.5 with GLFW.
On 3/16/10, Carsten
Just tried it, same configuration OS X 10.6.2, GHC 6.12.1, GLFW 4.2,
etc. Fresh install. No problem at all, and no work around needed.
On 3/17/10, Paul L nine...@gmail.com wrote:
It sounds like the windowSizeCallback wasn't called when the app first
started up. You may try naming that callback
Does anybody know why the type families only supports equality test
like a ~ b, but not its negation?
--
Regards,
Paul Liu
Yale Haskell Group
http://www.haskell.org/yale
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
/2010 01:08 AM, Paul L wrote:
Does anybody know why the type families only supports equality test
like a ~ b, but not its negation?
This has annoyed me, too. However, HList provides something quite similar,
namely the TypeEq[1] fundep-ed class which will answer type-equality with a
type-level
Thanks a lot for the explanation. Do you think supporting type
inequality test in type families would require UndecidableInstances?
For the reason that wren ng thornton mentioned?
On Sat, Jul 17, 2010 at 4:56 AM, o...@okmij.org wrote:
Ryan Ingram wrote:
But it doesn't generalize; you need to
GLFW is a Haskell module for GLFW OpenGL framework. It provides an
alternative to GLUT for OpenGL based Haskell programs.
The current 0.3 version is for download from hackageDB at:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GLFW-0.3
Same as the previous 0.2 version it requires
Peter is right at saying it's the sample GLFW program that didn't
handle Window Close event. I didn't double check his modification
because I run Linux/X11 with xmonad where there is no CLOSE button for
any window, but I trust his modification works fine :-)
As for the alternatives, I don't think
On 3/25/08, Luke Palmer [EMAIL PROTECTED] wrote:
Er, not Ctrl, of course... Mod-Shift-C. /me goes to punish his hand
for compusive send presses.
I believe that is to kill a window rather than a normal window close.
--
Regards,
Paul Liu
Yale Haskell Group
http://www.haskell.org/yale
Pardon me to hijack this thread, but I have an idea to build a
different kind of Web Framework and am not sure if somebody has
already done it.
The idea is to take REST further: every HTML page you see is a program
in its running state (as a continuation monad). Each click on its link
or form
Thank you guys for all the good references!
To address a few concerns with this approach:
1. By stateless I don't mean to strip away any persistency. The
program can access file storage or DBMS just like any ordinary I/O
operation.
2. If we take it to the extreme side, the entire program
strangely I don't get this behavior. I'm also running GHC 6.10.4 on
Linux, Are you sure that your system GL driver handles double
buffering correctly?
BTW, cabal install bloxorz fails to compile due to some type
mismatch between GLfloat and Float. But once this is fixed, everything
compiles and
The problem you mentioned has long been fixed in the darcs version,
but then there is also another problem: you need GHC 6.12 in order to
compile GLFW for Snow Leopard. Here is a detail description of why
prior versions of GHC fails to work:
http://hackage.haskell.org/trac/ghc/ticket/3522
I've
Trying to give different semantics to the same declarative definition based
on whether it's recursively defined or not seems rather hack-ish, although
I can understand what you are coming from from an implementation angle.
Mathematically an integral operator has only one semantics regardless
of
really
interested
in knowing whether anybody has implemented a higher order method?
Regards
J-C
On Tue, Apr 21, 2009 at 5:03 AM, Paul L nine...@gmail.com wrote:
Trying to give different semantics to the same declarative definition
based
on whether it's recursively defined or not seems
Let-expression in the EDSL indeed solves the sharing problem, but only
partially.
Recursion appears when you have a leaf node pointing back to the root
node or another branch and forming a cyclic graph in the data
structure. It is often desirable to recover cyclic sharing when
BTW, I doubt the (cyclic) sharing problem relates that much to purity,
because in an impure language (or the unsafe observable sharing), you
still have to remember whether something has been traversed or not and
in the worst case accumulates everything that's been traversed so far
before releasing
, and repeated updates will inevitably
result in space and time leaks.
--
Regards,
Paul Liu
Yale Haskell Group
http://www.haskell.org/yale
On 6/6/09, Chung-chieh Shan ccs...@post.harvard.edu wrote:
On 2009-05-27T03:58:58-0400, Paul L wrote:
One possible solution is to further introduce a fixed point data
Previously you had lastOrNil taking m [a] as input, presumably
generated by mapM. So mapM is actually building an entire list before
it returns the argument for you to call lastOrNil. This is where you
had unexpected memory behavior.
Now you are fusing lastOrNil and mapM together, and instead of
I'm glad to announce a new version of GLFW, 0.4.1, has been uploaded
to HackageDB. Notable changes include:
* workaround for a FFI bug that affects GHC 6.10 on 64-bit machines.
* fix for the compilation problem on OS X for GHC 6.10.1
* compatibility fix to work with both OpenGL 2.3.0.0 and
I'm pleased to annouce that a library for Causal Commutative Arrows
(CCA) has been uploaded to Hackage DB. It implements CCA normalization
using Template Haskell and a modified arrow pre-processor (based on
arrowp) to generate outout that Template Haskell can parse. It's
highly experimental since
It's available on Hackage DB at http://hackage.haskell.org/package/LambdaINet
Thanks to Kim-Ee Yeoh for pushing me into releasing this piece of code
I wrote two years ago. I'll just quote the README from the source
tarball below.
LambdaINet
==
LambdaINet implements an interaction net
v.dijk@gmail.com wrote:
On Mon, Sep 14, 2009 at 7:36 AM, Paul L nine...@gmail.com wrote:
It's available on Hackage DB at
http://hackage.haskell.org/package/LambdaINet
Nice! Screenshots anywhere?
Bas
--
Regards,
Paul Liu
Yale Haskell Group
http://www.haskell.org/yale
Now it's at version 0.1.2 with the EnableGUI fix for Mac OS X.
On 9/14/09, Paul L nine...@gmail.com wrote:
I just bumped the version to 0.1.1 that fixes an embarrassing bug,
i.e., the first example shown on the screen was actually wrong.
I took a screenshot of the interaction net showing
I'm trying to use newArray to allocate something that has 100M unboxed
doubles. It takes quite a few seconds to do so on GHC 6.10.2. But
doing the same thing (and initialize all to 0) in C returns
immediately. Setting RTS heap size doesn't help. Does anybody happen
to know why?
--
Regards,
Paul
wow, using newArray_ and initialize the whole thing myself is much
faster than newArray. But why?
On 9/18/09, Don Stewart d...@galois.com wrote:
ninegua:
I'm trying to use newArray to allocate something that has 100M unboxed
doubles. It takes quite a few seconds to do so on GHC 6.10.2. But
Thanks very much for the explanation, I now have a better understanding.
On 10/26/08, David Menendez [EMAIL PROTECTED] wrote:
..[snipped]..
It may be helpful to rewrite the types with a more explicit notation.
For example,
runST :: (a :: *) - ((s :: *) - ST s a) - a
mapST_wrong :: (a :: *)
Hi everyone,
It's sad to see the OpenGL binding being dropped from GHC binary
installers starting from 6.10. Though this issue has been brought up
and discussed before, I'm sure a lot of people who based their work on
OpenGL would share the same sympathy.
I'm not here to argue whether this
On 11/22/08, Don Stewart [EMAIL PROTECTED] wrote:
ninegua:
Hi everyone,
It's sad to see the OpenGL binding being dropped from GHC binary
installers starting from 6.10. Though this issue has been brought up
and discussed before, I'm sure a lot of people who based their work on
OpenGL would
On 11/23/08, Duncan Coutts [EMAIL PROTECTED] wrote:
2. It still wouldn't work for the OpenGL package on Windows, because
the configure scripts require a Unix-style built environment
(MinGW/MinSys or Cygwin).
Yes, building it requires mingw/msys, but with it cabal install opengl
really does
Nice to see this discussion, and I just want to comment on the
applicative v.s. arrow style. The example Henrik gave is
z - sf2 sf1 - x
which models a composition, and is in general the strength of a
combinator approach. But the strength of Applicative, in my opinion,
is not composition but
On 12/19/08, Conal Elliott co...@conal.net wrote:
As long as we use not just the arrow abstraction but also *arrow notation*,
I don't know how we'll ever be able to get an efficient implementation, in
which portions of computed signals get recomputed only when necessary. And
probably the
them on 1
or 2 OS threads seem rather arbitary. Why?
Regards,
Paul L
import Control.Concurrent
import System.Random
import Data.Array.MArray
import Data.Array.IO
import System.IO.Unsafe
import Control.Exception
1. Quick Sort
testQSort' n verbose = do
let b = (0, n - 1)
arr - newArray b 0
replying to my own message... the behavior is only when -O is used
during compilation, otherwise they both run on 2 cores but at a much
lower (1/100) speed.
On 7/6/07, Paul L [EMAIL PROTECTED] wrote:
I have two parallel algorithms that use the lightweight GHC thread and
forkIO. I compile them
explain the
difference.
Indeed, after I insert a yield after spawnRemover (i + 1), it now
happily crunches number on both CPUs. Thank you both for the
suggestions!
Regards,
Paul L
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org
is greatly
appreciately!
Regards,
Paul L
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Thanks for the info. I indeed replaced everything, but it only works
after I recompile Graphics.UI.GLUT module.
Regards,
Paul L
On 7/25/07, Marc A. Ziegert [EMAIL PROTECTED] wrote:
to replace only libglut.so is not enough. if i understand you correctly, you
changed the backend without the API
library instead? Or is it a problem of
loading dynamic libraries on OS X?
Regards,
Paul L
On 8/1/07, Alan Mock [EMAIL PROTECTED] wrote:
This works fine for me on PPC and x86 10.4.10. Which GLUT
implementation are you using? Does the code hang or does it crash?
Alan Mock
On Aug 1, 2007
vertex4 = GL.Vertex4
Note that the coordinate system for rasterization is different from
GL's transformation matrix.
If you really want the stroke font, you should use Roman or MonoRoman,
then you may transform your position using GL.translate (GL.Vector3 x
y 0).
Regards,
Paul L
On 8/1/07, Dave Tapley
will then be able to recognize the freeglut, at
least confirmed by experiments on my Linux box a few days ago.
Regards,
Paul L
On 8/1/07, Ronald Guida [EMAIL PROTECTED] wrote:
Hi,
I am trying to use freeglut with GHCi 6.6.1, and I'm stuck. I
downloaded freeglut 2.4.0 and compiled it. I am on a Windows
Are you trying it on Linux?
I had exactly the same problem. I believe it's with with X11/OpenGL.
I've written C programs using GLUT, freeGLUT and GLFW (another OpenGL
Window Kit) to re-open window after first one is closed. Unfortunately
all gave the same fault. So it leads me to believe the
Ok, after spending some time looking for a solution, here is a stroke
of genius by wxHaskell folks at
http://wxhaskell.sourceforge.net/building-macosx.html
I've tried this enableGUI trick using GHCi, it works with my GLFW
interface to Haskell which suffered from the same problem as GLUT on
OS X,
Thanks for the massive update! Is there a new version of Orchid coming along?
On 3/22/09, Sebastiaan Visser sfvis...@cs.uu.nl wrote:
Hi all,
I am pleased to announce a new version of Salvia, the lightweight
Haskell Web Server Framework with modular support for serving static
files,
.
Loading package Tensor-1.0.0.1 ... linking ... done.
Loading package OpenGL-2.4.0.1 ... linking ... done.
Loading package GLFW-0.4.2 ... linking ... done.
Michael
--- On Sun, 1/30/11, Paul L nine...@gmail.com wrote:
From: Paul L nine...@gmail.com
Subject: Re: [Haskell-cafe] Code from
8
In the second argument of `openWindow', namely
`[DisplayStencilBits 8 DisplayAlphaBits 8]'
In a stmt of a 'do' expression:
openWindow
(Size 400 400) [DisplayStencilBits 8 DisplayAlphaBits 8] Window
[michael@localhost ~]$
--- On *Sun, 1/30/11, Paul L nine
the comma when I put it all on one line. Sorry.
Yes, it compiles and runs, just like it did before.
Michael
--- On Sun, 1/30/11, Paul L nine...@gmail.com wrote:
From: Paul L nine...@gmail.com
Subject: Re: [Haskell-cafe] Code from Haskell School of Expression hanging.
To: michael rice nowg
Maybe you want to remove Snowflake.o (or even *.o) and then try compiling it
again.
Regards,
Paul Liu
On Sun, Jan 30, 2011 at 4:11 PM, michael rice nowg...@yahoo.com wrote:
SimpleGraphics has a bunch of main programs: main0, main1, main2, main3,
and main3book. I sequentially changed each to
Forgot to CC the list, please see below.
On Wed, Mar 30, 2011 at 2:29 PM, Mathijs Kwik bluescreen...@gmail.com wrote:
someBox :: Either A B ~ O
someBox = handleA ||| handleB
Not sure about this. If you are modeling the input as Either A B, then
you are excluding the possibility of both A and
On Sun, Mar 20, 2011 at 10:18 PM, David Barbour dmbarb...@gmail.com wrote:
The (***) and () operations, as specified in Control.Arrow, are
inherently synchronization points.
Ideally one could do something like:
(a1 *** a2) first a3
and the output from a1 would be piped directly as input
On Fri, Apr 1, 2011 at 1:09 PM, Mathijs Kwik bluescreen...@gmail.com wrote:
I think this defies the CPS style stream processors goal.
In reality, the outputs might be infinite, or just very very many,
which will cause space leaks if they need to be buffered.
If the input (and in your case,
example of f.
Regards,
Paul Liu
On Fri, Apr 1, 2011 at 1:55 PM, David Barbour dmbarb...@gmail.com wrote:
On Fri, Apr 1, 2011 at 11:47 AM, Paul L nine...@gmail.com wrote:
On Sun, Mar 20, 2011 at 10:18 PM, David Barbour dmbarb...@gmail.com wrote:
The (***) and () operations, as specified
are criticizing). It may
require some type level magic, but I am quite positive that
difficulties can be overcome.
Regards,
Paul Liu
On Fri, Apr 1, 2011 at 6:00 PM, David Barbour dmbarb...@gmail.com wrote:
On Fri, Apr 1, 2011 at 2:57 PM, Paul L nine...@gmail.com wrote:
I now understand where you
Sorry, forgot to CC the list. I wonder why Gmail doesn't default to reply-all.
On Fri, Apr 1, 2011 at 9:48 PM, David Barbour dmbarb...@gmail.com wrote:
If we ignore the 'delay' primitive (which lifts latency into program
logic), my model does meet all the arrow laws. Nonetheless, the issues
62 matches
Mail list logo
