headers
Duncan Coutts | 1 May 2009 01:26
Picon
Picon
Favicon

Re: Final word on OpenAL?

On Thu, 2009-04-30 at 19:58 +0200, Sven Panne wrote:
> [ resending mail because of some strange Postfix error message ]
> 
> Am Donnerstag, 30. April 2009 19:19:54 schrieb Don Stewart:
> > We definitely want to avoid a culture of "packing in bug fixes and
> > features" prior to release, though, as that's a recipe for new bugs!
> 
> I fully understand this, but due to the extremely poor communication of the 
> schedule, this is a far better option than shipping something which has non-
> trivial bugs.

I was thinking why it was that we didn't think to contact the package
maintainers. I guess the reason is because we didn't want them to do
anything.

Now that you point it out of course it's obvious that we should have
contacted them all and said explicitly that there is nothing that we
want them to do. To say that we've picked released versions of their
packages and that they will be able to get updates into the next minor
and major releases (for bug fixes and features/changes respectively).
That would have avoided giving the false hope that it was still possible
to get changes in.

Something for us to learn for next time.

Duncan
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 May 2009 01:29
Picon
Picon
Favicon

Re: Release dates

On Wed, 2009-04-29 at 22:13 +0200, Luis Cabellos wrote:
> On Wed, Apr 29, 2009 at 2:27 PM, Duncan Coutts
> <duncan.coutts@...> wrote:
> > On Wed, 2009-04-29 at 13:25 +0200, Luis Cabellos wrote:
> >> Maybe, it worth to change releases number to time-based numbering
> >>
> >> e.g:
> >>   * 2009.05.04   instead 2009.2.0
> >>   * 2009.06.01   instead 2009.2.1
> >>   * 2009.07.13   instead 2009.2.2
> >
> > Not all releases are equal. We need an indication of major/minor
> > releases. There are supposed to be two major releases every year (ie
> > every 6 months). Minor releases are API compatible. We need to be able
> > to see that in the version number.
> >
> > However we also need to be able to identify testing pre-releases. Hence
> > the suggestion for odd/even. $date.1.x and $date.3.x being testing
> > pre-releases for $date.2.0 and $date.4.0.
> >
> 
> Ok, I see the point. Now I know why that numbering I like it.

I've now documented it on the wiki

http://trac.haskell.org/haskell-platform/wiki/VersionNumbers
Permalink | Reply | 0 comments |
headers
Mikhail Glushenkov | 1 May 2009 06:19
Picon
Gravatar

Third-party C libraries policy?

Hi all,

Currently, glut32.dll is not bundled with the Windows installer,
though it probably should be. I vaguely remember that it is not
part of the base XP install (though I have glut32.dll in
WINDOWS\system32 for some reason). The question is, where should
we put it? Touching WINDOWS\system32 (and installing a DLL
system-wide in general) is not very good behaviour (the main
cause of the "DLL Hell"); if we use $GHC_DIR, it'll work only
with GHCi, but not with the standalone executables.

In general, what is the policy on third-party C libraries such as
GLUT and OpenAL? Should we bundle them with the Haskell Platform
installer or let the user search for them on her own?
Permalink | Reply | 4 comments |
headers
Duncan Coutts | 1 May 2009 10:24
Picon
Picon
Favicon

Re: Third-party C libraries policy?

On Fri, 2009-05-01 at 04:19 +0000, Mikhail Glushenkov wrote:
> Hi all,
> 
> Currently, glut32.dll is not bundled with the Windows installer,
> though it probably should be. I vaguely remember that it is not
> part of the base XP install (though I have glut32.dll in
> WINDOWS\system32 for some reason). The question is, where should
> we put it? Touching WINDOWS\system32 (and installing a DLL
> system-wide in general) is not very good behaviour (the main
> cause of the "DLL Hell"); if we use $GHC_DIR, it'll work only
> with GHCi, but not with the standalone executables.

Right, it doesn't come with XP by default. I guess it comes with most
graphics cards's drivers.

Does the existing ghc installer install glut32.dll?

> In general, what is the policy on third-party C libraries such as
> GLUT and OpenAL? Should we bundle them with the Haskell Platform
> installer or let the user search for them on her own?

I'm not sure yet. Ideally we bundle them but dlls are a particular
problem for Windows because currently there's nowhere sensible to put
them where they will be found by programs that users compile themselves.
Supporting isolated assemblies might make it better (though they can
only be installed by admin).

Duncan
Permalink | Reply | 3 comments |
headers
Claus Reinke | 1 May 2009 12:19

Re: Third-party C libraries policy?

>> Currently, glut32.dll is not bundled with the Windows installer,
>> though it probably should be. I vaguely remember that it is not
>> part of the base XP install (though I have glut32.dll in
>> WINDOWS\system32 for some reason).

possibly installed there by an earlier ghc installer?

>> The question is, where should
>> we put it? Touching WINDOWS\system32 (and installing a DLL
>> system-wide in general) is not very good behaviour (the main
>> cause of the "DLL Hell"); if we use $GHC_DIR, it'll work only
>> with GHCi, but not with the standalone executables.
>
> Right, it doesn't come with XP by default. I guess it comes with most
> graphics cards's drivers.
>
> Does the existing ghc installer install glut32.dll?

Every time it didn't, that lead to bug reports (and usually updated installers).

