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 wrote:
>
> If we ignore the 'delay' primitive (which lifts latency into program
> logic), my model does meet all the arrow laws. Nonetheless, the issues
> of physical synch
amps of the
tuple elements (what is exactly what you 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 wrote:
> On Fri, Apr 1, 2011 at 2:57 PM, Paul L wrote:
>&g
want to give a specific example of "f".
Regards,
Paul Liu
On Fri, Apr 1, 2011 at 1:55 PM, David Barbour wrote:
> On Fri, Apr 1, 2011 at 11:47 AM, Paul L wrote:
>> On Sun, Mar 20, 2011 at 10:18 PM, David Barbour wrote:
>>
>>> The (***) and (&&&) operatio
On Fri, Apr 1, 2011 at 1:09 PM, Mathijs Kwik 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, the output fedback as i
On Sun, Mar 20, 2011 at 10:18 PM, David Barbour 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 to a3
Forgot to CC the list, please see below.
On Wed, Mar 30, 2011 at 2:29 PM, Mathijs Kwik 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 B occur at the same
t
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 wrote:
> SimpleGraphics has a bunch of main programs: main0, main1, main2, main3,
> and main3book. I sequentially changed each to main and ran all
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 wrote:
>
> From: Paul L
> Subject: Re: [Haskell-cafe] Code from Haskell School of Expression hanging.
> To: "michael rice"
) [DisplayStencilBits 8 DisplayAlphaBits 8] Window
> [michael@localhost ~]$
>
>
>
> --- On *Sun, 1/30/11, Paul L * wrote:
>
>
> From: Paul L
> Subject: Re: [Haskell-cafe] Code from Haskell School of Expression hanging.
> To: "michael rice"
>
... linking ... done.
> Loading package StateVar-1.0.0.0 ... linking ... done.
> 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 Su
I'm the maintainer of the SOE code. This is rather puzzling, since
apparently GLFW works on your setup. I don't think there is much big
difference in SOE than the sample GLFW program from the Haskell Wiki.
So when you run the SOE program, did you see the window but just all blank?
Or you never see
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, wrote:
>
> Ryan Ingram wrote:
>> But it doesn't generalize; you need to create a wi
HList certainly provides an alternative. But given the use of
UndecidableInstances and OverlappingInstances, I was hoping that type
families could come a little cleaner. Or does it not matter?
On Fri, Jul 16, 2010 at 8:32 PM, Steffen Schuldenzucker
wrote:
> On 07/17/2010 01:08 AM, Paul L wr
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
http://www.haskell.org/mail
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 wrote:
> It sounds like the windowSizeCallback wasn't called when the app first
> started up. You may try naming that callback fu
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 Sc
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 jus
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
wow, using newArray_ and initialize the whole thing myself is much
faster than newArray. But why?
On 9/18/09, Don Stewart 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
>> doing the s
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 L
Now it's at version 0.1.2 with the EnableGUI fix for Mac OS X.
On 9/14/09, Paul L 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 showi
van Dijk wrote:
> On Mon, Sep 14, 2009 at 7:36 AM, Paul L wrote:
>> It's available on Hackage DB at
>> http://hackage.haskell.org/package/LambdaINet
>
> Nice! Screenshots anywhere?
>
> Bas
>
--
Regards,
Paul Liu
Yal
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 bas
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 w
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 old
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
during
update (Rec f).
Haskell would not evaluate under lambda, 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 wrote:
> On 2009-05-27T03:58:58-0400, Paul L wrot
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
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
showing/reading/inter
kinds of ODEs require 2 specific methematical solutions, I
>> do
>> not find suprising that this fact is also reflected in a program.
>>
>> I have not the same experience as some poster/authors but I am curious
>> about the way the current FRPs are able to accuratel
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 wh
Thanks for the massive update! Is there a new version of Orchid coming along?
On 3/22/09, Sebastiaan Visser 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, directories indices, d
On 12/19/08, Conal Elliott 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 Arrow abstract
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 b
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
> rea
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
>>
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 decisi
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 ::
Tnaks for the clarification, please see my further questions below
On 10/25/08, Daniel Fischer <[EMAIL PROTECTED]> wrote:
>
> Sure, (g (flip readArray 0)) :: ST s Int, or, explicitly, forall s. ST s Int,
> there's nothing to restrict the s, so it's legitimate to pass it to runST.
..[snipped]..
> W
I'm have some trouble using the ST monad, and I think
I'm confused about its use of existential type.
> {-# OPTIONS -XRankNTypes #-}
> import Control.Monad.ST
> import Data.Array.ST
I want to implement a map function that unfold
all ST monads in a list:
> mapST :: (a -> (forall s . ST s b)) -> [
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 includi
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 subm
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
_
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
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 Cab
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 and
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
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
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 cons
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 h
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 do
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 f
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
L PROTECTED]> 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.
>
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
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, b
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 probl
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
ertex4 Float
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
t still renders black screen in GHCi, but will not render
when compiled.
I wonder why the event callback is blocked when using GLUT in GHCi?
Regards,
Paul L
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ry another GLUT 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?
windowName = do
createWindow windowName
displayCallback $= clear [ColorBuffer]
Has anyone been successful at getting GLUT to work on OS X?
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 witho
freeglut support? Any help is greatly
appreciately!
Regards,
Paul L
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ter splitting, and continue to sort
the other half in the original thread. This could 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
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 compil
OS is not used anywhere, the decision of running 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&#x
67 matches
Mail list logo
