- Glasgow-haskell-users

RE: how to determine a programs memory usage at runtime?
by Simon Marlow 22 Jun '04

22 Jun '04

On 21 June 2004 09:14, John Meacham wrote: > There might be some RTS calls to query the heap, but someone else is > probably more qualified to comment on that. The value of the mblocks_allocated variable in the RTS will give you the number of "megablocks" currently mmap()ed into the address space of the executable, which roughly equates to the amount of memory the program is using. A megablock is MBLOCK_SIZE bytes, currently 1Mb. Megablocks are never released, so this only gives you an upper limit for the amount of memory in use. Cheers, Simon

2 1

Re: F#
by MR K P SCHUPKE 21 Jun '04

21 Jun '04

>Not? How about Erm, actually I was trying to be diplomatic... What with MS supporting GHC's development. I completely agree with the statement about the CLR straight jacket. Secondly... I agree with you about multi-parameter type classes and fundeps enabling you to do this - but thats not Haskell 98 and you also sun into the closed verses open representation problem. If you look at the paper Ralf, Oleg and I have been wotking on: http://homepages.cwi.nl/~ralf/HList/ You will see that an alternative approach is possible... Here we can use the type of an HList to model an objects interface, and using this technique we have all the examples from an O'Caml tutorial implemented in Haskell (This is not actually in the paper due to running out of space - but will probably be the subject of a separate paper). Keean.

1 0

Re: F#
by MR K P SCHUPKE 21 Jun '04

21 Jun '04

Can't help but comment... >"Purely functional languages like Haskell are excellent >within certain niches, but non-trivial problems exist >with language interoperability between lazy and strict >languages." I don't wish to appear to be too harsh on Microsoft, (after all they are supporting work on GHC) - but they tend to ignore all non-Microsoft solutions... deliberatly (its a marketing thing). So when you read the above - you have to substitute "Microsoft languages" for "strict languages" for it to really make sense ... after all C is the predominant language of the day, and I have found it relatively easy to do C FFI stuff, okay so you have to allocate and deallocate memory, but you would have to do that in C anyway. It seems to me the author of that quota had "languages" like Visual-Basic in mind. Here the work of marshalling is pretty complex compared to usual Visual-Basic fare... The other area (again MS specific) that F# has better interoperability, is .NET . F# (notice similarity to C#) is a funtional language within the .NET framework - hence supports the 'COM' style interface within the language primitives, just like C# does. This means coding a .NET component in F# is trivial - In haskell its still pretty hard-core (its hard even in C hence the prevelence of visual-toolkits on the MS platform - and also the eventual development of C#) The only way the author of this comment can be persuaded to delete it I think is if Haskell were to have a neat .NET component interface, unfortunately Haskell's class system is not up to incorporating OO hierachies like .NET without some changes... I think however the complexities mentioned relate to .NET / COM style object systems, and not traditional languages like C. Maybe we should ask for the quote to be revised to: "interoperability between lazy and component based object hierachies" ? Keean.

2 1

how to determine a programs memory usage at runtime?
by Bernard James POPE 21 Jun '04

21 Jun '04

Hi all, Is there any way I can find out or estimate the memory size of a program while it is executing? This may very well be problematic and system specific, but I haven't a clue where to look. Perhaps there is a posix interface I am missing? Or a hook into the runtime? Why do I want to know this? I'm experimenting with interleaving the execution of buddha's debugging algorithm with the execution of the debuggee. Assume for the moment that the debuggee runs in one thread and the debugger runs in another. One strategy I want to test is running the debuggee until some threshold of memory has been used, suspend the debuggee and jump to the debugger, then possibly back again. Cheers, Bernie.

2 1

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 19 Jun '04

19 Jun '04

On 17 June 2004 16:29, Peter Robinson wrote: > Well the build finally succeeded but unfortunately I immediately get a > segfault when running ghc/ghci. > I've attached the output of > # strace -o log ./ghc It looks like registerised compilation on x86_64 isn't quite working yet, then. If you're up to debugging this, then I suggest you start from a simpler program - try hello world registerised, and then slightly larger programs if that works. Compile programs with -debug, and run with gdb to find out where the crash is happening. Cheers, Simon

4 8

RE: trying to install unregistered build on linux w/ uClibc
by Simon Marlow 18 Jun '04

18 Jun '04

