[m-dev.] Proposed installation profiles

[Julien Fischer]

Here are a proposed set of installation profiles as discussed in the "New
release?" thread.

There will be a new option to the configure script, '--enable-install-profile',
that allows users to select an "installation profile", which is a set of library
grades to install. Below is a proposed set of installation profiles.

Note that:

* LLDS_BASE is the best supported LLDS base grade on the system, as determined
by the configure script.
* the default grade for every profile is "hlc.gc".
* the "stseg" component is specified for all low-level C grades (not just
the debugging and deep profiling ones).
* .mm grades aren't included; we can add a "table" profile if it's thought that
they should be.


Profile: minimal
Grades:
- hlc.gc


Profile: base
Grades:
- hlc.gc
- hlc.gc.par (if pthreads is available)
- LLDS_BASE.gc.stseg
- LLDS_BASE.gc.par.stseg
- java (if Java is available)
- csharp (if .NET / Mono is available)
- erlang (if OTP is available)


Profile: trail
Grades:
- all the grades in the "base" profile
- hlc.gc.trseg
- LLDS_BASE.gc.stseg.trseg


Profile: debug
GRADES:
- all the grades from the "base" profile
- LLDS_BASE.gc.debug.stseg.trseg
- LLDS_BASE.gc.decldebug.stseg.trseg


Profile: profile
Grades:
- all the grades from the "base" profile
- hlc.gc.prof
- hlc.gc.memprof
- LLDS_BASE.gc.prof.stseg
- LLDS_BASE.gc.memprof.stseg
- LLDS_BASE.gc.profdeep.stseg


Profile: debug-profile
Grades:
- all the grades from the "base" profile
- all the grades from the "debug" profile
- all the grades from the "profile" profile"


Profile: debug-trail
Grades:
- all the grades from the "base" profile
- all the grades from the "trail" profile
- all the grades from the "debug" profile


Profile: profile-trail
Grades:
- all the grades from the "base" profile
- all the grades from the "profile" profile
- all the grades from the "trail profile


Profile: full
Grades:
- all the grades from the "base" profile
- all the grades from the "debug" profile
- all the grades from the "profile" profile
- all the grades from the "trail" profile


Profile: all
Grades: as above, but with versions of the above for any supported inefficient
LLDS base grades as well (e.g. on a system where LLDS_BASE is 'asm', you would
also get the 'reg' and 'none' versions of *all* the low-level C grades).

[Zoltan Somogyi]

Post by Julien Fischer
There will be a new option to the configure script, '--enable-install-profile',

The "enable-" prefix suggests that you could also disable a profile,
so I would suggest a different name, even if that requires a bit more work
in configure.ac. How about simply --install-profile=...?

Post by Julien Fischer
that allows users to select an "installation profile", which is a set of library
grades to install. Below is a proposed set of installation profiles.

I like this set of profiles. I have just two concerns.

One: should the debug profile include ssdebug for hlc? I don't use it,
so I don't know how generally useful it is.

Two: the "all" profile should be given a name that makes it clear
that it includes grades that are very unlikely to be useful.

Zoltan.

[Julien Fischer]

Post by Zoltan Somogyi

Post by Julien Fischer
There will be a new option to the configure script, '--enable-install-profile',

The "enable-" prefix suggests that you could also disable a profile,
so I would suggest a different name,

IIRC, we're restricted to using the AC_ARG_ENABLE and AC_ARG_WTIH macros,
which means the options are going to be have to be of the form
--{with,without,enable,disable}--<somthing>.

We can catch the use of --disable-install-profile when the configure
script is run.

Post by Zoltan Somogyi
even if that requires a bit more work in configure.ac. How about
simply --install-profile=...?

I think it will be more than a bit of work and making our configure script
even more complicated is the last thing I really want to do!

Post by Zoltan Somogyi

Post by Julien Fischer
that allows users to select an "installation profile", which is a set of library
grades to install. Below is a proposed set of installation profiles.

I like this set of profiles. I have just two concerns.
One: should the debug profile include ssdebug for hlc? I don't use it,
so I don't know how generally useful it is.

