[mercury-users] DASD request

[Vladimir Gubarkov]

Hi, Robert

I agree with you that mercury compiler compilation is too slow. I remember
when I tried to build it from sources on my AMD 3000+ Ghz 2 Gb box it took
nearly 4-5 hours.

However if you are a Windows user, you can get already compiled binaries of
mercury from

http://code.google.com/p/winmercury/


<http://code.google.com/p/winmercury/>Sincerely yours,
Vladimir

On Wed, Oct 13, 2010 at 5:23 PM, Robert Shiplett <grshiplett at gmail.com>wrote:

> I hope I am not the first non-academic user to ask merc-dev's that the
> likely size of HD required be indicated at least to an order of mag
>
> Having never spent so many hours and CPU cycles just to get a compiler
> + libraries to build for a language which I only propose to use (as
> opposed to requested, suggested or required to use by a client or
> manager), it was intensely frustrating to have what finally appeared
> to be a succesful install run simply fail at 3 am  ( I awoke due to
> the HD silence ) with a lack of space.
>
> While many new machines have 2 250Gb drives, my old XP box has added
> Firewire devices as needed: and with a new contract I will have more
> space.
>
> But just as I now live within 2 Gb of RAM for a single core i586,
> something would have to go off an HD to make room for a full mercury
> build.
>
> 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 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?
>
> Or: why is mercury not yet building mercury?
>
> Best regards
> an exasperated new user
> PS:  and Smalltalk begat Ruby (yet Self-inlining begat Google V8.
> Hmmm.  Why am I not more easily amused?)
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20101013/96f85e53/attachment.html>