[Haskell-cafe] What causes <>?

[Martin Hofmann]

I've already posted this mail on haskell-cafe, but apparently the
subject suggested a too simple question, so I try it here again. I am
picking up a discussion with the same topic from haskell-users on
8th November. 

Thunks with reference on themselves was mentioned as main reason for
<>.

> A safe recursive definition would be
>   let x = Foo (x+1)
> However, if you leave out the constructor,
>   let x = x + 1
> you get a <> (or a deadlock).
> 

Are there any other reasons? 

I am trying to debug monadic code which stores state information in a
record maintaining several Data.Maps, but in vain so far. A state is
modified/changed in several steps by a compound function i.e.

changeA $ changeB $ changeC state

Could this also lead to a deadlock? If so, can I prevent this using CPS?
If the state transformation is the main purpose/computation of the monad
at all, is it better to use CPS? Is code using mtl, records or Data.Map
more prone to <> or does this not matter at all. How can I
identify self-referencing thunks more easily? Is there any rule of thumb
to prevent <>? Are there any less obvious newbie mistakes causing
< then the one above?

Sorry, a lot of questions at once, but I am kind of helpless because I
can't find any reason of my <>, so any comments, experience, and
tips are highly appreciated.

Thanks,

Martin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Install Yi editor with GHC 6.10.1

[Andy Stewart]

Hi Austin,

Austin Seipp <[EMAIL PROTECTED]> writes:

> Excerpts from lazycat.manatee's message of Tue Dec 02 23:18:50 -0600 2008:
>> Hi all,
>> 
>> I have install GHC 6.10.1 and Gtk2hs (darcs version) in Debian.
>> So i want to ask, have anyone install Yi (darcs version) with GHC 6.10.1
>> successfully?
>
> Yes. cabal install is basically the easiest way to do it:
>
>  $ cabal update
>  $ cabal install yi
>
>> And the best way to install darcs version Yi?
>
>  $ darcs get http://code.haskell.org/yi yi-darcs
>  $ cd yi-darcs
>  $ cabal install
>
> You will need darcs v2 (I normally use the yi darcs repo fwiw, jpb
> pushes lots of little fixes/optimizations regularly. Recently in yi
> 0.5.2 and the darcs version some major memory leaks have been fixed it
> seems.)
>
> Austin

Thank you.

But i have install Yi 0.5.2 and 0.5.3 and got same error:

,
| 
| 
| [ 78 of 105] Compiling Yi.Core  ( Yi/Core.hs, dist/build/Yi/Core.o )
| [ 79 of 105] Compiling Yi.File  ( Yi/File.hs, dist/build/Yi/File.o )
| [ 80 of 105] Compiling Yi.MiniBuffer( Yi/MiniBuffer.hs, 
dist/build/Yi/MiniBuffer.o )
| [ 81 of 105] Compiling Yi.Dired ( Yi/Dired.hs, dist/build/Yi/Dired.o )
| [ 82 of 105] Compiling Yi.Eval  ( Yi/Eval.hs, dist/build/Yi/Eval.o )
| [ 83 of 105] Compiling Yi.Mode.Compilation ( Yi/Mode/Compilation.hs, 
dist/build/Yi/Mode/Compilation.o )
| [ 84 of 105] Compiling Yi.Mode.Interactive ( Yi/Mode/Interactive.hs, 
dist/build/Yi/Mode/Interactive.o )
| [ 85 of 105] Compiling Yi.Mode.Haskell  ( Yi/Mode/Haskell.hs, 
dist/build/Yi/Mode/Haskell.o )
| [ 86 of 105] Compiling Yi.Search( Yi/Search.hs, 
dist/build/Yi/Search.o )
| [ 87 of 105] Compiling Yi.TextCompletion ( Yi/TextCompletion.hs, 
dist/build/Yi/TextCompletion.o )
| [ 88 of 105] Compiling Yi.UI.Gtk.ProjectTree ( Yi/UI/Gtk/ProjectTree.hs, 
dist/build/Yi/UI/Gtk/ProjectTree.o )
| 
| Yi/UI/Gtk/ProjectTree.hs:19:40:
| Module `Graphics.UI.Gtk' does not export `Event'
| cabal: Error: some packages failed to install:
| yi-0.5.2 failed during the building phase. The exception was:
| exit: ExitFailure 1
`

Any help?

  -- Andy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Galchin, Vasili]

Warning: This package indirectly depends on multiple versions of the same
package. This is highly likely to cause a compile failure.
package binary-0.4.2 requires bytestring-0.9.0.1
package bio-0.3.4.1 requires bytestring-0.9.1.0


ah ha .. Ketil, this is what you are saying? If so, how do I fix? install a
newer version of binary?

regards, vasili

On Wed, Dec 3, 2008 at 1:32 AM, Ketil Malde <[EMAIL PROTECTED]> wrote:

> "Galchin, Vasili" <[EMAIL PROTECTED]> writes:
>
> > I think I am getting a namespace collition between
> >
> >   Data.ByteString.Lazy.Char8.ByteString
> >
> > and
> >
> >  Data.ByteString.Lazy.Internal.ByteString 
>
> You rarely need to import 'Internal' directly.
>
> > here is the error message 
> >
> > Couldn't match expected type `B.ByteString'
> >against inferred type
> > `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString'
>
> Are you sure this is not just a versioning problem?  I.e. that some
> library is built against bytestring-0.X.Y, but your current import is
> bytestring-0.A.B, but your program expects these to be the same?  (And
> they probably are, but the compiler can't really tell).
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Galchin, Vasili]

On Wed, Dec 3, 2008 at 1:32 AM, Ketil Malde <[EMAIL PROTECTED]> wrote:

> "Galchin, Vasili" <[EMAIL PROTECTED]> writes:
>
> > I think I am getting a namespace collition between
> >
> >   Data.ByteString.Lazy.Char8.ByteString
> >
> > and
> >
> >  Data.ByteString.Lazy.Internal.ByteString 
>
> You rarely need to import 'Internal' directly.
>
> > here is the error message 
> >
> > Couldn't match expected type `B.ByteString'
> >against inferred type
> > `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString'
>
> Are you sure this is not just a versioning problem?  I.e. that some
> library is built against bytestring-0.X.Y, but your current import is
> bytestring-0.A.B, but your program expects these to be the same?  (And
> they probably are, but the compiler can't really tell).

  ^^ oh great ;^) how can ascertain this situation?

- vasili


>
>
> -k
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Install Yi editor with GHC 6.10.1

[Austin Seipp]

Excerpts from lazycat.manatee's message of Tue Dec 02 23:18:50 -0600 2008:
> Hi all,
> 
> I have install GHC 6.10.1 and Gtk2hs (darcs version) in Debian.
> So i want to ask, have anyone install Yi (darcs version) with GHC 6.10.1
> successfully?

Yes. cabal install is basically the easiest way to do it:

 $ cabal update
 $ cabal install yi

> And the best way to install darcs version Yi?

 $ darcs get http://code.haskell.org/yi yi-darcs
 $ cd yi-darcs
 $ cabal install

You will need darcs v2 (I normally use the yi darcs repo fwiw, jpb
pushes lots of little fixes/optimizations regularly. Recently in yi
0.5.2 and the darcs version some major memory leaks have been fixed it
seems.)

Austin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Ketil Malde]

"Galchin, Vasili" <[EMAIL PROTECTED]> writes:

> I think I am getting a namespace collition between
>
>   Data.ByteString.Lazy.Char8.ByteString
>
> and
>
>  Data.ByteString.Lazy.Internal.ByteString 

You rarely need to import 'Internal' directly.  

> here is the error message 
>
> Couldn't match expected type `B.ByteString'
>against inferred type
> `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString'

Are you sure this is not just a versioning problem?  I.e. that some
library is built against bytestring-0.X.Y, but your current import is
bytestring-0.A.B, but your program expects these to be the same?  (And
they probably are, but the compiler can't really tell).

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: "Real World Haskell", now shipping

[Jason Dusek]

Andrew Coppin <[EMAIL PROTECTED]> wrote:
> ...it has been my general experience that almost everything
> obtained from Hackage fails miserably to compile under
> Windows. (IIRC, one package even used a Bash script as part of
> the build process!) I haven't seen similar problems on Linux.
> (But I don't use Linux very often.)

  I try very hard to make my programs work on Windows; and
  indeed, one of things I appreciate about Haskell is how easy
  it is to create binaries and packages that are cross platform.

  However, the only time I actually use Windows is to build and
  test my Haskell packages. Most of the people on this list --
  and I wager, most people on the mailing lists for any open
  source programming language -- are working on a NIXalike; we
  can work with bug reports, but we can't very well be the
  fabled "many eyeballs" on a platform we don't use. Ask not
  what your Haskell can do for you, but rather what you can do
  for your Haskell :)

> About the worst problem there was Gtk2hs being confused about
> some Autoconfig stuff or something...

  Well, what else would a package built with GNU toolchain be
  confused about? Is there some miraculous language and package
  system for it where compiling libraries made with autotools is
  just a snap on Windows?

--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Deriving

[Johan Jeuring]

What happens when a type adds driving such as:

newtype SupplyT s m a = SupplyT (StateT [s] m a)

deriving (Functor, Monad, MonadTrans, MonadIO)

Two questions:

How does the deriving implement the instance?

Is there a way for me to add  my own classes in the deriving?  for  
example


newtype .
   deriving( xyz)


In general you would have to resort to generic programming techniques
to obtain your own deriving mechanism.

See the generics category on Hackage for libraries:

http://hackage.haskell.org/packages/archive/pkg-list.html

To find out what you can do with the various generic programming
techniques, you can read (shameless plugs):

Alexey Rodriguez Yakushev, Johan Jeuring, Patrik Jansson, Alex Gerdes,
Oleg Kiselyov, Bruno C. d. S. Oliviera. Comparing Libraries for Generic
Programming in Haskell. In Andy Gill, editor, Proceedings of the ACM
SIGPLAN Haskell Symposium. An extended version is available as Technical
report Utrecht University UU-CS-2008-010, 2008.

Ralf Hinze, Johan Jeuring, and Andres Löh. Comparing approaches to  
generic

programming in Haskell. In Roland Backhouse, Jeremy Gibbons, Ralf Hinze,
and Johan Jeuring, editors, Lecture notes of the Spring School on
Datatype-Generic Programming 2006, LNCS 4719, pages 72 - 149, 2007,
Springer-Verlag.

-- Johan Jeuring

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Install Yi editor with GHC 6.10.1

[Andy Stewart]

Hi all,

I have install GHC 6.10.1 and Gtk2hs (darcs version) in Debian.
So i want to ask, have anyone install Yi (darcs version) with GHC 6.10.1
successfully?

And the best way to install darcs version Yi?

Thank you very much!

  -- Andy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ByteString web site papers

[Galchin, Vasili]

Hello,

http://www.cse.unsw.edu.au/~dons/fps.html

Are the papers/slides still up-to-date for someone to get up-to-speed on
ByteString motivation and implementation? Anything more recent?

Regards, Vasili
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Deriving

[wren ng thornton]

Daryoush Mehrtash wrote:

What happens when a type adds driving such as:

newtype SupplyT s m a = SupplyT (StateT [s] m a)
deriving (Functor, Monad, MonadTrans, MonadIO)


Two questions:

How does the deriving implement the instance?


With GeneralizedNewtypeDeriving, since newtypes are just a 
reinterpretation of the underlying type, the deriving clause just uses 
the instance for the underlying type (massaging it with the 
wrapping/unwrapping functions for the newtype). The primary use for this 
is for defining a newtype on monad transformer stacks, for which it 
succeeds excellently. However, if the semantics of your newtype are 
different than the underlying type w.r.t. the type class, then it's not 
so good.



For the more basic kind of deriving clause, the compiler knows about how 
to create generic instances for obvious things, e.g. the compiler can 
derive the obvious Show instance by doing introspection on the source 
code. However, these derivations are limited to classes with an obvious 
implementation based solely on the structure of the type definition.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Galchin, Vasili]

I think I am getting a namespace collition between

  Data.ByteString.Lazy.Char8.ByteString

and

 Data.ByteString.Lazy.Internal.ByteString 

here is the error message 

Couldn't match expected type `B.ByteString'
   against inferred type
`bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString'




On Tue, Dec 2, 2008 at 8:18 PM, Galchin, Vasili <[EMAIL PROTECTED]> wrote:

> I am getting a collision with "Internal"  sigh.
>
>
> vasili
>
>
> On Tue, Dec 2, 2008 at 5:59 PM, Duncan Coutts <[EMAIL PROTECTED]
> > wrote:
>
>> On Tue, 2008-12-02 at 17:43 -0600, Galchin, Vasili wrote:
>> > Hello,
>> >
>> >  Some mention is made in corresponding web pages about
>> > implementation difference of these three different DataString impl.
>> > Any advice?
>>
>> Perhaps you need to ask a more specific question.
>>
>> Data.ByteString is a simple strict sequence of bytes (as Word8). That
>> means the whole thing is in memory at once in one big block.
>>
>> Data.ByteString.Char8 provides the same type as Data.ByteString but the
>> operations are in terms of 8-bit Chars. This is for use in files and
>> protocols that contain ASCII as a subset. This is particularly useful
>> for protocols containing mixed text and binary content. It should not be
>> used instead of proper Unicode.
>>
>>
>> Data.ByteString.Lazy is a different representation. As the name
>> suggests, it's lazy like a lazy list. So like a list the whole thing
>> does not need to be in memory if it can be processed incrementally. It
>> supports lazy IO, like getContents does for String. It is particularly
>> useful for handling long or unbounded streams of data in a pure style.
>>
>> Data.ByteString.Lazy.Char8 is the Char8 equivalent.
>>
>> Duncan
>>
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Galchin, Vasili]

I am getting a collision with "Internal"  sigh.


vasili

On Tue, Dec 2, 2008 at 5:59 PM, Duncan Coutts
<[EMAIL PROTECTED]>wrote:

> On Tue, 2008-12-02 at 17:43 -0600, Galchin, Vasili wrote:
> > Hello,
> >
> >  Some mention is made in corresponding web pages about
> > implementation difference of these three different DataString impl.
> > Any advice?
>
> Perhaps you need to ask a more specific question.
>
> Data.ByteString is a simple strict sequence of bytes (as Word8). That
> means the whole thing is in memory at once in one big block.
>
> Data.ByteString.Char8 provides the same type as Data.ByteString but the
> operations are in terms of 8-bit Chars. This is for use in files and
> protocols that contain ASCII as a subset. This is particularly useful
> for protocols containing mixed text and binary content. It should not be
> used instead of proper Unicode.
>
>
> Data.ByteString.Lazy is a different representation. As the name
> suggests, it's lazy like a lazy list. So like a list the whole thing
> does not need to be in memory if it can be processed incrementally. It
> supports lazy IO, like getContents does for String. It is particularly
> useful for handling long or unbounded streams of data in a pure style.
>
> Data.ByteString.Lazy.Char8 is the Char8 equivalent.
>
> Duncan
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: "Real World Haskell", now shipping

[Brandon S. Allbery KF8NH]

On 2008 Dec 2, at 14:44, Andrew Coppin wrote:
Regardless, it has been my general experience that almost everything  
obtained from Hackage fails miserably to compile under Windows.  
(IIRC, one package even used a Bash script as part of the build  
process!) I haven't seen similar problems on Linux. (But I don't use  
Linux very often.) About the worst problem there was Gtk2hs being  
confused about some Autoconfig stuff or something...



Many packages assume you have the msys / mingw stuff installed on  
Windows (if they work at all; those of us who don't develop on Windows  
wouldn't really know how to go about being compatible).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Gwern Branwen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Dec 2, 2008 at 2:43 AM, Andy Stewart  wrote:
> Thank you very much.
> So anyone install XMonad with GHC 6.10.1 success?
>
>  -- Andy

Darcs XMonad and XMC support 6.10, but there is an open bug where
apparently on 6.10 and x86_64 architecture, XMonad.Prompt (and derived
modules) will not work correctly.

- --
gwern
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkk12dwACgkQvpDo5Pfl1oLFoACfVvz9WZ5NFTN1h+gEXJuoyNFG
GjsAoJQdqz5Z5qb2r7XQp7TlMUuc+rHc
=iqHY
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The Knight's Tour: solutions please

[ajb]

G'day all.

Quoting Bertram Felgenhauer <[EMAIL PROTECTED]>:


  successors n b = sortWith (length . succs) . succs

[...]

  successors n b = sortWith (length . (succs =<<) . succs) . succs

[...]
  successors n b = sortWith (length . (succs =<<) . (succs =<<) .   
succs) . succs

[...]

These improved heuristics don't come cheap though.


The heuristic is cheaper and more useful when the ply of the tree
is low.  It's more expensive and less useful when the ply is high.
Moreover, deeper neighbour searches may only be useful in cases where
the shallower searchers fail to settle on the best course of action.

So something like the following might be better.  Note that "d" here
is an example only; I don't promise it's good.

successors n b = sortWith heuristic . succs
where
heuristic p = let ps = succs p
  d = 5 - length ps `div` 2
  in map length . take d . iterate (succs =<<) $ ps

One more thing: Deeper neighbour searches are also unnecessarily expensive
because they recompute "succs" a lot.  It seems to me that if you memoed
this, what you'd actually have is an explicit lazy search tree data
structure.  Hint hint.

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Moving the messages for compiler to another file?

[Alexander Dunlap]

On Tue, Dec 2, 2008 at 2:56 AM, nml <[EMAIL PROTECTED]> wrote:
> How about moving the messages for compiler to an additional file?
>
> My motivation is that we often face a trade-off between
> aesthetical(elegant code) and practical(efficient code).
> Like pragmas and strictness annotations, I often feel they make the
> source code ugly.
> They don't affect the semantics of our programs, do they?
>
> Some people would say this beautifying should be accomplished by an
> editor, like hiding/showing option for those information.
>
> But such separation has additional benefits.
> For instance, making the source code more compiler-independent.
> (yeah, this is not the case with language-extensions)
> And we avoid dispersing those information among our lines. (or even files)
> In some cases, it would be convenient.
>
> I'm not sure if this idea is reasonable, reachable or just naive.
> Suggestions?
>
> Best regards
> -nml
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

One problem is that in many cases, the things that you're talking
about DO affect semantics. Consider strictness annotations:

> f (!x) = Just x
> g x = Just x
> h (Just _) = True
> h Nothing = False

Now h (f _|_) == _|_, but h (g _|_) == True, even though a strictness
annotation was the only difference between them. (For those not
already familiar with it, _|_ ("bottom") is a semantically undefined
value, equivalent to an infinite loop.)

I agree that it's good to reduce semantically-irrelevant code, but I'm
not sure how feasible the proposal would be. I think GHC's rewrite
rules may be of interest in this problem (the debate between elegant
and fast code). Don Stewart has also written about this issue and has
a couple of really good posts on his blog
(http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast).

Warm regards,
Alex
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Duncan Coutts]

On Tue, 2008-12-02 at 17:43 -0600, Galchin, Vasili wrote:
> Hello,
>  
>  Some mention is made in corresponding web pages about
> implementation difference of these three different DataString impl.
> Any advice?

Perhaps you need to ask a more specific question.

Data.ByteString is a simple strict sequence of bytes (as Word8). That
means the whole thing is in memory at once in one big block.

Data.ByteString.Char8 provides the same type as Data.ByteString but the
operations are in terms of 8-bit Chars. This is for use in files and
protocols that contain ASCII as a subset. This is particularly useful
for protocols containing mixed text and binary content. It should not be
used instead of proper Unicode.


Data.ByteString.Lazy is a different representation. As the name
suggests, it's lazy like a lazy list. So like a list the whole thing
does not need to be in memory if it can be processed incrementally. It
supports lazy IO, like getContents does for String. It is particularly
useful for handling long or unbounded streams of data in a pure style.

Data.ByteString.Lazy.Char8 is the Char8 equivalent.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8

[Galchin, Vasili]

Hello,

 Some mention is made in corresponding web pages about implementation
difference of these three different DataString impl. Any advice?

Regards, Vasili
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Duncan Coutts]

On Tue, 2008-12-02 at 18:04 +, Claus Reinke wrote:
> >> ghc --make -package OpenGL -package GLUT something.hs
> >> I get nothing but undefined references in the linking phase.
> >> C:\Program 
> >> Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:
> >> (.text+0x15): undefined reference to `glutWarpPointer'
> >
> > Does ghc-pkg describe OpenGL tell you that the package needs some gl C
> > lib? Eg "ld-options: -lGLU -lGL -lm"
> 
> Yes:

Then I've no idea. Is it missing all symbols or is it just a few? Does
your GL dll actually contain those symbols.

This doesn't immediately appear to me to be a Cabal/cabal-install
problem. Perhaps we can ask for some wider help with this one.

> >> Btw, is the format for the cabal config file documented somewhere?
> >> I though I had set documentation to True.
> >
> > At the moment only in the config file itself. It lists all the fields
> > (commented out) and where there are default values it lists those too.
> 
> ah, I wasn't sure whether those '--' were meant to indicate options or
> commenting (a comment in the first line might make usage unambiguous?-)

Good idea.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Deriving

[Martin Huschenbett]

If you use a newtype the answer to the second question is yes. Just put

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

in the first line of your module or pass -XGeneralizedNewtypeDeriving to 
ghc or ghci.


Daryoush Mehrtash schrieb:

What happens when a type adds driving such as:

newtype SupplyT s m a = SupplyT (StateT [s] m a)

deriving (Functor 
, 
Monad , 
MonadTrans, MonadIO)


Two questions:

How does the deriving implement the instance?

Is there a way for me to add  my own classes in the deriving?  for example

newtype .
   deriving( xyz)


Thanks





___
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] Deriving

[Daryoush Mehrtash]

What happens when a type adds driving such as:

newtype SupplyT s m a = SupplyT (StateT [s] m a)
deriving (Functor
,
Monad 
,
MonadTrans, MonadIO)


Two questions:

How does the deriving implement the instance?

Is there a way for me to add  my own classes in the deriving?  for example

newtype .
   deriving( xyz)


Thanks
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] global variables for foreign C functions

[Andrea Rossato]

On Mon, Dec 01, 2008 at 05:30:33PM -0800, Judah Jacobson wrote:
> You can limit the size of that stub file using:
> 
> foreign import ccall "&progname" progname :: Ptr (Ptr CChar)
> 
> which lets you access that global variable and write the
> getters/setters in Haskell rather than C.

this solves my problems quite nicely indeed, but I still cannot figure
how to write a setter function that actually works.

That is to say, after:
newCString "new_name" >>= poke progname

this:
putStrLn . show =<< peekCString =<< peek progname

would return "new_name", but the library, which is using "progname" to
produce some debugging messages, doesn't seem to get it correctly: the
original bits are gone, but instead of "new_name" I get some garbage.

Thanks to everyone for the interesting and useful hints.

Andrea
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Claus Reinke]

I believe these errors are caused by the wrong calling convention
being used in the Haskell bindings. This part in the configure script
tests the build (host) platform:

case "$host" in
*-mingw32) CALLCONV=stdcall ;;
*)  CALLCONV=ccall ;;
esac

Since it doesn't test for Cygwin, you end up with the calling
convention being ccall, which leads to the linker errors because of
associated name mangling (you would also see run-time crashes if you
managed to somehow link your program).


Ah, that makes sense! And, indeed, for the archives, this workaround 
fixes the issue (even when building from cygwin bash):


   cabal install opengl glut --configure-option="--host=i386-unknown-mingw32" 
--reinstall

Thanks, now FunWorlds can ride again!-)

I suppose we could document this on the OpenGL wiki, but even
better would be a fix to OpenGL's configure (apart from checking 
the build environment (mingw) rather than the host (cygwin here), it 
should ensure that the build uses exactly what configure has tested 
successfully) or .cabal (allways setting the --host configure option 
if on windows)?


[cc-ed to hopengl list, since this seems to be an OpenGL-specific 
issue, not a general Cabal one; Cabal++ :-]


Claus

PS of course, a high-level interpretation of the linker errors, by
   cabal or by ghc, would also help in such cases (linking object
   code is a ghc-internal detail, we work with Haskell code!-).

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: "Real World Haskell", now shipping

[Andrew Coppin]

John Goerzen wrote:

On Mon, Dec 01, 2008 at 09:59:24PM +, Andrew Coppin wrote:
  
  

OK, now I'm puzzled. I don't remember that! :-}



OK, I went back and looked at my Git logs and you're right.  Wrong
Andrew.  Sorry.
  


LOL! S'OK...


I would welcome bug reports and, even better, patches for this stuff.

But I was pretty sure that HDBC and HDBC-ODBC in particular are
working on Windows.
  


OK, well how about this then: In a few weeks when I upgrade to GHC 
6.10.1, I'll tell you whether it builds there. ;-)


For the record, which package is the "correct" one to use? Hackage seems 
to have a bazillion different database packages, and I have literally no 
idea which ones are the currently maintained ones...


Regardless, it has been my general experience that almost everything 
obtained from Hackage fails miserably to compile under Windows. (IIRC, 
one package even used a Bash script as part of the build process!) I 
haven't seen similar problems on Linux. (But I don't use Linux very 
often.) About the worst problem there was Gtk2hs being confused about 
some Autoconfig stuff or something...


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Pekka Karjalainen]

On Tue, Dec 2, 2008 at 6:55 PM, Claus Reinke <[EMAIL PROTECTED]> wrote:
> I finally got round to trying cabal-install with OpenGL/GLUT,
> using a freshly built ghc head, a cygwin bash, and
[...]

>   C:\Program
> Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:
> (.text+0x15): undefined reference to `glutWarpPointer'
[...]

I believe these errors are caused by the wrong calling convention
being used in the Haskell bindings. This part in the configure script
tests the build (host) platform:

case "$host" in
*-mingw32) CALLCONV=stdcall ;;
*)  CALLCONV=ccall ;;
esac

Since it doesn't test for Cygwin, you end up with the calling
convention being ccall, which leads to the linker errors because of
associated name mangling (you would also see run-time crashes if you
managed to somehow link your program).

Pekka
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: The Knight's Tour: solutions please

[Bertram Felgenhauer]

ChrisK wrote:
> Hmmm... it seems that n=63 is a special case.
>
> [EMAIL PROTECTED] wrote:
>> Yes, there is a solution for n=99 and for n=100 for that matter --
>> which can be found under one second. I only had to make a trivial
>> modification to the previously posted code
>>> tour n k s b | k > n*n   = return b
>>>  | otherwise = do next <- (foldr mplus mzero).map return $ 
>>> successors n b s
>>>   tour n (k+1) next $ insrt next k b
>> I replaced foldl1 mplus with foldr mplus zero.
>
> The old version sees no solution to n=63 quite quickly:
>
>> time nice ./fromwiki-63 63
>> fromwiki-63: Prelude.foldl1: empty list
>> real 0m0.285s
>> user 0m0.172s
>> sys  0m0.026s

That's a bug. When the list of candidates is empty at that point, the
program should backtrack, not terminate.

In fact there are solutions for n=63. Using the first improved heuristic
from my previous mail in this thread:

> time ./tour2 63
   14  143  148  2116  229  226  2418  553  578  571   10  551  584 
 573   12  549  630  643   14  547  670  665   16  545  684  679   18  543  770 
 765   20  541  816  867   22  539  952  995   24  537 1044 1121   26  535 1208 
1231   28  533 1300 1307   30  531  494  489   32  491  404   39   34   37
...
real0m1.750s
user0m1.564s
sys 0m0.008s


> The version with the 'tour' given above does not halt after running up to 
> 0.4 GB of RAM, so I killed it.

In fact, replacing  foldl1 mplus  by  foldr mplus mzero  fixed that bug.

Bertram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Sugestion for a basic Utf8 type.

[Mauricio]

>   So  this  proposal  is  more   than  a  UTF8  type,  since  it
>   encompasses a  move away from  text as lists.  What interfaces
>   would we have to text in this proposal?
>

Normal users  would import modules with  specific interfaces, like
functions or instances.

One possible such  module would be Streams like  those sugested in
the  previous article.  Others could  offer functionality  I don't
know of  -- maybe there's  some usefull interface for  japanese or
greek users we (non japanese or greek) don't imagine.

My first attempt  would be PortugueseText, with a  type that could
only be built after Portuguese "primitives" or read from Utf8 with
possible errors,  and convert to  Utf8 of course. That  type would
always convert  to Utf8 with  correct diacriticals, and  sort with
the  latest Portuguese  agreements. Mapping  over syllables  could
be  allowed,  that  makes  sense in  syllabic  languages.  Quotes,
questions,  parenthesis etc.  could  be done  with functions  like
'quote «Ser ou não ser»'.

Other could be SimpleEnglishTextAsList, that could offer something
close  to what  we  have today,  with  functions for  uppercasing,
lowercasing and well behaved (non ambiguous) sorting.

Writers  of very  basic modules  would  have to  touch Utf8  using
Foreign.  So,  maybe  the  only  standard  interface  would  be  a
(ForeignPtr?) pointer to  a null terminated block  of memory. This
would make Foreign a new Prelude,  maybe. In the end, this is just
a basic block of memory that we can fill with utf-8 text, and that
serves as a common denominador.

Best,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Claus Reinke]

ghc --make -package OpenGL -package GLUT something.hs
I get nothing but undefined references in the linking phase.
C:\Program 
Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:
(.text+0x15): undefined reference to `glutWarpPointer'