I don't think the .ssdebug grades are in a state documentation-wise or
testing-wise where we should consider them stable. If that situation
changes, then it would make sense for the debug profile to include
hlc.gc.ssdebug, java.ssdebug, csharp.ssdebug etc.

Post by Zoltan Somogyi
Two: the "all" profile should be given a name that makes it clear
that it includes grades that are very unlikely to be useful.

Perhaps, "extra" or "inefficient" (we already have an
"--enable-inefficient-grade" option)?

Are there any other opinions on the profile names?

Julien.

[Zoltan Somogyi]

Post by Julien Fischer
* the "stseg" component is specified for all low-level C grades (not just
the debugging and deep profiling ones).

We currently denote the distinction between LLDS grades with
and without stack segments in grade names by component names
"" for no stack segments and ".stseg" for stack segments.

I propose that we also allow something like ".nostseg"
to also denote no stack segments. Then, after a transition period,
we should switch the meaning of "" to mean stack segments,
i.e. make stack segments the default.

Zoltan.

[Julien Fischer]

Post by Zoltan Somogyi

Post by Julien Fischer
* the "stseg" component is specified for all low-level C grades (not just
the debugging and deep profiling ones).

We currently denote the distinction between LLDS grades with
and without stack segments in grade names by component names
"" for no stack segments and ".stseg" for stack segments.
I propose that we also allow something like ".nostseg"
to also denote no stack segments. Then, after a transition period,
we should switch the meaning of "" to mean stack segments,
i.e. make stack segments the default.

I have no objection to making stack segments the default, but I would
prefer to avoid having grade components that represent the absence
of a feature. I suggest that rather than ".nostseg" we have a component
that indicates the use of a fixed size stack, for example ".fixed_st"
or something along that line.

Julien.

[Zoltan Somogyi]

Post by Julien Fischer
I have no objection to making stack segments the default, but I would
prefer to avoid having grade components that represent the absence
of a feature.

Agreed.

Post by Julien Fischer
I suggest that rather than ".nostseg" we have a component
that indicates the use of a fixed size stack, for example ".fixed_st"
or something along that line.

How about ".stfix", to parallel ".stseg"?

Zoltan.

[Julien Fischer]

Post by Zoltan Somogyi

Post by Julien Fischer
I suggest that rather than ".nostseg" we have a component
that indicates the use of a fixed size stack, for example ".fixed_st"
or something along that line.

How about ".stfix", to parallel ".stseg"?

Yes, ".stfix" is good.

Julien.

[Dirk Ziegemeyer]

Hi,

Post by Julien Fischer

Post by Zoltan Somogyi

Post by Julien Fischer
* the "stseg" component is specified for all low-level C grades (not just
the debugging and deep profiling ones).

We currently denote the distinction between LLDS grades with
and without stack segments in grade names by component names
"" for no stack segments and ".stseg" for stack segments.
I propose that we also allow something like ".nostseg"
to also denote no stack segments. Then, after a transition period,
we should switch the meaning of "" to mean stack segments,
i.e. make stack segments the default.

I have no objection to making stack segments the default, but I would
prefer to avoid having grade components that represent the absence
of a feature. I suggest that rather than ".nostseg" we have a component
that indicates the use of a fixed size stack, for example ".fixed_st"
or something along that line.

Do I understand it right, that the use of stseg would avoid stack overflow errors like described in Mantis #385 and mailing list http://www.mercurylang.org/list-archives/developers/2015-April/016288.html?

This would be a very good reason to make stseg the default grade.

Best regards,
Dirk

[Zoltan Somogyi]

Post by Dirk Ziegemeyer
Do I understand it right, that the use of stseg would avoid stack overflow errors like described in Mantis #385 and mailing list http://www.mercurylang.org/list-archives/developers/2015-April/016288.html?

In low level grades, yes. In those grades, Mercury manages the stacks itself,
and with stack segments, the available stack space is limited only by the
availability of memory and its fragmentation.

In high level grades, Mercury does not manage the stack. Instead, we leave
the management of the stack to the C, Java, C# or Erlang compiler.

Post by Dirk Ziegemeyer
This would be a very good reason to make stseg the default grade.

That is our reasoning as well. However, there is a cost: a slight slowdown.

Zoltan.

[Peter Wang]

