April 2005 - Glasgow-haskell-users

RE: Viewing profiles with daVinci (uDraw)
by Simon Marlow 13 Apr '05

13 Apr '05

Oops, cgprof is a program used internally by ghcprof. Just shows how much I know about it! Cheers, Simon On 13 April 2005 16:37, Christian Maeder wrote: > ghcprof should be adapted to the new release of uDraw(Graph) > http://www.informatik.uni-bremen.de/uDrawGraph > > Who maintains ghcprof? (What has cgprof to do with it?) > > Christian > > Simon Marlow wrote: >> On 13 April 2005 14:00, Bernd Holzmüller wrote: >> >>> I am trying to create graphical profile information via +RTS -px >>> and then ghcprof <binary>.prof. However, the uDraw application >>> (former: daVinci) complains: "Option -startappl requires exactly >>> two arguments (<directory> <filename>)". Any idea? >> >> You might be the first person to try this in a while. I suspect >> some mismatch between the command-line syntax expected by your >> version of daVinci and the syntax cgprof expects to use. >> >> We don't use cgprof, does anyone else? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Viewing profiles with daVinci (uDraw)
by Simon Marlow 13 Apr '05

13 Apr '05

On 13 April 2005 14:00, Bernd Holzmüller wrote: > I am trying to create graphical profile information via +RTS -px and > then ghcprof <binary>.prof. > However, the uDraw application (former: daVinci) complains: "Option > -startappl requires exactly two arguments (<directory> <filename>)". > Any idea? You might be the first person to try this in a while. I suspect some mismatch between the command-line syntax expected by your version of daVinci and the syntax cgprof expects to use. We don't use cgprof, does anyone else? Cheers, Simon

2 1

Viewing profiles with daVinci (uDraw)
by Bernd Holzmüller 13 Apr '05

13 Apr '05

Hi all, I am trying to create graphical profile information via +RTS -px and then ghcprof <binary>.prof. However, the uDraw application (former: daVinci) complains: "Option -startappl requires exactly two arguments (<directory> <filename>)". Any idea? Thanks, Bernd

1 0

garbage collection
by Bulat Ziganshin 12 Apr '05

12 Apr '05

Hello glasgow-haskell-users, 1) can you add disableGC and enableGC procedures? this can significantly improve performance in some cases 2) if, for example, program's data before GC is 80 mb and after GC is 60 mb then the program will occupy after GC the whole 140 mb and ALL this space will be marked by OS as used! if there's a memory shortage, old program data even can be swapped to disk despite the fact that we absolutely don't need them! that behaviour significantly enlarge memory needs of GHC-compiled programs if this unused memory will be returned to OS or marked as unneeded after GC then will problem will go on. preferably this must be done during the time of GC, on each page which contents has been already compacted. in this case such program will never use more than 80mb of real memory (+ 1 page + memory for GC) -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Re[2]: GHC 6.4/mingw32: files larger than 4 GB andhFileSize/hSetFileSize/c_stat
by Bulat Ziganshin 12 Apr '05

12 Apr '05

Hello Simon, mingw32 have 32-bit off_t type; access to large files are supported with special functions and structures defined in msvcrrt.dll: _CRTIMP __int64 __cdecl _lseeki64(int, __int64, int); _CRTIMP __int64 __cdecl _telli64(int); _CRTIMP int __cdecl _fstati64(int, struct _stati64 *); _CRTIMP int __cdecl _stati64(const char *, struct _stati64 *); struct _stati64 { .... __int64 st_size; .... }; so, we need either 1) define COff to __int64 instead of off_t and rewrite existing functions to work with 64 bit filesizes or 2) define new set of low-level functions to work with 64 bit filesizes. define high-level functions in terms of these 64-bit functions on Win32 what solution will be better? in the first case COff no longer will be equal to off_t, what some applications can imply. in the second case we will add a lot of duplicating code is there any other (GHC-supported) environments supporting 64 bit filesizes, but having only 32-bit off_t? (sorry for my bad English, i'm too far from native speaker) Friday, April 08, 2005, 3:33:36 PM, you wrote: SPJ> By all means. If someone cares to send us a patch, we'll incorporate SPJ> it. SPJ> | While GHC I/O library on mingw32 platform perfectly reads and writes SPJ> | files larger than 4 GB, functions hFileSize/c_fstat, SPJ> | hSetFileSize/c_ftruncate and c_stat are still tied to C functions SPJ> | returning 32 bit values and as a result truncate larger sizes to their SPJ> | low 32 bits. Can this behaviour be fixed in the next bug-fix version? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
by SourceForge.net 12 Apr '05

12 Apr '05

Feature Requests item #1084122, was opened at 2004-12-12 17:54 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: John Skaller (skaller) Assigned to: Nobody/Anonymous (nobody) Summary: RPM doesn't support --prefix Initial Comment: After installing ghc for linux using rpm with --prefix=/usr/local, the ghc scriipt incorrectly thinks the libraries etc are in /usr: #!/bin/sh GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2"; TOPDIROPT="-B/usr/lib/ghc-6.2.2"; # Mini-driver for GHC exec $GHCBIN $TOPDIROPT ${1+"$@"} After editing, at least the compiler actually starts up :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-12 06:06 Message: Logged In: NO Still a problem with 6.2.4 - Additionally, you now need to edit the package.conf file. Karl M. Syring syring(a)email.com ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 08:26 Message: Logged In: YES user_id=48280 Re-opened. Any RPM gurus out there who could knock this one on the head? Note it's not just the ghc script, there's a couple of other scripts that need munging (ghci, ghc-pkg, hsc2hs maybe). ---------------------------------------------------------------------- Comment By: John Skaller (skaller) Date: 2004-12-13 06:54 Message: Logged In: YES user_id=5394 I can see it isn't supported :) However after the change to those two lines, the compiler works, links libraries, and the resultant binary executes correctly (as far as I can tell never having written any Haskell before .. :) So why not support it? I had no choice .. my root partition, containing /usr is 97% full.. :) ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 04:54 Message: Logged In: YES user_id=48280 You're trying to install the binary RPM using a different prefix? That's not supported, I'm afraid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_…

1 0

RE: installing ghc without already having ghc
by Simon Marlow 11 Apr '05

11 Apr '05

On 11 April 2005 16:25, Jessica Brennan [staff] wrote: >> Anything we can help with? > > I was able to get a binary for netbsd20 working. However with > building it I get a few errors. So I tried doing the cross compiling > an unregistered version, but I get the same errors in the same spot. > > ----------------------------------------------------------------------- > ==fptools== gmake all -wr; > in /devel/build/NetBSD/ghc/ghc-6.4/ghc/compiler > ------------------------------------------------------------------------ > test: unknownunknown: bad number > test: unknownunknown: bad number > test: unknownunknown: bad number > test: unknownunknown: bad number > test: unknownunknown: bad number > test: unknownunknown: bad number > test: unknownunknown: bad number Which step of the bootstrap is this? It looks like the configure script has failed to detect the version of GHC installed on your system. Cheers, Simon

2 1

RE: installing ghc without already having ghc
by Simon Marlow 11 Apr '05

11 Apr '05

On 08 April 2005 17:20, Jessica Brennan wrote: > On Fri, 8 Apr 2005, Tim Smith wrote: > >> On 2005 Apr 07, Jessica Brennan [staff] <jib(a)panix.com> wrote: >>> I am trying to install ghc-6.4 on netbsd20. I read through the >>> install instructions, however they say you need a working copy of >>> ghc already. >> >> I'd probably look here first: >> >> ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/ghc/README.html >> >> I expect that package should work for you; even if it doesn't, you >> should be able to use the work done there as a good starting point. > > Thanks with that binary I was able to build the program that I needed, > though I still wasn't able to build ghc from the source. Anything we can help with? Cheers, Simon

2 1

Porting the GHC to GNU/Hurd
by Thomas Schwinge 10 Apr '05

10 Apr '05

[ Grrr. Why do I have to subscribe just to post this message? ] Hello! Is someone aware of any efforts to port the GHC to GNU/Hurd? If not, I'd like to give that a try. Regards, Thomas

1 0

OpenGL/GLUT examples crashing: known problem?
by Tim Smith 09 Apr '05

09 Apr '05

Hi! I just got GLUT to compile with a recent GHC (tried both ghc6.4 and a fresh CVS), see: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1177838&group_… Anyways, now I did 'gmake' in GLUT/examples. Everything builds fine, but a number of the examples don't work. I.e., in RedBook: 2:39 ~/local/src/build/libraries/GLUT/examples/RedBook$ for f in `find . -type f -perm 755 -print`; do if $f >/dev/null 2>&1; then echo "$f OK"; else echo "$f failed"; fi; done ./Alpha OK ./BezCurve OK ./BezMesh failed ./BezSurf OK ./BlendEqn OK ./Checker OK ./Clip failed ./ColorMat failed ./ColorMatrix OK ./ColorTable OK ./Combiner OK ./Convolution OK ./Cube OK ./CubeMap failed ./DList OK ./Double OK ./DrawF OK ./Feedback OK ./Fog failed ./FogCoord OK ./Font OK ./Hello OK ./Histogram OK ./Image OK ./Light failed ./Lines OK ./MVArray failed ./Material failed ./Minmax OK ./Mipmap OK ./Model OK ./MoveLight failed ./MultiTex OK ./PickDepth OK ./PickSquare OK ./Planet failed ./Polys OK ./Quadric failed ./Robot OK ./Scene failed ./Select OK ./ShadowMap failed ./Smooth OK ./SurfPoints OK ./Surface failed ./Teapots failed ./Tess OK ./TexBind OK ./TessWind OK ./TexGen failed ./TexProx OK ./TexSub OK ./Texture3D OK ./TextureSurf OK ./Trim failed ./UnProject OK ./VArray OK ./Wrap OK This is probably some known bug, but I wanted to check. If so, does anyone know what the parameters are on what can be used, and what will core dump? If it's not a known bug, I'll file a bug report - any other info that would be helpful? Thank you! Tim -- If you're not part of the solution, you're part of the precipitate.

3 2