Does ghc-pkg describe OpenGL tell you that the package needs some gl C
lib? Eg "ld-options: -lGLU -lGL -lm"


Yes:

   $ ghc-pkg field OpenGL 
import-dirs,library-dirs,hs-libraries,include-dirs,includes,cc-options,ld-options

   import-dirs: "C:\\Program Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202"
   library-dirs: "C:\\Program Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202"
   hs-libraries: HSOpenGL-2.2.1.1
   include-dirs: "C:\\Program 
Files\\Haskell\\OpenGL-2.2.1.1\\ghc-6.11.20081202\\include"
   includes: HsOpenGL.h
   cc-options:
   ld-options: -lglu32 -lopengl32

   $ ghc-pkg field GLUT 
import-dirs,library-dirs,hs-libraries,include-dirs,includes,cc-options,ld-options

   import-dirs: "C:\\Program Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202"
   library-dirs: "C:\\Program Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202"
   hs-libraries: HSGLUT-2.1.1.2
   include-dirs: "C:\\Program 
Files\\Haskell\\GLUT-2.1.1.2\\ghc-6.11.20081202\\include"
   includes: HsGLUT.h
   cc-options:
   ld-options: -lglut32 -lglu32 -lopengl32


When you ghc --make -v, is it actually linking to a gl C lib?


It looks that way:

*** Linker: (slightly reformated)
C:\ghc\ghc-6.11.20081202\gcc

-BC:\ghc\ghc-6.11.20081202\gcc-lib/

-IC:\ghc\ghc-6.11.20081202\include/mingw/ -v -o Lift.exe
-DDONT_WANT_WIN32_DLL_SUPPORT obj\Main.o obj\FunWorlds.o
obj\Scene.o obj\Behavior.o C:\DOCUME~1\cr3\LOCALS~1\Temp\/ghc3144_0/ghc3144_0.o

-LC:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202

-LC:\Program Files\Haskell\containers-0.2.0.0\ghc-6.11.20081202

-LC:\Program Files\Haskell\OpenGL-2.2.1.1\ghc-6.11.20081202

-LC:\ghc\ghc-6.11.20081202\haskell98-1.0.1.0 
-LC:\ghc\ghc-6.11.20081202\random-1.0.0.1
-LC:\ghc\ghc-6.11.20081202\process-1.0.1.1 
-LC:\ghc\ghc-6.11.20081202\directory-1.0.0.2
-LC:\ghc\ghc-6.11.20081202\old-time-1.0.0.1 
-LC:\ghc\ghc-6.11.20081202\old-locale-1.0.0.1
-LC:\ghc\ghc-6.11.20081202\filepath-1.1.0.1 
-LC:\ghc\ghc-6.11.20081202\Win32-2.2.0.0
-LC:\ghc\ghc-6.11.20081202\bytestring-0.9.1.4
-LC:\Program Files\Haskell\array-0.2.0.0\ghc-6.11.20081202 
-LC:\ghc\ghc-6.11.20081202\base-3.0.3.0
-LC:\ghc\ghc-6.11.20081202\syb-0.1.0.0 -LC:\ghc\ghc-6.11.20081202\base-4.0.0.0
-LC:\ghc\ghc-6.11.20081202\integer-0.1.0.0 
-LC:\ghc\ghc-6.11.20081202\ghc-prim-0.1.0.0
-LC:\ghc\ghc-6.11.20081202 -LC:\ghc\ghc-6.11.20081202/gcc-lib

-lHSGLUT-2.1.1.2 -lglut32 -lglu32 -lopengl32 -lHScontainers-0.2.0.0
-lHSOpenGL-2.2.1.1 -lglu32 -lopengl32

-lHShaskell98-1.0.1.0 -lHSrandom-1.0.0.1 -lHSprocess-1.0.1.1 
-lHSdirectory-1.0.0.2
-lHSold-time-1.0.0.1 -lHSold-locale-1.0.0.1 -lHSfilepath-1.1.0.1 
-lHSWin32-2.2.0.0
-luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbytestring-0.9.1.4 
-lHSarray-0.2.0.0
-lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSbase-4.0.0.0 -lwsock32 -lmsvcrt -lkernel32
-luser32 -lshell32 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lgmp 
-lwsock32
-u _ghczmprim_GHCziTypes_Izh_static_info -u 
_ghczmprim_GHCziTypes_Czh_static_info
-u _ghczmprim_GHCziTypes_Fzh_static_info -u 
_ghczmprim_GHCziTypes_Dzh_static_info
-u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info
-u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info
-u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info
-u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info
-u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info
-u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info
-u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u 
_base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure
-u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure
-u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure
-u _base_GHCziWeak_runFinalizzerBatch_closure -u 
_base_GHCziTopHandler_runIO_closure
-u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -u 
_base_GHCziConc_runSparks_closure
-lHSffi