Post by Julien Fischer
Here are a proposed set of installation profiles as discussed in the "New
release?" thread.
There will be a new option to the configure script, '--enable-install-profile',
that allows users to select an "installation profile", which is a set of library
grades to install. Below is a proposed set of installation profiles.
* LLDS_BASE is the best supported LLDS base grade on the system, as determined
by the configure script.
* the default grade for every profile is "hlc.gc".
* the "stseg" component is specified for all low-level C grades (not just
the debugging and deep profiling ones).
* .mm grades aren't included; we can add a "table" profile if it's thought that
they should be.
Profile: minimal
- hlc.gc
Profile: base
- hlc.gc
- hlc.gc.par (if pthreads is available)
- LLDS_BASE.gc.stseg
- LLDS_BASE.gc.par.stseg
- java (if Java is available)
- csharp (if .NET / Mono is available)
- erlang (if OTP is available)

Can we move the non-C grades out of base? I don't have any use for them
and that's probably true for many people. The people who do want to
play with the java and csharp backends probably know who they are?

The erlang grade has been broken in an easily reproduceable way since
2011 (will fix), and we've not heard a peep. That suggests there is no
need to include erlang in any profile.

Post by Julien Fischer
Profile: trail
- all the grades in the "base" profile
- hlc.gc.trseg
- LLDS_BASE.gc.stseg.trseg
Profile: debug
- all the grades from the "base" profile
- LLDS_BASE.gc.debug.stseg.trseg
- LLDS_BASE.gc.decldebug.stseg.trseg
Profile: profile
- all the grades from the "base" profile
- hlc.gc.prof
- hlc.gc.memprof
- LLDS_BASE.gc.prof.stseg
- LLDS_BASE.gc.memprof.stseg
- LLDS_BASE.gc.profdeep.stseg
Profile: debug-profile
- all the grades from the "base" profile
- all the grades from the "debug" profile
- all the grades from the "profile" profile"
Profile: debug-trail
- all the grades from the "base" profile
- all the grades from the "trail" profile
- all the grades from the "debug" profile
Profile: profile-trail
- all the grades from the "base" profile
- all the grades from the "profile" profile
- all the grades from the "trail profile
Profile: full
- all the grades from the "base" profile
- all the grades from the "debug" profile
- all the grades from the "profile" profile
- all the grades from the "trail" profile

I suggest allowing multiple additive profiles to be specified.
That will cut down the number of profile names, and not require the user
to know the order of the words.

The command line option might look like:

--enable-installation-profile=trail,profile,debug

We could also accept aliases "debugging", "profiling", "trailing".

Peter

[Julien Fischer]

Hi Peter,

Post by Peter Wang

Post by Julien Fischer
Profile: base
- hlc.gc
- hlc.gc.par (if pthreads is available)
- LLDS_BASE.gc.stseg
- LLDS_BASE.gc.par.stseg
- java (if Java is available)
- csharp (if .NET / Mono is available)
- erlang (if OTP is available)

Can we move the non-C grades out of base? I don't have any use for them
and that's probably true for many people.

I thought about having a separate profile for them, but since they don't
take very long to build anyway it didn't seem worth adding another
profile just for them.

Post by Peter Wang
The people who do want to play with the java and csharp backends
probably know who they are?

IMO, the Java backend has developed to a point where it should be
included by default.

Post by Peter Wang
The erlang grade has been broken in an easily reproduceable way since
2011 (will fix), and we've not heard a peep.
That suggests there is no need to include erlang in any profile.