Though it would be nice not to put it into system dirs. How about
cabal's installed programs bin dir? Or have a cabal/dlls dir, and add
that to the end of PATH?

As a very last resort, you could bundle glut32.dll, but not install it
(put it in a haskell-platform/dlls directory and advise users to do their
preferred thing to make it accessible). That wouldn't work out of
the box, but at least the box would come with all parts, and users
would be in control, if they prefer using another version of glut32.dll,
such as freeglut's).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Duncan Coutts | 1 May 2009 13:17
Picon
Picon
Favicon

Re: Third-party C libraries policy?

On Fri, 2009-05-01 at 11:19 +0100, Claus Reinke wrote:
> >> Currently, glut32.dll is not bundled with the Windows installer,
> >> though it probably should be. I vaguely remember that it is not
> >> part of the base XP install (though I have glut32.dll in
> >> WINDOWS\system32 for some reason).
> 
> possibly installed there by an earlier ghc installer?
> 
> >> The question is, where should
> >> we put it? Touching WINDOWS\system32 (and installing a DLL
> >> system-wide in general) is not very good behaviour (the main
> >> cause of the "DLL Hell"); if we use $GHC_DIR, it'll work only
> >> with GHCi, but not with the standalone executables.
> >
> > Right, it doesn't come with XP by default. I guess it comes with most
> > graphics cards's drivers.
> >
> > Does the existing ghc installer install glut32.dll?
> 
> Every time it didn't, that lead to bug reports (and usually updated installers).
> 
> Though it would be nice not to put it into system dirs. How about
> cabal's installed programs bin dir? Or have a cabal/dlls dir, and add
> that to the end of PATH?

Using the PATH to manage windows dlls is workable but not at all nice.
We have loads of problems with it for the gtk2hs installers. We have to
check carefully that the same dlls are not already on the PATH,
otherwise things go wrong. It's pretty fragile.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikhail Glushenkov | 1 May 2009 14:22
Picon
Gravatar

Re: Third-party C libraries policy?

Hi Duncan,

Duncan Coutts <duncan.coutts <at> ...> writes:

> Does the existing ghc installer install glut32.dll?

No, though it includes GLUT headers and libglut32.a, so that GLUT
can be compiled out-of-the-box.

> For now I think we should just do whatever the existing ghc installer
> does.

Ok, understood!

One option that I'm considering regarding third-party libraries
is to put them to WINDOWS\system32 (or another system-wide
location), but make installing them optional (and off by
default).
Permalink | Reply | 0 comments |
headers
Mikhail Glushenkov | 2 May 2009 08:12
Picon
Gravatar

Windows Installer RC

Hi all,

I've uploaded the release candidate Windows installer to

http://code.haskell.org/~refold/HaskellPlatform-2009.2.0-rc1-setup.exe

Unless someone finds serious bugs in this RC, this version will
be released on Monday unchanged.

What's new in 2009.2.0-rc1:

    * We now use a single root directory for both GHC and
      extralibs
      ($PROGRAMFILES\Haskell Platform\$HP_VERSION).

    * Installed files are tracked precisely (no unsafe `rm -rf`
      business).

    * A new installation mode which doesn't touch the system
      settings or registry was introduced. Suggested by Claus
      Reinke.

    * Installer size was cut down by 50% by turning on 7z
      compression (thanks to Bulat Ziganshin for the heads-up).

    * The welcome screen is now slightly less dull.

Known issues:

    * The installer may work with restricted user accounts, but
(Continue reading)

Permalink | Reply | 14 comments |
headers
Mikhail Glushenkov | 2 May 2009 08:24
Picon
Gravatar

Re: Re[4]: Windows installer - beta release

Hi Bulat,

Bulat Ziganshin <bulat.ziganshin <at> ...> writes:

> >> btw, HP installer creates "Start menu/Haskell Platform/6.10.2" menu. may
> >> be it should be "Start menu/Haskell Platform/2009.0.0"?
> 
> > The default value is "GHC/6.10.2" - I assume that you
> > changed "GHC" to "Haskell Platform" manually?
> 
> no! i've installed HP into C:\Base\Compiler\HaskellPlatform but this
> probably doesn't make difference

This should be fixed in the latest RC.
Permalink | Reply | 2 comments |
headers
Claus Reinke | 2 May 2009 15:57

Re: Windows Installer RC

>    * We now use a single root directory for both GHC and
>      extralibs
>      ($PROGRAMFILES\Haskell Platform\$HP_VERSION).

Is this location configurable? Is it baked into any code?

What is the directory structure below the root?

>    * Installed files are tracked precisely (no unsafe `rm -rf`
>      business).

Thanks!

>    * A new installation mode which doesn't touch the system
>      settings or registry was introduced.

Thanks, that is good to know. Combined with uninstall and better
compression, that means I'll actually want to use this for a GHC 6.10.3
installation (when things are stable;-), to replace my ageing GHC 6.8.3
(which I mostly use to build GHC head, and to check what non-head
users can see on their systems). Will all files be extracted under the root?

Could you please provide some details about what the default
installation mode will do to the system settings or registry, so that
people can make an informed choice about which installation mode
to use? File types used, associated actions, default actions, PATH
settings, other settings (?), what happens to existing settings, how
does the installer integrate with existing installations of GHC, Cabal,
WinHugs, ...?
(Continue reading)

Permalink | Reply | 11 comments |

Gmane