Re: [Haskell-cafe] Heads Up: code.haskell.org is upgrading to darcs 2

2008-09-11 Thread Henning Thielemann


On Wed, 10 Sep 2008, Duncan Coutts wrote:


Furthermore, we have done real world tests using copies of all the 153
repositories on code.haskell.org which comes to around 2GB.

We wanted to verify a couple things:
1. that using darcs 1 on the client and darcs 2 on the server works
   fine to pull and push patches. This corresponds to a project
   where all the users are still using darcs 1.
2. that using a mixture of darcs 1 and darcs 2 clients works when
   pushing and pulling patches between the clients via the server.
   This corresponds to a project where some users have upgraded but
   others have not yet.

We tested with darcs 1.0.9 and 2.0.2 in three combinations:
 client darcs 1, server darcs 1
 client darcs 1, server darcs 2
 client darcs 2, server darcs 2

The test consisted of obliterating a significant number of patches from
each repository and pushing them back. In a separate experiment each
repository was converted to darcs v2 format which worked without problem
in every case.


Many thanks for the extensive testing! It's crucial to do that before 
facing code.haskell.org users with this major change.

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


[Haskell-cafe] Re: [Haskell] Heads Up: code.haskell.org is upgrading to darcs 2

2008-09-11 Thread Eric Y. Kow
 We are upgrading /usr/bin/darcs to version 2 on the machine that hosts
 code.haskell.org.
 
 That means it will be used by everyone who uses ssh to push or pull from
 a darcs repository on code.haskell.org. Pulling via http is completely
 unaffected.

Thanks Duncan!  Now my hope is that we can encourage the good folk at
Galois to make a similar upgrade for darcs.haskell.org

-- 
Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow
PGP Key ID: 08AC04F9


pgpqsdDI8O6LU.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] typeclass question

2008-09-11 Thread Tim Docker
I have a typeclass related question that I have been puzzling over.

In a library I am working on, I have a series of functions for
converting values to Renderables:

| labelToRenderable :: Label - Renderable
| legendToRenderable :: Legend - Renderable
| axisToRenderable :: Axis v - Renderable
| layoutToRenderable :: Layout x y - Renderable

These names are overloaded for convenience via a typeclass:

| class ToRenderable a where
|   toRenderable :: a - Renderable
|
| instance ToRenderable Label where
|   toRenderable = labelToRenderable
| ...

But some recent changes mean that Renderable needs to become a type
constructor, and the functions now product different types:

| labelToRenderable :: Label - Renderable ()
| legendToRenderable :: Legend - Renderable String
| axisToRenderable :: Axis v - Renderable ()
| layoutToRenderable :: Layout x y a - Renderable a

Is there a nice way to overload a toRenderable function for these?
Something like this is possible:

| class ToRenderable a b where
|   toRenderable :: a - Renderable b

But the above is, I think, too general for my needs. I don't want
to be able to generate Renderables of different type b for a single input
type a.

Also, MPTC take me out of the world of haskell 98, which I was trying
to avoid. Am I missing something simple?

Any pointers would be much appreciated.

Tim


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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Johannes Waldmann

 | class ToRenderable a b where
 |   toRenderable :: a - Renderable b
 
 But the above is, I think, too general for my needs. I don't want
 to be able to generate Renderables of different type b for a single input
 type a.

Sounds like a functional dependency (class ToReadable a b | a - b )

 Also, MPTC take me out of the world of haskell 98, which I was trying
 to avoid. 

Why. Everyone does it,
and MPTC will be in Haskell-Prime  (but FD may be not)
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma

J.W.



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Henning Thielemann


On Thu, 11 Sep 2008, Tim Docker wrote:


I have a typeclass related question that I have been puzzling over.

In a library I am working on, I have a series of functions for
converting values to Renderables:

| labelToRenderable :: Label - Renderable
| legendToRenderable :: Legend - Renderable
| axisToRenderable :: Axis v - Renderable
| layoutToRenderable :: Layout x y - Renderable

These names are overloaded for convenience via a typeclass:


I think that type classes are not for keystroke reduction, but for writing 
generic algorithms. If there is no algorithm that becomes more generic by 
the use of a type class, I would not use a type class, but stick to 
labelToRenderable and friends.

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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Tim Docker
 Also, MPTC take me out of the world of haskell 98, which I was trying
 to avoid.

 Why. Everyone does it,

Well, it's a library that others might use, so I would prefer to avoid
using language extensions, especially functional deps which I don't
understand, and which seem to have an uncertain future.

