#1056: Visual Haskell, 0.2 build hangs
---+
Reporter: kr.angelov | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler|
#1056: Visual Haskell, 0.2 build hangs
+---
Reporter: kr.angelov | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler|
#1056: Visual Haskell, 0.2 build hangs
+---
Reporter: kr.angelov | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component:
#804: Signal handlers always installed, evem in a DLL
--+-
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
#886: Profiling doesn't work with -threaded
+---
Reporter: Lemmih | Owner:
Type: task| Status: new
Priority: normal | Milestone:
#946: Complete and integrate a tags and module-graph analyser using the GHC API
--+-
Reporter: simonpj | Owner:
Type: task | Status: new
Priority: normal|
#932: Improve inlining
--+-
Reporter: simonpj | Owner: simonpj
Type: task | Status: new
Priority: normal| Milestone: 6.8
Component: Compiler |Version: 6.4.2
#879: Merge GHCi.debugger patches
--+-
Reporter: mnislaih | Owner: mnislaih
Type: task | Status: closed
Priority: normal| Milestone: 6.8
Component:
#954: internal error: scavenge_mark_stack: unimplemented/strange closure type 28
@ 0xaffe7500
+---
Reporter: guest | Owner:
Type: bug | Status: closed
Priority:
#1057: Implicit parameters on breakpoints
-+--
Reporter: mnislaih | Owner:
Type: bug | Status: new
Priority: normal|
#1057: Implicit parameters on breakpoints
+---
Reporter: mnislaih| Owner: mnislaih
Type: bug | Status: assigned
Priority: normal
#1058: Highlight matching parantheses in Visual Studio
+---
Reporter: m4dc4p | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
#1058: Highlight matching parantheses in Visual Studio
-+--
Reporter: m4dc4p | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
#1059: Control.Monad.Identity documentation
--+-
Reporter: Andriy | Owner:
Type: proposal | Status: new
Priority: normal | Milestone:
| it works as expected. which is why I think that the type should be:
|
| f :: forall t. ((forall b. C t b) = t - t)
|
| or, bringing the quantifiers to the front:
|
| f :: forall t. exists b. (C t b = t - t)
My brain is too small to figure out the consequences of adding first-class
Hello,
The same oddity with type checking can happen in Haskell 98 as well:
http://www.mail-archive.com/haskell@haskell.org/msg06754.html
-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Hello Haskellers,
GHC Trac has a Visual Haskell category. Please report all bugs and
feature requests using it.
Cheers,
Krasimir
On 12/8/06, Krasimir Angelov [EMAIL PROTECTED] wrote:
Hello Haskellers,
The final version of Visual Haskell 0.2 is ready:
http://www.haskell.org/visualhaskell
Hi Krasimir,
On Mon, 18 Dec 2006 17:17:25 +0900, Krasimir Angelov [EMAIL PROTECTED] wrote:
GHC Trac has a Visual Haskell category. Please report all bugs and
feature requests using it.
Where we have to post release engineering bug?
You agreed with including GLUT, readline, OpenAL and ALUT
Announcing vty, a very simple terminal interface library.
In 150 non-blank non-comment lines of Haskell (and 7 lines of C) vty
provides:
* Automatic handling of suspend/resume (SIGTSTP+SIGCONT)
* Automatic handling of window resizes
* Automatic computation of minimal differences
* Minimizes
| Is that an intrinsic feature of the language, or could compilers'
| optimisation plausibly get clever enough to do well without lots of
| seq
| and explicit unboxings and suchlike?
|
| I believe that compilers can get a lot cleverer - my hope is that one
| day the natural Haskell definition
Hi,
dons mentions in his blog post that Data.Map’s lookup is generalized
over the Monads, whereas Prelude.maybe isn’t. Are there good reasons not
to do that to Prelude.maybe as well?
Alternatively, how about adding this function to Data.Maybe, analogous
to maybeToList
maybeToM Nothing = fail
Bulat Ziganshin wrote:
Hello Waldemar,
Sunday, December 17, 2006, 2:44:28 AM, you wrote:
Maybe, but what is still unclear for me: Haskell is wrong for GUI/Database
application because of lack of good libraries or because of it's way of
programming???
primarily, first. to some degree,
OK, after years of looking and discussing and doing HSoE exercises, I
have finally decided that Haskell is far enough into practical
usefulness that I should give it a try in a real project.
The basic idea is a browser game - this touches all the potentially hard
issues without miring me too
On Mon, 18 Dec 2006, Donald Bruce Stewart wrote:
P.S. The comments on this thread makes me think that the state of the
art high perf programming in Haskell isn't widely known.
Very true. I really like to know some more clean tricks for speedup.
___
Hello David,
Monday, December 18, 2006, 6:00:29 AM, you wrote:
My trouble is that I really don't understand the limitations on FDs, which
as I understand it is why Simon P.J. opposes adding them to Haskell':
they're hard to understand.
ghc 6.6 user manual contains great introduction into FD
On Mon, Dec 18, 2006 at 09:29:24AM +, Joachim Breitner wrote:
dons mentions in his blog post that Data.Map???s lookup is generalized
over the Monads, whereas Prelude.maybe isn???t. Are there good reasons not
to do that to Prelude.maybe as well?
I can't see how such a generalization could
Hiya folks,
I got slightly annoyed at having to tab beyond .hi files when editing
haskell code with vim, so I decided to wrap some stuff together in a
haskell
file type plugin. It has some preliminary (read: very stupid) folding
support,
and allows you to call out to ghci easily to get type
Hi,
Am Montag, den 18.12.2006, 17:42 +0100 schrieb Tomasz Zielonka:
On Mon, Dec 18, 2006 at 09:29:24AM +, Joachim Breitner wrote:
dons mentions in his blog post that Data.Map???s lookup is generalized
over the Monads, whereas Prelude.maybe isn???t. Are there good reasons not
to do that
On Mon, Dec 18, 2006 at 04:59:45PM +, Joachim Breitner wrote:
Well, that???s a possible implementation of a maybeToM. The question is:
Is it useful enough for a name on it???s own?
...and for putting it in Prelude?
It would be interesting to try to estimate the number of functions
useful
I can't see how such a generalization could look like, especially since
maybe can be used with arbitrary monad:
maybe (fail Nothing) return
Well, that???s a possible implementation of a maybeToM. The question is:
Is it useful enough for a name on it???s own?
I thought it was useful
Hi,
Am Montag, den 18.12.2006, 18:12 +0100 schrieb Tomasz Zielonka:
On Mon, Dec 18, 2006 at 04:59:45PM +, Joachim Breitner wrote:
Well, that???s a possible implementation of a maybeToM. The question is:
Is it useful enough for a name on it???s own?
...and for putting it in Prelude?
Hi,
Am Montag, den 18.12.2006, 09:22 -0800 schrieb Stefan O'Rear:
module Data.Generics.Serialization.Standard ...
-- |Convert a 'Maybe' object into any monad, using the imbedding defined by
-- fail and return.
fromMaybeM :: Monad m = String - Maybe a - m a
fromMaybeM st = maybe (fail st)
Hello Simon,
Monday, December 18, 2006, 12:08:49 PM, you wrote:
My view is that Haskell's performance is very seldom the limiting factor
of course. when someone said about GPG i just mentioned that this project
may be hihgly speed-dependent and this case Haskell is definitely not the
solution
Hello ajb,
Monday, December 18, 2006, 4:12:01 AM, you wrote:
time. For example, for certain types of problem, Haskell minimises the
amount of time between the point where I start typing and the point where
I have the answer.
of course, we can fool any topic by changing the names. no one
Hello Donald,
Monday, December 18, 2006, 3:51:48 AM, you wrote:
Haskell can't provide fast execution speed unless very low-level
programming style is used (which is much harder to do in Haskell than in C,
see one of my last messages for example) AND jhc compiler is used
I have to dispute
Hello Henning,
Monday, December 18, 2006, 4:46:16 PM, you wrote:
Very true. I really like to know some more clean tricks for speedup.
use C. seriously :)
you can look into sources of FPS and Streams libs, speed-optimized parts
are written in the imperative way and all that you can do in
On 12/18/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Simon,
Monday, December 18, 2006, 12:08:49 PM, you wrote:
My view is that Haskell's performance is very seldom the limiting factor
of course. when someone said about GPG i just mentioned that this project
may be hihgly
Hi Bulat,
let's go further in this long-term discussion. i've read Shootout problems
and concluded that there are only 2 tasks which speed is dependent on
code-generation abilities of compiler, all other tasks are dependent on
speed of used libraries. just for example - in one test TCL was
Hi,
I have to dispute this Bulat's characterisation here. We can solve
lots
of nice problems and have high performance *right now*. Particularly
concurrency problems, and ones involving streams of bytestrings.
No need to leave the safety of GHC either, nor resort to low level
evil
code.
Sebastian Sylvan [EMAIL PROTECTED] writes:
On 12/18/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Simon,
Monday, December 18, 2006, 12:08:49 PM, you wrote:
My view is that Haskell's performance is very seldom the limiting factor
of course. when someone said about GPG i just
Bulat Ziganshin [EMAIL PROTECTED] writes:
Hello ajb,
Monday, December 18, 2006, 4:12:01 AM, you wrote:
time. For example, for certain types of problem, Haskell minimises the
amount of time between the point where I start typing and the point where
I have the answer.
of course, we can
On Tue, Dec 19, 2006 at 01:55:55AM +0300, Bulat Ziganshin wrote:
no. it seems that you never tried to write such code and believe someone
else who's said that such code may be written. try to write something very
simple, like summing bytes in memory buffer, before you will do any
conclusions
On Mon, Dec 18, 2006 at 11:57:59PM +0100, [EMAIL PROTECTED] wrote:
... but I wonder: GPG, AFAIK undertakes some special measures to
ensure that neither clear text nor private keys are paged out to the
disk (since it might be recovered from there by the enemy). How
would you lock data in memory
Hi all (and Don!),
I have some rewritten versions of readInt below...
Bulat Ziganshin wrote:
Hello Donald,
Monday, December 18, 2006, 3:51:48 AM, you wrote:
Haskell can't provide fast execution speed unless very low-level
programming style is used (which is much harder to do in Haskell
Tomasz Zielonka [EMAIL PROTECTED] writes:
On Mon, Dec 18, 2006 at 11:57:59PM +0100, [EMAIL PROTECTED] wrote:
... but I wonder: GPG, AFAIK undertakes some special measures to
ensure that neither clear text nor private keys are paged out to the
disk (since it might be recovered from there by
On Tue, Dec 19, 2006 at 12:26:29AM +0100, [EMAIL PROTECTED] wrote:
You could just mlock() everything allocated by the RTS...
Brute force. :-)
I would call it simplicity ;-)
This way you are also guarding yourself against inadvertenty leaking
clues about the key to non mlock'ed memory (cause
On 12/18/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Sebastian,
Monday, December 18, 2006, 10:58:52 PM, you wrote:
Yes, if you just write naive Haskell code it will probably be slower
than C, but why on earth would you do that? There are significant
benefits (less bugs, better
On Sun, Dec 17, 2006 at 03:43:27PM +0300, Bulat Ziganshin wrote:
Haskell can't provide fast execution speed unless very low-level
programming style is used (which is much harder to do in Haskell than in C,
see one of my last messages for example) AND jhc compiler is used
I have experienced the
I'm allergic to hex constants. Surely, they are not necessary.
-- Lennart
On Dec 18, 2006, at 18:14 , Chris Kuklewicz wrote:
Hi all (and Don!),
I have some rewritten versions of readInt below...
Bulat Ziganshin wrote:
Hello Donald,
Monday, December 18, 2006, 3:51:48 AM, you
On Mon, Dec 18, 2006 at 12:14:36AM +0100, Joachim Durchholz wrote:
Magnus Therning schrieb:
There is of course the possibility that Haskell would bring a whole slew
of yet-to-be-determined security issues. I doubt it will be worse than
C though.
Haskell might be prone to denial-of-service
Comments and suggestions welcome :-)
hi Joachim.
i have some suggestions:
apache:
use fastcgi instead of hacking an own http-server.
http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/
http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/doc/
server:
there are virtual linux servers
A small announcement :)
5 years after its inception, under the guiding hand of Shae Erisson (aka
shapr), the #haskell IRC channel[1] on freenode has finally reached 300
users!
We reached 200 users in January, 250 users for the first time in August,
and didn't expect hit to reach 300 for a while.
Hi David,
I don't think you need functional dependencies or associated
type synonyms to get your example to work. In the past,
I have used the abstraction that you are describing (I call it
an indexed monad and it has a nice categorical definition).
Here is how you can define it:
class
Hi all,
This is my first post. Inspired by Don's hmp3, I've started
my pet project hxine: A Haskell music player using Xine engine.
This was long time ago and I just picked this thing up again:
darcs get http://lintao.org/repos/hxine
To play CD:
./hxine cd:/
./hxine cd://2-
./hxine cd://-5
to
I was trying to get a ghc going in my shell account the other day and
found that the data at
http://haskell.org/ghc/docs/6.6/html/building/sec-porting-ghc.html
didn't apply at all.
The system is a netbsd alpha which turns up as alpha-unknown-netbsd
through configure.
I didn't find any
The code below does not compile unless the bar function is
annotated with a suitable constraint on the class of the formal
parameter.
module Main where
class (C a)
data (C foo) = XY foo = X foo | Y foo
bar :: a - XY a
bar aFoo = X aFoo
main = return ()
I get:
$ ghc Test.hs
Reto,
You gave us a code snippet:
The code below does not compile unless the bar function is
annotated with a suitable constraint on the class of the formal
parameter.
module Main where
class (C a)
data (C foo) = XY foo = X foo | Y foo
bar :: a - XY a
bar aFoo = X aFoo
main =
57 matches
Mail list logo
