Re: [Haskell-cafe] How to understand such a newtype ?
On Sun, Nov 22, 2009 at 3:47 AM, Felipe Lessa wrote: > ... > Well, “ReaderT XConf (StateT XState IO) a” is *the* type :). > It's a monad that is a Reader of XConf and has a State of XState. ... and also wraps a monad to allow IO access inside the X monad. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: GPipe-1.1.0 with greatly improved performance
Hi, GPipe 1.1.0 is now available on Hackage. This update includes the following: * BIG performance increase: The previous shader cache keys grew exponential in size in relation to the GPipe program. This is now fixed with a completely new shader generator so the cache key sizes are linear relative to the program. In addition, the cache now uses patricia trees instead of an ordinary map, which will be a big performance win in programs with many shaders. In the simple example on http://www.haskell.org/haskellwiki/GPipe I got an performance increase of factor 2.7(!), and expect it to be even larger for more complex programs. * Other minor fixes: Fixed so min, max, abs and sign no longer works on Vertex Int and Fragment Int types, since its not supported in GLSL 1.20. Reexport of Vec-Boolean instances so you dont need to import that package on its own any more. Added IfB instances for the associated type Color. Cheers Tobias _ Nya Windows 7 gör allt lite enklare. Hitta en dator som passar dig! http://windows.microsoft.com/shop___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's wrong with code.haskell.org ?
On Sun, Nov 22, 2009 at 4:39 AM, John Millikin wrote: > code.h.o and community.h.o have rather flaky hosting, and have been > going down often recently. The only solution seems to be waiting until > the admins notice. > They have hardware problems - dying HDs and such. IIRC there were plans to replace the problematic hardware, but I don't know how far that has gotten. Maybe we should have a fundraiser for the purpose? -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell code from hi
On Sun, Nov 22, 2009 at 1:04 AM, Uwe Hollerbach wrote: > Ouch... my condolences, but I think you're screwed. I think the .hi > files are purely interface info, and the .o files have all the info on > what to actually do (and getting to .hs files from .hi+.o is gonna be > like going from sausage to pig, in any case). If you haven't messed > with the disk, I think your best bet might be to try and undelete > files. That might be as messy as looking at the raw disk image and > trying to recover disk sectors, or possibly there are still entire > files there that are just not referenced by directory entries. Either > (or any) way, it's a bit chancy... > And this why you always, *always* use a revision-control system or at least good backups. .hi files actually do contain some code, specifically what ghc decides can be inlined (see ghc --show-iface), but it's not the sort of code you'd get any use from. Have a look, you'll see. -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell code from hi
I really get the point, and what I should have been doing. Anyways shit happens! Thanks for the answers though. 2009/11/22 Svein Ove Aas > On Sun, Nov 22, 2009 at 1:04 AM, Uwe Hollerbach > wrote: > > Ouch... my condolences, but I think you're screwed. I think the .hi > > files are purely interface info, and the .o files have all the info on > > what to actually do (and getting to .hs files from .hi+.o is gonna be > > like going from sausage to pig, in any case). If you haven't messed > > with the disk, I think your best bet might be to try and undelete > > files. That might be as messy as looking at the raw disk image and > > trying to recover disk sectors, or possibly there are still entire > > files there that are just not referenced by directory entries. Either > > (or any) way, it's a bit chancy... > > > And this why you always, *always* use a revision-control system or at > least good backups. > > .hi files actually do contain some code, specifically what ghc decides > can be inlined (see ghc --show-iface), but it's not the sort of code > you'd get any use from. Have a look, you'll see. > > -- > Svein Ove Aas > -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wiki software?
On Sat, Nov 21, 2009 at 3:09 PM, Gwern Branwen wrote: > This doesn't surprise me; but how much slower are we talking? > > If it's not at the point that a browser of a Gitit wiki could notice > the difference, then it seems to me that the dep ought to be loosened: > the parsec/quickcheck/base diamond dependency problem is one of the > worst ones a user can run into, the hardest to resolve, and one that > can arise in the course of ordinary safe use of Haskell. Running 'pandoc --strict' over the Markdown readme.text takes: ~0.09s with pandoc built against parsec-2 ~0.19s with pandoc built against parsec-3 on my machine. I have a branch of parsec-3 which seems to brings us back to parsec-2 numbers, but also fails the rst-reader test-case in the pandoc testing suite: http://community.haskell.org/~aslatter/code/parsec/cps Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Existential type question
Hi all,
I've come across some code I just can't figure out how to write
appropriately. Below is a silly example that demonstrates what I'm trying to
do. I don't really have the appropriate vocabulary to describe the issue, so
I'll let the code speak for itself. In particular, I'm trying to understand
what the correct type signatures for unwrapMyData and bin should be.
Thanks,
Michael
---
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}
class Monad m => MonadFoo x m where
foo :: x -> m a
data MyData a = forall i. Integral i => MyLeft i
| MyRight a
instance Monad MyData where
return = MyRight
(MyLeft i) >>= _ = MyLeft i
(MyRight x) >>= f = f x
instance Integral i => MonadFoo i MyData where
foo = MyLeft
bar :: MonadFoo Int m => Int -> m String
bar 0 = return "zero"
bar i = foo i
baz :: String -> MyData String
baz "zero" = MyRight "Zero"
baz _ = MyLeft (-1 :: Integer)
--This works: unwrapMyData (MyLeft i) = foo (fromIntegral i :: Integer)
unwrapMyData (MyLeft i) = foo i -- This is what I'd like to work
unwrapMyData (MyRight a) = return a
bin i = do
a <- bar i
b <- unwrapMyData $ baz a
return $ b ++ "!!!"
instance Show a => MonadFoo a IO where
foo = fail . show -- I know, it's horrible...
main = do
res <- bin 0
putStrLn res
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existential type question
Am Sonntag 22 November 2009 19:24:48 schrieb Michael Snoyman:
> Hi all,
>
> I've come across some code I just can't figure out how to write
> appropriately. Below is a silly example that demonstrates what I'm trying
> to do. I don't really have the appropriate vocabulary to describe the
> issue, so I'll let the code speak for itself. In particular, I'm trying to
> understand what the correct type signatures for unwrapMyData and bin should
> be.
>
> Thanks,
> Michael
>
> ---
>
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE ExistentialQuantification #-}
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE FlexibleContexts #-}
> class Monad m => MonadFoo x m where
> foo :: x -> m a
>
> data MyData a = forall i. Integral i => MyLeft i
>
> | MyRight a
>
> instance Monad MyData where
> return = MyRight
> (MyLeft i) >>= _ = MyLeft i
> (MyRight x) >>= f = f x
> instance Integral i => MonadFoo i MyData where
> foo = MyLeft
>
> bar :: MonadFoo Int m => Int -> m String
> bar 0 = return "zero"
> bar i = foo i
>
> baz :: String -> MyData String
> baz "zero" = MyRight "Zero"
> baz _ = MyLeft (-1 :: Integer)
>
> --This works: unwrapMyData (MyLeft i) = foo (fromIntegral i :: Integer)
> unwrapMyData (MyLeft i) = foo i -- This is what I'd like to work
I don't see how it could (except perhaps...). The type would be
unwrapMyData ::(forall i. (Integral i => MonadFoo i m)) => MyData a -> m a
- the MyData a -> m a part is obviously necessary, but MyLeft can wrap *any*
integral
type, so you indeed need instances MonadFoo i m for *every* integral type. You
can't
specify that condition in Haskell.
You could try
instance MonadFoo a [] where
foo _ = []
instance MonadFoo a Maybe where
foo _ = Nothing
(more general,
instance (MonadPlus m) => MonadFoo a m where
foo _ = mzero
)
unwrapMyData :: (MonadPlus m) => MyData a -> m a
that might be got to work, but it's very likely not even remotely what you want
(unwrapMyData :: MyData a -> [a] would work with the above instance, I think,
but it would
be rather pointless).
> unwrapMyData (MyRight a) = return a
>
> bin i = do
> a <- bar i
You must specify which instance of MonadFoo to use here, otherwise it is
impossible to
determine which instance of bar to use, and the type of bin is irredeemably
ambiguous
(show . read).
> b <- unwrapMyData $ baz a
> return $ b ++ "!!!"
>
> instance Show a => MonadFoo a IO where
> foo = fail . show -- I know, it's horrible...
>
> main = do
> res <- bin 0
> putStrLn res
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
On Fri, Nov 20, 2009 at 9:36 PM, Victor Mateus Oliveira wrote: > I'm looking for something more integrated with a gui library. The > jgraph integrates with swing, so you can move, create, delete, have > popup menus, select nodes, and so on. > > I haven't found yet.. If there isn't, I thinking in create one lib > with wxHaskell using wxDC... But by now, I really prefer to use one > existing library. Blobs [http://www.cs.york.ac.uk/fp/darcs/Blobs/] might be a better starting point than implementing from scratch on wxdc martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Idea for a very simple GUI llibrary
Hi,
Here is a sketch for a library with these properties:
-> Easy to test. All Haskell code can be tested in a text
terminal. Also, testing code that uses the library can also be
done without using a GUI.
-> Extremely easy to document and use.
-> Not even close to Gtk2hs power, but enough for small
applications.
-> Could be the first GUI to build on hackage :)
What we need is:
-> MyState. A user suplied type for application state.
-> WidId. A user suplied type for widget identifiers.
-> Gui wi. A type capable of describing an interface with all of
its state. It's an instance of Eq.
-> Event wi. A type for events.
-> Prop. A type for properties than can related to a WidId.
Running an application would be like this:
main = runGUI
initState -- An initial MyState.
event -- :: MyState -> DiffTime -> Event WidId -> MyState
props -- :: WidId -> [Prop]
action -- :: MyState -> DiffTime -> IO (Maybe (MyState,Gui WidId))
timeout-- :: DiffTime
DiffTime parameters for callbacks are always the time elapsed
since application started.
From initState and event, the implementation of runGUI can save a
state that optionally changes with time.
From props, it can get details on what to present in widgets
associated with a WidId (selected state, picture to draw etc.).
action presents a chance for using IO, and optionally change state
and GUI description.
timeout is the maximum time runGUI implementation is allowed to
wait between calls to action.
Examples for those types:
newtype MyState = {
lastUpdate :: DiffTime,
builtGui :: Bool,
earthCoordinates :: (Double,Double),
map :: SVG,
...
}
data WidId = XCoord | YCoord | MapWindow | ReloadButton ...
data Gui widid = TitleWindow (Gui widid)
| Tabs [(String,Gui widid)]
| PressButton String widid
| Selection [String] widid
| ...
deriving Eq
{-
Eq is needed by runGUI to detect if GUI has
changed after the last call to action.
-}
data Event widid = ButtonPressed widid
| FileSelected String widid
| OptionSelected String widid
| ...
data Prop widid = Active Bool
| Text String
| Draw SVG
| ...
I believe this can represent most kinds of simple applications,
and be efficient enough for practical use.
It's interesting that all of this can be designed, implemented and
tested independent of runGUI implementation. Actually, if you want
a pet project and want to write and design the Haskell part, I may
probably be able to write runGUI for you :)
Best,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] some help debugging ghci build on powerpc
I'm trying to build ghc so that ghci will be included under linux power-pc. The build dies here: ~/ghc6-6.10.4/rts$ /home/briand/ghc6-6.10.4/ghc/stage1-inplace/ghc -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -optc-w -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -optc-DNOSMP -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c StgCRun.c -o StgCRun.o /tmp/ghc21791_0/ghc21791_0.s: Assembler messages: /tmp/ghc21791_0/ghc21791_0.s:15:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc21791_0/ghc21791_0.s:19:0: Error: junk at end of line, first unrecognized character is `@' That relates to this line(s): StgRun: .quad .StgRun,.t...@tocbase,0 .size StgRun,24 .globl StgReturn It _looks_ like it's grabbing the right stuff from StgCRun.c, i.e. it's really trying to compile for power pc. I was hoping that this was a bit of cruft and someone could direct me to a fix for the assembly portion so I can get a little farther along. Thanks, Brian P.S. Or somebody could also tell me if trying to have the latest ghc working on power pc is even worth working on. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Idea for a very simple GUI llibrary
Nice idea. I will try it if you write runGUI :-)
This is an imperative style library. For more Haskellian GUI library
ideas, see Fruit (http://www.haskell.org/fruit/) and TVs
(http://www.haskell.org/haskellwiki/TV). They may not pass the
"builds" constraint :-P
Luke
2009/11/22 Maurício CA :
> Hi,
>
> Here is a sketch for a library with these properties:
>
> -> Easy to test. All Haskell code can be tested in a text
> terminal. Also, testing code that uses the library can also be
> done without using a GUI.
>
> -> Extremely easy to document and use.
>
> -> Not even close to Gtk2hs power, but enough for small
> applications.
>
> -> Could be the first GUI to build on hackage :)
>
> What we need is:
>
> -> MyState. A user suplied type for application state.
>
> -> WidId. A user suplied type for widget identifiers.
>
> -> Gui wi. A type capable of describing an interface with all of
> its state. It's an instance of Eq.
>
> -> Event wi. A type for events.
>
> -> Prop. A type for properties than can related to a WidId.
>
> Running an application would be like this:
>
> main = runGUI
> initState -- An initial MyState.
> event -- :: MyState -> DiffTime -> Event WidId -> MyState
> props -- :: WidId -> [Prop]
> action -- :: MyState -> DiffTime -> IO (Maybe (MyState,Gui
> WidId))
> timeout -- :: DiffTime
>
> DiffTime parameters for callbacks are always the time elapsed
> since application started.
>
> From initState and event, the implementation of runGUI can save a
> state that optionally changes with time.
>
> From props, it can get details on what to present in widgets
> associated with a WidId (selected state, picture to draw etc.).
>
> action presents a chance for using IO, and optionally change state
> and GUI description.
>
> timeout is the maximum time runGUI implementation is allowed to
> wait between calls to action.
>
> Examples for those types:
>
> newtype MyState = {
> lastUpdate :: DiffTime,
> builtGui :: Bool,
> earthCoordinates :: (Double,Double),
> map :: SVG,
> ...
> }
>
> data WidId = XCoord | YCoord | MapWindow | ReloadButton ...
>
> data Gui widid = TitleWindow (Gui widid)
> | Tabs [(String,Gui widid)]
> | PressButton String widid
> | Selection [String] widid
> | ...
> deriving Eq
> {-
> Eq is needed by runGUI to detect if GUI has
> changed after the last call to action.
> -}
>
> data Event widid = ButtonPressed widid
> | FileSelected String widid
> | OptionSelected String widid
> | ...
>
> data Prop widid = Active Bool
> | Text String
> | Draw SVG
> | ...
>
> I believe this can represent most kinds of simple applications,
> and be efficient enough for practical use.
>
> It's interesting that all of this can be designed, implemented and
> tested independent of runGUI implementation. Actually, if you want
> a pet project and want to write and design the Haskell part, I may
> probably be able to write runGUI for you :)
>
> Best,
> Maurício
>
> ___
> 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] What's wrong with code.haskell.org ?
code.h.o and community.h.o have rather flaky hosting, and have been going down often recently. Yes, we know that code/community.h.o can be somewhat flaky. However, it does claim to have been up continuously for the last 79 days. I suspect it is that (a) the service daemons occasionally die for no obvious reason, or (b) some users are running processes that sometimes hog the CPU, memory, or network bandwidth. They have hardware problems - dying HDs and such. No, that is a different machine: hackage/darcs.h.o. A new server is on order, but we do not yet have a delivery date. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What's wrong with code.haskell.org ?
Svein Ove Aas writes: > On Sun, Nov 22, 2009 at 4:39 AM, John Millikin wrote: >> code.h.o and community.h.o have rather flaky hosting, and have been >> going down often recently. The only solution seems to be waiting until >> the admins notice. >> > They have hardware problems - dying HDs and such. > > IIRC there were plans to replace the problematic hardware, but I don't > know how far that has gotten. Maybe we should have a fundraiser for > the purpose? Hope they can fix this problem completely, then running stable... -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Idea for a very simple GUI llibrary
You should also check out Fudgets and "Tangible Functional
Programming." Fudgets is a really old Haskell UI library concept;
Tangible FP is a recent Google talk about a UI library inspired by
Haskell types.
2009/11/22 Luke Palmer :
> Nice idea. I will try it if you write runGUI :-)
>
> This is an imperative style library. For more Haskellian GUI library
> ideas, see Fruit (http://www.haskell.org/fruit/) and TVs
> (http://www.haskell.org/haskellwiki/TV). They may not pass the
> "builds" constraint :-P
>
> Luke
>
> 2009/11/22 Maurício CA :
>> Hi,
>>
>> Here is a sketch for a library with these properties:
>>
>> -> Easy to test. All Haskell code can be tested in a text
>> terminal. Also, testing code that uses the library can also be
>> done without using a GUI.
>>
>> -> Extremely easy to document and use.
>>
>> -> Not even close to Gtk2hs power, but enough for small
>> applications.
>>
>> -> Could be the first GUI to build on hackage :)
>>
>> What we need is:
>>
>> -> MyState. A user suplied type for application state.
>>
>> -> WidId. A user suplied type for widget identifiers.
>>
>> -> Gui wi. A type capable of describing an interface with all of
>> its state. It's an instance of Eq.
>>
>> -> Event wi. A type for events.
>>
>> -> Prop. A type for properties than can related to a WidId.
>>
>> Running an application would be like this:
>>
>> main = runGUI
>> initState -- An initial MyState.
>> event -- :: MyState -> DiffTime -> Event WidId -> MyState
>> props -- :: WidId -> [Prop]
>> action -- :: MyState -> DiffTime -> IO (Maybe (MyState,Gui
>> WidId))
>> timeout -- :: DiffTime
>>
>> DiffTime parameters for callbacks are always the time elapsed
>> since application started.
>>
>> From initState and event, the implementation of runGUI can save a
>> state that optionally changes with time.
>>
>> From props, it can get details on what to present in widgets
>> associated with a WidId (selected state, picture to draw etc.).
>>
>> action presents a chance for using IO, and optionally change state
>> and GUI description.
>>
>> timeout is the maximum time runGUI implementation is allowed to
>> wait between calls to action.
>>
>> Examples for those types:
>>
>> newtype MyState = {
>> lastUpdate :: DiffTime,
>> builtGui :: Bool,
>> earthCoordinates :: (Double,Double),
>> map :: SVG,
>> ...
>> }
>>
>> data WidId = XCoord | YCoord | MapWindow | ReloadButton ...
>>
>> data Gui widid = TitleWindow (Gui widid)
>> | Tabs [(String,Gui widid)]
>> | PressButton String widid
>> | Selection [String] widid
>> | ...
>> deriving Eq
>> {-
>> Eq is needed by runGUI to detect if GUI has
>> changed after the last call to action.
>> -}
>>
>> data Event widid = ButtonPressed widid
>> | FileSelected String widid
>> | OptionSelected String widid
>> | ...
>>
>> data Prop widid = Active Bool
>> | Text String
>> | Draw SVG
>> | ...
>>
>> I believe this can represent most kinds of simple applications,
>> and be efficient enough for practical use.
>>
>> It's interesting that all of this can be designed, implemented and
>> tested independent of runGUI implementation. Actually, if you want
>> a pet project and want to write and design the Haskell part, I may
>> probably be able to write runGUI for you :)
>>
>> Best,
>> Maurício
>>
>> ___
>> 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
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