Fine by me. (BTW it's broken in quite a few ways.)

...

Post by Peter Wang

Post by Julien Fischer
Profile: full
- all the grades from the "base" profile
- all the grades from the "debug" profile
- all the grades from the "profile" profile
- all the grades from the "trail" profile

I suggest allowing multiple additive profiles to be specified.

OK.

Post by Peter Wang
That will cut down the number of profile names, and not require the user
to know the order of the words.
--enable-installation-profile=trail,profile,debug
We could also accept aliases "debugging", "profiling", "trailing".

Yes.

Julien.

[Mark Brown]

Post by Peter Wang
I suggest allowing multiple additive profiles to be specified.
That will cut down the number of profile names, and not require the user
to know the order of the words.

That would also leave the name profile-trail (alias trail-profile) to
mean a profile where grades would include both profiling and trailing,
which otherwise not be covered.

On the listed profiles:
- If your project requires trailing, you probably really don't care
about non-trailing grades, except for the one used to build the
compiler. So I don't think trail should include all base grades.
- If incrementally installing, and grades are selected that are
already installed, are they re-installed? If so, I would rather that
debug and profile do not include the base grades either, since these
profiles are ones that are likely to be added after initial
installation (*). Developers can write base,profile,debug if they want
base grades up front.

Cheers,
Mark.

(*) It's nice to be able to start compiling your newly written code,
even though you are still waiting for the other tools to be installed.

[Julien Fischer]

Hi Mark,

Post by Mark Brown

Post by Peter Wang
I suggest allowing multiple additive profiles to be specified.
That will cut down the number of profile names, and not require the user
to know the order of the words.

That would also leave the name profile-trail (alias trail-profile) to
mean a profile where grades would include both profiling and trailing,
which otherwise not be covered.

Another option would be that to install the profiling versions of the
trailing grades if both the "profile" and "trail" profiles are
specified. (So specifying both profiles would be a bit more than
additive.)

Post by Mark Brown
- If your project requires trailing, you probably really don't care
about non-trailing grades,

I do! :-P

Post by Mark Brown
except for the one used to build the compiler.

The one used to build the compiler is not necessarily the default
grade (e.g. with the source distribution the compiler is built in
hlc.gc.pregn, but the default grade is hlc.gc or BEST_LLDS_BASE.gc.)

Post by Mark Brown
So I don't think trail should include all base grades.

In the interests of keeping the number of profiles small, I think it
should.

Julien.

[Paul Bone]

Post by Julien Fischer
Here are a proposed set of installation profiles as discussed in the "New
release?" thread.

I agree with these proposals, my votes are:

Installation profiles: yes.
Peter's suggestions about profiles: yes, especially multiple profiles.
Stack segments by default: okay, I don't mind.

I think it will be a good idea to keep the number of profiles small.
Otherwise we're shifting the "which grades" problem to a "which profiles"
problem to some extent.

I also suggest combining profiling and debugging into a "devel" profile
instead of separate profiling and debugging profiles. This should be the
profile that people choose if they want to develop Mercury programs and
libraries. (They might also combine this with something like trailing.)
Part of the rationale is that if you're developing something in Mercury
there's a good chance that you might want to both debug and profile it.

[Paul Bone]

Related question.

Assuming we go with installation profiles. Which profile should be the
default. I'm thinking of the scenario where a user doesn't read README or
INSTALL (they should have). And they do ./configure && make && make
install. What should they get? will they be surprised by the amount of time
that make install takes?

My thoughts are that the best solution for now is the "base" profile. Maybe
once make builds the library grades rather than make install we can change
this to "developer". I realize that moving the libgrades from make install
to make doesn't actually save any time. However the issue is that people
don't expect make install to take so much time. IMHO this is a reasonable
expectation.

[Sebastian Godelet]

Hello,

You raise a good point, Paul,
I'm also curious about "./configure --enable-minimal-install", which would install asm_fast.gc for example, and --profile minimal would install hlc.gc.
For simplicity, should --enable-minimal-install be an alias for --profile minimal? It seems confusing otherwise.

Sebastian.

-----Original Message-----
Behalf Of Paul Bone
Sent: Friday, October 23, 2015 1:55 PM
Subject: Re: [m-dev.] Proposed installation profiles
Related question.
Assuming we go with installation profiles. Which profile should be the
default. I'm thinking of the scenario where a user doesn't read README or
INSTALL (they should have). And they do ./configure && make && make
install. What should they get? will they be surprised by the amount of time
that make install takes?
My thoughts are that the best solution for now is the "base" profile. Maybe
once make builds the library grades rather than make install we can change
this to "developer". I realize that moving the libgrades from make install to
make doesn't actually save any time. However the issue is that people don't
expect make install to take so much time. IMHO this is a reasonable
expectation.
--
Paul Bone
_______________________________________________
developers mailing list
https://www.mercurylang.org/lists/listinfo/developers

[Julien Fischer]

Hi Sebastian,

Post by Sebastian Godelet
You raise a good point, Paul,
I'm also curious about "./configure --enable-minimal-install", which
would install asm_fast.gc for example,
and --profile minimal would
install hlc.gc.
For simplicity, should --enable-minimal-install be an alias for --profile minimal? It seems confusing otherwise.

--enable-minimal-install should deleted once installation profiles exist.

Julien.

[Julien Fischer]

Post by Paul Bone
Related question.
Assuming we go with installation profiles. Which profile should be the
default.

I would say "base".

Post by Paul Bone
I'm thinking of the scenario where a user doesn't read README or
INSTALL (they should have). And they do ./configure && make && make
install. What should they get?

Hmmm, well one option is that they could get the following error
message:

configure: error: please select an installation profile ...

;-)

