On 10/5/06, Simon Marlow [EMAIL PROTECTED] wrote:
Win32-2.0 was never officially announced or tagged, as far as I'm aware.Isthat right?So can't the Win32 package included with GHC 6.6 be called version 2.0?We have branched all the packages for GHC 6.6.This does I suppose constitute a
release
On Sun, Oct 08, 2006 at 02:48:03PM -0500, Brian Smith wrote:
Finally, something was mentioned about the Cabal version number only being
accurate for when somebody uses Cabal sdist --snapshot mechanism. However,
this isn't documented, and the documentation for sdist claims that it
doesn't work
On 10/8/06, Ross Paterson [EMAIL PROTECTED] wrote:
On Sun, Oct 08, 2006 at 02:48:03PM -0500, Brian Smith wrote: Finally, something was mentioned about the Cabal version number only being accurate for when somebody uses Cabal sdist --snapshot mechanism. However,
this isn't documented, and the
On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
I was looking under latest stable version on the Cabal website. I
thought it was the latest version of the docs because the URL had
latest in it.
Hmm, quite a bit of historical stuff there.
I see that it is documented in later
On 10/8/06, Ross Paterson [EMAIL PROTECTED] wrote:
On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote: I see that it is documented in later versions. But, I don't see how that mechanism would help in this situation.You still have to bump the version number immediately before you release.
On 10/2/06, Ian Lynagh [EMAIL PROTECTED] wrote:
We are pleased to announce the Second Release Candidate phase for GHC 6.6.I am using release candidate 2. I noticed some problems with Cabal, so I uninstalled 1.1.4 and installed the latest version from the Darcs repository. Now, programs that use
On Sun, 2006-10-08 at 18:55 -0500, Brian Smith wrote:
On 10/2/06, Ian Lynagh [EMAIL PROTECTED] wrote:
We are pleased to announce the Second Release Candidate phase
for GHC 6.6.
I am using release candidate 2. I noticed some problems with Cabal, so
I uninstalled
Hello glasgow-haskell-users,
i don't see updates in ghc 6.6 users guide on the haskell.org (for example,
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghc-language-features.html#options-language
still contains -fno-monomorphism-restriction,-fno-monomorphism-restriction
line). can you
Brian Smith wrote:
The GHC 6.6 release candidate ships with Win32-2.0. But, this is
actually Win32 2.0 plus some modifications (see recent patches).
Shouldn't the version number be inrcremented to be over 2.0? I think
that this applies to the other libraries as well.
Also, the GHC-6.6 darcs
On 10/5/06, Simon Marlow [EMAIL PROTECTED] wrote:
Brian Smith wrote:
The GHC 6.6 release candidate ships with Win32-2.0. But, this is
actually Win32 2.0 plus some modifications (see recent patches).
Shouldn't the version number be inrcremented to be over 2.0? I think
that this applies
On Thu, Oct 05, 2006 at 01:16:12PM +0300, Esa Ilari Vuokko wrote:
I think that version number in repo should always be bigger than
released version, so that snapshot names reflect versioning better.
You need to use something like setup sdist --snapshot to get an
accurate version for a snapshot,
The GHC 6.6 release candidate ships with Win32-2.0. But, this is actually Win32 2.0 plus some modifications (see recent patches). Shouldn't the version number be inrcremented to be over 2.0? I think that this applies to the other libraries as well.
Also, the GHC-6.6 darcs-all script does not pull
We are pleased to announce the Second Release Candidate phase for GHC 6.6.
Snapshots beginning with 6.5.20061001 are release candidates for 6.6
We would be particularly interested to hear whether or not the 6.6 RC
works for people who were having trouble with 6.4.2.
Also, please note
Ian Lynagh schrieb:
We are pleased to announce the Second Release Candidate phase for GHC 6.6.
Snapshots beginning with 6.5.20061001 are release candidates for 6.6
We would be particularly interested to hear whether or not the 6.6 RC
works for people
This RC works for our (about
Ian Lynagh [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
http://www.haskell.org/ghc/dist/current/dist/
Hello Ian,
Is it on purpose that the lastest windows build does not include
cabal-install?
Since the September builds I don't see any logs for the mingw build?
Rene.
On Mon, 2006-10-02 at 17:06 +0200, Rene de Visser wrote:
Ian Lynagh [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
http://www.haskell.org/ghc/dist/current/dist/
Hello Ian,
Is it on purpose that the lastest windows build does not include
cabal-install?
Yes that is
Bulat Ziganshin wrote:
how about adding to the list of extra libs the following very useful ones:
regex-*
FilePath
MissingH
Edison
Let me echo what Ian said: the idea with extralibs was not to bundle useful
stuff with GHC, but rather to *separate* from GHC as many of the bundled
libraries
Christian Maeder wrote:
Simon Marlow schrieb:
Only a week late, we are pleased to announce the Release Candidate phase
for GHC 6.6.
Snapshots beginning with 6.5.20060831 are release candidates for 6.6
Download snapshots from here:
http://www.haskell.org/ghc/dist/current/dist/
I've
Simon Marlow schrieb:
Christian Maeder wrote:
I've downloaded the source bundle ghc-6.5.20060918-src.tar.bz
After ./configure and make, I realized that I have no root permissions
for installation. So called
./configure --prefix=/local/home/maeder/ghc-6.5
followed by make and make install
On Tue, Sep 19, 2006 at 08:45:30PM +0400, Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
how about adding to the list of extra libs the following very useful ones:
I think we're too late in the release process to be adding libraries.
Also, I think we would like to move towards
Am Mittwoch, 23. August 2006 15:23 schrieb Bulat Ziganshin:
[...]
i think that better way is to supply non-core libs in source form and
just recompile them in this case. so, [...]
Nice theory, but this doesn't work at all in practice: The majority of the
packages mentioned so far are not
Hi
Nice theory, but this doesn't work at all in practice: The majority of the
packages mentioned so far are not purely Haskell, so one needs tons of
development tools and C libraries, headers, etc. (all in a consistent state,
of course) to compile those packages, which is a bit tricky on *nices
On 19.09 21:28, Tomasz Zielonka wrote:
On Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote:
I would suggest -fforce-recomp for force recompilation.
-frecompile-all
- Einar Karttunen
___
Glasgow-haskell-users mailing list
Hello glasgow-haskell-users,
i've put my hands on the ghc 6.6/mingw32 dated 1st september
(http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-mingw32.tar.gz)
overall, compilation of my 5 kloc application was fine. on the
6.2-6.4 transition, i was bitten by two API changes
Hello Simon,
Monday, September 4, 2006, 1:16:22 PM, you wrote:
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghc-language-features.html
still don't mention -fparr option :)
-fparr is definitely not working in 6.6, so documenting it would almost
certainly be a bad idea.
it
Simon Marlow schrieb:
Only a week late, we are pleased to announce the Release Candidate phase
for GHC 6.6.
Snapshots beginning with 6.5.20060831 are release candidates for 6.6
Download snapshots from here:
http://www.haskell.org/ghc/dist/current/dist/
I've downloaded the source
Hello glasgow-haskell-users,
how about adding to the list of extra libs the following very useful ones:
regex-*
FilePath
MissingH
Edison
?
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing
Hi,
While I'd dearly love for FilePath to go in, the API is not quite
stable enough yet - I have another few API changes that I need to make
before I send out another version that is suitable for inclusion to
base, so i'd like to make those changes first, have another round of
review etc. then
On Tue, Sep 19, 2006 at 02:33:46PM +0400, Bulat Ziganshin wrote:
3. ghc 6.6 includes smart relinking capability which don't relink exe
file if it already exists and .hs source files was not changed. that's
great but ignores other .o files that can be also linked to program,
for example those
Tomasz Zielonka [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
BTW. The -fno-recomp option has a very unintuitive name, at least for
me. When I see -fno-recomp, my brain thinks no recompilation,
meaning no unneccesary recompilation, which is what --make does by
default. Using
On Tue, Sep 19, 2006 at 09:13:56PM +0200, Rene de Visser wrote:
I would suggest -fforce-recomp for force recompilation.
I like it.
Best regards
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Hello Neil,
Tuesday, September 19, 2006, 9:22:33 PM, you wrote:
While I'd dearly love for FilePath to go in, the API is not quite
stable enough yet
it's not problem by itself - ext libs should just contain most useful
libs that are preinstalled with ghc itself. one can easily upgrade them
--
Zielonka
| Sent: 01 September 2006 19:55
| To: Simon Marlow
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: ANNOUNCE: GHC 6.6 Release Candidate
|
| On Fri, Sep 01, 2006 at 11:03:09AM +0100, Simon Marlow wrote:
| Please test as much as possible, bugs are much cheaper if we find
them
| before
Hi Duncan,
On Mon, 11 Sep 2006 17:34:26 +0900, Duncan Coutts [EMAIL PROTECTED] wrote:
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell
packages with the latest GHC 6.6 RC snapshot. Here is his report of what
failed, and how:
http://www.haskell.org/~gentoo/gentoo-haskell
Niklas Broberg patched haskell-src-exts so it should work using the
latest version from darcs.
On 9/11/06, Duncan Coutts [EMAIL PROTECTED] wrote:
Hi folks,
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell
packages with the latest GHC 6.6 RC snapshot. Here is his report of what
On Mon, 2006-09-11 at 13:24 +0200, Johan Tibell wrote:
Niklas Broberg patched haskell-src-exts so it should work using the
latest version from darcs.
That's great.
Do you know if there will be a release with a tarball? Generally distros
only package released versions. Alternatively if the
Niklas Broberg patched haskell-src-exts so it should work using the
latest version from darcs.
That's great.
Do you know if there will be a release with a tarball? Generally distros
only package released versions. Alternatively if the changes are not
that big then we can apply a patch to the
Hi folks,
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell
packages with the latest GHC 6.6 RC snapshot. Here is his report of what
failed, and how:
http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html
You'll note that there are some common ones, like
| With reference to the documentation [about lexically scoped type
variables] that just appeared in darcs:
For the benefit of others, the draft 6.6 documentation is here
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions
.html#scoped-type-variables
| Result type
Ross Paterson wrote:
data T = forall a. MkT [a]
k :: T - T
k (forall a. MkT [t]) = MkT t3
where
t3::[a] = [t,t,t]
What was wrong with the example in the documentation?
k :: T - T
k (MkT [t::a]) = MkT t3
where
t3::[a] = [t,t,t]
The type of (t) is (a) -
Brian Hulley wrote:
Ross Paterson wrote:
data T = forall a. MkT [a]
k :: T - T
k (forall a. MkT [t]) = MkT t3
where
t3::[a] = [t,t,t]
What was wrong with the example in the documentation?
k :: T - T
k (MkT [t::a]) = MkT t3
where
t3::[a] = [t,t,t]
The
With reference to the documentation that just appeared in darcs:
Result type signatures are now equivalent to attaching the signature
to the rhs, i.e. redundant.
How about finishing the decoupling of type variable binding from pattern
type signatures by introducing an (optional) pattern form
Hi Simon,
Which version of the testsuite should I be using to test my
builds of the release candidates?
Best Wishes,
Greg
On Sep 1, 2006, at 6:03 AM, Simon Marlow wrote:
Only a week late, we are pleased to announce the Release Candidate
phase for GHC 6.6.
Snapshots beginning
On 05 September 2006 14:21, Gregory Wright wrote:
Which version of the testsuite should I be using to test my
builds of the release candidates?
Good question. We haven't made any tarballs of the testsuite, but just
grabbing the current sources from darcs is fine.
Cheers,
Simon
Bulat Ziganshin wrote:
Hello Simon,
Friday, September 1, 2006, 2:03:09 PM, you wrote:
Only a week late, we are pleased to announce the Release Candidate phase for GHC
6.6.
Release Notes don't mention new features added to
7.4.12. Generalised derived instances for newtypes,
namely
| also, section 7.4.7 of GHC documentation
| (
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions
.html#linear-implicit-
| parameters )
| mentions linear implicit parameters what was planned to omit from
GHC 6.6
I've now removed linear implicit parameters from the User
Only a week late, we are pleased to announce the Release Candidate phase for GHC
6.6.
Snapshots beginning with 6.5.20060831 are release candidates for 6.6
Download snapshots from here:
http://www.haskell.org/ghc/dist/current/dist/
Right now we have the source bundles:
http
Hello Simon,
Friday, September 1, 2006, 2:03:09 PM, you wrote:
Only a week late, we are pleased to announce the Release Candidate phase for
GHC
6.6.
Release Notes don't mention new features added to
7.4.12. Generalised derived instances for newtypes,
namely automatic deriving instances
On Fri, Sep 01, 2006 at 11:03:09AM +0100, Simon Marlow wrote:
Please test as much as possible, bugs are much cheaper if we find them
before the release!
I was playing with impredicativity, when I got this strange error
message:
Prelude :l Imp
[1 of 1] Compiling Imp (
Currently the tool is general enough to be used with Hugs or any other
project. You just need to have a prepared (template) MSI database and
the tool will add your files to it. What I tend to add is a special
mode where the tool will read your .cabal file and will automatically
detect which files
The usage of something else than cabarc isn't supported directly and
will require extra work. Is the lzma algorithm better than bz2? If I
have to use something better than cabarc I would prefer more popular
compression algorithm. For Visual Haskell the Nullsoft installer isn't
an option because
Hello Krasimir,
Friday, August 25, 2006, 10:49:50 AM, you wrote:
The usage of something else than cabarc isn't supported directly and
will require extra work. Is the lzma algorithm better than bz2? If I
for compression of binary data (and most of windows distribution is
executable), lzma is
Hello Neil,
Tuesday, August 22, 2006, 5:04:58 PM, you wrote:
Just for reference, I did this with WinHugs, I created WinHugs and
MinHugs - with the explicit goal that a student at a uni should be
able to install MinHugs on their disk space without blowing their
quota. The difference was about
On 24 August 2006 11:20, Henning Thielemann wrote:
On Tue, 22 Aug 2006, Simon Marlow wrote:
- A source tree can optionally be populated with more packages,
which will be included in the build as normal. At the moment,
the only packages you can add in this way are:
ALUT, HGL,
Hello Simon,
Thursday, August 24, 2006, 2:40:55 PM, you wrote:
This means that making a minimal distribution in a build tree that has
everything is not just a matter of removing stuff, also the Haddock
index must be rebuilt, and the package database needs to have the extra
packages removed
Bulat Ziganshin wrote:
Hello Simon,
Thursday, August 24, 2006, 2:40:55 PM, you wrote:
This means that making a minimal distribution in a build tree that has
everything is not just a matter of removing stuff, also the Haddock
index must be rebuilt, and the package database needs to have the
On Thu, Aug 24, 2006 at 12:22:05PM +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
at least we can start by removing from ghc distribution large
graphics/sound libraries that was already cabalized. are there such
beasts?
All those packages are already Cabalized. Hugs uses Cabal to build
I wrote simple tool that I am using to build MSI installer for Visual
Haskell. It will not be so hard to extend it to support Cabal. After
that it will be easy to prepare an installer for GHC with optional
libraries. Don't expect it to be ready for 6.6 release!
Cheers,
Krasimir
On 8/22/06,
Hi Karsmir,
I wrote simple tool that I am using to build MSI installer for Visual
Haskell. It will not be so hard to extend it to support Cabal. After
that it will be easy to prepare an installer for GHC with optional
libraries. Don't expect it to be ready for 6.6 release!
Would it be
Hello Krasimir,
Thursday, August 24, 2006, 6:15:17 PM, you wrote:
I wrote simple tool that I am using to build MSI installer for Visual
Haskell. It will not be so hard to extend it to support Cabal. After
that it will be easy to prepare an installer for GHC with optional
libraries. Don't
Simon,
... At the moment,
the only packages you can add in this way are:
ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi,
fgl, haskell-src, html, mtl, network, parsec, time, xhtml
... instead include smaller and more fundamental
packages: ByteString, regexps,
Hello Peter,
Wednesday, August 23, 2006, 10:00:00 AM, you wrote:
... At the moment,
the only packages you can add in this way are:
ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi,
fgl, haskell-src, html, mtl, network, parsec, time, xhtml
... instead include smaller
Bulat Ziganshin [EMAIL PROTECTED] writes:
1. Simon suggests that there is a core GHC distribution. it should be
GHC _compiler_ itself and contains only libraries whose implementation
are closely tied to compiler version [...]
2. For windows-like OSes where users prefer to see larger
Bulat Ziganshin wrote:
one interesting question you not mentioned - whether it will be
possible to include in GHC bundles non-BSD licensed libs and tools.
although it seems more on behalf of packagers, it's still interesting
to discuss here. one thing that i definitely will be glad to see is
Bulat Ziganshin wrote:
on the other side, when we upgrade ghc itself, it should
be possible to leave versions of these libraries that are already
installed
Now *that* is the tricky part. It's something I believe is important and I'd
like to see GHC support this in the future.
Just
Chris Kuklewicz wrote:
Simon Marlow wrote:
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
I have a small comment...
So here's what I
Simon Marlow wrote:
Chris Kuklewicz wrote:
Simon Marlow wrote:
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
I have a small comment
Chris Kuklewicz wrote:
Simon Marlow wrote:
Chris Kuklewicz wrote:
Simon Marlow wrote:
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
I
Simon Marlow wrote:
If the base package is upgraded without also replacing the other
libraries... this is where it gets really tricky. Binary
dependencies between library code tend to be very deep due to
cross-module inlining and optimisations, so right now the chances of
upgrading base without
of the documentation seems to refer to JRegex - while this is
useful for someone moving from one to the other, it won't mean much to
someone trying to grok the new regex stuff in GHC 6.6. Any chance of
having some more basic docs?
I should absorb the example files into a large piece of haddock documentation
Hello Simon,
Wednesday, August 23, 2006, 2:26:56 PM, you wrote:
Just replacing GHC without upgrading libraries (or RTS) should be possible
imho this is not very useful. typically, bug fixes are spread over
compiler, rts and libraries, so upgrading only compiler seems very
strange idea and
Hi Bulat,
sorry, but you miscitated me and seems to misinterpret whole idea:
Sorry about that. I put the emphasis on your mention of
fundamental, almost to the exclusion of compiler-builds. My point
was that there are two design considerations when you are designing a
compiler system:
On 23 August 2006 14:27, Chris Kuklewicz wrote:
I need to add some build system stuff for GHC: Makefile,
package.conf.in, and possibly configure.ac. Instead of the fps
dependency, there will be a base=2.0 dependency (ideally we would
have conditional dependencies, but Cabal support for that
Simon Marlow wrote:
On 23 August 2006 14:27, Chris Kuklewicz wrote:
I need to add some build system stuff for GHC: Makefile,
package.conf.in, and possibly configure.ac. Instead of the fps
dependency, there will be a base=2.0 dependency (ideally we would
have conditional dependencies, but
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
For a while we have had the goal of devolving as many of the libraries
that ship with GHC as possible
Hello Simon,
Tuesday, August 22, 2006, 2:11:46 PM, you wrote:
- A source tree can optionally be populated with more packages,
which will be included in the build as normal. At the moment,
the only packages you can add in this way are:
ALUT, HGL, HUnit, OpenAL, OpenGL,
Hi
i think that inclusion of large packages in installer - independent of
how great they are - is a wrong decision.
Just for reference, I did this with WinHugs, I created WinHugs and
MinHugs - with the explicit goal that a student at a uni should be
able to install MinHugs on their disk space
Simon Marlow wrote:
So here's what I propose:
- A GHC source tree will contain a core set of packages. This is
what you will get if you download ghc-6.6-src.tar.bz2, or do
sh darcs-all get in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm
Hello Brian,
Tuesday, August 22, 2006, 5:52:29 PM, you wrote:
sh darcs-all get in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm,
Cabal, unix, Win32
Should mtl not also be included here too as it is a relatively small package
but
Bulat Ziganshin wrote:
Hello Brian,
Tuesday, August 22, 2006, 5:52:29 PM, you wrote:
sh darcs-all get in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm,
Cabal, unix, Win32
Should mtl not also be included here too as it is a
and updated independently.
fo example, you can update mtl from 2.0 to 3.0 version while using
still ghc 6.6 you installed four years ago. now library versions are
fixed at moment of major GHC release (6.4/6.6/..) and don't changed
during year or two
--
Best regards,
Bulatmailto
Simon Marlow wrote:
Here is what I propose to do regarding the libraries we ship with GHC
6.6. Comments are appreciated, since we need to finalise this story
before the release candidate at the end of this week.
I have a small comment...
So here's what I propose:
- A GHC source tree
Hello Simon,
one interesting question you not mentioned - whether it will be
possible to include in GHC bundles non-BSD licensed libs and tools.
although it seems more on behalf of packagers, it's still interesting
to discuss here. one thing that i definitely will be glad to see is
MissingH
Reilly Hayes wrote:
Any chance of getting ticket #608 onto the list for the 6.6 release?
Ticket #608 is Make the NCG* able to compile the RTS. *Please correct
me if I am wrong, but my understanding of the dependencies suggests that
this is the key obstacle to dynamically linked builds on
Any chance of getting ticket #608 onto the list for the 6.6 release? Ticket #608 is "Make the NCG able to compile the RTS". Please correct me if I am wrong, but my understanding of the dependencies suggests that this is the key obstacle to dynamically linked builds on x86 platforms. My reasoning
Help build the anticipation:
http://haskell.org/hawiki/GHC_206_2e6
Present text:
GHC 6.6:
Will be out before May 2006.
Included:
* Parallel GHC
* Associated types with class
Maybe:
* Impredicativity
* GADT Typeclass interaction
* Data types as kinds
No:
Jim
101 - 186 of 186 matches
Mail list logo