$ ls C:/ghc/ghc-6.11.20081202/gcc-lib/*gl*
C:/ghc/ghc-6.11.20081202/gcc-lib/CRT_noglob.o  
C:/ghc/ghc-6.11.20081202/gcc-lib/libglut.a
C:/ghc/ghc-6.11.20081202/gcc-lib/libglaux.a
C:/ghc/ghc-6.11.20081202/gcc-lib/libglut32.a
C:/ghc/ghc-6.11.20081202/gcc-lib/libglu32.a
C:/ghc/ghc-6.11.20081202/gcc-lib/libopengl32.a


Btw, is the format for the cabal config file document

[Haskell-cafe] Problem building HXQ on Mac OS 10.5.5

[Tobias Kräntzer]

Hi,

I'm new to haskell and wonted to start tinkering a bit with this  
language, specifically with HXQ. I have installed ghc with macports.


Now while building HXQ I get the following error:

Main.hs:20:9:
Not in scope: type constructor or class `C.SomeException'

Unfortunately I'm also new to Mac OS X. Before I developed on Linux.
It would be great, if someone could give me a hint.

Thanks,
Tobias

PS: Below the details

--
~$ cabal install hxq
Resolving dependencies...
'HXQ-0.11.0' is cached.
Configuring HXQ-0.11.0...
Preprocessing library HXQ-0.11.0...
Preprocessing executables for HXQ-0.11.0...
Building HXQ-0.11.0...
.
.
.
Loading package haskell98 ... linking ... done.
[20 of 21] Compiling Text.XML.HXQ.XQuery ( src/Text/XML/HXQ/XQuery.hs,  
dist/build/xquery/xquery-tmp/Text/XML/HXQ/XQuery.o )
[21 of 21] Compiling Main ( Main.hs, dist/build/xquery/ 
xquery-tmp/Main.o )


Main.hs:20:9:
Not in scope: type constructor or class `C.SomeException'
cabal: Error: some packages failed to install:
HXQ-0.11.0 failed during the building phase. The exception was:
exit: ExitFailure 1

--
~$ ghc-pkg list
/opt/local/lib/ghc-6.10.1/./package.conf:
Cabal-1.6.0.1, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0,
base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0,
directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3),
(dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3),
(dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, (ghc-6.10.1),
ghc-prim-0.1.0.0, haddock-2.3.0, haskell-src-1.0.1.3,
haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.2, integer-0.1.0.0,
mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1,
packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1,
pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1,
regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3,
rts-1.0, stm-2.1.1.2, syb-0.1.0.0, template-haskell-2.3.0.0,
time-1.1.2.2, unix-2.3.1.0, xhtml-3000.2.0.1
/Users/tobias/.ghc/i386-darwin-6.10.1/package.conf:
readline-1.0.1.0

--
Tobias Kräntzer
[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Brandon S. Allbery KF8NH]

On 2008 Dec 2, at 2:48, Andy Stewart wrote:

,
| * The following packages will be built:
| *
| * glib  : yes
| * gtk   : yes
| * glade : no
| * cairo : yes
| * svgcairo  : no
| * gtkglext  : no
| * gconf : no
| * sourceview: no
| * mozembed  : no
| * soegtk: yes
| * gnomevfs  : no
| * gstreamer : no
| * documentation : no
`

So i want to ask, what libraries need to install for support full
gtk2hs?


You need the native development libraries for all the listed  
libraries.  On Linux a first cut is to check for (rpm or apt as  
appropriate) packages named (something)-dev or (something)-devel, e.g.  
glade-dev.  (Some of them will be versioned, for example gconf2- 
devel.)  The Haskell libraries are wrappers for the native libraries.


On OSX there's the additional complication that there are both native  
(new, not well tested, not very complete) and X11 (uglier but well  
tested) versions of many of these, and the two don't mix.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Sugestion for a basic Utf8 type.

[Jason Dusek]

  So this proposal is more than a UTF8 type, since it
  encompasses a move away from text as lists. What interfaces
  would we have to text in this proposal?

--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Duncan Coutts]

On Tue, 2008-12-02 at 16:55 +, Claus Reinke wrote:

> But when I actually try to build anything using (yes, I know the explicit
> package flags aren't needed with --make)
> 
> ghc --make -package OpenGL -package GLUT something.hs
> 
> I get nothing but undefined references in the linking phase.
> 
> C:\Program 
> Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:
> (.text+0x15): undefined reference to `glutWarpPointer'

Does ghc-pkg describe OpenGL tell you that the package needs some gl C
lib? Eg "ld-options: -lGLU -lGL -lm"

When you ghc --make -v, is it actually linking to a gl C lib?

> Btw, is the format for the cabal config file documented somewhere?
> I though I had set documentation to True.

At the moment only in the config file itself. It lists all the fields
(commented out) and where there are default values it lists those too.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] GHC 6.10 and OpenGL

[Claus Reinke]

I finally got round to trying cabal-install with OpenGL/GLUT,
using a freshly built ghc head, a cygwin bash, and


> http://haskell.org/~duncan/cabal/cabal.exe


   cabal-install version 0.6.0
   using version 1.6.0.1 of the Cabal library


> Yes, building it requires mingw/msys, but with it cabal install opengl
> really does work (I've tried it).


   cabal.exe opengl glut

The first oddity was in the dependency resolution phase, where cabal.exe
insists on installing array-0.2.0.0 and containers-0.2.0.0, which are already
installed. Ignoring that, the build went through without any apparent hitch.
Here is the relevant part of the build log:

   package: GLUT-2.1.1.2
   os: windows
   arch: i386
   compiler: ghc-6.11.20081202
   client: cabal-install-0.6.0
   flags: split-base
   dependencies: OpenGL-2.2.1.1 array-0.2.0.0 base-3.0.3.0
 containers-0.2.0.0
   install-outcome: InstallOk
   docs-outcome: NotTried
   tests-outcome: NotTried

   package: OpenGL-2.2.1.1
   os: windows
   arch: i386
   compiler: ghc-6.11.20081202
   client: cabal-install-0.6.0
   flags:
   dependencies: base-3.0.3.0
   install-outcome: InstallOk
   docs-outcome: NotTried
   tests-outcome: NotTried

   package: array-0.2.0.0
   os: windows
   arch: i386
   compiler: ghc-6.11.20081202
   client: cabal-install-0.6.0
   flags:
   dependencies: base-4.0.0.0 syb-0.1.0.0
   install-outcome: InstallOk
   docs-outcome: NotTried
   tests-outcome: NotTried

   package: containers-0.2.0.0
   os: windows
   arch: i386
   compiler: ghc-6.11.20081202
   client: cabal-install-0.6.0
   flags:
   dependencies: array-0.2.0.0 base-4.0.0.0
   install-outcome: InstallOk
   docs-outcome: NotTried
   tests-outcome: NotTried

But when I actually try to build anything using (yes, I know the explicit
package flags aren't needed with --make)

   ghc --make -package OpenGL -package GLUT something.hs

I get nothing but undefined references in the linking phase.

   C:\Program 
Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:
(.text+0x15): undefined reference to `glutWarpPointer'
   C:\Program 
Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3d): 
undefined reference to `glutReshapeWindow'
   C:\Program 
Files\Haskell\GLUT-2.1.1.2\ghc-6.11.20081202/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x65): 
undefined reference to `glutPositionWindow'

   ..


The problem is that this places an additional barrier on distribution:
Haskell OpenGL authors cannot simply distribute their Haskell code,
because many other Haskellers will not be able to get it to work:


For the rest of the issues I think the proper solution is the platform
installer which would include cabal.exe and a pre-built OpenGL.

We could probably do better for packages that need mingw. Most of them
record this information in the build-type: Configure, so perhaps
cabal.exe should check if sh.exe is present before trying to build
packages that need it. If that sounds sensible then lets file a ticket
so we don't forget.


'build-type: Configure' just means that configure is needed, but says
nothing about whether that is the MSys/Cygwin/.. variant of the
toolchain, or which version. That would be okay if the variant/version
didn't matter, but that is rarely the case.

Why not have a shallow facade cabal-package for the native packages/
tools? Then cabal packages could depend on precise versions of those
facade packages for windows builds, and users would know exactly
what they need (and whether they have it, if the test for MSys/configure
is in the msys-configure package, or where to get it, if that is documented
in the facade packages; the same trick should work for other tool
dependencies, such as happy/alex/..; possibly even for non-haskell
library dependencies for API FFI bindings: depend on the msys-configure
package, run configure to see whether library is installed, register outcome
as a cabal facade package with how-to-get-it information).

Btw, is the format for the cabal config file documented somewhere?
I though I had set documentation to True.

Claus


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Sugestion for a basic Utf8 type.

[Mauricio]

>> I would like to sugest a new basic type in Haskell. What if we had
>> something like this (with any other quoting character):
>>
>> «Je ne parle pas français. (...) ¿Hablas español?»
>>
>> This would  be of type  Utf8. I  think now it  is not a  bad idea,
>> since Haskell source  code is supposed to be  utf-8.  The internal
>> representation of  this datatype would be a  null terminated utf-8
>> byte vector. ...

> Stream fusion on Haskell Unicode strings - Tom Harper
> http://www.wellquite.org/non-blog/AngloHaskell2008/tom%20harper.pdf
> (...)

Actually, what  I suggest is quite  different, in points  I see as
worthwhile:

* His focus  is on speed and  memory, my goal is  more elegant and
  safe code.

* His approach  consolidates Prelude. My  approach allows complete
  elimination of  Prelude. If we had  a Utf8 basic  type, we could
  have modules with many different basic types, and many different
  ideas on how to 'read «something» :: '. In the future,
  we  could write  a  module to  implement  some sort  of not  yet
  invented  numeral type,  which other  module would  allow  to be
  readed from Chinese kanji.

* He wants  to preserve  many properties of  [Char]. I  think Utf8
  type  should  have  no  standard  properties at  all.  See  next
  argument on why this would avoid some unsafe code.

* He insists on the idea of text as something over char. Well, I'm
  probably alone  there, but I think  this was nice,  but today we
  could have better approachs.  Except  for source code, text is a
  block of information, not  a sequence of anything.  I explicitly
  would like  a type we  could not map  over, because we  can't do
  that — text is built from  so many things, there's no basic unit
  we can apply  functions to.  Even something like  "printing of a
  table  of   all  characters   and  their  unicode   numbers"  is
  impossible, since a lot of  unicode is not printable. "Are these
  blocks  of text  equal?"   also  do not  work  like that,  since
  different sets of  bytes can have the same  meaning. If you want
  some piece of text to  obey specific properties, you should have
  to extract it to a  proper type.

Sorry if this is insane for some reason.

Thanks,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sugestion for a basic Utf8 type.

[Jason Dusek]

  Unlike native Strings, this would have the potential for a
  runtime parse error at every character.

--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] GHC on Fedora 10 - getMBlock: mmap: Permission denied

[Fraser Wilson]

Thanks, Bulat, ticket #738 appears to be it.  It was fixed in September, but
I guess it hasn't made it to yum yet, although there's a work-around with
permissions and so forth.

cheers,
Fraser.

On Tue, Dec 2, 2008 at 4:42 PM, Bulat Ziganshin
<[EMAIL PROTECTED]>wrote:

> Hello Fraser,
>
> Tuesday, December 2, 2008, 6:34:19 PM, you wrote:
>
> search in GHC tracker: afair there was some SELinux-releated report
>
> > Why didn't that occur to me?  I should get more sleep. Thanks for
> > the tip.  Now I know that it definitely is SELinux, a system I
> > understand not at all, I presume the problem is in these context
> > things ... ghc has system_u and bin_t, while audley has unconfined_u
> > and file_t.  Time to go poking about.  The unconfined_u looks suspicious.
> >
> > cheers,
> > Fraser.
>
> > On Tue, Dec 2, 2008 at 3:48 PM, David Leimbach <[EMAIL PROTECTED]>
> wrote:
> >  Did you try turning off SELinux to check?
>
> > 2008/12/2 Fraser Wilson <[EMAIL PROTECTED]>
> >
> >  Hi all,
>
> > Has anybody seen this?  I thought it might be an SELinux thing, but
> > then I wouldn't expect GHC or darcs to run.  Audley is a fairly
> > simple program in operating system feature terms, but I get the same
> > error with anything I build myself.
> >
> > [EMAIL PROTECTED] audley]$ ./dist/build/audley/audley
> > audley: internal error: getMBlock: mmap: Permission denied
> > (GHC version 6.8.3 for i386_unknown_linux)
> > Please report this as a GHC bug:
> > http://www.haskell.org/ghc/reportabug
> >  Aborted
> > [EMAIL PROTECTED] audley]$ ghc --version
> > The Glorious Glasgow Haskell Compilation System, version 6.8.3
> > [EMAIL PROTECTED] audley]$ cat /proc/version
> > Linux version 2.6.27-0.352.rc7.git1.fc10.i686
> > ([EMAIL PROTECTED]) (gcc version 4.3.2 20080917
> > (Red Hat 4.3.2-4) (GCC) ) #1 SMP Tue Sep 23 21:26:04 EDT 2008
> >  [EMAIL PROTECTED] audley]$
>
> > cheers,
> > Fraser.
>
> > --
> > http://thewhitelion.org/mysister
> >
> > ___
> >  Haskell-Cafe mailing list
> >  Haskell-Cafe@haskell.org
> >  http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
> >
>
>
>
>
>
>
> --
> Best regards,
>  Bulatmailto:[EMAIL PROTECTED]
>
>


-- 
http://thewhitelion.org/mysister
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] GHC on Fedora 10 - getMBlock: mmap: Permission denied

[Bulat Ziganshin]

Hello Fraser,

Tuesday, December 2, 2008, 6:34:19 PM, you wrote:

search in GHC tracker: afair there was some SELinux-releated report

> Why didn't that occur to me?  I should get more sleep. Thanks for
> the tip.  Now I know that it definitely is SELinux, a system I
> understand not at all, I presume the problem is in these context
> things ... ghc has system_u and bin_t, while audley has unconfined_u
> and file_t.  Time to go poking about.  The unconfined_u looks suspicious.
>  
> cheers,
> Fraser.

> On Tue, Dec 2, 2008 at 3:48 PM, David Leimbach <[EMAIL PROTECTED]> wrote:
>  Did you try turning off SELinux to check?  

> 2008/12/2 Fraser Wilson <[EMAIL PROTECTED]>
>  
>  Hi all,

> Has anybody seen this?  I thought it might be an SELinux thing, but
> then I wouldn't expect GHC or darcs to run.  Audley is a fairly
> simple program in operating system feature terms, but I get the same
> error with anything I build myself.
>   
> [EMAIL PROTECTED] audley]$ ./dist/build/audley/audley
> audley: internal error: getMBlock: mmap: Permission denied
>     (GHC version 6.8.3 for i386_unknown_linux)
>     Please report this as a GHC bug: 
> http://www.haskell.org/ghc/reportabug
>  Aborted
> [EMAIL PROTECTED] audley]$ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.8.3
> [EMAIL PROTECTED] audley]$ cat /proc/version
> Linux version 2.6.27-0.352.rc7.git1.fc10.i686
> ([EMAIL PROTECTED]) (gcc version 4.3.2 20080917
> (Red Hat 4.3.2-4) (GCC) ) #1 SMP Tue Sep 23 21:26:04 EDT 2008
>  [EMAIL PROTECTED] audley]$

> cheers,
> Fraser.

> -- 
> http://thewhitelion.org/mysister
>  
> ___
>  Haskell-Cafe mailing list
>  Haskell-Cafe@haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-cafe
>  


>  






-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC on Fedora 10 - getMBlock: mmap: Permission denied

[Fraser Wilson]

Why didn't that occur to me?  I should get more sleep. Thanks for the tip.
Now I know that it definitely is SELinux, a system I understand not at all,
I presume the problem is in these context things ... ghc has system_u and
bin_t, while audley has unconfined_u and file_t.  Time to go poking about.
The unconfined_u looks suspicious.

cheers,
Fraser.

On Tue, Dec 2, 2008 at 3:48 PM, David Leimbach <[EMAIL PROTECTED]> wrote:

> Did you try turning off SELinux to check?
>
> 2008/12/2 Fraser Wilson <[EMAIL PROTECTED]>
>
>> Hi all,
>>
>> Has anybody seen this?  I thought it might be an SELinux thing, but then I
>> wouldn't expect GHC or darcs to run.  Audley is a fairly simple program in
>> operating system feature terms, but I get the same error with anything I
>> build myself.
>>
>> [EMAIL PROTECTED] audley]$ ./dist/build/audley/audley
>> audley: internal error: getMBlock: mmap: Permission denied
>> (GHC version 6.8.3 for i386_unknown_linux)
>> Please report this as a GHC bug:
>> http://www.haskell.org/ghc/reportabug
>> Aborted
>> [EMAIL PROTECTED] audley]$ ghc --version
>> The Glorious Glasgow Haskell Compilation System, version 6.8.3
>> [EMAIL PROTECTED] audley]$ cat /proc/version
>> Linux version 2.6.27-0.352.rc7.git1.fc10.i686 (
>> [EMAIL PROTECTED]) (gcc version 4.3.2 20080917 (Red
>> Hat 4.3.2-4) (GCC) ) #1 SMP Tue Sep 23 21:26:04 EDT 2008
>> [EMAIL PROTECTED] audley]$
>>
>> cheers,
>> Fraser.
>>
>> --
>> http://thewhitelion.org/mysister
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
http://thewhitelion.org/mysister
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Duncan Coutts]

On Tue, 2008-12-02 at 11:01 +, Colin Paul Adams wrote:
> > "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes:
> 
> >> gstreamer
> 
> Duncan> Those names are the names of the Haskell
> Duncan> components/packages. All of them (except soegtk) are
> Duncan> wrappers for C libraries with similar names. So you need
> Duncan> to install the system packages that contain the
> Duncan> development files for those C libraries. For example the
> Duncan> system package for glib might be called something like
> Duncan> "glib-dev" or "glib-devel". On some systems they also have
> Duncan> more numbers in like "glib2-devel" or be prefixed with
> Duncan> "lib", like "libglib-dev".
> 
> I have gstreamer-devel installed, but configure doesn't find it.

Specifically you need the native package that provides the file
gstreamer-0.10.pc Eg on my system I've got the file:
/usr/lib/pkgconfig/gstreamer-0.10.pc

If you run ./configure --enable-gstreamer it'll tell you something
similar.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC on Fedora 10 - getMBlock: mmap: Permission denied

[David Leimbach]

Did you try turning off SELinux to check?

2008/12/2 Fraser Wilson <[EMAIL PROTECTED]>

> Hi all,
>
> Has anybody seen this?  I thought it might be an SELinux thing, but then I
> wouldn't expect GHC or darcs to run.  Audley is a fairly simple program in
> operating system feature terms, but I get the same error with anything I
> build myself.
>
> [EMAIL PROTECTED] audley]$ ./dist/build/audley/audley
> audley: internal error: getMBlock: mmap: Permission denied
> (GHC version 6.8.3 for i386_unknown_linux)
> Please report this as a GHC bug:
> http://www.haskell.org/ghc/reportabug
> Aborted
> [EMAIL PROTECTED] audley]$ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.8.3
> [EMAIL PROTECTED] audley]$ cat /proc/version
> Linux version 2.6.27-0.352.rc7.git1.fc10.i686 (
> [EMAIL PROTECTED]) (gcc version 4.3.2 20080917 (Red
> Hat 4.3.2-4) (GCC) ) #1 SMP Tue Sep 23 21:26:04 EDT 2008
> [EMAIL PROTECTED] audley]$
>
> cheers,
> Fraser.
>
> --
> http://thewhitelion.org/mysister
>
> ___
> 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] Compilers

[Jules Bean]

John Meacham wrote:

I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.


My understanding is that you can have a .cabal file which merely 
specifies the dependency information and metadata, but delegates all the 
actual building to your existing configure and make infrastructure.


It could then be entirely ignored (by someone who chose to type 
./configure && make) but it would still work for someone who wanted to 
use cabal (using the metadata to get any dependencies, and then 
thereafter using the make-based build).


Is this not a good path for a project like JHC?

Jules

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compilers

[Jules Bean]

John Meacham wrote:

I never was opposed to a cabal 'target' for jhc. I have 'make dist'
'make dist-rpm' and hopefully 'make msi' soon, adding a 'make
dist-hackage' alongside is not a bad thing, however, it is if it
complicates the standard build or comes to dominate development effort
or can't be done without duplication of functionality.


My understanding is that you can have a .cabal file which merely 
specifies the dependency information and metadata, but delegates all the 
actual building to your existing configure and make infrastructure.


It could then be entirely ignored (by someone who chose to type 
./configure && make) but it would still work for someone who wanted to 
use cabal (using the metadata to get any dependencies, and then 
thereafter using the make-based build).


Is this not a good path for a project like JHC?

Jules

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Sugestion for a basic Utf8 type.

[Bayley, Alistair]

> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mauricio
> 
> I would like to sugest a new basic type in Haskell. What if we had
> something like this (with any other quoting character):
> 
> «Je ne parle pas français. Meu nome é Maurício. ¿Hablas español?»
> 
> This would  be of type  Utf8. I  think now it  is not a  bad idea,
> since Haskell source  code is supposed to be  utf-8.  The internal
> representation of  this datatype would be a  null terminated utf-8
> byte vector. ...


Stream fusion on Haskell Unicode strings - Tom Harper
http://www.wellquite.org/non-blog/AngloHaskell2008/tom%20harper.pdf

I don't know what it's status is. The original implementation used UTF16 rather 
than UTF8.

Alistair
*
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Sugestion for a basic Utf8 type.

[Mauricio]

Hi,

I would like to sugest a new basic type in Haskell. What if we had
something like this (with any other quoting character):

«Je ne parle pas français. Meu nome é Maurício. ¿Hablas español?»

This would  be of type  Utf8. I  think now it  is not a  bad idea,
since Haskell source  code is supposed to be  utf-8.  The internal
representation of  this datatype would be a  null terminated utf-8
byte vector. No standard operations would be defined on that type,
i.e., it would be  a “communication standard” between everybody,
but module  writers could develop  different basic usage  based on
operations on them  using Foreign.  (I think it  would be dificult
to set default operations, since  there are so many things you can
do with utf-8.)

Pros:

 * There  would  be  no  doubt   you  can  use  utf-8  when  using
   this, since there's no conversion involved.

 * Cleaner code  on utf8 operations,  maybe.  There are  many utf8
   modules today with different goals in mind, I thing it would be
   nice if  they could share this  common basic type  and a common
   underline implementation.

Cons:

 * Probably, many. I have no deep understanding of Haskell.

Thanks for your attention,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: The Knight's Tour: solutions please

[ChrisK]

Hmmm... it seems that n=63 is a special case.

[EMAIL PROTECTED] wrote:

Yes, there is a solution for n=99 and for n=100 for that matter --
which can be found under one second. I only had to make a trivial
modification to the previously posted code


tour n k s b | k > n*n   = return b
 | otherwise = do next <- (foldr mplus mzero).map return $ 
successors n b s
  tour n (k+1) next $ insrt next k b


I replaced foldl1 mplus with foldr mplus zero.



The old version sees no solution to n=63 quite quickly:


time nice ./fromwiki-63 63
fromwiki-63: Prelude.foldl1: empty list

real0m0.285s
user0m0.172s
sys 0m0.026s


The version with the 'tour' given above does not halt after running up to 0.4 GB 
of RAM, so I killed it.


Though having no solution may be tied to starting in the corner.

--
Chris

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Duncan Coutts]

On Tue, 2008-12-02 at 19:58 +0800, Andy Stewart wrote:
> Hi Dunca,
> 
> Duncan Coutts <[EMAIL PROTECTED]> writes:

> And i use darcs version of gtk2hs,
> when i ./configure, i got below information:

> But when i "make", i got below error information:
> 
> ,
> | glib/System/Glib.hs:13:0:
> | Failed to load interface for `System.Glib.UTFString':
> |   Use -v to see a list of the files searched for.
> | make[1]: *** [glib/System/Glib.o] error 1
> `

Usually this is not the first thing to go wrong, but for some reason
make does not stop immediately. Check further up in the build log for
the first error.

The best place to get help on this is the gtk2hs-users mailing list
https://lists.sourceforge.net/lists/listinfo/gtk2hs-users

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Andy Stewart]

Hi Dunca,

Duncan Coutts <[EMAIL PROTECTED]> writes:

> On Tue, 2008-12-02 at 15:48 +0800, Andy Stewart wrote:
>
>> When i ./configure gtk2hs souce code, i will got below information:
>> 
>> ,
>> | * The following packages will be built:   
>> | * 
>> | * glib  : yes 
>> | * gtk   : yes 
>> | * glade : no  
>> | * cairo : yes 
>> | * svgcairo  : no  
>> | * gtkglext  : no  
>> | * gconf : no 
>> | * sourceview: no
>> | * mozembed  : no  
>> | * soegtk: yes 
>> | * gnomevfs  : no  
>> | * gstreamer : no 
>> | * documentation : no
>> `
>> 
>> So i want to ask, what libraries need to install for support full
>> gtk2hs?
>
> Those names are the names of the Haskell components/packages. All of
> them (except soegtk) are wrappers for C libraries with similar names. So
> you need to install the system packages that contain the development
> files for those C libraries. For example the system package for glib
> might be called something like "glib-dev" or "glib-devel". On some
> systems they also have more numbers in like "glib2-devel" or be prefixed
> with "lib", like "libglib-dev".
>
> You almost certainly have the runtime files for all these packages
> installed already, so it's only the "dev"/"devel" variants that you need
> to install.
>
> Duncan

I have install GHC 6.10.1 and install those debian packages for
predepend for gtk2hs:

,
| libglade2-dev
| libgtksourceview-dev
| libgconf2-dev
| librsvg2-dev
| libgstreamer-plugins-base0.10-dev
| libgstreamer0.10-dev
| libgtkglext1-dev
| libgnomevfs2-dev
| xulrunner-dev
`

And i use darcs version of gtk2hs,
when i ./configure, i got below information:

,
| * The following packages will be built:   
| * 
| * glib  : yes 
| * gtk   : yes   
| * gio   : yes   
| * glade : yes  
| * cairo : yes 
| * svgcairo  : yes  
| * gtkglext  : yes  
| * gconf : yes 
| * sourceview: yes
| * mozembed  : yes  
| * soegtk: yes   
| * gnomevfs  : yes  
| * gstreamer : yes 
| * documentation : no
| *
`

But when i "make", i got below error information:

,
| glib/System/Glib.hs:13:0:
| Failed to load interface for `System.Glib.UTFString':
|   Use -v to see a list of the files searched for.
| make[1]: *** [glib/System/Glib.o] error 1
`

So can you help me?
Is i missing something?

Thank you very much!

  -- Andy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Andy Stewart]

Colin Paul Adams <[EMAIL PROTECTED]> writes:

>> "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes:
>
> >> gstreamer
>
> Duncan> Those names are the names of the Haskell
> Duncan> components/packages. All of them (except soegtk) are
> Duncan> wrappers for C libraries with similar names. So you need
> Duncan> to install the system packages that contain the
> Duncan> development files for those C libraries. For example the
> Duncan> system package for glib might be called something like
> Duncan> "glib-dev" or "glib-devel". On some systems they also have
> Duncan> more numbers in like "glib2-devel" or be prefixed with
> Duncan> "lib", like "libglib-dev".
>
> I have gstreamer-devel installed, but configure doesn't find it.
I use Debian, about gstreamer need libgstreamer-plugins-base0.10-dev
and libgstreamer0.10-dev.

libgstreamer-plugins-base0-dev is "base" set for GStreamer development files
libgstreamer0.10-dev is core development files for GStreamer development

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Andy Stewart]

Hi all,

Thanks for your help.

I have install all depend with below Debian package:
libglade2-dev libgtksourceview-dev libgconf2-dev librsvg2-dev
libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev libgtkglext1-dev
libgnomevfs2-dev xulrunner-dev 

Colin Paul Adams <[EMAIL PROTECTED]> writes:

>> "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes:
>
> Duncan> Those names are the names of the Haskell
> Duncan> components/packages. All of them (except soegtk) are
> Duncan> wrappers for C libraries with similar names. So you need
> Duncan> to install the system packages that contain the
> Duncan> development files for those C libraries. For example the
> Duncan> system package for glib might be called something like
> Duncan> "glib-dev" or "glib-devel". On some systems they also have
> Duncan> more numbers in like "glib2-devel" or be prefixed with
> Duncan> "lib", like "libglib-dev".
>
> Do you know the names of the Fedora 10 packages needed for sourceview,
> mozembed and documentation?
I think sourceview is libgtksourceview-dev,
mozembed is xulrunner-dev.
Document just document and example, i don't install it.
I doesn't use Fedora 10, but i think you can those packages from Debian
package name.

  -- Andy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] import

[Bulat Ziganshin]

Hello Vasili,

Tuesday, December 2, 2008, 2:08:03 PM, you wrote:

it's just convention to make modules like this:

module System.Stream (
module System.Stream.Class,
module System.Stream.Transformer,
module System.Stream.Instance,
module System.Stream.Utils,
  ) where

import System.Stream.Class
import System.Stream.Transformer
import System.Stream.Instance
import System.Stream.Utils



> specifically I am concerned about ByteString and underlying nodes .. ???



> On Tue, Dec 2, 2008 at 3:45 AM, Bulat Ziganshin
> <[EMAIL PROTECTED]> wrote:
>  
> Hello Vasili,
>  

>  Tuesday, December 2, 2008, 11:48:40 AM, you wrote:
 >>  I am a little uncertain about "import" semantics in a
 >> hierarchical package ... i.e. if I import the root of a package root
 >> do I get everything under the "root's" namespace, i.e. the namespace tree?
>  
>  
> no. you import just *module*, and it gives you just the identifiers
>  exported by module (by default - all symbols *defined* in this module)
>  
>  --
>  Best regards,
>   Bulat                            mailto:[EMAIL PROTECTED]
>  
>  

>   


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] import

[Galchin, Vasili]

specifically I am concerned about ByteString and underlying nodes .. ???



On Tue, Dec 2, 2008 at 3:45 AM, Bulat Ziganshin
<[EMAIL PROTECTED]>wrote:

> Hello Vasili,
>
> Tuesday, December 2, 2008, 11:48:40 AM, you wrote:
> >  I am a little uncertain about "import" semantics in a
> > hierarchical package ... i.e. if I import the root of a package root
> > do I get everything under the "root's" namespace, i.e. the namespace
> tree?
>
> no. you import just *module*, and it gives you just the identifiers
> exported by module (by default - all symbols *defined* in this module)
>
> --
> Best regards,
>  Bulatmailto:[EMAIL PROTECTED]
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Colin Paul Adams]

> "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes:

>> gstreamer

Duncan> Those names are the names of the Haskell
Duncan> components/packages. All of them (except soegtk) are
Duncan> wrappers for C libraries with similar names. So you need
Duncan> to install the system packages that contain the
Duncan> development files for those C libraries. For example the
Duncan> system package for glib might be called something like
Duncan> "glib-dev" or "glib-devel". On some systems they also have
Duncan> more numbers in like "glib2-devel" or be prefixed with
Duncan> "lib", like "libglib-dev".

I have gstreamer-devel installed, but configure doesn't find it.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Colin Paul Adams]

> "Duncan" == Duncan Coutts <[EMAIL PROTECTED]> writes:

Duncan> Those names are the names of the Haskell
Duncan> components/packages. All of them (except soegtk) are
Duncan> wrappers for C libraries with similar names. So you need
Duncan> to install the system packages that contain the
Duncan> development files for those C libraries. For example the
Duncan> system package for glib might be called something like
Duncan> "glib-dev" or "glib-devel". On some systems they also have
Duncan> more numbers in like "glib2-devel" or be prefixed with
Duncan> "lib", like "libglib-dev".

Do you know the names of the Fedora 10 packages needed for sourceview,
mozembed and documentation?
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Moving the messages for compiler to another file?

[nml]

How about moving the messages for compiler to an additional file?

My motivation is that we often face a trade-off between
aesthetical(elegant code) and practical(efficient code).
Like pragmas and strictness annotations, I often feel they make the
source code ugly.
They don't affect the semantics of our programs, do they?

Some people would say this beautifying should be accomplished by an
editor, like hiding/showing option for those information.

But such separation has additional benefits.
For instance, making the source code more compiler-independent.
(yeah, this is not the case with language-extensions)
And we avoid dispersing those information among our lines. (or even files)
In some cases, it would be convenient.

I'm not sure if this idea is reasonable, reachable or just naive.
Suggestions?

Best regards
-nml
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Compatible problem with GHC 6.10.1

[Duncan Coutts]

On Tue, 2008-12-02 at 15:48 +0800, Andy Stewart wrote:

> When i ./configure gtk2hs souce code, i will got below information:
> 
> ,
> | * The following packages will be built:   
> | * 
> | * glib  : yes 
> | * gtk   : yes 
> | * glade : no  
> | * cairo : yes 
> | * svgcairo  : no  
> | * gtkglext  : no  
> | * gconf : no 
> | * sourceview: no
> | * mozembed  : no  
> | * soegtk: yes 
> | * gnomevfs  : no  
> | * gstreamer : no 
> | * documentation : no
> `
> 
> So i want to ask, what libraries need to install for support full
> gtk2hs?

Those names are the names of the Haskell components/packages. All of
them (except soegtk) are wrappers for C libraries with similar names. So
you need to install the system packages that contain the development
files for those C libraries. For example the system package for glib
might be called something like "glib-dev" or "glib-devel". On some
systems they also have more numbers in like "glib2-devel" or be prefixed
with "lib", like "libglib-dev".

You almost certainly have the runtime files for all these packages
installed already, so it's only the "dev"/"devel" variants that you need
to install.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] import

[Luke Palmer]

2008/12/2 Galchin, Vasili <[EMAIL PROTECTED]>:
> Hello,
>
>  I am a little uncertain about "import" semantics in a hierarchical
> package ... i.e. if I import the root of a package root do I get everything
> under the "root's" namespace, i.e. the namespace tree?

There is nothing at all magical about the . in a package name, other
than that it is replaced by a / when searching for modules in a
directory tree.  But you should treat it as any other identifier
character.  Any hierarchy is purely incidental :-)

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] import

[Bulat Ziganshin]

Hello Vasili,

Tuesday, December 2, 2008, 11:48:40 AM, you wrote:
>  I am a little uncertain about "import" semantics in a
> hierarchical package ... i.e. if I import the root of a package root
> do I get everything under the "root's" namespace, i.e. the namespace tree?

no. you import just *module*, and it gives you just the identifiers
exported by module (by default - all symbols *defined* in this module)

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHC on Fedora 10 - getMBlock: mmap: Permission denied

[Fraser Wilson]

Hi all,

Has anybody seen this?  I thought it might be an SELinux thing, but then I
wouldn't expect GHC or darcs to run.  Audley is a fairly simple program in
operating system feature terms, but I get the same error with anything I
build myself.

[EMAIL PROTECTED] audley]$ ./dist/build/audley/audley
audley: internal error: getMBlock: mmap: Permission denied
(GHC version 6.8.3 for i386_unknown_linux)
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted
[EMAIL PROTECTED] audley]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.3
[EMAIL PROTECTED] audley]$ cat /proc/version
Linux version 2.6.27-0.352.rc7.git1.fc10.i686 (
[EMAIL PROTECTED]) (gcc version 4.3.2 20080917 (Red Hat
4.3.2-4) (GCC) ) #1 SMP Tue Sep 23 21:26:04 EDT 2008
[EMAIL PROTECTED] audley]$

cheers,
Fraser.

-- 
http://thewhitelion.org/mysister
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] import

[Galchin, Vasili]

Hello,

 I am a little uncertain about "import" semantics in a hierarchical
package ... i.e. if I import the root of a package root do I get everything
under the "root's" namespace, i.e. the namespace tree?

thanks, vasili
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] The Knight's Tour: solutions please

[oleg]

Yes, there is a solution for n=99 and for n=100 for that matter --
which can be found under one second. I only had to make a trivial
modification to the previously posted code

> tour n k s b | k > n*n   = return b
>  | otherwise = do next <- (foldr mplus mzero).map return $ 
> successors n b s
>   tour n (k+1) next $ insrt next k b

I replaced foldl1 mplus with foldr mplus zero.

Here are the results:
for n=99, the first line of the board is

   1 4 2885 214 309 6 311 216 307 8 315 218 305 10 319 220 303 12 2021
222 301 14 1727 224 299 16 1699 226 297 18 1561 228 295 20 1247 230
293 22 1227 232 291 24 1165 234 289 26 1007 236 287 28 965 238 285 30
775 240 283 32 759 242 281 34 625 244 279 36 559 246 277 38 543 248
275 40 455 250 273 42 435 252 271 44 407 254 269 46 377 256 267 48 365
258 65 50 63 60 67 52 55

time is 0m0.730s


n=100

1 4 205 9996 209 6 207 9940 211 8 9897 9900 213 10 9895 9906 215
12 9809 9880 217 14 9807 9740 219 16 9799 9072 221 18 8445 8864 223 20
8443 8378 225 22 8347 8352 227 24 8331 7860 229 26 7863 7844 231 28
7749 7754 233 30 7735 7742 235 32 7733 7320 237 34 677 640 239 36 597
568 241 38 535 540 243 40 517 500 245 42 473 452 247 44 371 358 249 46
305 310 251 48 293 286 253 50 291 270 255 52 259 262

time is 0m0.373s

For n=101, time is 0m0.388s

wren ng thornton wrote:
> FWIW, fair choice (interleave) is much slower than unfair choice (mplus)
> in logict. Unfortunately this means you need to know a lot about the
> problem domain to correctly choose between them when maximal performance
> is at stake; just using fair choice everywhere costs too much for many
> problems.

I believe that FBackTrack relieves one from making the above choice:
the ordinary mplus is FBackTrack is both fair and speedy. There is no
longer any need for interleave; btw, interleave does not ensure
completeness, whereas FBackTrack, I conjecture, implements a complete
search procedure: if there is a solution, FBackTrack will eventually
find one. The only `drawback' of using FBackTrack is that the order
of the answers (if there are several) is essentially unpredictable.
Informally, the answers are delivered in the order of the difficulty
of finding them. This drawback is relative however: if we insist that
the sequence of answers of (m1 `mplus` m2) is the concatenation of the
sequences of answers of m1 and then m2, our search procedure is
incomplete.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The Knight's Tour: solutions please

[Bertram Felgenhauer]

Dan Doel wrote:
> On Monday 01 December 2008 1:39:13 pm Bertram Felgenhauer wrote:
> > As one of the posters there points out, for n=100 the program doesn't
> > actually backtrack if the 'loneliest neighbour' heuristic is used. Do
> > any of our programs finish quickly for n=99? The Python one doesn't.
> 
> Nothing I tried finished. Do you have any figures on how much backtracking 
> needs to be done to find a solution for n=99 (there is a solution, right?)?

Yes, there is a solution. After changing

  successors n b = sortWith (length . succs) . succs

to

  successors n b = sortWith (length . (succs =<<) . succs) . succs

in the LogicT solution, it finds one with no backtracking at all.

This heuristic fails on other n though, n=8 and n=66 at least.

The obvious next step,

  successors n b = sortWith (length . (succs =<<) . (succs =<<) . succs) . succs

works without backtracking up to n=100.

These improved heuristics don't come cheap though. Here are some timings
for n = 100:

  LogicT  :  0.48 user 0.00 system 0:00.48 elapsed
  LogicT' :  2.16 user 0.00 system 0:02.16 elapsed
  LogicT'': 13.84 user 0.01 system 0:13.86 elapsed

Bertram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: Haskell Communities and Activities Report (15th ed., November 2008)

[Benjamin L . Russell]

On Fri, 28 Nov 2008 16:15:30 -0800, Don Stewart <[EMAIL PROTECTED]>
wrote:

>Good work!
>
>It is always interesting to see the secret Haskell projects that only
>get announced via the HCAR. Things not on haskell@ or on hackage.
>
>For example, this under-the-radar project:
>
>http://www.haskell.org/communities/11-2008/html/report.html#sect7.7
>
>7.7  IVU Traffic Technologies AG Rostering Group
>
>Haskell to solve constraints on EU bus timetables! In production use!

Speaking of production use, one type of project that would be
interesting would be a study examining how Haskell can increase
programmer productivity for production use for programmers who are not
necessarily gifted in programming, but whose forte may lie in another
field and who are very interested in functional programming; i.e.,
some type of tabulated data (preferably a graph, although a table
would work, too) of data quantifying how useful Haskell is in allowing
one whose forte may not necessarily be in programming (say, a
physicist, mathematician, or even a translator who happens to have an
algorithmically-focused computer science degree) to equal or excel the
productivity of, say, a gifted C/C++ programmer in, say, setting up a
commercial Web site.

The reason is that recently, there has been news of people in academia
leaving for other realms because of worsening conditions (see "As
strikes begin, lecturer quits to become plumber" at
http://www.guardian.co.uk/uk/2004/feb/24/lecturerspay.highereducation,
and "Why I am Not a Professor OR The Decline and Fall of the British
University" at http://www.lambdassociates.org/blog/decline.htm).  Up
to know, my dream was to publish a paper on type theory to motivate
study of Haskell, but now it looks like I may need to aim for creating
a commercial Web site.  However, I am not sure of being able to
compete with commercial Web sites, because I am more of a
writer/translator who happens to like functional programming than a
real-life programmer.

I've already seen such articles as "Why Functional Programming
Matters" (see http://www.md.chalmers.se/~rjmh/Papers/whyfp.html), "Why
Haskell Matters" (see
http://www.haskell.org/haskellwiki/Why_Haskell_matters), and "Beating
the Averages" (see http://www.paulgraham.com/avg.html).  However,
these essays tend to focus on how a functional language FL is
structurally better than non-functional languages NFL in general,
without specifying the skill-level of the programmer.  Instead, it
would be interesting to find the minimum skill-level s necessary for,
say, somebody whose forte is not in programming, but who, say, studies
functional programming as a hobby, to use Haskell as a tool in
achieving a productivity level equivalent to that of a gifted C/C++
programmer.

To sum:  Can a theoretically-minded Haskell student who studies
Haskell out of interest in type theory compete with star C/C++
programmers in developing, say, commercial Web sites?

This is not quite clear, because even if Haskell can increase
programmer productivity by tenfold, a star programmer can also be more
productive than an average programmer by tenfold.

How risky is this challenge?

-- Benjamin L. Russell

>
>-- Don
>
>
>voigt:
>> On behalf of the many, many contributors, I am pleased to announce
>> that the
>> 
>> Haskell Communities and Activities Report
>>   (15th edition, November 2008)
>> 
>>http://www.haskell.org/communities/
>> 
>> is now available from the Haskell Communities home page in PDF and
>> HTML formats.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe