[mercury-users] DASD request

[Peter Ross]

Hi Robert,

Thanks for you feedback.

I agree that an initial install takes a very long time.

We should make the default install just install the following two
grades: asm_fast.gc and asm_fast.gc.debug.  For people just wishing to
experiment with the language, this is sufficient.  For people actually
using the language, then they nearly always customize the grades they
wish installed, so the default is meaningless to them anyway.

See below for more comments.

On Thu, Oct 14, 2010 at 12:23 AM, Robert Shiplett <grshiplett at gmail.com> wrote:
> I would propose adding advice for new users of mercury: plan to
> install on a recentlly defragged internal drive with 3 Gb free.
> Preferrrably run in parallel on multi-core CPU.  If you got 'em, smoke
> em.
>
> Or some such.
>
I would also like to point out that installing on a windows machine is
*much* slower than on a unix based machine.  I leave the windows build
overnight while my linux build is done in under an hour.


> I would change the final build order of grade to do no-prof before
> with prof for fast-asm.  Just a user suggestion: someone such as
> myself with a Prolog background is going to want a useable install
> against which to do some checks against the results m.org and
> MissionCriticalIT indicate.  What I had at 3am after several attempts
> is not yet that.
>
> Years of a low rate of user adoption could lead to neglect of
> user-adoption impediments: but for my interest, I would have abandoned
> the effort.  Not providing optional binaries is one such ( I spent
> years in Smalltalk on large corp (F100, F200) mission critical apps -
> yet as a dev community we mastered the clean shot thru the foot.)
>
> Even on the 16 Gb SSD chip for this linux netbook (as the XP CPU is
> occupied with Mercury mgnuc), there are no longer 3 Gb to be freed and
> a 32Gb chip must await a contract.
>
> These are just the facts of my life as a user: I report them in the
> hope that input from the environment is what is critical to
> evolutionary change ;-)
>


> No unpleasant or sarcastic tone is intended.  I am told that
> tolerating my manner of expressing myself is a question of an acquired
> taste.  Having come to enjoy steamed spinach - but not stewed pears -
> I can imagine this ...
>
> If instead the build were controlled by a near-logic language such as
> ICON (oh never mind - at my age I won't live to see configure/make go
> extinct ).  What fails, fails. Why backtrack to "finish" a build with
> some optimal outcome?
>
Actually you have a usable install, when the install fails during the
middle of library installation.  You just will only have the grades
available that have been installed so far.


> Or: why is mercury not yet building mercury?
>
Mercury does build mercury, as you can see the compiler is written in
Mercury.  However if you don't have a Mercury compiler installed then
you suffer a bootstrap problem.

The problem is solved by the release also containing the intermediate
C files, so all one needs is a C compiler to get an initial working
Mercury compiler.

Pete

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------