[mercury-users] DASD request

[Parker Jones]

I'd give Mercury more time if it was available precompiled as a debian package.  Reducing the barrier to entry doesn't seem to be a priority which is shame as it's an interesting language.

Cheers,
Parker

Date: Wed, 13 Oct 2010 19:07:11 +0400
Subject: Re: [mercury-users] DASD request
From: xonixx at gmail.com
To: mercury-users at csse.unimelb.edu.au

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/



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/20101014/9c2859da/attachment.html>