Re: [Haskell-cafe] hmatrix on os x

[brian]

Hi,

yep - that's the problem I had.

run cabal with the -v (verbose option)

   cabal install -v

so you can see exactly where it's failing

try the following :

  --extra-lib-dirs=PATH

where PATH was (for me) was /sw/lib

I'm not sure but I may have had to use --extra-include-dirs also.

Generally I have a lot of trouble with cabal installing things  
properly using the mac, but the above options usually fix the problem.


I did get hmatrix working.  Then when I ran a an example which did a  
simple vector operation, it segfaulted.  However the linear algebra  
routines all seemed to work.  Let me know what happens.


The linux pc gave me even more problems which I eventually traced to  
LD_LIBRARY_PATH needing to include the lib dirs.


HTH.

Brian

On Sep 9, 2009, at 11:57 PM, Martijn van Steenbergen wrote:


brian wrote:
yep I had some trouble too, although interestingly less than on  
linux pc.
can you provide some error messages and we can see if your problems  
are the same one's I saw.


If this helps, here is the error message I got:

Configuring hmatrix-0.5.2.2...
Checking foreign libraries... FAIL
*** Sorry, I can't link GSL.
*** Please make sure that the appropriate -dev packages are installed.
*** You can also specify the required libraries using
*** cabal install hmatrix --configure-option=link:lib1,lib2,lib3,etc.
setup: Package hmatrix-0.5.2.2 can't be built on this system.
cabal: Error: some packages failed to install:
hmatrix-0.5.2.2 failed during the building phase. The exception was:
exit: ExitFailure 1

M.


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

Re: [Haskell-cafe] instance Monad (Either String) in Prelude or Data.Either?

[Evan Laforge]

> if I understand you correctly, all libraries that software I write depends
> on, directly or indirectly, must be free of namespace conflicts.  Is that
> correct?

Well, it may be more accurate to say that class instances have no
namespaces, and are all implicitly global.  When you import a module,
you get all the instances it defines in the global namespace, whether
you want them or not.  Like I said, there was some argument with
people on one side saying importing is a valid way of controlling
instance visibility, and another side saying the fact that you have to
import at all is an implementation artifact and instances should be
considered global.

Practically speaking, I buy the second argument more, for the reason
you described above.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] instance Monad (Either String) in Prelude or Data.Either?

[Michael Steele]

> Right.  I know there was some argument a while back, but I thought
> that position that instances are global period was pretty "official".
> At least it made sense to me.  The more libraries you import the less
> control you have over the extent of what they may import.  But I guess
> it wouldn't be haskell if every third person didn't have an idea for a
> better way to implement the mtl...  I just want an exception with a
> message though!


A few days ago I was trying to refactor some code to use transformers +
monads-tf instead of mtl.  Eventually I gave up after getting error messages
about Either having conflicting Monad instances.  A few of the libraries I'm
using depend on mtl.

if I understand you correctly, all libraries that software I write depends
on, directly or indirectly, must be free of namespace conflicts.  Is that
correct?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Haskell Platform install fails on mtl

[Lyle Kopnicky]

It's a bug in the install.sh script. Here's the fix:

36a37,42
> # Is this exact version of the package already installed?
> is_pkg_installed () {
>   PKG_VER=$1
>   grep " ${PKG_VER} " installed.packages > /dev/null 2>&1
> }
>
40,43c46,53
<   cd "${pkg}" || die "The directory for the component ${PKG} is missing"
<   echo "Installing ${pkg}..."
<   install_pkg ${pkg}
<   cd ..
---
>   if is_pkg_installed "${pkg}"; then
> echo "Platform package ${pkg} is already installed. Skipping..."
>   else
>   cd "${pkg}" || die "The directory for the component ${PKG} is
missing"
>   echo "Installing ${pkg}..."
>   install_pkg ${pkg}
>   cd ..
>   fi

On Fri, Sep 11, 2009 at 1:04 PM, Lyle Kopnicky  wrote:

> OK, I was able to build the Haskell Platform on Ubuntu 9.04 with GHC
> 6.10.4. But when I try to install it, I get an error:
>
> Registering haskell-platform-2009.2.0.2...
> Reading package info from "dist/inplace-pkg-config" ... done.
> Writing new package config file... done.
> **
> * Building each component completed successfully.
> *
> * Now do "sudo make install"
> **
> l...@lwk-desktop:~/downloads/haskell-platform-2009.2.0.2$ sudo make install
> [sudo] password for lwk:
> scripts/install.sh
> Installing mtl-1.1.0.2...
>
> Error:
> The mtl-1.1.0.2/Setup script does not exist or cannot be run
> make: *** [install] Error 2
>
> - Lyle
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Just to let people know

[Sean Leather]

Thanks, Jeff. I'm CC'ing Andres just in case he didn't get this.

Sean

On Fri, Sep 11, 2009 at 22:27, Jeff Heard wrote:

> lhs2TeX does not compile with the latest version of base.  complaints
> about Control.Exception abound
> ___
> 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] Just to let people know

[Jeff Heard]

lhs2TeX does not compile with the latest version of base.  complaints
about Control.Exception abound
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell Platform install fails on mtl

[Lyle Kopnicky]

OK, I was able to build the Haskell Platform on Ubuntu 9.04 with GHC 6.10.4.
But when I try to install it, I get an error:

Registering haskell-platform-2009.2.0.2...
Reading package info from "dist/inplace-pkg-config" ... done.
Writing new package config file... done.
**
* Building each component completed successfully.
*
* Now do "sudo make install"
**
l...@lwk-desktop:~/downloads/haskell-platform-2009.2.0.2$ sudo make install
[sudo] password for lwk:
scripts/install.sh
Installing mtl-1.1.0.2...

Error:
The mtl-1.1.0.2/Setup script does not exist or cannot be run
make: *** [install] Error 2

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

Re: [Haskell-cafe] Unable to install Haskell Platform without editline

[Lyle Kopnicky]

On Fri, Sep 11, 2009 at 12:01 PM, Judah Jacobson
wrote:

> The above editline requirement is for the editline C library, not the
> Haskell bindings:
> http://www.thrysoee.dk/editline
>
> My guess is that you need to install a recent version of the
> libedit-dev package.
>

After installing libedit-dev, the rest of the build worked. Thanks! Now I'm
having a new problem, that I'll post in another thread.

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

Re: [Haskell-cafe] Unable to install Haskell Platform without readline

[Judah Jacobson]

On Fri, Sep 11, 2009 at 11:46 AM, Lyle Kopnicky  wrote:
> Hi folks,
>
> I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to install
> the Haskell Platform from source. It built quite a bit of stuff, with many
> warnings but no errors, and then finally died with the error below.
>
> To install editline, I need cabal, which is of course why I installed the
> Platform. I read an earlier thread from May that said that editline came
> with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be
> updated. Now the web site for the Platform says it comes with 6.10.4, so I
> assumed it should work with 6.10.4, but apparently it still has this problem
> of still missing editline.
>
> Am I doing something wrong?
>
> checking editline/readline.h usability... no
> checking editline/readline.h presence... no
> checking for editline/readline.h... no
> checking editline/editline.h usability... no
> checking editline/editline.h presence... no
> checking for editline/editline.h... no
> checking readline/readline.h usability... yes
> checking readline/readline.h presence... yes
> checking for readline/readline.h... yes
> checking for sign of read_history result on error... negative
> checking for rl_completion_matches... no
> checking for completion_matches... no
> configure: error: editline not found, so this package cannot be built
> See `config.log' for more details.
>
> Error:
> Configuring the editline-0.2.1.0 package failed
> make: *** [build.stamp] Error 2

The above editline requirement is for the editline C library, not the
Haskell bindings:
http://www.thrysoee.dk/editline

My guess is that you need to install a recent version of the
libedit-dev package.

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

[Haskell-cafe] Re: Unable to install Haskell Platform without editline

[Lyle Kopnicky]

I mean editline, not readline.

On Fri, Sep 11, 2009 at 11:46 AM, Lyle Kopnicky  wrote:

> Hi folks,
>
> I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to
> install the Haskell Platform from source. It built quite a bit of stuff,
> with many warnings but no errors, and then finally died with the error
> below.
>
> To install editline, I need cabal, which is of course why I installed the
> Platform. I read an earlier thread from May that said that editline came
> with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be
> updated. Now the web 
> sitefor the Platform says 
> it comes with 6.10.4, so I assumed it should work with
> 6.10.4, but apparently it still has this problem of still missing editline.
>
> Am I doing something wrong?
>
> checking editline/readline.h usability... no
> checking editline/readline.h presence... no
> checking for editline/readline.h... no
> checking editline/editline.h usability... no
> checking editline/editline.h presence... no
> checking for editline/editline.h... no
> checking readline/readline.h usability... yes
> checking readline/readline.h presence... yes
> checking for readline/readline.h... yes
> checking for sign of read_history result on error... negative
> checking for rl_completion_matches... no
> checking for completion_matches... no
> configure: error: editline not found, so this package cannot be built
> See `config.log' for more details.
>
> Error:
> Configuring the editline-0.2.1.0 package failed
> make: *** [build.stamp] Error 2
>
> - Lyle
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Unable to install Haskell Platform without readline

[Lyle Kopnicky]

Hi folks,

I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to install
the Haskell Platform from source. It built quite a bit of stuff, with many
warnings but no errors, and then finally died with the error below.

To install editline, I need cabal, which is of course why I installed the
Platform. I read an earlier thread from May that said that editline came
with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be
updated. Now the web
sitefor the
Platform says it comes with 6.10.4, so I assumed it should work with
6.10.4, but apparently it still has this problem of still missing editline.

Am I doing something wrong?