On 18 June 2004 16:50, Bennett Todd wrote: > Alas, still no joy. > > This sequence: > > tar xjf ghc-6.2.1-src.tar.bz2 > tar xzf ghc-6.2.1-i386-unknown-linux-hc.tar.gz > cd ghc-6.2.1 > ./configure --enable-hc-boot --enable-hc-boot-unregisterised > --prefix=/usr ./distrib/hc-build --enable-hc-boot-unregisterised > --prefix=/usr make ProjectsThatExist="glafp-utils ghc libraries > hslibs" prefix=$BPM_ROOT/usr install install-docs I think you need to 'make all' before 'make install'. Cheers, Simon

2 1

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 18 Jun '04

18 Jun '04

On 17 June 2004 13:09, Bennett Todd wrote: > 2004-06-17T09:04:40 Simon Marlow: >> Hmmm. Try these please: >> >> make show VALUE=ProjectsToBuild >> make show VALUE=ProjectsThatExist >> make show VALUE=SUBDIRS > > bash-2.05b$ make show VALUE=ProjectsToBuild > ProjectsToBuild="" > bash-2.05b$ make show VALUE=ProjectsThatExist > ProjectsThatExist="" > bash-2.05b$ make show VALUE=SUBDIRS > SUBDIRS="" > bash-2.05b$ > > Nothing in it, nothing in it, but the binding 'round it. Ok, $(ProjectsThatExist) is supposed to be set to all the projects in your source tree that can be built, which on a normal GHC build should be something like this: ProjectsThatExist="glafp-utils ghc libraries hslibs" This value is set right near the top of the top-level Makefile. Could you investigate and find out why it is empty in your tree? Cheers, Simon

2 1

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 18 Jun '04

18 Jun '04

On 17 June 2004 17:30, Peter Robinson wrote: > On Thursday 17 June 2004 17:38, Simon Marlow wrote: >> It looks like registerised compilation on x86_64 isn't quite working >> yet, then. If you're up to debugging this, then I suggest you start >> from a simpler program - try hello world registerised, and then >> slightly larger programs if that works.> >> Compile programs with -debug, and run with gdb to find out where the >> crash is happening. > I would if I could, but unfortunately I can't even start ghc (the > strace log I've attached before was created when running ghc without > _any_ arguments): # ./ghc > # Segmentation fault Yes, I meant building a program using the working ghc. Things get confusing with multi-stage bootstraps, so let's clarify: A : compiler bootstrapped from .hc files (unregisterised, builds unregisterised binaries) B : compiler built using stage1 in a new tree (unregisterised, builds registerised binaries) So it looks like your B compiler is crashing - which means that your A compiler is producing incorrect code. > Some other ones can be compiled but cannot be executed (like ghc). > All crashes are related to memory management: > > #../log:mmap(0x2a96300000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a96300000 > #../log:mmap(0x2a96400000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a96400000 > #../log:mmap(0x2a96500000, 30739081986048, > PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > -1 EINVAL (Invalid argument) #../log:write(2, "getMBlock: mmap: > Invalid argumen"..., 33) = 33 Furthermore, your A compiler is also crashing. Very strange... this one could be a gcc problem, but I really don't know. You might try going back to 3.4.0, but back off to 3.3.3 to avoid the crash that happened before. Failing that, it's gdb I'm afriad. Cheers, Simon

1 0

RE: Unregistered build (was Re: AMD64)
by Simon Marlow 17 Jun '04

17 Jun '04

On 17 June 2004 14:08, Peter Robinson wrote: > ------------------------------------------------------------------------ > ==fptools== make all -wr; > in /home/thaldyron/var/ghcbuild/ghc-6.2.20040613/libraries/base > ------------------------------------------------------------------------ > rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir > GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print > | xargs rm -f __rm_food; fi; > ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude > -#include HsBase.h -funbox-strict-fields -package-name base -O > -Rghc-timing > -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi > warning: don't know how to split object files on this architecture There's the clue: ghc-split isn't set up to handle this platform yet. If you don't feel up to fixing it, then just set 'SplitObjs=NO' in mk/build.mk and carry on. Cheers, Simon

2 1

RE: Unregistered build (was Re: AMD64)
by Gerd M 17 Jun '04

17 Jun '04

Simon Marlow wrote: >This one looks like a failure from GCC, not GHC. If possible, you >should send a bug report to the GCC folks or Gentoo as requested. > >You could try using a different version of GCC to work around the >problem. Unfortunately I've only got one gcc version installed at the moment and I'm not sure if installing another version won't break something... Maybe I will give it another try later this week, thanks for your help so far! Regards Gerd > >Cheers, > Simon _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1