Post by Paul Bone
will they be surprised by the amount of time that make install takes?

That's a separate issue.

Julien.

[Matthias Güdemann]

Hi,

I like the idea of installation profiles. Yet, I am unsure whether this
grouping is the best, but maybe it is just a question of default
profile selection.

My hypothesis is that this simplification is mainly to provide less
surprise to new users. Therefore, I think that a *default* should
include the declarative debugger grade and support for
parallelism. These are prominent features of Mercury, at least, these
are the features I tell people about.

Best regards,
Matthias

[Paul Bone]

Post by Matthias Güdemann
Hi,
I like the idea of installation profiles. Yet, I am unsure whether this
grouping is the best, but maybe it is just a question of default
profile selection.
My hypothesis is that this simplification is mainly to provide less
surprise to new users. Therefore, I think that a *default* should
include the declarative debugger grade and support for
parallelism. These are prominent features of Mercury, at least, these
are the features I tell people about.

This is probably the most difficult question to answer. It occurs to me
that if we ask N people what they think. we'll have N different answers.

Everyone has their own ideas about what a basic feature of Mercury (or
anything else) is. I'm not saying we shouldn't ask, just that we'll
probably dissappoint N-1 people.

[Matthias Güdemann]

Hi Paul,

Post by Paul Bone
This is probably the most difficult question to answer. It occurs to
me that if we ask N people what they think. we'll have N different
answers.

yes definitively. Sorry, I saw your mail only after I had sent mine.

Asking this question on [m-dev.] limits N quite a lot, so there may not
be yoo many different answers to your question. My goal was primarily to
ask for whom this feature will be introduced: new users or
developers.

Honestly, I do not have strong opinions about what should be the default
value.

Best regards,
Matthias

[Dirk Ziegemeyer]

Hi,

Post by Matthias Güdemann
My hypothesis is that this simplification is mainly to provide less
surprise to new users. Therefore, I think that a *default* should
include the declarative debugger grade and support for
parallelism. These are prominent features of Mercury, at least, these
are the features I tell people about.

Are the parallel grades the only option to use more than one processor with a mercury program? Are these parallel grades stable already? If yes, why don’t you just include the parallel grades instead of the non-parallel grades in a basic/minimal installation?

Best regards,
Dirk

[Julien Fischer]

Hi,

Post by Dirk Ziegemeyer

Post by Matthias Güdemann
My hypothesis is that this simplification is mainly to provide less
surprise to new users. Therefore, I think that a *default* should
include the declarative debugger grade and support for
parallelism. These are prominent features of Mercury, at least, these
are the features I tell people about.

Are the parallel grades the only option to use more than one processor
with a mercury program?

For the C backends, yes. For the non-C backends, a separate .par
component is not necessary.

Post by Dirk Ziegemeyer
Are these parallel grades stable already?

For the high-level C backend (moduluo the need to replace the use of
unnamed semaphores on OS X with something that works), yes.

Post by Dirk Ziegemeyer
If yes, why don’t you just include the parallel grades instead of the
non-parallel grades in a basic/minimal installation?

The parallel grades being available is dependent on a POSIX threads
library being available -- while that is pretty much always the case on
Linux, it requires more work on other systems, for example Windows using
MSVC as the C compiler. Since the inclusion of .par grades is
conditional on the presence of pthreads, the non .par versions are still
the default.

Julien.