Tim

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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Johannes Waldmann
(Henning:)

 If there is no algorithm that becomes more generic by the use of a type
class,
 I would not use a type class, but stick to labelToRenderable [...]

The problem with function names as labelToRenderable
is that they have type information as part of the name.

Consistency of that information cannot be enforced by the language,
which makes it dangerous.

If you want type information
(e.g. to resolve overloading, for the compiler - and for the reader!)
use the language, and write a type annotation.

J.W.




signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Johannes Waldmann

 Well, it's a library that others might use, so I would prefer to avoid
 using language extensions, especially functional deps which I don't
 understand, and which seem to have an uncertain future.

I think there will be a storm of protest
if support for this simple shape of dependencies ( ... | a - b )
would be dropped from the major Haskell implementations.

(There used to be some status page on what compiler
supports what extension, anyone know the current location for that?)

J.W.



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Haskell and Java

2008-09-11 Thread Mauricio

 Sorry about this. I hit a critical mass of darcs conflicts (I look
 forward to giving git a try) around the same time I got really busy at
 work. I've been meaning to get back into it (and update it to GHC HEAD)
 but I haven't received sufficient nagging yet. Please yell if you're
 interested in LambdaVM. At the very least I should be able to help get
 whatever is in darcs compiling.

Would it allow allow Haskell to also call Java code,
besides running in JVM?

I think I'm not enough to nag you alone.



If you're looking for more people to nag you... I'm working on a 
compiler for a new declarative language. Right now we're using Haskell 
for a proof-of-concept interpreter, though one of the near-term goals 
for the compiler itself is a Java FFI/backend. Since much of the 
language is in the runtime engine, it'd be a shame to have to rewrite it 
all in Java or deal with the horror of JNI.




We can use this page, already pointed
on this thread:

http://haskell.org/haskellwiki/Applications_and_libraries/Interfacing_other_languages#Java

We could add something like if you want something
working regarding the interaction between Haskell
and Java, please nag Brian Alliet at [EMAIL PROTECTED]

Best,
Maurício

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


Re: [Haskell-cafe] Haskell as a scripting language.

2008-09-11 Thread Chaddaï Fouché
2008/9/10 David F. Place [EMAIL PROTECTED]:
 Hi, All.

 I needed to make a batch of edits to some input files after a big change
 in my program.  Normally, one would choose some scripting language, but
 I can't bear to program in them.   The nasty thing about using Haskell
 is that giving regexes as string constants sometime requires two levels
 of quoting.  For instance. (mkRegex ) matches \\.


Since some times in the HEAD and in the future 6.10 release, you can
use quasiquoting to get nice regex syntax as in Perl or Ruby.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexqq

(quasiquoting basically allows you to embed a DSL with significantly
different syntax in your Haskell and still get typechecking and other
advantages at compile-time (though I imagine the errors won't be very
nice).

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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Jonathan Cast
On Thu, 2008-09-11 at 13:23 +0200, Johannes Waldmann wrote:
  Well, it's a library that others might use, so I would prefer to avoid
  using language extensions, especially functional deps which I don't
  understand, and which seem to have an uncertain future.
 
 I think there will be a storm of protest
 if support for this simple shape of dependencies ( ... | a - b )
 would be dropped from the major Haskell implementations.

For backwards-compatibility reasons, or because you think they're better
than type families?

Personally, I am quite enthusiastic about type families, although that
is influenced by a (somewhat abandoned) project of mine that ended up
with a 3 parameter type class (5 for the sub-class created for
quickCheck support) with one-to-one relations every way.  And multiple
`global' variables implemented with dynamic parameters (they would have
needed to be thread-local, eventually, anyway) with types parameterized
on the afore-mentioned 3 parameters plus two more to allow the choice
between ST and STM.  When you get types like this:

 -- | Wait for another thread to change the buffer contents.
 displayWaitRedisplay :: (Buffer b d mk,
   ?currentBuffer :: BufferState b d mk STM
TVar,
   ?currentWindow :: Window b d mk c STM TVar)
  = b TVar - STM ()

types like this:

 -- | Wait for another thread to change the buffer contents.
 displayWaitRedisplay :: (Buffer b, ?currentBuffer :: BufferState b STM,
  ?currentWindow :: Window b c STM)
  = b TVar - STM ()
 
look like heaven.

jcc


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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Johannes Waldmann



if support for this simple shape of dependencies ( ... | a - b )  ...


For backwards-compatibility reasons, 


Yes.


or because you think they're better than type families?


Don't know (haven't used them).

Concrete example: I have  this class Partial p i b | p i - b
http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/tool/src/Challenger/Partial.hs?rev=1.28

What would type families buy me here?

In my code, this class has tons of instances (I count 80).
How much would I need to change them? Could this be automated?

Thanks - J.W.




signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Jonathan Cast
On Thu, 2008-09-11 at 18:34 +0200, Johannes Waldmann wrote:
  if support for this simple shape of dependencies ( ... | a - b )  ...
 
  For backwards-compatibility reasons, 
 
 Yes.

This gives point, then, to my concerns about letting Haskell become a
practical language.  At some point, production systems always seem to be
end-of-lifed by backwards compatibility.

  or because you think they're better than type families?
 
 Don't know (haven't used them).
 
 Concrete example: I have  this class Partial p i b | p i - b
 http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/tool/src/Challenger/Partial.hs?rev=1.28
 
 What would type families buy me here?

I can't figure out what b is.  I could, of course, argue that it would
force you to come up with a name for `b', so people reading the code
could understand what it does.

 In my code, this class has tons of instances (I count 80).
 How much would I need to change them?

   instance Partial p i b where
= instance Partial p i
 type B p i = b

And type signatures involving Partial would have to change.

  Could this be automated?

To a certain extent.  Finding the places that need to change could be
automated, which is always the first step :)

jcc


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


Re: [Haskell-cafe] typeclass question

2008-09-11 Thread Iavor Diatchki
Hi Tim,
Your example seems like a perfect fit for functional dependencies.

On Thu, Sep 11, 2008 at 3:36 AM, Tim Docker [EMAIL PROTECTED] wrote:
 Well, it's a library that others might use, so I would prefer to avoid
 using language extensions, especially functional deps which I don't
 understand, and which seem to have an uncertain future.

I completely agree with you that it is a good idea to stick to
Haskell'98 when you can, especially in library code, so you'll have to
decide if you really want to use the class.  As for not understanding
functional dependencies, it sounds like you are not giving yourself
enough credit.  Your previous comment basically contains the
definition of a functional dependency:

| But the above is, I think, too general for my needs. I don't want
| to be able to generate Renderables of different type b for a single input
| type a.

This is all there is to a fun. dep., from a programmer's
perspective---it adds a constraint on the instances one can declare
for a given multi-parameter type class.

Hope this helps,
-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Windows details

2008-09-11 Thread Jeff Zaroyko
Andrew Coppin andrewcoppin at btinternet.com writes:

 
 Steve Schafer wrote:
  Version information and application icons are both stored in data
  structures called resources; these are appended to the executable
  portion of the application, inside the EXE file. 

 
 Thanks for your input. I'm now playing with XN Resource Editor. Getting 
 the version information to work correctly appears to be tricky, but 
 everything else seems quite straight forward...
 

In theory, you should be able to use mingw's windres tool to produce an object
file from the resource definition which you'd link with the rest of your 
program.

http://www.mingw.org/MinGWiki/index.php/MS resource compiler

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


Re: [Haskell-cafe] Re: Windows details

2008-09-11 Thread Andrew Coppin

Jeff Zaroyko wrote:

In theory, you should be able to use mingw's windres tool to produce an object
file from the resource definition which you'd link with the rest of your 
program.

http://www.mingw.org/MinGWiki/index.php/MS resource compiler
  


Yes, there's a cryptic comment burried away in the GHC manual that says 
GHC itself already uses windres to embed the manifest file into the 
compiled binary file. (And sure enough, if you crawl through with a hex 
editor you'll find the raw XML in there.) There's an option to tell GHC 
to not do this - however, I don't see any option anywhere to tell it to 
embed a *different* resource file instead. And frankly, the linker 
command looks frightening. (For starters, it's 6 pages long. I'm not 
kidding!)


XN Resource Editor makes adding an icon child's play. (Interestingly, 
this also becomes the default window icon without any further action, 
which is nice.) However, either XN nor Resource Hack are able to embedd 
correct version info. And both of them crash quite a lot. (Even more 
interestingly, XN seems to make GHC-compiled binary files dramatically 
*smaller*... huh??)


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


Re: [Haskell-cafe] Re: Haskell and Java

2008-09-11 Thread Brian Alliet
On Wed, Sep 10, 2008 at 09:50:36PM -0300, Mauricio wrote:
 Would it allow allow Haskell to also call Java code,
 besides running in JVM?

Yep. LambdaVM can fully access existing Java code. The base library
heavily uses FFI to access java.io.* to implement Handle, etc. 'foreign
export' even works so you can call back into Haskell from Java. For
more information see:

http://wiki.brianweb.net/LambdaVM/FFI

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


Re: [Haskell-cafe] Haskell and Java

2008-09-11 Thread Andrew Coppin

Marc Weber wrote:

There used to be.
http://www.cs.rit.edu/~bja8464/lambdavm/
  


My God... so it exists already?

Heh, and to think I was going to try to implement this... ;-)

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


[Haskell-cafe] Re: Windows details

2008-09-11 Thread Jeff Zaroyko
Andrew Coppin andrewcoppin at btinternet.com writes:

 
 Jeff Zaroyko wrote:
  In theory, you should be able to use mingw's windres tool to produce
  an object file from the resource definition which you'd link with 
  the rest of your program.
 
 
 Yes, there's a cryptic comment burried away in the GHC manual that says 
 GHC itself already uses windres to embed the manifest file into the 
 compiled binary file. (And sure enough, if you crawl through with a hex 
 editor you'll find the raw XML in there.) There's an option to tell GHC 
 to not do this - however, I don't see any option anywhere to tell it to 
 embed a *different* resource file instead. 

All I meant by linking is including the object file when you invoke ghc.

windres foo.rc -o foores.o
ghc bar.hs foo.o

-Jeff

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


[Haskell-cafe] Re: mailing list choices?

2008-09-11 Thread Peter Hercek

Did Yahoo  Google groups add support for NNTP yet?
In past this did not work.
If it still does not work then this would be one reason
 to prefer something which works with gmane.

Peter.

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


[Haskell-cafe] compiling ghc-6.8.3: unrecognized command line option -fconfigure-option= (SOLVED)

2008-09-11 Thread Poor Yorick
For anyone who might experience the same problem...

Intalling ghc-6.8.3, the following error occurred:

make -C libraries all
make[1]: Entering directory `/path/to/src/gh
c-6.8.3/ghc-6.8.3/libraries'

rm -f -f stamp/configure.library.*.base base/unbuildable
( cd base  setup/Setup configure \
--enable-library-profiling --enable-split-objs \
   --prefix=/NONEXISTANT \
   --bindir=/NONEXISTANT \
   --libdir=/NONEXISTANT \
   --libsubdir='$pkgid' \
   --libexecdir=/NONEXISTANT \
   --datadir=/NONEXISTANT \
   --docdir=/NONEXISTANT \
   --htmldir=/NONEXISTANT \
   --interfacedir=/NONEXISTANT \
   --with-compiler=../../compiler/stage1/ghc-inplace \
   --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \
   --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \
   --with-ld=/path/to/bin/ld \  

   --haddock-options=--use-contents=../index.html \
   --use-index=../doc-index.html \
  --configure-option='--prefix=/path/to/ghc-6.8.3'
  --configure-option='CC=gcc -m32'
  --configure-option='LDFLAGS=-Wl,-rpath,/path/to/lib
  -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags
  -L/path/to/lib -L/path/to/lib64
  --configure-option='
  --configure-option='CPPFLAGS=-I/path/to/include
  --configure-option=' \ 
   --configure-option=--with-cc=gcc ) \
   touch stamp/configure.library.build-profiling-splitting.base
  || touch base/unbuildable 

Configuring base-3.0.2.0...
configure: WARNING: Unrecognized options: --with-hc, --with-hc-pkg
checking for gcc... gcc
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.


config.log showed this:


configure:2171: checking for C compiler default output file name
configure:2193: gcc  -I/path/to/include  --configure-option= 
-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags 
-L/path/to/lib -L/path/to/lib64--configure-option= conftest.c  5
cc1: error: unrecognized command line option -fconfigure-option=
cc1: error: unrecognized command line option -fconfigure-option=
configure:2197: $? = 1
configure:2235: result: 
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME Haskell base package
| #define PACKAGE_TARNAME base
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING Haskell base package 1.0
| #define PACKAGE_BUGREPORT [EMAIL PROTECTED]
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2242: error: C compiler cannot create executables
See `config.log' for more details.

##  ##
## Cache variables. ##
##  ##

ac_cv_env_CC_set=set
ac_cv_env_CC_value='gcc -m32'
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value='-I/path/to/include  --configure-option='
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 
-Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64--configure-option='
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_prog_ac_ct_CC=gcc

## - ##
## Output variables. ##
## - ##

CC='gcc'
CFLAGS=''
CPP=''
CPPFLAGS='-I/path/to/include  --configure-option='
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
GREP=''
LDFLAGS='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 
-Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64--configure-option='
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
OBJEXT=''
PACKAGE_BUGREPORT='[EMAIL PROTECTED]'
PACKAGE_NAME='Haskell base package'
PACKAGE_STRING='Haskell base package 1.0'
PACKAGE_TARNAME='base'
PACKAGE_VERSION='1.0'
PATH_SEPARATOR=':'
SHELL='/bin/sh'
ac_ct_CC='gcc'
bindir='/NONEXISTANT'
build_alias=''
datadir='/NONEXISTANT'

Re: [Haskell-cafe] Re: Windows details

2008-09-11 Thread Steve Schafer
On Thu, 11 Sep 2008 20:24:24 +0100, you wrote:

XN Resource Editor makes adding an icon child's play. (Interestingly, 
this also becomes the default window icon without any further action, 
which is nice.)

That's how Windows works: If an EXE contains at least one icon, then the
first icon is used by default.

However, either XN nor Resource Hack are able to embedd correct version
info.

The VERSIONINFO resource is actually rather complicated internally. In
particular, the value that we think of as the version number (e.g.,
1.2.3.456) is stored in two different formats (binary integer and
string) in at least four different places, depending on how many
languages are supported in the resource (file version as integer,
product version as integer, and one each of file version as string and
product version as string for each language). I don't recall offhand
which one of these is what you see reported in the Properties dialog,
but it's quite possible that you're setting the value of the wrong
one, and that's why you're not seeing what you expect.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Connecting to wireless network

2008-09-11 Thread Marco Túlio Gontijo e Silva
Hello,

I've made a small program[0] to connect to a wireless network.  Comments are
welcome.

Greetings.

0: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/n-m

-- 
Marco Túlio Gontijo e Silva
Página: http://marcotmarcot.iaaeee.org/
Blog: http://marcotmarcot.blogspot.com/
Correio: [EMAIL PROTECTED]
XMPP: [EMAIL PROTECTED]
IRC: [EMAIL PROTECTED]
Telefone: 25151920
Celular: 98116720
Endereço:
  Rua Turfa, 639/701
  Prado 30410-370
  Belo Horizonte/MG Brasil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Can you do everything without shared-memory concurrency?

2008-09-11 Thread Aaron Denney
On 2008-09-10, David Roundy [EMAIL PROTECTED] wrote:
 On Wed, Sep 10, 2008 at 03:30:50PM +0200, Jed Brown wrote:
 On Wed 2008-09-10 09:05, David Roundy wrote:
  I should point out, however, that in my experience MPI programming
  involves deadlocks and synchronization handling that are at least as
  nasty as any I've run into doing shared-memory threading.

 Absolutely, avoiding deadlock is the first priority (before error
 handling).  If you use the non-blocking interface, you have to be very
 conscious of whether a buffer is being used or the call has completed.
 Regardless, the API requires the programmer to maintain a very clear
 distinction between locally owned and remote memory.

 Even with the blocking interface, you had subtle bugs that I found
 pretty tricky to deal with.  e.g. the reduce functions in lam3 (or was
 it lam4) at one point didn't actually manage to result in the same
 values on all nodes (with differences caused by roundoff error), which
 led to rare deadlocks, when it so happened that two nodes disagreed as
 to when a loop was completed.  Perhaps someone made the mistake of
 assuming that addition was associative, or maybe it was something
 triggered by the non-IEEE floating point we were using.  But in any
 case, it was pretty nasty.  And it was precisely the kind of bug that
 won't show up except when you're doing something like MPI where you
 are pretty much forced to assume that the same (pure!) computation has
 the same effect on each node.

Ah, okay.  I think that's a real edge case, and probably not how most
use MPI.  I've used both threads and MPI; MPI, while cumbersome, never
gave me any hard-to-debug deadlock problems.

-- 
Aaron Denney
--

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


Re: [Haskell-cafe] Linker Errors For OpenGL / GLUT 'Hello World' Program.

2008-09-11 Thread Brandon S. Allbery KF8NH

On 2008 Sep 12, at 0:24, Donnie Jones wrote:
I am trying to test do some OpenGL / GLUT programming in Haskell,  
but I had linker issues testing the 'Hello World' OpenGL Haskell  
program.  I believe the linker issues were caused because the  
Haskell GLUT package couldn't find the GLUT C libraries that were  
installed with Debian packages.  I have tested that my OpenGL  
install does work with

(...)

checking for GLUT library... no


You need to check config.log from the Haskell GLUT build to see why it  
couldn't find (or possibly couldn't link with) the GLUT library.


--
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