| Whoa! If 'now' is 123456 seconds after midnight on 1 Jan 1970,
| then 10 seconds later must be 123466 seconds after midnight 1
| Jan 1970,
| regardless of daylight saving time or whatever. Surely!
|
| But adding "1 day" to 123456 seconds after midnight on 1 Jan
| 1970 might add
|
Na qrnik.glasgow-haskell-bugs piszesz:
Thanks for the report. I've fixed this in the CVS sources.
Thanks.
There was also another case. I don't know if it's the same thing
and whether it got fixed too:
import Concurrent
main = do
result - newEmptyMVar
forkIO (putMVar
| Whoa! If 'now' is 123456 seconds after midnight on 1 Jan 1970,
| then 10 seconds later must be 123466 seconds after midnight 1
| Jan 1970,
| regardless of daylight saving time or whatever. Surely!
|
| But adding "1 day" to 123456 seconds after midnight on 1 Jan
| 1970 might add
Simon Marlow wrote:
It seems that arithmetic on ClockTimes should be just on seconds since 1970,
whereas arithmetic on CalendarTimes should take into account DST, leap
seconds and all that. But we only have TimeDiff. I think this library
needs a redesign.
If you remember, ages ago I
| If you remember, ages ago I suggested having several sorts of
| TimeDiff.
There are two issues
- getting a correct impl of the (possibly stupid) Haskell 98
Time library
- improving the library definition (but then it's not H98)
I was addressing the former; you are addressing the
Hi,
I got round yesterday's compilation problem (panic on interface file), by
compiling the module Widgets.lhs without -O.
The demo program now compiles.
It runs normally and will happily give a time profile.
./demos +RTS -pT
However, when run with heap profiling
./demos +RTS -hC
it crashes
I seem to be unable to access the CVS tree on glass.cse.ogi.edu. 'cvs
update' just hangs. A traceroute seems to show glass to be
inaccessible; a straight ssh hangs too.
Here's the traceroute info.
sphere:kw217$ traceroute glass.cse.ogi.edu
traceroute to glass.cse.ogi.edu (129.95.44.145), 30
Hi all,
I tried to write a Win32 program in with GHC 4.05 but I am stumbeling over
the definition
type WNDCLASS =
(ClassStyle, -- style
HINSTANCE, -- hInstance
MbHICON, -- hIcon
MbHCURSOR, -- hCursor
MbHBRUSH,-- hbrBackground
MbLPCSTR,-- lpszMenuName
ClassName)
| My question is: Why Haskell compiler makers do not try to
| catch with Clean
| team, and surpass them? After all, there are many more people working
| with Haskell than with Clean.
A brief response.
First, Clean is indeed an excellent system, and its implementors
are fearsomely talented. As
Dear Colleagues,
Three lectureships (Ref:R1868A) and one readership position (Ref:R1868C) are
available at the Department of Computer Science of Sheffield University. I
would be grateful if you could bring these positions to the attention of anyone
who might be interested.
One of the
I think the GHC developers have got their priorities about right. Yes, GHC is
slow, hard to build, and big. That's because it's a research project.
It's more important now to concentrate on demonstrating that Haskell is a good
language for all sorts of real programming problems. It won't be
I will try to give a collective answer to the reactions to my letter.
Tom Pledger wants this to be constructive. That is my intention, of
course. Since I am not able to program in languages like C or
Oberon, I would like to have a practical lazy functional compiler
(or a practical prolog
Eduardo Costa answers to (?):
Please, correct me if I am wrong: Clean is a proprietary language.
Yes. You are right. What is worse: They do not make this point very
clear (for instance, I could not find the price anywhere). You know, I do
not mind if the language is proprietary or not.
| ourselves on Haskell. I infer from your letter that the GHC
| team has no
| interest on building a practical Haskell compiler, but to
| play and experiment with the language.
I didn't speak clearly enough if that is your inference!
First, GHC is certainly a practical Haskell compiler in the
On 25-Nov-1999, George Russell [EMAIL PROTECTED] wrote:
I think the GHC developers have got their priorities about right. Yes, GHC
is slow, hard to build, and big. That's because it's a research project.
Making GHC easier to build would make it easier for researchers;
it might well
On Thu, 25 Nov 1999, Eduardo Costa wrote:
course. Since I am not able to program in languages like C or
Oberon, I would like to have a practical lazy functional compiler
(or a practical prolog compiler). I hope to convince people to implement
such a compiler.
I think the compiler that you
On 25-Nov-1999, Eduardo Costa [EMAIL PROTECTED] wrote:
Fergus Henderson
Why a compiler should be small, and produce small code, etc?
I completely understand the desire for the compiler to produce
small code. I was asking about your desire for the compiler
itself to be small.
A small
Eduardo Costa on small Haskell compilers:
Besides, it becomes easier to install, and uninstall. For instance,
Dr. Alcimar (that you know quite well) is finishing his prosthetic arm
for amputees. Clean was able to produce code that was small enough,
uses heap sparingly, and was fast enough to
| I mean, a group who could produce a
| competitive compiler, useful not only to people who are
| interested in testing
| the language, but also in using it to produce commercial and
| industrial tools.
I think that would be absolutely splendid and I would do whatever
I could to support such a
It is not obvious that Haskell provides an order of magnitude improvement
in any of these areas. Where I think Haskell (or Haskell compiler
writers), could really be useful is in providing better XML transformation
languages and implementations. XML Schemas are emerging as the defacto
type
20 matches
Mail list logo