checking editline/readline.h usability... no
checking editline/readline.h presence... no
checking for editline/readline.h... no
checking editline/editline.h usability... no
checking editline/editline.h presence... no
checking for editline/editline.h... no
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking for sign of read_history result on error... negative
checking for rl_completion_matches... no
checking for completion_matches... no
configure: error: editline not found, so this package cannot be built
See `config.log' for more details.

Error:
Configuring the editline-0.2.1.0 package failed
make: *** [build.stamp] Error 2

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

Re: [Haskell-cafe] RE: Darcs and NFS Resolution

[Jason Dagit]

Hi Darrell,

This message definitely also belongs on the darcs-us...@darcs.net mailing
list.  You can find information about how to subscribe here:
http://lists.osuosl.org/mailman/listinfo/darcs-users

Please join our list!  I'm adding the list to the CC list in my reply.

On Fri, Sep 11, 2009 at 9:20 AM, Lewis-Sandy, Darrell wrote:

> Thanks to everyone who pointed me in the right direction on this problem, I
> have been able to find a work around that allows me to push to an archive on
> a network file share.
>
> After some digging, I discovered the root of the problem.  Briefly,  Darcs
> uses the standard library System.Directory to perform file manipulations.
>  This library make use of compiler pragmas to conditionally compile either
> the Windows or Linux specific functions based on the host operating system.
>
> This approach assumes that when your operating system is a Linux variant,
> all your mounted volumes will natively support POSIX.  When you have mounted
> CIFS volumes, this will result in errors when calling those library
> functions to create, rename, copy and delete files or folders!   Given the
> flexibility of the Linux operating system, A more versatile implementation
> for System.Directory might be able to detect the file system of each volume
> at runtime and choose the appropriate functions to call.  But I digress...
>
> To workaround the inability to push to a CIFS volume in darcs, I modified
> the workaround.hs module to shell out to the OS's rename function rather
> than using the Haskell library's rename function.  Specifically:
>

Ah clever way to test this.


>
> I added the following code after the #else near line 80:
>
> renameFile :: FilePath -> FilePath -> IO ()
> renameFile old new = do
> ecode <- System.Cmd.rawSystem "mv" [old,new]
> case ecode of
> ExitSuccess -> return ()
> ExitFailure n -> putStrLn ("renameFile failed with exit code" ++
> show n)
>
> which ensures that when the operating system is not WIN32, that renaming of
> files will be performed by the OS shell.  I then added the System.Cmd module
> to the list of imports by inserting the following code near line 21
>
> import qualified System.Cmd(rawSystem)
>
> after a recompile I could push to a CIFS volume, for example:
>
> sudo darcs push /mnt/cifsvol
>
> this is an obvious hack, and does not address the inability to put to a
> CIFS share (put depends upon copyFile and would need to be hacked to
> shell-out as well).   Archives on the CIFS share have to be created by
> navigating to that folder and initializing.
>

Interesting.


>
> Shelling out is clearly a poor long term solution; a longer term solution
> would ideally introduce into the Haskell System.Directory library the
> ability to apply the correct functions transparently in accordance with the
> file system of the volume.
>

Yes, and in the meantime we can implement something like this in
workaround.hs.

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

Re: [Haskell-cafe] Essentials about type classes?

[Kim-Ee Yeoh]

Hi Fredrik,


Temaran wrote:
> 
> data Dar = Dar String String
>   deriving (Show, Eq)
> 
> class Bar a where
> foo :: a -> Int
> 
> instance Bar Dar where
> foo(Dar n c) = length c
> 
> but it keeps generating the same error;
> 
> ERROR "./Bar.hs":16 - Inferred type is not general enough
> *** Expression: foo
> *** Expected type : a -> Int
> *** Inferred type : Dar -> Int
> 

You're missing indentation. Instead of declaring foo as a member of the
typeclass, your code says it's a top-level function fully-polymorphic in the
first parameter. That's why defining it later as foo (Dar ...) gives the
error message it does.

-- 
View this message in context: 
http://www.nabble.com/Essentials-about-type-classes--tp25393728p25405022.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] Control.Exception base-3/base-4 woes

[Antoine Latter]

On Fri, Sep 11, 2009 at 10:42 AM, David Menendez wrote:
> On Fri, Sep 11, 2009 at 11:26 AM, Neil Brown  wrote:
>>
>> Can anyone tell me how to fix this?  I don't think that changing to always
>> use Control.Exception would fix this, because I need to give a different
>> type for catch in base-3 to base-4, so there's still the incompatibility to
>> be dealt with.
>
> I'd try using a cabal flag to set a CPP flag.
>
> E.g., from cabal
>
>    Flag Base3
>        Description: Use Version 3 of Base
>        Default: False
>
>    Library/Executable
>        if flag(Base3)
>            CPP-Options: -D _BASE_3_
>            Build-Depends: base >= 3 && < 4
>
>        else
>            Build-Depends: base >= 4 && < 5
>
> And then do,
>
>    #if _BASE_3_
>    import qualified Control.Exception as C
>    #else
>    import qualified Control.OldException as C
>    #endif
>

I've had success with this. See:

http://hackage.haskell.org/packages/archive/uuid/1.0.2/uuid.cabal

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

Re: [Haskell-cafe] Control.Exception base-3/base-4 woes

[Bulat Ziganshin]

Hello Neil,

Friday, September 11, 2009, 7:26:47 PM, you wrote:

i suggest you to import extensible-exceptions package instead - it's
available even for ghc 6.8. alternatively, you may import
old-exceptions package (or something like this). trying to develop code
compatible with both versions of exceptions should be a nightmare :D


> Hi,

> In my CHP library I need to do some exception catching.  I want the 
> library to work on GHC 6.8 (with base-3 -- this is the current version
> in Ubuntu Hardy and Jaunty, for example) and GHC 6.10 (which comes with
> base-4).  But base-3 and base-4 need different code for exception 
> catching (whether it's importing Control.OldException or giving a type
> to the catch method). 

> Here's what I currently do -- my Haskell file contains this:

> #if __GLASGOW_HASKELL__ >= 609
> import qualified Control.OldException as C
> #else
> import qualified Control.Exception as C
> #endif

> My cabal file contains this (it used to say just "base,..." but Hackage
> complained at me the other day when I tried to upload that):

> Build-Depends:   base >= 3 && < 5, ...

> This works on two machines: one is 6.8+base-3, the other is 
> 6.10+base-3&base-4, where cabal seems to use base-4.  However, I have 
> had a bug report (now replicated) which stems from a different 
> 6.10+base-3&base-4 machine where cabal picks base-3 instead.  The real
> problem is that the #if is based on GHC version, but really it should be
> based on which base-* library is being used.  I know the code works with
> base-3 (use Control.Exception) and base-4 (use Control.OldException) but
> I can't get the build process right to alter the code based on which 
> base-* library is being used.

> Can anyone tell me how to fix this?  I don't think that changing to 
> always use Control.Exception would fix this, because I need to give a 
> different type for catch in base-3 to base-4, so there's still the 
> incompatibility to be dealt with.

> Thanks,

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


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

[Haskell-cafe] RE: Darcs and NFS Resolution

[Lewis-Sandy, Darrell]

Thanks to everyone who pointed me in the right direction on this problem, I 
have been able to find a work around that allows me to push to an archive on a 
network file share.  

After some digging, I discovered the root of the problem.  Briefly,  Darcs uses 
the standard library System.Directory to perform file manipulations.  This 
library make use of compiler pragmas to conditionally compile either the 
Windows or Linux specific functions based on the host operating system.

This approach assumes that when your operating system is a Linux variant, all 
your mounted volumes will natively support POSIX.  When you have mounted CIFS 
volumes, this will result in errors when calling those library functions to 
create, rename, copy and delete files or folders!   Given the flexibility of 
the Linux operating system, A more versatile implementation for 
System.Directory might be able to detect the file system of each volume at 
runtime and choose the appropriate functions to call.  But I digress...

To workaround the inability to push to a CIFS volume in darcs, I modified the 
workaround.hs module to shell out to the OS's rename function rather than using 
the Haskell library's rename function.  Specifically:

I added the following code after the #else near line 80:

renameFile :: FilePath -> FilePath -> IO ()
renameFile old new = do
 ecode <- System.Cmd.rawSystem "mv" [old,new] 
 case ecode of
 ExitSuccess -> return ()
 ExitFailure n -> putStrLn ("renameFile failed with exit code" ++ show 
n) 

which ensures that when the operating system is not WIN32, that renaming of 
files will be performed by the OS shell.  I then added the System.Cmd module to 
the list of imports by inserting the following code near line 21

import qualified System.Cmd(rawSystem)
 
after a recompile I could push to a CIFS volume, for example:

sudo darcs push /mnt/cifsvol

this is an obvious hack, and does not address the inability to put to a CIFS 
share (put depends upon copyFile and would need to be hacked to shell-out as 
well).   Archives on the CIFS share have to be created by navigating to that 
folder and initializing.  

Shelling out is clearly a poor long term solution; a longer term solution would 
ideally introduce into the Haskell System.Directory library the ability to 
apply the correct functions transparently in accordance with the file system of 
the volume.  

Cheers
-Darrell Lewis-Sandy

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

Re: [Haskell-cafe] instance Monad (Either String) in Prelude or Data.Either?

[Evan Laforge]

On Fri, Sep 11, 2009 at 6:10 AM, Edward Kmett  wrote:
> Unfortunately, the instance of Monad for Either a is somewhat misguided in
> Haskell.
>
> There is a spurious restraint that the Left value in your Either be a member
> of some Error class, which was brought about by the deletion of MonadZero
> from Haskell 98 (as part of the elimination of failure free patterns, and an
> attempted simplification of the language).

I just tried it, and my own instance for Monad (Either String) (all
I'm really interested in anyway) can coexist with the one for Error e
=> Monad (Either e).  But indeed, with the presence of fail, you can't
write the general Monad (Either e) which "should" work.  And it does
require FlexibleInstances.  I suppose as long as flexible instances
aren't standard then even the String instance can't go in the Prelude.

> In theory, this is good, because you can then define your own monad instance
> for Either without that constraint -- if you don't care to exploit the Error
> instance's ability to get fail to work. Or you want a real Either monad for
> tricks like Oleg's recent post on the constructive law of excluded middle,
> or to talk about apomorphisms as a generalized anamorphism, parameterized on
> the either monad so it can be symmetrical to paramorphisms. In practice,
> you link in someone's code that links in the MTL, and then you're stuck
> using the MTL instance anyways.

Right.  I know there was some argument a while back, but I thought
that position that instances are global period was pretty "official".
At least it made sense to me.  The more libraries you import the less
control you have over the extent of what they may import.  But I guess
it wouldn't be haskell if every third person didn't have an idea for a
better way to implement the mtl...  I just want an exception with a
message though!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] adding state in GUIs (qtHaskell)

[Jeremy O'Donoghue]

Michael Mossey wrote:
> Duncan Coutts wrote:
>> On Wed, 2009-09-09 at 18:29 -0700, Michael P Mossey wrote:
>>> I'm trying to learn qtHaskell. I realize few people on this list
>>> know anything about qtHaskell, but I have a question that probably
>>> relates to all GUIs as implemented in Haskell. I just need a hint
>>> that could help me figure out the next step, which I might be able
>>> to infer from the qtHaskell API.
>>
>> Ultimately it's done by some kind of mutable state, either an IORef,
>> MVar or a thread.
In wxHaskell, the 'simplest' way to code this looks something like the
following (literate Haskell)

Structure containing 'state' of all of the GUI objects

> data UIState = UIState { uiConnect:: Button ()
>, uiPort   :: TextCtrl ()
>, uiUser   :: TextCtrl ()
>, uiPasswd :: TextCtrl ()
>, uiSandbox:: TextCtrl ()
>, uiClients:: ComboBox ()
>, uiChanges:: SingleListBox ()
>, uiChangeInfo :: TextCtrl ()
>, uiOrigin :: TextCtrl ()
>, uiUpdate :: TextCtrl ()
>, uiFrame  :: Frame ()
>}

> uiState = unsafePerformIO $ newMVar (Nothing :: Maybe UIState)

Ensure that we initialize exactly once...

> uiInitState bt pt us pw sb cl ci ch or up f =
> takeMVar uiState >>= \st ->
> case st of
>   Nothing -> let st' = UIState bt pt us pw sb cl ci ch or up f in
>  putMVar uiState (Just st')
>   Just _  -> return ()

Get the mutable state.
Note that in the error case we deliberately do not put the MVar back, as
a means
to block all threads waiting on the MVar (as this would indicate a general
programming/threading issue to be identified).

> getMVarState mv txt =
> takeMVar mv >>= \may_st ->
> case may_st of
>   Nothing -> error (txt ++ " is not available")
>   Just st -> putMVar mv may_st >>
>  return st

Fetch the UI state - this will fail fatally if we fetch before state is
initialized

> uiGetState = getMVarState uiState "UI state"

I don't have anything as neat to show you as Duncan's suggetion (I'd
also be interested to see a cleaner way to do it - this sort of code
always grates a little with me, although all of the major Haskell GUI
bindings seem to need a similar programming style.

However, at the most basic 'trying it out' level, I suspect that
something very like this will work just as well for qtHaskell as it does
for wxHaskell.
>> On top of these you can layer nicer stuff like a state monad (with a
>> 'runState' function that saves and restores from an IORef).
>>
>> A personal favourite of mine is having the GUI event handler post data
>> over a channel to a thread. That thread reads from the channel and deals
>> with the events. The state of the GUI app is then held as local
>> parameters in that thread.
>>
>> Doing this of course requires that the GUI lib you're using can cope
>> with normal Haskell (forkIO) threads. This is possible with gtk2hs, I
>> don't know about the others.
Regards
Jeremy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation

[Maurí­cio CA]

> The C library prints error messages to stderr. (...)

> Attached is the patch to the C levmar library.

Thanks for the file.

> The license issue is indeed a problem. Either your (linked +
> distributed) code must be GPL or you must acquire a different
> (commercial) license from the author of the C library.

I don't think the GPL is itself a problem, I just meant that by
packaging levmar with your bindings-levmar you probably have to
GPL bindings-levmar itself. Although, since you used BSD, I don't
think anyone will waste time bothering you about that.

> Lapack has to be installed on the hackage server in order for
> the package to build. Another option is to temporarily remove
> the dependency on lapack from the cabal file. (...). But the
> downside is that someone won't be able to cabal install it
> without first modifying the .cabal file. That is unacceptable in
> my opinion.

Yes, this is difficult to solve... I've even asked that some nice,
trusted C libraries could be installed on hackage so that we could
bind to them. Maybe this can be accepted in the future if the idea
of having many good quality bindings-* packages grow up.

In the mean time, we have a two-sided problem: if we release a
package with linking options removed we have to edit cabal file,
which is unacceptable in my opinion too; and if we do not, all
bindings-*, as well as all packages built on them, will be marked
with "Build failure" on hackage and lack documentation, which is
also unnaceptable...

The good thing is that this problem can be isolated on bindings-*
packages. If it is solved, it is solved once and for all. So far,
my solution has been this:

* to leave a 'pkg-config' line in bindings-* cabal file. This way,
your package can be used properly as long as your installed
library has pkg-config configuration, and this is easy to add
(even for your favorite distribution library package) if it
doesn't.

* to comment that pkg-config line, so that hackage will build your
package. Users can just add something like 'pkgconfig-depends: levmar'
to their own packages.

Though I have no reason to claim this is the best solution.

Also: bindings-common has some macros that could easy your job. You
could have used, for instance:

#bindings_frac LM_INIT_MU
#bindings_frac LM_STOP_THRESH
#bindings_frac LM_DIFF_DELTA

Although this would add a dependency, so I don't know if
it's worth.


Best,
Maurício

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

RE: [Haskell-cafe] Control.Exception base-3/base-4 woes

[Sittampalam, Ganesh]

Neil Brown wrote:

> Can anyone tell me how to fix this?  I don't think that changing to
> always use Control.Exception would fix this, because I need to give a
> different type for catch in base-3 to base-4, so there's still the
> incompatibility to be dealt with.   

http://hackage.haskell.org/package/extensible-exceptions ?

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Control.Exception base-3/base-4 woes

[David Menendez]

On Fri, Sep 11, 2009 at 11:26 AM, Neil Brown  wrote:
>
> Can anyone tell me how to fix this?  I don't think that changing to always
> use Control.Exception would fix this, because I need to give a different
> type for catch in base-3 to base-4, so there's still the incompatibility to
> be dealt with.

I'd try using a cabal flag to set a CPP flag.

E.g., from cabal

Flag Base3
Description: Use Version 3 of Base
Default: False

Library/Executable
if flag(Base3)
CPP-Options: -D _BASE_3_
Build-Depends: base >= 3 && < 4

else
Build-Depends: base >= 4 && < 5

And then do,

#if _BASE_3_
import qualified Control.Exception as C
#else
import qualified Control.OldException as C
#endif

-- 
Dave Menendez 

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

[Haskell-cafe] Control.Exception base-3/base-4 woes

[Neil Brown]

Hi,

In my CHP library I need to do some exception catching.  I want the 
library to work on GHC 6.8 (with base-3 -- this is the current version 
in Ubuntu Hardy and Jaunty, for example) and GHC 6.10 (which comes with 
base-4).  But base-3 and base-4 need different code for exception 
catching (whether it's importing Control.OldException or giving a type 
to the catch method). 


Here's what I currently do -- my Haskell file contains this:

#if __GLASGOW_HASKELL__ >= 609
import qualified Control.OldException as C
#else
import qualified Control.Exception as C
#endif

My cabal file contains this (it used to say just "base,..." but Hackage 
complained at me the other day when I tried to upload that):


Build-Depends:   base >= 3 && < 5, ...

This works on two machines: one is 6.8+base-3, the other is 
6.10+base-3&base-4, where cabal seems to use base-4.  However, I have 
had a bug report (now replicated) which stems from a different 
6.10+base-3&base-4 machine where cabal picks base-3 instead.  The real 
problem is that the #if is based on GHC version, but really it should be 
based on which base-* library is being used.  I know the code works with 
base-3 (use Control.Exception) and base-4 (use Control.OldException) but 
I can't get the build process right to alter the code based on which 
base-* library is being used.


Can anyone tell me how to fix this?  I don't think that changing to 
always use Control.Exception would fix this, because I need to give a 
different type for catch in base-3 to base-4, so there's still the 
incompatibility to be dealt with.


Thanks,

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

Re: [Haskell-cafe] Externally derive instance of Data?

[José Pedro Magalhães]

Hi Dimitry,

I think what you want is stand-alone deriving:
http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving


Cheers,
Pedro

On Fri, Sep 11, 2009 at 16:29, Dimitry Golubovsky wrote:

> Hi,
>
> Given a datatype defined somewhere in a third-party package, without
> deriving (Data) specified.
>
> Is it possible, in my module which is importing that datatype from
> that package, to auto-derive instance of Data for the said datatype?
> The goal is not to recompile the package just because an auto-derived
> instance is needed.
>
> Or no way other than to recompile the package?
>
> Thanks.
>
> --
> Dimitry Golubovsky
>
> Anywhere on the Web
> ___
> 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] Externally derive instance of Data?

[Dimitry Golubovsky]

Hi,

Given a datatype defined somewhere in a third-party package, without
deriving (Data) specified.

Is it possible, in my module which is importing that datatype from
that package, to auto-derive instance of Data for the said datatype?
The goal is not to recompile the package just because an auto-derived
instance is needed.

Or no way other than to recompile the package?

Thanks.

-- 
Dimitry Golubovsky

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

[Haskell-cafe] Re: Problem installing OpenGL

[Seb]

Think I've found the solution my self. If I download the packages and
make a small change in the .cabal-file everything seems to work fine
again.

All i had to do was replace "extra-libraries: GL" with "frameworks:
OpenGL". Not sure if this is the proper fix to make as I'm not any
good with cabal packages and how that works, but it worked for me.

On Sep 10, 5:25 pm, Seb  wrote:
> Hi,
>
> I'm having trouble installing OpenGL through cabal. It fails when it
> tries to install OpenGLRaw with this error message:
>
> cabal: Missing dependency on a foreign library:
> * Missing C library: GL
>
> I'm running OS X Leopard and have Xcode 3.1.3 installed. Do i have to
> install something separate or is cabal just not looking in the right
> places?
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.orghttp://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] instance Monad (Either String) in Prelude or Data.Either?

[Edward Kmett]

Unfortunately, the instance of Monad for Either a is somewhat misguided in
Haskell.

There is a spurious restraint that the Left value in your Either be a member
of some Error class, which was brought about by the deletion of MonadZero
from Haskell 98 (as part of the elimination of failure free patterns, and an
attempted simplification of the language).

In order to support the arguable misfeature of including 'fail' in Monad,
the Either instance for Monad has this extra constraint.

That in and of itself is only mildly annoying, but then to use that
constraint requires a multi-parameter type class for MonadError, which isn't
a Haskell 98 feature. So it isn't in the standard prelude, which tries to
limit itself to that which could be plausibly implemented as Haskell 98, but
instead sits off in one of the dozen or so monad transformer library
variants floating around.

In theory, this is good, because you can then define your own monad instance
for Either without that constraint -- if you don't care to exploit the Error
instance's ability to get fail to work. Or you want a real Either monad for
tricks like Oleg's recent post on the constructive law of excluded middle,
or to talk about apomorphisms as a generalized anamorphism, parameterized on
the either monad so it can be symmetrical to paramorphisms. In practice,
you link in someone's code that links in the MTL, and then you're stuck
using the MTL instance anyways.

-Edward Kmett
On Thu, Sep 10, 2009 at 9:03 PM, Evan Laforge  wrote:

> Is there any particular reason to not move the instance to the
> prelude?  A module was failing when imported from one place and ok
> when imported from another, so I spent a frustrating 10 minutes
> searching for the instance.  I couldn't find a way to search haddock
> for instances (not even grep on the html), nor hoogle, nor anything
> else.  Finally I turned to google and found a couple of haskell-cafe
> threads with people wondering why other people's code failed for them.
>  This was especially frustrating because I knew I had written my own
> instance when I originally couldn't find it, then removed my own when
> I did find it, then forgot where I found it *two times* so I knew it
> existed, just not where.  So this is the third time I've done this
> search.  Now I have a few commented 'import Control.Monad.Error ()'
> scattered about in a few "low level" modules to try to make sure it's
> visible everywhere and next time I go hunting I can look in my own
> modules.
>
> If orphan instances are discouraged, shouldn't the instance for Monad
> Either be declared where Either is?  This should probably go for
> Functor Either too.  I notice that Monad Maybe is in Prelude, and it
> would be a pain if it weren't.
>
> If there's no particular reason to not move it, I'll do a libraries
> proposal... or since it involves the prelude should this be
> haskell-prime?
> ___
> 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[2]: [Haskell-cafe] memoization

[Bulat Ziganshin]

Hello staafmeister,

Friday, September 11, 2009, 4:57:01 PM, you wrote:

> Here memo2 is a function that works like a combinator to obtain a memoized
> recursive function. However the type of the function depends on how I define
> it. In point-free style it gets the wrong
> type, however if I define (s2) with explicit arguments the type is correct?
> Do you know what happens here? I would expect the types to be the same.

looks like you need to pass -fno-monomorphism-restriction to ghci.
it's a "bug" of haskell definition, expected to be removed in the next
language version


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] memoization

[staafmeister]

Hi,

Investigating memoization inspired by replies from this thread. I
encountered something strange in the behavior of ghci. Small chance it's a
bug, it probably is a feature, but I certainly don't understand it :)

The interpreter session went as follows

GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> :load test_bug.hs
[1 of 1] Compiling Main ( test_bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> let s1 = memo2 solve2
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.1 ... linking ... done.
Loading package filepath-1.1.0.2 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.2 ... linking ... done.
Loading package unix-2.3.2.0 ... linking ... done.
Loading package directory-1.0.0.3 ... linking ... done.
Loading package process-1.0.1.1 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package haskell98 ... linking ... done.
*Main> :type s1
s1 :: [()] -> [()] -> ModP
*Main> let s2 a b = memo2 solve2 a b
*Main> :type s2
s2 :: (Eq t) => [t] -> [t] -> ModP

Here memo2 is a function that works like a combinator to obtain a memoized
recursive function. However the type of the function depends on how I define
it. In point-free style it gets the wrong
type, however if I define (s2) with explicit arguments the type is correct?
Do you know what happens here? I would expect the types to be the same.

Another question is: I use now makeStableName for equality but using this
function memoization does not work and it still takes a long (exponential?)
time to go through the codejam testcases. The memoization using data.map
works flawless.

Greetings,
Gerben

ps.

The content of test_bug.hs is

import Data.IORef
import System.IO.Unsafe
import Control.Exception
import qualified Data.Map as M
import Text.Printf
import qualified Data.HashTable as H
import System.Mem.StableName
import Data.Ratio
import Array

memo f = unsafePerformIO $ do
  cache <- H.new (==) (H.hashInt . hashStableName)
  let cacheFunc = \x -> unsafePerformIO $ do stable <- makeStableName x
 lup <- H.lookup cache stable
 case lup of
   Just y -> return y
   Nothing -> do let res = f
cacheFunc x
 H.insert cache
stable res
 return res
  return cacheFunc

memo2 f = curry $ memo (\g (x,y) -> f (curry g) x y)

newtype ModP = ModP Integer deriving Eq

p=10007

instance Show ModP where
  show (ModP x) = printf "%d" x

instance Num ModP where
  ModP x + ModP y = ModP ((x + y) `mod` p)
  fromInteger x = ModP (x `mod` p)
  ModP x * ModP y = ModP ((x * y) `mod` p)
  abs = undefined
  signum = undefined

solve2 f _ [] = 1::ModP
solve2 f [] _ = 0::ModP
solve2 f (hs:ts) t@(ht:tt) | hs==ht = f ts tt + f ts t
   | otherwise = f ts t

go (run, line) = "Case #"++show run++": "++show ((memo2 solve2) line
"welcome to code jam")

main = interact $ unlines . map go . zip [1..] . tail . lines

-- 
View this message in context: 
http://www.nabble.com/memoization-tp25306687p25400506.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] adding state in GUIs (qtHaskell)

[Roman Cheplyaka]

* Duncan Coutts  [2009-09-10 20:43:54+]
> A personal favourite of mine is having the GUI event handler post data
> over a channel to a thread. That thread reads from the channel and deals
> with the events. The state of the GUI app is then held as local
> parameters in that thread.
> 
> Doing this of course requires that the GUI lib you're using can cope
> with normal Haskell (forkIO) threads. This is possible with gtk2hs, I
> don't know about the others.

I also would be happy to see some code. Recently I need to write a small
app in gtk2hs which had to deal with state. I used Reader monad with
IORef's in it, but got tired of mixing code in different monads. (It
would help, btw, if gtk2hs functions were not in IO, but in MonadIO).

So I'm curious how 'gtk2hs app done right' looks like.

-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANNOUNCE: A Levenberg-Marquardt implementation

[Roel van Dijk]

>> * http://hackage.haskell.org/package/bindings-levmar-0.1
>
> Which were the changes you needed to do to the library code? I
> believe this is going to cause you two problems: maintenance (as
> you can't always be sure the patched version didn't introduce a
> bug) and license (as levmar is GPL. You can't distribute it linked
> to non GPL code).
The C library prints error messages to stderr. We can check some
things before calling the C functions to ensure that some erroneous
conditions do not occur, but we can't prevent all cases. Since the
functions already returned a generic error code we disabled all
printing to stderr and created an enumeration of error codes. In
Haskell we wrap this error code in a nice data type so if something
goes wrong you'll know why. We have send a patch with these changes to
the author and we are waiting for a reply.

The license issue is indeed a problem. Either your (linked +
distributed) code must be GPL or you must acquire a different
(commercial) license from the author of the C library. The benefits of
the library we have chosen for this binding is that it is small, just
a few .c files, and it has almost no dependencies. If anyone knows of
any other implementations of Levenberg-Marquardt that are also easy to
bind then we would certainly like to hear it. If the feature set is
not to different we might be able to provide a common interface.

>> * http://hackage.haskell.org/package/levmar-0.1
>
> Cool.
>
> Don't you think the type level natural numbers deserve their own
> package?
Perhaps in the future. For this release we just focused on levmar. We
might also use another package for type level programming if it suits
our needs.

>> Unfortunately the documentation of these libraries is not
>> available from hackage because bindings-levmar won't configure
>> because of a missing dependency (lapack) on the hackage server.
>
> I'll try to write you a patch to solve that after I study better
> your code.
Lapack has to be installed on the hackage server in order for the
package to build. Another option is to temporarily remove the
dependency on lapack from the cabal file. The package would probably
build, you just wouldn't be able to link against it. But the downside
is that someone won't be able to cabal install it without first
modifying the .cabal file. That is unacceptable in my opinion.


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