00:00:00 --- log: started haskell/05.04.22 00:00:15 Yeah, thats why I think the logic needs to be in the Ix instance... at least, with the current situation. 00:00:26 yes 00:00:31 I don't see what storable instances have to do with your compiler generating array code 00:00:51 it doesn't. they were unrelated problems. 00:01:06 they just both happened to involve the word 'array' :) 00:01:15 :-) 00:03:12 It might not be too bad if you provide like a getOrigin :: PixArray -> Spot then use (spot { x = 3, y = 4}) so the user never has to see the 'stride, padding and width' fields in the indices. but it is still hacky. 00:04:19 yes, make that the only way to construct a value of the index type, sadly it is a bit hacky 00:05:48 --- join: moomlyn (~moomlyn@CPE-203-45-44-84.vic.bigpond.net.au) joined #haskell 00:16:21 --- quit: mwc ("Leaving") 00:21:30 meuning 00:24:53 --- quit: Gahhh (Read error: 60 (Operation timed out)) 00:37:00 * wli watches hircules deadlock horrendously 00:37:09 --- quit: Pseudonym ("using sirc version 2.211+ssfe") 00:37:11 Okay, where do bugreports go? 00:38:00 (hircules:11838): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-1': Success 00:38:00 Exception: Maybe.fromJust: Nothing 00:38:06 that doesn't look so hot either 00:39:34 --- quit: Itkovian () 00:41:17 --- join: nlv11757_ (~niels@neo1a.ehv.campus.philips.com) joined #haskell 00:41:28 morning nlv 00:41:46 and #haskell 00:43:38 morning earthy 00:43:43 and #haskell ofcourse 00:43:55 --- join: abl (withersoev@S0106001111af03a8.ed.shawcable.net) joined #haskell 00:44:37 --- quit: dMaus ("Client exiting") 00:52:52 lol, surpriiiiise my ported ocaml pretty printer isnt too fast :P 00:53:43 well, pity 00:54:02 i'll profile it in my free time 00:54:23 what free time? 00:54:35 havent figured out that bit :P 00:54:48 ah, your Copious Free Time... 00:54:58 also called `ronde tuitjes' 00:55:05 hehe 00:55:55 i guess i wont be pretty printing the linux kernel anytime soon :P 00:58:31 It is likely the quadratic append problem. see the comment in the pretty printer that comes with the standard haskell library for an interesting anecdote about just that bug. 00:58:54 Any hints on what burned me wrt. hircules? 01:00:21 http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Text/PrettyPrint/HughesPJ.hs?rev=1.16 01:02:34 ok thnks john 01:08:27 ghcplatform.h:1:1: unterminated #ifndef 01:08:44 JohnMeacham: I was playing with jhc and noticed that using Data.Map in Frontend saved much memory (815mb -> 575mb) but runtimes grew by 5%... 01:09:05 Need I say "wtf?" 01:09:22 BUG: modifier "malloc" is not a name attribute 01:09:24 hehe 01:11:12 ah 01:11:20 it needs to figure out gcc -m32 somewhere 01:13:09 Eeek! 01:13:12 815MB? 01:13:19 What kind of beast is that? 01:15:53 feh, cross compilers are still absent 01:16:25 --- join: malcolm (~malcolm@abbess.demon.co.uk) joined #haskell 01:20:24 wlix: it's JohnMeacham's new jhc Haskell compiler that does whole program copilation and optimisation. Apparently it's producing some good code but the compilation itself is a bit on the memory hungary side at the moment. 01:21:58 --- join: Itkovian (~ageorges@dragnipur.elis.UGent.be) joined #haskell 01:25:34 unlit: cannot open "basicTypes/BasicTypes.lhs" 01:25:45 dcoutts_: As requested, I'll add the GPL licence file to hscolour later today. 01:30:24 malcolm, cheers, I was just editing the code now to make it do xhtml with and then using CSS rather than doing the colour directly 01:30:36 hscolour? 01:31:00 * Heffalump should catch up on the Haskell mailing list 01:31:20 Heffalump, malcolm's Haskell html/terminal syntax colouriser 01:31:26 dcoutts_: yes, that sounds nicer - I learnt HTML back in 1994, before such things existed! 01:31:37 ah, cool 01:31:39 (plain old curses sounds nice ot me) 01:32:06 wli, actually I was just ripping that bit of the code out :-) 01:32:46 --- join: martink_ (~martin@pD9EB2C6D.dip0.t-ipconnect.de) joined #haskell 01:33:31 does jhc just target x86? 01:33:48 it produces ansi C. 01:34:09 oh, and a minimal runtime system so presumably it'll be quite portable? 01:34:48 yes, but it still needs of work to be suitable for real world things. 01:35:18 yeah, I know 01:36:47 this business about not needing target support for tail calls, how does it avoid tail recursion blowing the stack? 01:37:24 oh, /me reads down 01:37:53 it's not obvious to me how that handles mutual recursion that wasn't inlined, though 01:44:48 --- quit: malcolm () 01:45:17 pretty hopeless 01:45:46 well, I guess if it uses a target that does support inlining it'll be fine 01:46:42 owwwww man, how sneaky 01:47:05 ? 01:47:10 so when's someone going to write a C-- front end for gcc? 01:47:13 if ... then ... else ... 01:47:13 >|< ... 01:47:13 >|< 01:47:13 s/inlining/tail calls/ in what I just said 01:47:19 dcoutts_: _front_ end? 01:47:27 parenthesis around the if forgotten, 01:47:35 why not? 01:47:36 nlv11757_: ah, yes 01:47:39 get SSA and all 01:47:39 so suddenly everything below belongs to the else branch :D 01:47:40 I run into that quite a bit 01:47:53 they claim it's not so hard to write gcc front ends these days, there's a HOWTO on the web 01:48:10 is the gcc intermediate language lower-level than C--? 01:48:47 Heffalump, I believe so, they've got the tree SSA form and the RTL form which are both lower level 01:49:17 Well it is not that writing gcc frontends is hard - but that they are quite ugly. 01:49:38 they've also got something called GIMPLE which is based on the stuff from mcgill I think 01:50:00 musasabi, 'cause you've got to write them in C ? :-) 01:50:48 yeah, I noticed it was based on the stuff Laurie did on McCat 01:50:57 this is a bit out of date now probably: http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html 01:51:02 from 2002 01:52:21 http://gcc.gnu.org/projects/tree-ssa/#gimple for some details on the IR 01:52:39 dcoutts_: yes, and the gcc is purposefully not very modular.. 01:53:17 musasabi, does it matter that much? 01:53:59 dcoutts_: if you don't mind "parse a bit, put stuff into global variables, call a function, goto 1" mentality then no. 01:54:24 I know they don't want non-FOSS programs to take advantage of the gcc backend for an open source front end I would have though it'd be ok 01:54:50 oh I see it's the statefull API that's unpleasent 01:56:28 I'm not saying a C-- front end would be a thing of beauty but it would be very useful. It should allow high level languages to generate decent code and be fairly portable. 01:57:15 dcoutts_: I agree it would be quite nice, not something that would be fun to hack on one's free time though. 01:57:16 * wli watches the impending breakage as gtk2hs shows clear signs of being about to fail to build 01:57:31 I suppose the qcmm people must have looked into it, so I wonder what the reasons to go a different route were 01:58:08 wli, :-) is that you trying to get it to work with ghc 6.4? 01:58:20 nope, 6.2 01:58:31 wli, or trying to get it to build using less than 1Gb ram? :-) 01:58:49 it's exploding all over the place, starting with autoconf > 2.13 puking all over configure.ac 01:59:02 ./configure: line 4588: syntax error near unexpected token `GLIB,gobject-2.0' 01:59:02 ./configure: line 4588: `PKG_CHECK_MODULES(GLIB,gobject-2.0 >= 2.0.0)' 01:59:06 crap like that too 01:59:27 yes, I think we were using autoconf-2.5x 01:59:48 dcoutts: well, it doesn't work with autoconf2.50 or autoconf2.59, only autoconf2.13 02:00:02 do you need to autoreconf? are you having to patch configure.ac or Makefile.am? 02:00:16 Commenting garbage out of configure.ac configure.ac 02:00:35 --- join: magr (~magr@patroclus.uebb.cs.tu-berlin.de) joined #haskell 02:01:11 it was the very first program check 02:01:14 doesn't work with autoconf2.59? that's the version that I use 02:01:44 diff -u -r1.38 configure.ac 02:01:44 --- configure.ac 11 Apr 2005 02:46:07 -0000 1.38 02:01:44 +++ configure.ac 22 Apr 2005 09:02:33 -0000 02:01:44 @@ -42,7 +42,6 @@ 02:01:44 ]) 02:01:44 02:01:45 Maybe you meant: pl wn 02:01:46 dnl Checks for programs. 02:01:48 -AM_PROG_CC_C_O 02:01:50 AC_PROG_CPP 02:01:52 AC_PROG_INSTALL 02:01:54 AC_PROG_LN_S 02:01:59 that's what puked 02:02:06 Maybe debian screws with autoconf 02:02:29 I wouldn't put it beyond them in the least. 02:02:45 yes, I never know about that line, some versions of automake demand that it be there and others don't 02:03:23 so what was it you needed to patch in configure.ac ? 02:03:45 dcoutts: I pasted cvs diff -u to the channel 02:04:02 oh 02:04:05 right 02:04:51 and that stops ./configure --bla-bla from working? ie the one that comes pre-built in the tarball 02:05:20 dcoutts: it stops the configure script from being generated; autoreconf fails 02:05:32 dcoutts: the configure script failing with the second paste I've not figured out how to fix yet 02:05:45 do you always autoreconf as a policy or do you use the original ./configure if it works? 02:06:46 dcoutts: I grabbed cvs. ./configure was not present in cvs, as it is a generated file. 02:07:13 oh, cvs version, ok 02:07:40 hircules says it needs cvs 02:09:14 on http://haskell.org/hircules/ that news item is a tad old. I dobt the current cvs version would work for it 02:10:03 we've changed quite a bit since 2003, like using hierarcical module names 02:10:06 I'm about to find out. 02:11:14 ok, so you did a cvs checkout, you did autoreconf-2.59 and the first error was? 02:12:21 dcouttts: let me back out to virgin 02:13:30 $ autoreconf --version 02:13:30 autoreconf (GNU Autoconf) 2.59 02:13:31 ... 02:13:40 $ autoreconf 02:13:40 aclocal: configure.ac: 45: macro `AM_PROG_CC_C_O' not found in library 02:13:40 autoreconf2.50: aclocal failed with exit status: 1 02:13:58 this could be a debian problem 02:14:33 so this is an automake marco that automake really wants to be there. I think it complains bitterly if its not. 02:15:02 I don't think I understand the patch you posted earlier. You were doing what? 02:15:09 dcoutts: if you look carefully it says it's version 2.50 02:15:26 dcoutts: it removed the AM_PROG_CC_C_O usage 02:16:42 yes, version 2.50. Is that the latest version you've got (often you'll have several versions of autoconf/automake since many packages require specific versions) 02:17:11 dcoutts: I invoked 2.59 and something went wrong with debian magic and it got redirected to 2.50 02:17:26 If I take out the AM_PROG_CC_C_O line then it complains: 02:17:27 Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.ac' 02:17:27 autoreconf-2.59: automake failed with exit status: 1 02:18:39 it's still puking here 02:18:49 reputedly 2.59 but not reporting a version string in the error message 02:18:52 ok, try editing configure.ac and changing the line "AC_PREREQ(2.50)" to require 2.59 02:19:02 $ autoconf 02:19:03 configure.ac:45: error: possibly undefined macro: AM_PROG_CC_C_O 02:19:03 If this token and others are legitimate, please use m4_pattern_allow. 02:19:03 See the Autoconf documentation. 02:19:56 OOh. can you send a patch? converting everything to use Data.Map consistantly has been on my todo list forever. I was worried because bias of some functions was different so I didn't want to do a search and replace. 02:20:02 $ autoreconf 02:20:02 aclocal: configure.ac: 46: macro `AM_PROG_CC_C_O' not found in library 02:20:02 autoreconf: aclocal failed with exit status: 1 02:20:05 same 02:20:13 dcoutts: what's aclocal where you're at? 02:20:23 that was for musasabi 02:20:29 * wli ritually anathematizes auto* etc. while he's at it. 02:21:17 aclocal has lots of stuff put there by automake but no `AM_PROG_CC_C_O' macro 02:21:40 dcoutts: how about automake? 02:21:53 $ automake --version 02:21:53 automake (GNU automake) 1.4-p6 02:22:38 I really want a c-- frontend for gcc.... 02:22:52 well Makefile.am says it requires 1.8 and automake will use the appropriate version of itself even if automake --version would suggest otherwise 02:23:05 but you can try automake-1.9 02:23:21 dcoutts: it's got to be something random different 02:23:31 dcoutts: it's automake, only 1.4-p6 is installed 02:23:44 My thoughts were to write the cmm to GIMPLE converter in haskell, then do a simple raw GIMPLE shim front end for gcc. then you could reuse the cmm stuff from ghc. 02:24:35 wli, I wonder why when you run automake it doesn't complain that it it too old to process Makefile.am 02:24:46 dcoutts: any way to get a proper version error out of automake? 02:26:14 wli, try $ automake -v --gnu that should make it throw fits :-) 02:26:52 okay, tons of warnings (at the very least): 02:26:55 /usr/share/aclocal/tcl.m4:124: warning: underquoted definition of SC_PATH_TKCONFIG 02:26:56 /usr/share/aclocal/tcl.m4:228: warning: underquoted definition of SC_LOAD_TCLCONFIG 02:27:16 let's nuke 1.9 and roll back to 1.8 02:27:31 I don't trust the debian autodetaction of needed versions any further than I can throw it. 02:27:56 yeah, sure enough 1.9 puked all over that stuff 02:28:13 the underquoted stuff is all fine, it's usually complaining about other packages that have not updated their installed marcos 02:28:26 the fatal stuff was:` 02:28:27 configure.ac: required file `./missing' not found 02:28:27 automake: cannot open < /usr/share/automake-1.9/am/header-vars.am: No such file or directory 02:29:04 wild guess is that means the deb 1.9 package is broken 02:29:21 for the required file not found issue, use $ autoreconf --install 02:29:24 okay, and it puked: 02:29:25 configure.ac: required file `./missing' not found 02:29:25 Makefile.am: required file `./compile' not found 02:29:25 Makefile.am: required file `./depcomp' not found 02:29:25 autoreconf: automake failed with exit status: 1 02:29:25 autoreconf 46.48s user 2.48s system 92% cpu 53.040 total 02:30:16 if you only got those three errors thats a good sign :-) 02:30:21 dcoutts: call me an old fuddy-duddy or whatever, but maybe things are better off without the autotools 02:30:37 wli, tell me about it, it's all black magic 02:30:42 wil :: wooo! 02:31:28 autoconf is reasonable, automake considerably more evil 02:31:49 heheh automake asks for soooo much investment before it gives back 02:31:55 As far as I'm concerned the whole lot should go to Hell. 02:31:56 wli, SimonM was trying to build on fedora core 3 and kept getting this autoconf problem which we never did figure out and juhp could not reproduce. definately evil. 02:32:13 and most people don't actually use the information autoconf gives them 02:32:54 To add insult to injury, they're dogslow and singlethreaded. 02:33:18 having re-implemented our build system using automake I can advise everyone else that automake is not well suited for languages other than the few in genuinely supports (ie C/C++) 02:33:32 this is where we get distros medaling with tools breaking them in unique and irritating ways, sometimes fixing them 02:33:40 dcoutts :: i'd agree with that 02:34:35 it's all hackery upon hackery, and its basically because make is just not good enough 02:34:39 Well, personally I refuse to ever use autotools in any userspace stuff I write. 02:35:07 autoconf does make some things a lot easier though 02:35:22 dcoutts: do tell 02:35:31 a consistant configuration interface 02:35:47 very useful when you want to compile something, it usually behaves in a way you expect 02:36:24 You may need to be more concrete and beat me over the head with it. I'm just a kernel hacker, I've never seen these things be anything but a pain wrt. building and/or hacking on other people's userspace programs. 02:37:26 ie, i have a build environment with CFLAGS, CPPFLAGS, LDFLAGS, CXXFLAGS, F77FLAGS, can go --prefix=/tool/foo --exec-prefix=/tool/foo/ultrasparcIII-Solaris9/ --some-options=foo 02:37:26 if we got rid of autoconf we'd have to replace it with something similar that checked for the existance of ghc, etc did various different things depending on the version of ghc, then there's the thing that C tools support autoconf well, we can do all our checks for gtk+ quite easily 02:38:27 something like autoconf is the wrong solution to finding packages 02:38:57 --- quit: Itkovian () 02:39:08 gah. FrontEnd.Env is a monstrositiy... no offense to the hatchet authors.. but they sure seemed to like to do things in oddly circuitous ways sometimes. 02:39:23 wli, oh, sure it's a pain to try to understand some random projects autoconf/automake system. It is a barrier to contributors I think that once they've got some code they think should work and would like to contribute they then have to extend configure.ac/Makefile.am to do something or other without really understanding it. 02:39:38 it's just blindly following existing patterns 02:39:57 okay, the mozembed stuff is throwing me because I can't find the debain package 02:40:02 and if you need to do something new, you're stuffed 02:40:04 A simple app directory scheme would solve the problem for non-system base libraries and programs, and the system base stuff compatibility wrappers and such could be written 02:40:12 ./configure --disable-mozilla 02:40:17 +for 02:40:57 maintining autoconf scripts is also lots of redundant between projects 02:41:02 wli, alternatively the package is probably mozilla-devel or something like that 02:41:56 wli, whichever mozilla package that provides mozilla-gtkmozembed.pc 02:45:47 wli, so after all this hassle, is there anything I can change that will make the cvs checkout build "out of the box" ? What things did we fix to make it work in the end? 02:46:12 JohnMeacham: yes, I can send the patch. 02:46:18 dcoutts: nothing for out-of-the-box, but finding some way to give a clear automake version error might help 02:46:59 did you edit the AC_PREREQ(2.50) line in the end? 02:47:31 yes 02:47:55 did that change things? should I do that in cvs? 02:48:21 dcoutts: it didn't change anything but it will give better errors for autoconf version mismatches since 2.50 doesn't work 02:48:57 musasabi: no need. I have started converting things and getting rid of FrontEnd.Env alltogether at the same time. 02:49:21 If I realized it made that much of a difference I would have done it sooner. 02:49:38 --- join: Itkovian (~ageorges@dragnipur.elis.UGent.be) joined #haskell 02:49:52 dcoutts: I was getting nailed by debian screwups where invoking autoconf with their autodetection of autoconf versions would invoke one version for some pieces and another version for others (recursive invocation???) 02:49:56 does Data.Map.insertWith pass the existing value as the left or right argument of the combining function? 02:50:32 http://www.cs.helsinki.fi/u/ekarttun/haskell/convert-frontend-to-data.map.patch 02:51:23 dcoutts: I "solved" this by eliminating all automake and autoconf versions installed besides the ones the program absolutely required. 02:51:25 It seems that joining the maps is taking ~20% of execution time with both finitemaps and maps. 02:51:37 So getting rid of Frontend.Env would be a good thing. 02:52:02 dcoutts: INSTALL/README notes about parallel installed versions of automake/autoconf screwing up may also help. 02:52:06 JohnMeacham: yes, the argument order is reversed as compared to addToFM_C. 02:52:21 wli, probably not recursive, we've only got a single global configure.ac and Makefile.am (recursive make consdiered harmfull - another nice idea that automake doesn't properly support) 02:52:44 * wli crosses his fingers wrt. mozilla-dev being the "mozembed" stuff. 02:53:19 wli, ok, I'll document these things and the autoreconf --install for cvs users 02:53:25 thanks 02:53:49 dcoutts: mozilla-dev is the gtk-mozembed package for debian 02:54:21 6 cpus, 3.5GB RAM on this box 02:54:42 ok, I'll mention that, I think it's the same for fedora and others 02:55:22 wli, sadly you can't make -j 6 as the automake generated makefile will break horribly :-) 02:56:02 dcoutts: I did make -j 16, I'm watching it break, then. 02:56:23 wli, good luck! 02:56:25 brilliant 02:56:29 automake generates crap makefiles, too 02:56:54 remind me of the benefits of autotools again? =) 02:56:59 er... 02:58:19 roll on improved cabal stuff I say. cabal doesn't yet support things that want to install half a dozen packages (and build a few tools to get there) 02:59:01 I think the makefile is infinite looping instead of finishing the build. 02:59:11 Yeah, I think a problem is that the unification algorithm uses substitution maps rather than in-place updates. 02:59:40 I'll document the -j oh-no-you-don't fact too :-) 03:00:06 * wli watches 5 cpus sit idle while an individual cpu (and the individual cpus here are slow) grinds helplessly away for hours on it 03:00:55 blocking on butt-slow nfs filesystem IO single-threadedly even beyond the dogslow individual cpus... 03:01:15 even the lone cpu is mostly idle 03:01:18 wli, sorry :-( if it makes you feel better I get the same effect on my old sparc here 03:01:38 dcoutts: UltraEnterprise 3000, 6x 300MHz UltraSPARC II. 03:02:06 chosen specifically for its ability to do parallel builds... 03:02:28 so I'm crawling along a bit faster at 500MHz UltraSPARC IIe 03:02:43 musasabi: thanks for investigating this! 03:03:11 dcoutts: Well, it's mostly IO-bound, so in principle, with all the cpus busy, it does well. 03:03:32 Of course, the sad, sad, x86-64 story doesn't help my quad x86-64 box I could otherwise use for all this. 03:03:46 for C code with decent makefiles (like the kernel) I'm sure it's great 03:04:23 Not sure what the ppc64 story is at all but there's a dual G5 wishing it could do anything sitting around too (I appear to largely be making use of it for video playback since the Apple Cinema display is rather nifty). 03:04:32 gtk2hs builds on x86-64 it's just that most of the demos immediatly segfault :-) 03:04:59 ghc's rts seems to be treading on stuff allocated by gtk+ / pango 03:05:16 dcoutts: My autotools/etc. "wizardry" is insufficient to get a basic x86-64 haskell setup going. 03:05:29 --- quit: noclouds (Remote closed the connection) 03:05:48 If it were lower-level stuff I could probably cope. 03:05:53 you're using debian right? it has ghc for x86-64 I'm sure 03:06:08 That is probably due to the horrible FFI bug with x86-64 I posted to the list. 03:06:08 or you can use SimonM's binary snapshot 03:06:13 The x86-64 box is SLES9, 9.1 etc. 03:06:30 Everything appears to *REALLY* hate SuSE. 03:06:53 It is pretty much a showstopper, seems worthy of a point-release of ghc to fix.. 03:06:56 JohnMeacham, yes that looked interesting, though I don't think we were using any "&foo" ffi style things 03:07:05 ah. 03:07:31 It's basically flying blind on rpm deps with --nodeps everywhere since the pkg names and splits are different and then praying binary compat wrt. library symbol usage doesn't stop the show. 03:07:43 we're using that for importing C finalisers but in my tests I don't think any of them were being run before I found the corruption 03:07:57 --- join: yoda- (einstien@l3-202-89-187-38.arach.net.au) joined #haskell 03:08:24 wli, SimonM's snapshot should work on anything I think 03:08:25 I think it's safe to call SuSE a doorstop wrt. Haskell atm. 03:09:15 wli, you should be using Gentoo, we've now got 3 dedicated developers in the Haskell herd :-) 03:09:19 dcoutts: I don't see an obvious download link. 03:09:35 wli, I'll find the link... 03:10:05 dcoutts: The x86-64 box is destined to run 32-bit debian userspace (it's currently residue.holomorphy.com but will have holomorphy.com's disks transplanted to it in the eventual future). 03:10:51 The sparc64 box with the gtk2hs build running is analyticity.holomorphy.com. 03:12:23 I think the G5 is going to become the next monad.holomorphy.com and will eventually be visible to the world. 03:13:22 (Im' debating making it monodromy.holomorphy.com but it's a little painful since there's another MacOX X box, a G3, parked on that hostname) 03:14:37 Anyway, I got burned by gentoo a while ago and it's got a couple of years still before I'm willing to give it another shot. 03:17:09 PACKAGE_VERSION et al get redefinition warnings 03:18:56 looks like I won't have anything to look at until sometime tomorrow 03:19:12 wli, found it: http://www.haskell.org//pipermail/glasgow-haskell-users/2005-March/008097.html 03:19:13 'morning 03:19:43 JohnMeacham: np, the code is is fun to hack. 03:24:22 feh, no ghci 03:24:31 yep 03:25:04 kind of painful, I do significant amounts of work in ghci 03:26:32 After extreme amounts of pain, I fooled every shell script, makefile, and C/cpp/Haskell hardcoded piece of crap in ghc and fixed up some assorted oddities (I think it probably took over a month, not that someone else who knew wtf they were doing couldn't have done it faster) into dropping an i386 ghc onto the SuSE x86-64 box. 03:26:47 ghci included 03:27:09 Where ghci was the point of the exercise. 03:27:17 and it worked? 03:27:28 there were a number of attempts that didn't work 03:27:51 I think most of the problems were centered around invoking external things like gcc/ld/etc. wrongly 03:28:12 they're still not 100% cleaned up, I have to use shell script wrappers to pass the -m32 etc. options 03:28:33 The cases where the wrappers weren't enough I finally pinned down, though. 03:28:44 you can add -m32 to the ghc_extra_opts of package base 03:28:54 It wasn't enough. 03:28:57 JohnMeacham: what parts of the code are you actively working on? (So I will look into other things and not do overlapping stuff) 03:29:15 Or at least I remember finding some obviously canonical place to throw in options and it not being enough. 03:31:14 It's hard to believe the x86-46 ghci isn't there yet; x86-64 just doesn't have so many relocation types that it hurts to implement the linking. 03:31:17 --- join: theorbtwo (~theorb@84-245-186-27.muc.bpool.celox.de) joined #haskell 03:31:37 Not that I understand a single line of Linker.c 03:31:51 wli, me either! 03:32:08 I don't know what it is about linker writers. 03:32:12 Or at least the opensource ones. 03:32:25 (I've seen closed-source linkers that were comprehensible.) 03:32:48 libbfd, Linker.c, etc. etc. 03:33:08 The NT DLL loaders for e.g. video players, too. 03:33:23 I'm looking forward to the demise of Linker.c in favour of using the standard dl and haskell packages as .so files 03:33:57 Such a simple task as walking over binary data and following the directions given by the various tables etc. obfuscated to degrees unparallelled in any other field of programming. 03:34:14 :-) 03:34:51 And bizarrely the commercial equivalents are completely immune to whatever phenomenno this is. 03:35:06 The two I've seen, that is. 03:36:08 --- quit: dude4545 (Client Quit) 03:37:35 The only ghci porting threads I can find are the ones where I bitched about the things being broken on sparc64. 03:38:28 /usr/lib/ghc-6.2.2/include/config.h:1047:1: warning: "PACKAGE_VERSION" redefined 03:38:29 In file included from :24: 03:38:29 gtk2hs-config.h:88:1: warning: this is the location of the previous definition 03:38:36 dcoutts: there's the redefinition error 03:38:44 er, warning 03:38:48 wli, yes, don't worry about it 03:39:21 I am still getting rid of the vestiges of FrontEnv.Env 03:39:38 I made an informal todo list on the Jhc page of the wiki. 03:39:50 it's because hsc2hs #includes ghc's autoconf-generated config.h and we include our own and so some things clash, but nothing that maters 03:40:05 feel free to add stuff. it is not very complete. 03:42:54 --- join: malcolm (~malcolm@abbess.demon.co.uk) joined #haskell 03:43:05 I just added the full contents of my local todo list. 03:43:23 http://haskell.org/hawiki/Jhc 03:43:23 I was thinking about learning how to do graphics stuff... 03:44:19 wli, learing gtk(2ha) is not so hard 03:44:33 ha/hs 03:45:09 dcoutts: Well, I had more in mind stuff like dumping physical models etc. onto screens rendered etc. 03:45:19 JohnMeacham: currently I am looking at Relation.. 03:45:50 dcoutts: I'm not sure general windowing is mathy enough to hold my interest. 03:45:52 ah. it is just used for mutually recursive module exports. 03:46:20 wli, we had one person do a ray tracer, it used the Pixbuf support to display stuff in a gui and from there to save to png/jpeg etc 03:47:33 dcoutts: could be interesting 03:47:44 he had a function that generated a list of colors and then with a little glue code we stuff that into a Pixbuf which can be displayed or otherwise manipulated 03:48:26 I've been looking mostly at hopengl (gtk2hs is mostly for hircules, which I wanted to try out) 03:48:35 is it bitmap or vector or 3d you'd need? 03:48:44 oh, 3D stuff 03:49:08 by and large I've been farting around with surface models 03:49:15 not getting very far 03:49:30 gtk+hs had hOpenGL support but we've not ported it to gtk2hs yet 03:50:06 it's on our todo list along with cairo support 03:50:58 there. no more FrontEnd.Env. 03:52:32 --- quit: theorbtwo ("Download Gaim: http://gaim.sourceforge.net/") 03:54:51 --- join: dude4545 (DTT0OfS2@pool-70-107-32-219.ny325.east.verizon.net) joined #haskell 03:55:20 --- join: ves (~adebisi@cpc2-john1-4-0-cust166.renf.cable.ntl.com) joined #haskell 03:56:28 --- join: Dabian (M0RTEN@dabian.member.fsf) joined #haskell 03:56:37 Hi Dabian : ) 03:56:38 anyway, the stuff I've been farting around with has been attempts to use piecewise iplicit cubic and quadric surfaces 03:56:48 Are you Paltas? 03:56:55 ;-) 03:57:06 Dabian, Forgot to kill my client in Odense. 03:57:11 e.g. pieces like x^t A x + + c = 0 03:57:37 where x = (x1, x2, x3) etc. 03:58:09 The idea being that you can test intersections with lines and planes using conic section gunk and/or elliptic curve gunk. 03:58:25 wli, lol! I've just made such a assignment 03:58:34 just only with lines. 03:59:20 Haskell is crazy :) 03:59:22 Palle: hmm, this has stymied me for a while, maybe you know an answer. How does one get consistent equations for the coefficients from a triangulated set of points etc.? 03:59:33 It was just a very special version, about using a AVL tree.. 03:59:59 I think elib 1.0 provides avltree.el 04:00:02 (I actually had my heart set on the cubic variation of this.) 04:00:13 -- If minx we insert, if maxx we delete else we preform a rangeSearch 04:00:13 sweepLine :: [ListEntry] -> AVL [Char] -> [(SegID, SegID)] 04:00:13 sweepLine [] d = [] 04:00:13 sweepLine ((x, segid, LMinX, y, _):ls) d = sweepLine ls (insert (y, segid) d) 04:00:13 sweepLine ((x, segid, LMaxX, y, _):ls) d = sweepLine ls (delete y d) 04:00:14 sweepLine ((x, segid, LX, y1, y2):ls) d = getSegID segid (rangeSearch y1 y2 d) ++ sweepLine ls d 04:00:47 properly not the same method we are speaking about, finding the intersection lines 04:01:20 Dabian, The craft of functional programming 04:01:20 :) 04:01:35 Palle: Well, I don't have so many problems with the e.g. intersection methods since those were thought through up-front, but rather, when I have a surface whose pieces are composed of these things, how to get useful equations for the coefficients. 04:01:54 --- join: Narrenschiff (~ritchie@itsnotthatbig.plus.com) joined #haskell 04:02:13 vs. inconsistent or underdetermined equations. 04:02:56 wli, your level of mathematics is properly higher than mine, so I properly don't have a solution 04:03:12 I actually can't figure out how to cope with any surface model apart from piecewise planar surfaces. 04:03:20 Because of that single issue. 04:03:50 --- join: theorbtwo (~theorb@84-245-186-27.muc.bpool.celox.de) joined #haskell 04:04:25 I have other, worse issues, like I've never gotten useful interaction of a surface model with a rendering scheme (output) or any kind of successful model of a real world object (input), but I'm holding out until I can do the basic parts before trying to deal with those issues. 04:05:20 JohnMeacham: btw when reading jhc code should I add haddock comments to it (no real hassle when I am working on understanding what different parts do) ? 04:06:50 palle: ANyway, for the cubic part, the intersection with a plane is particularly pretty; elliptic curve bits allow you to parametrize the curve of intersection outright. 04:07:17 musasabi: maybe lhs comments would be better for describing the code 04:07:23 Sure. that would be great. 04:07:35 Palle: This is the captivating bit that has me hooked on this thing. 04:07:38 --- join: JaffaCake (~simonmar@tide17.microsoft.com) joined #haskell 04:08:39 skew: the source is not literate, and personally I like haddock better ;) 04:08:40 Palle: (This isn't anything deep per se, just reusing someone else's theorem I happen to know offhand, and then plug-and-chug with the formulae.) 04:09:23 wli e.g. pieces like x^t A x + + c = 0 04:09:23 wli where x = (x1, x2, x3) etc. 04:09:29 but this is actually the problem? 04:09:42 musasabi: I think they have different purposes. Haddock is far better for documenting public interfaces, but I like lhs for following along and explaining complicated details, motivation, all that kind of stuff 04:09:54 Hmmm. I thought I fixed the empty lines problem... 04:09:57 Palle: each piece is meant to cover a triangle in the triangulation of the sample points of the surface. 04:12:09 skew: yes, but on the other hand that does not help for documenting interfaces.. But now away for lunch. 04:12:24 but what you wrote up seems like determin the roots from a n-degree polynomia? 04:12:52 this is way to mathematical for me. 04:12:53 TFK: I tested your PasteBin, and what appear to be empty leading and trailing lines are actually due to the output of hscolour getting truncated. 04:12:58 Mathematics suck. :) 04:13:07 Palle: that's the quadratic case, and it's a surface, degree 2, 3 variables, 1 constraint 04:13:13 (or a variety) 04:13:29 Programming is the mathematics of 21st century, except that it does not suck. :-) 04:13:32 ah and elippisic there is the problem? 04:13:50 I'm glad that I only need a course in Discrete Mathematics and Linear Algabra. 04:13:58 malcolm, hmmm. why does it get truncated? 04:14:14 I will post unsolicited links: 04:14:18 http://www.politiken.dk/media/grafik/4067.gif 04:14:37 Palle: Not the ellipse, no. It's figuring out what the coefficients (the matrix A, the vector b, and the scalar c) should be from the triangular mesh. 04:14:50 Dabian, hahaha! :) 04:15:16 wli, aha! 04:15:21 TFK: don't know. Maybe something to do with running it as a separate process, with the consequent issues of flushing pipes and all that. 04:15:29 anybody remember how to do subscripts and superscripts in HTML? 04:15:43 Palle: :) 04:15:45 Well, in my tests it worked fine. Can you tell me how to replicate the problem? 04:15:46 debian :: care to translate into english? 04:15:51 wli, but it seems like a Math problem, not a haskell programming problem 04:15:58 df_: Will german do? 04:16:11 df_, Mathematics Genuis: Virgin his entire life 04:16:33 First singer in a avarage rockband = 300 woman per. year 04:16:36 Justice? 04:16:41 -- 04:16:48 Palle: Not really math, more like graphics/physics/etc. 04:16:50 Matematisches geni, jungfrau fuer dass ganze leben 04:16:55 hehe 04:17:11 ta palle, debian 04:17:14 Mathematics genuis by his life worsest equation. 04:17:20 Palle: Something of an arbitrary design decision to be made for the "most pleasing" results. 04:17:27 TFK: have a look at 6.html generated by your PasteBin (I can't remember the URL) 04:17:36 Who's this? Erdos? 04:17:40 wli, I'm only C.S. student :( 04:17:42 df_: The unterscrift sagt : A mathematican facing the most diffecould equation of his life. ;-) 04:17:43 Yeah, I did (that's why I was puzzled :-) 04:17:58 Palle: Well, the graphics people supposedly figure out how to do this. 04:17:59 df_, properly a better translation :) 04:18:16 wli, Really.. seems mutch more of science for these people :) 04:18:20 Palle: The notion is to cook up a "new" surface model so ther eisn't an answer to this floating around. 04:18:29 Palle: That I know of, anyway. 04:18:33 Well, at least re-pasting it worked. 04:18:38 --- quit: autrijus (Read error: 110 (Connection timed out)) 04:19:08 Palle: Not at all, checking out Chris Hecker's talks on conference schedules discovers graphics geeks banging out partial diffeq solvers to better simulate splashing water etc. 04:19:15 TFK: There are about 20 lines missing from the output. 04:20:05 TFK: I suggest you find a largish chunk of haskell code (say hscolour itself?) and try that out - see if it all appears, or if some gets truncated. 04:20:16 Anyway, the implicit cubic curve has 20 degrees of freedom. 04:20:25 er 04:20:29 implicit cubic surface 04:20:30 wli: no kidding, the hard part a lot of the time is making all the hacks interoperate... 04:20:31 wli, but it's still hard mathematics .. but well yes.. 04:20:48 Palle: it's mostly-solved mathematics, you go looking for what other people've done for you 04:20:52 TFK: I suspect it may be that only one buffer-full (4096 chars) gets through. 04:20:56 wli, Are you studying mathematics since you got into such a trouble? 04:20:56 Palle: nah, no new discoveries 04:20:57 malcolm, oh... hmmm, OK, I will try that. 04:21:27 wli: right. Chris Hecker may be a big name but he's the first to point out all he did was popularise age-old material 04:21:39 Palle: I studied mathematics in school, graduated about 5-6 years ago, etc. 04:22:00 wli, Okay. At collage/university i guess? 04:22:20 Palle: Yes. I've mostly been looking at 1890's-era material for useful bits to scavenge. 04:22:40 musasabi: if you are submitting documentation update patches, could you also delete all whitespace at the end of lines? I forgot to filter everything in the initial import. for these doc/cleanup patches it is best to not touch too many files in the same patch to avoid spurious conflicts with other patches that need to touch multiple files. 04:23:06 Philippa: Any thoughts on the piecewise implicit cubic surface issue? 04:23:13 :%s/ *$// in vim will do it. don't bother with files you arn't editing anyway. 04:23:31 wli: sadly not, it's a long time since I was doing graphics vaguely seriously myself :-( 04:23:55 That reminds me, I should go back to the p-adic surd simplifier at some point. 04:23:56 well, I might have if I were walked through it bit by bit, but my brain's been a bit slow the last few weeks 04:25:02 Philippa: I haven't gotten far enough (embarrassingly, in something over a year) for there to be anything to walk over. Cover each triangle with an implicit cubic surface (3 vars, degree 3) and somehow get equations for the coefficients. I've never figured out how to get the coefficients out of a triangular mesh. 04:25:09 --- quit: jewel (Read error: 110 (Connection timed out)) 04:25:57 It's somewhat interesting to see someone obviously completely new to programming (using wordpad to edit haskell source files) investigating the list monad :) (referring to haskell-cafe posts) 04:26:19 wli, Which mathematicans/subject is interestning in 1890, I can only think of De'Morgan and Ada, but it's a bit earlier. 04:26:20 (the implicit cubic surface looks like C1*x**3+C2*x**2*y+C3*x*y**2+C4*y**3+C5*x**2*z+C6*x*z**2+C7*z**3+C8*y**2*z+C9*y*z**3+C10*x*y*z+C11*x**2+C12*y**2+C13*z**2+C14*x*y+C15*x*z+C16*y*z+C17*x+C18*y+C19*z+C20=0) 04:26:25 Hmmm, hbin code x3 makes hbin.exe not terminate. 04:26:29 Palle: Try Ramanujan. 04:26:29 Well, I suppose it's possible that they're new to windows. 04:26:56 Yeah, I spent a lot of time de-literating the hatchet source to use in jhc. please don't reintroduce lhs files. 04:27:00 wli: what's the purpose in this particular case? 04:27:04 (and Lebesgue, Brouwer, Whittaker, Watson, et al) 04:27:13 is there a reason that eg some flavour of subdivision surfaces won't work? 04:27:37 (eg you need an equation) 04:28:06 Philippa: It's supposed to be a flavor of such, so you e.g. do your mesh refinement based on these cubic surfaces. 04:28:10 JohnMeacham: Why not just { for file in *.lhs; do unlit $file >`basename $file .lhs`.hs; done } 04:29:40 I could have used that advice about 3 years ago :) 04:29:56 Philippa: The hope is that the refinement can be done in larger steps with the high degree, so instead of doubling the number of points one chops them up into e.g. 256 pieces in one shot. 04:30:13 The unlit tool I had at the time stripped the comments rather than turning them into hs-style comments. 04:31:07 and it wasn't really a lot of time. I just periodically did one file I happened to be editing. But yeah, I am trying to haddockize the source. 'make hsdocs' will create haddock docs for everything. 04:31:17 Yup, it doesn't terminate for any longish code... 04:31:52 Philippa: The reason why I think it's vaguely plausible is because I've got an analytic attack on how to do intersections with planes etc. for cutting corners. 04:31:58 wli: fair enough. My brain's definitely in first gear today, sorry 04:32:04 JohnMeacham: If you had the source to unlit, I'm sure it would have been easy enough to generate comments instead of discarding documentation. Water under the bridge I suppose. 04:32:16 I'm looking over the lhs2TeX documentation trying to figure out how to mix lhs and Haddoc comments 04:32:59 Philippa: And the "special functions" involved are actually cheaper than trigonometric functions to compute, there are "AGM methods" that converge quadratically (numerical sense, the error squares at each iteration). 04:33:21 yeah. it wasn't really a decision. if I even sat down intent on converting the lhs files to hs I would have done that. but it just sort of happened every now and again when the lhs files anoyed me... 04:33:32 wli: cool 04:34:06 --- join: arjanb (arjanb@borganism.student.utwente.nl) joined #haskell 04:34:17 I just need to redo this so I'm not actually using the trig functions as subroutines. =) 04:34:20 df_: Are you from switcherland? 04:34:43 df_: (Just a random guessing) 04:36:05 Dabian, Bist du froh, bei deutsch sprechen? 04:37:05 England 04:37:07 --- part: Itkovian left #haskell 04:37:10 --- join: dave2718 (~~dave@ip-85-160-93-179.eurotel.cz) joined #haskell 04:37:23 oh, yeah 04:38:05 I spent most of this time farting around with using an underdetermined system of equations and using the remaining degrees of freedom for minimizing curvature. 04:38:42 (where the sense of this is varied in attempts to get it rammed though) 04:38:43 --- quit: tintin (Remote closed the connection) 04:39:09 L62 norm of Gaussian and/or Riemannian curvature across the thing, etc. 04:39:17 feh 04:39:21 L^2 norm that is 04:40:06 and similarly farting around with the analogue for fitting plane curves. 04:41:07 --- join: tintin (1000@tintin.user) joined #haskell 04:41:12 So that's what I've been doing wrt. graphics. 04:41:45 minimax curvature is probably the most interesting 04:49:43 wli: not sure if it is relevant, but you might find my adaptive simulated annealing code in haskel interesting. it can max/minimize (pretty much) arbitrary haskell functions. even ones using algebraic data types in their domain. 04:50:03 http://repetae.net/john/recent/out/HsASA.html 04:50:07 it is pretty raw though... 04:50:58 JohnMeacham: Sounds useful for some other things, though this particular one needs some kind of analytic solution. 04:51:15 JohnMeacham: (or an analytically-derived fast approximation) 04:51:44 ah. 04:52:23 a trickier problem :). but at least you know when you solved it and don't have to say "seems close enough." :) 04:52:24 (the second of these is really always the case because the analytic solutions are rarely directly computable in terms of hardware instructions) 04:53:56 back. 04:53:56 JohnMeacham: The L^2 norm is particularly attractive from the standpoint that discontinuities in/around absolute value signs and odd behavior of maxima to be minimized disappear, but is still rather badly bahaved. 04:54:40 JohnMeacham: ok, I'll try to do them file-by-file. 04:58:38 let me set up an implicit cubic spline and show what goes wrong 04:58:54 (a curve instead of a surface, the surface has a lot more issues) 04:59:43 --- join: chris2 (~chris@p54888167.dip0.t-ipconnect.de) joined #haskell 05:00:31 GHC rocks! :) 05:01:20 Palle! 05:02:12 xerox, ? :) 05:02:27 Hi :) 05:02:35 Hi, how are you? 05:02:49 Fine, just woke up.. :-) 05:02:59 --- part: JaffaCake left #haskell 05:03:25 xerox, about the same here. :) 05:03:48 How's code? 05:03:49 I take every opportunity i can to sleep after noon 05:04:02 xerox, Just started doing some real things with GHC.. :) 05:04:23 Nice to hear! 05:04:26 10 coefficients, 9 actual degrees of freedom (there is "scale invariance", any scalar factor may be eliminated from the coefficients, so normalize the 10-vector to L^2 norm 1). 05:04:53 xerox, I've been taking a university course in haskell, but it seems pretty useless with hugs, and then i spotted GHC :) 05:05:45 What are you doing? 05:06:32 Just try to get started with some simple IO :) 05:07:24 zip [0..] [1.01281,0.98363,0.96452,0.94536,0.90716,0.95065,0.93860,0.90430,0.86965,0.85264,0.85417,0.89685,0.93795,0.92058,0.90833,0.89289,0.87463,0.85306,0.86155,0.90248,0.91183,0.90521,0.88784,0.89198,0.88335,0.87073,0.87692,0.88612,0.91695,0.95626,0.99308,0.97781,0.98081,0.98134,1.00105,1.01859,1.06260,1.07833,1.07985,1.08621,1.15651,1.16755,1.13621,1.11477,1.12684,1.17148,1.17211,1.22918,1.26263,1.26478,1.22626,1.19851,1.20110,1.21466,1.22717,1.21998,1.22258,1 05:07:31 feh 05:07:50 http://holomorphy.com/~wli/euro-vs-usd.txt 05:08:49 Is it possible to get commandline arguments? 05:09:12 System.getArgs 05:09:15 hawiki didn't have any results 05:10:10 Palle: http://www.haskell.org/ghc/documentation.html 05:10:35 Hierarchial Libraries tells you about everything that comes with GHC 05:11:40 deciding on demo deadlines is always productive 05:12:25 deadlines get you going 05:13:46 --- quit: kzm (Remote closed the connection) 05:14:49 --- join: Itkovian (~Itkovian@dragnipur.elis.UGent.be) joined #haskell 05:15:19 --- part: Itkovian left #haskell 05:15:26 So, now time for continuity constraints... 05:16:06 wli, thanks 05:16:13 skew, and thanks 05:16:13 :) 05:19:23 Anyway, implicit differentiation reveals continuity constraints to be rather nightmarish. 05:20:35 I should close all open handles before returning from some file i/o function, right? 05:20:50 yes. 05:21:09 of those handles are on the function scope 05:21:16 ghc-6.4 no longer closes all handles when the program exits. 05:21:21 So 4th-order continuity pins down the interior intervals. 05:21:22 really?! 05:21:27 that means that unflushed data can be lost. 05:21:36 if the handle is a parameter it depends on the semantics of your function 05:21:38 if you don't flush/close. 05:21:41 --- join: JaffaCake (~simonmar@tide17.microsoft.com) joined #haskell 05:21:56 Greetings, JaffaCake. 05:21:56 Hmmm. 05:22:09 musasabi, it's part of a really thorny problem with finalisers and garbage collection 05:22:10 afternoona all 05:22:13 third-order implicit derivatives crash maple 05:22:14 I've read that I can't trust the GC on closing files, but I didn't know it wouldn't close them even on termination. 05:22:16 gd afternoon 05:23:03 TFK: well, the handles always go away when the program dies. 05:23:15 ghc-6.4 no longer closes all handles when the program exits. 05:23:27 o_O? 05:23:56 skew: right, the OS closes the files but user space does not necessarily flush first 05:24:05 I mean it's not like your program will leak file descriptors off the computer 05:24:06 you get six degrees of freedom left over from the endpoints 05:24:17 Hmm, OK, thanks. 05:24:35 Heh, can't map hClose to a list of handles o_O 05:24:37 Now you're in real trouble. 05:24:49 some of the data you wrote might go away too 05:24:56 TFK: mapM_ hClose handles 05:24:56 Minimax curvature hurts, badly. 05:25:06 ah, thanks 05:26:47 Hmmm. 05:28:00 TFK: Personally, I think that is a bug. all files should be closed on exit just like C does. 05:28:12 (Or Python does) 05:29:14 is hGetContents lazy? 05:29:54 yes 05:30:03 it leaves the handle in a wierd state 05:30:06 How can I make it strict? 05:30:19 JohnMeacham: I wrote a multivariate polynomial lib and Grobner basis solver to help out with stuff like this. 05:30:22 Or is there a strict lookalike? 05:31:09 I don't think you would want to make reading stdin strict. For the rest, you know where the docs are, right? 05:31:50 I am browsing System.IO, but the word "strict" doesn't appear there. 05:32:29 sequence (repeat getChar) - but I wouldn't recommend it. Why do you think you want it to be strict? a fully expanded haskell list takes up a whole lot of memory. 05:32:35 All files *are* closed, they are just not flushed. 05:32:41 JohnMeacham: http://holomorphy.com/~wli/Poly.hs 05:32:48 Besides, I'm not reading from stdin, but from an output stream from runInteractiveProcess. 05:32:59 Which means that I know what I'm doing. Kinda. 05:33:01 wli: interesting. 05:33:13 a non-lazy hGetContents variant would be very nice.. 05:33:45 you want to tell me there isn't any? 05:33:51 currently one just does str <- hGetContents; status <- length str `seq` waitForProcess ... 05:33:55 Uh-oh. gedit does Haskell synhl!! O_O 05:34:00 Oh. 05:34:04 * TFK tries that 05:34:16 Err, what does that do? o_O 05:35:03 oh, I get it. 05:35:11 Why length, though? 05:35:17 JohnMeacham: I think that one's set up to do some nonstandard variant on rational splines. 05:35:44 musasabi: I still consider it a bug they arn't flushed though :) 05:35:53 JohnMeacham: dependencies for FrontEnd/ParseUtils.o FrontEnd/Lexer.o don't seem to be correctly generated into depend.make. 05:36:17 in what timezone is berckeley? 05:36:37 JohnMeacham: consider the case where the RTS is exiting due to a deadlock trying to evaluate a string that should be writting to a handle... 05:36:40 GMT - 7 or something like that 05:36:53 Yeah, there is something odd about it. ghc is suposed to follow dependencies when using dependency generation, but it seems to miss a lot so I use the 'find' statement. I am not sure if it is a bug in ghc or I am doing something wrong. 05:37:09 adding them manually just works though. 05:37:38 TFK: length's sort of the minimal function that evaluates the entire list/string 05:38:03 anything less runs a risk of being optimised to a constant 05:38:14 the C library doesn't flush the buffers on segfault either. (which seems like a similar error condition). but on normal program exit it does. a standard 'atexit' like function in the libraries would be nice. 05:38:27 I don't think I need seq, then. 05:40:11 TFK: Of course, the simplest solution would be not to fork off a separate process in the first place - just snip the bits of hscolour you need and call them directly within your own program. 05:40:15 JohnMeacham: what is the problem with dependency generation? 05:40:31 JohnMeacham: I remember needing to point it at the right directories with -i -I 05:40:42 I would like to keep it extensible. An external process seems the best way for this. 05:41:07 TFK: you need seq if you want to've made sure you load the lot before you continue processing 05:41:48 I mean, you /could/ do something else hacky to make length evaluate first, but that's even ickier and at least the seq version's a known idiom 05:41:51 Hmmm. 05:42:02 skew: I am not sure exactly. perhaps I left out a -i.. 05:42:04 otherwise the IO's lazy 05:42:51 JohnMeacham: If I remember correctly it doesn't try to turn Parent.Module into ./Parent/Module.hs like e.g. javac 05:43:17 TFK: here is a minimal case doing it http://repetae.net/cgi-bin/darcs.cgi/jhc/FilterInput.hs?c=annotate 05:43:51 * theorbtwo wonders if somebody that has grepable logs of this chan would mind tellling me when autrijus was sketching out a plan for Evalable? 05:44:07 musasabi, thanks, will look into it 05:44:43 If you need something more complex then I suggest at looking at MissingH - that is where I got my ideas on how to do things correctly. 05:44:50 google usually reveals this channels isnt it theorbtwo? 05:45:55 Doesn't look that way to me, nlv11757_. 05:46:03 theorbtwo: http://meme.b9.com/ 05:47:16 musasabi, my current problem is to get hscolour to terminate at all. At first I thought this is a matter of closing input/output/error streams properly, to leach all the output. Apparently it isn't. 05:47:19 theorbtwo, "autrijus Evalable" in google gives me the first link 05:47:36 try "#haskell log" 05:47:41 "journal of autrijus" 05:47:55 That gives me his journal. 05:48:02 I want the actual conversation that took place here. 05:48:13 Hmmm. 05:48:21 owwww 05:48:23 malcolm's already given you a link 05:48:23 Found the meme search just after I asked here, but oddly it doesn't find me anything. 05:48:24 sry 05:48:24 use it 05:48:35 i thought you were just interested in the date 05:48:37 TFK: or just sod it and import hscolour's modules directly, it's not a lot of code (I'm working on it atm) 05:49:16 dcoutts_, (1) it would be nice if Hbin would be extensible. (2) popen is a good thing to know to do properly. 05:49:44 (1) Hbin? (2) true 05:50:30 (1) ...is what I'm working on. (2) yup. 05:51:14 AH! 05:51:31 There are two ells in the middle of Evallable, at least when autrijus is spelling it! 05:51:48 (And I should have thought before to read the whole day referred to in that journal entry. 05:51:58 I think the problem is this. If I do not close out, then hscolour doesn't terminate on large input. However, if I do close out, then there is no output at all. This is why I was wondering about strictness. 05:54:00 Interestignly enough, waitForProcess means that it waits until hscolour terminates, which it doesn't. I'm closing the in stream to hscolour beforehand, it it matters. 05:55:43 (all this on large input - malcolm suggested that this happens because only the first buffered chunk gets through) 05:57:51 --- join: Itkovian (~Itkovian@dragnipur.elis.UGent.be) joined #haskell 05:58:00 --- join: Muad_Dibber (~muaddib@barbel.students.cs.uu.nl) joined #haskell 05:59:09 TFK: Ah! light dawns. You need to add "hFlush stdout" to the bottom of main in hscolour. 06:00:08 --- part: nlv11757_ left #haskell 06:01:40 stdout? o_O 06:01:45 * TFK does that 06:01:53 Oh. 06:02:02 :-D 06:04:09 sorry, what were the flags needed again? ghc --make --cpp and there was a third one you suggested... 06:04:45 --- quit: dave2718 ("I'm off") 06:04:48 TFK: You'll need "import IO" as well. ghc --make -cpp -ffi 06:05:13 sankyu! let's see how it works out 06:05:49 --- join: dave2718 (~dave@ip-85-160-93-179.eurotel.cz) joined #haskell 06:10:29 I wish there were a standard project containing QuickCheck rules to test everything specificed in the Haskell Report. 06:10:45 It would make regression/conformance testing much easier. 06:12:17 JohnMeacham: you might want to try hooking up GHC's regression suite to jhc 06:12:26 it runs with Hugs these days 06:15:35 Hmm, can't I put a normal function call after a case/where statement? I'm getting a parse error, of all things. 06:15:37 I'll take a look at it. so far, nofib has been a pretty good regression suite. 06:15:56 nofib doesn't test the dark corners :) 06:16:07 do you have FFI? 06:16:13 Yup. 06:16:24 neat 06:16:31 calling C from haskell, but not calling haskell from C. not any technical reason. it just hasn't come up yet. 06:16:40 --- join: basti_ (~basti@p54AE120E.dip0.t-ipconnect.de) joined #haskell 06:16:53 adjustor thunks are fun 06:16:58 hi 06:17:19 Yeah. I might have to give up my 100% portable generated C claim if I implement those :) 06:17:34 TFK: hFlush stdout goes after the last case alternative, at the same indentation level as the 'where' keyword 06:18:00 But I have done OS programming before, so it won't be completly strange territory. 06:18:15 you can probably crib from GHC's implementation too 06:18:19 Hmm. But why can't it go after the case block entirely? Or is that simply illegal? 06:19:14 I'm excited that we've got another Haskell implementation, and not just a toy one either 06:19:14 Eh? It does go after the whle case block. You just have to make sure the layout is correct. 06:19:29 JaffaCake: Me too. 06:20:04 Heh. Yeah, part of my motivation for making the push to it being a 'real' compiler was I feared haskell might stagnate as a single-implementation language :). 06:20:08 JohnMeacham, I'd take JaffaCake's advice on that one, have you ever looked at ghc's Adjustor.c? You wouldn't want to re-implement that! You'd need to know far more about various chips and ABIs that you ever wanted to know. 06:21:07 --- quit: Function (Client Quit) 06:21:55 --- join: Function (~Function@pietvanderstaaij.demon.nl) joined #haskell 06:22:04 --- join: Bo (~bo@nat.kollegienet.dk) joined #haskell 06:22:34 (not that I really thought that would happen.) but I do think multiple implementations with very different internal styles are a good thing. extensions which might be hard in one might be easy in other other, and only the best need be crossported. 06:23:39 yes, and I'm looking forward to racing against each other - we only race against ourselves these days, it gets pretty lonely :) 06:23:46 --- quit: Muad_AFK ("Leaving") 06:23:50 http://haskell.org/hawiki/HaskellIrcPastePage <--- this is what I did originally. I'm not sure why I got that error. 06:23:52 Yeah, I have seen Adjustor... no fun. perhaps we could seperate it out into a little bitty C library we can both link too. 06:25:12 heh. well, GHC is going to win races for a while. its global transformations are a huge win and I won't be able to reasonably compete until I implement most of them. 06:25:21 --- quit: Paltas (Read error: 104 (Connection reset by peer)) 06:25:52 --- join: autrijus (~autrijus@220-132-132-105.HINET-IP.hinet.net) joined #haskell 06:25:56 you do global transformations, don't you? 06:26:46 TFK: You can't put the function call after the 'where' block. 'Where' scopes over the entire definition above it. You want to put the call just above the 'where' keyword. 06:26:50 JohnMeacham, it could probably be done in a more portable but slower way, by creating an extra mapping from C function pointers you've handed out to the corresponding StablePtr. So a call from C through one of these pointers would need to do a lookup in a hash table where as the Adjustor.c way creates a little bit of straigt line code so it's quick. 06:26:50 Yeah, but don't have most of the ones ghc does. just a simplifier/inliner, basic strictness and some unboxing. no detection of one-shot lambdas or update avoidance yet. 06:27:40 don't worry, GHC's detection of one-shot is mostly missing, and we don't have any update avoidance at all 06:27:43 malcolm, oh, I had no idea. Thanks. I'll need to read up on the lexical rules some more, then. 06:28:30 I have found the interplay between the core and grin transformations interesting. I will find that a core optimization will actually signifigantly speed up the grin points-to analysis. It is why I don't have ' -O' option yet... it is actually slower if I turn off optimizations. 06:28:46 is there any possibility of making a list of functions of different types? 06:29:05 (and arities?) 06:29:22 slower if you turn off optimisations? that's the correct behaviour, isn't it? 06:29:32 JaffaCake: compilation time too 06:29:33 I mean, the compiler takes longer. 06:29:42 ah 06:29:58 Because a much more complicated program is presented to the points-to analysis. 06:30:08 because optimisation simplifies the program, making later stages quicker? 06:30:12 right 06:30:29 -O0 should turn off points-to, then! 06:30:47 basti_, bascially no. you've got to wrap them in some data constructor and if you want a not-fixed set of types you probably need to use exestentials 06:30:59 Hmm. hscolour still doesn't terminate. 06:31:24 heh, can't be done. the points-to is needed to get rid of all higher order functions and create the eval code. 06:32:00 "jhc the (always) optimising compiler" 06:32:01 dcoutts_: hmmm i see, so its boilerplate template haskell again... 06:32:29 ok, I haven't read up on points-to 06:32:37 generic haskell. 06:32:52 basti_, using exesentials can often be a nice solution 06:32:57 how does it get rid of higher-order functions? by specialising? 06:33:17 Yeah, I am using Boquist's method of compilation. My core (based on the lambda-cube) is transformed into a first-order monadic form with _only_ statically known function calls. 06:33:24 i did not fully understand existentials yet 06:33:54 Welp, still the exact same behaviour. 06:34:07 Do you have any idea how that might scale to separate compilation? 06:34:18 the points-to analysis determines at every eval point, all the possible things it can be pointing too, then inserts a simple case statement which scrutinizes the value and calls the appropriate function. pretty much all 'eval's only have a couple possible cases. 06:34:20 basti_: they've got several uses, but an easy one is letting you write the type "something belonging to this type class" 06:34:51 basti_, it's very similar to the idea of OOP interfaces, you can put various supported values behind the interface but once you've done so you can no longer call an functions that rely on the specific type of the thing you stuck behind the interface 06:35:05 --- quit: Narrenschiff ("Leaving") 06:35:16 hmmmmm 06:35:33 whats the difference between "something belonging to this type class" and "Class a => a"? 06:35:52 basti_, all those 'a's have to be the same 06:36:02 I have some ideas. right now it does seperate compilation of a sort, it creates 'haskell object' files. (ho) files whith contain the partially compiled code. I don't think I will ever be able to do seperate compilation at the .o object code level, but if I can move enough computation to the generation of the ho files, that should be good enough. 06:36:20 basti_: consider a heterogenous list of things belonging to SomeClass 06:36:28 sort of like having a custom haskell linker :) 06:36:29 hmm 06:36:33 i see. 06:36:43 right - I've seen other languages do that 06:36:43 can you not generate .o by making some kind of worst-case open-world assumption? 06:36:46 you need an existential constructor to allow that 06:36:55 or do passing HOFs across the boundary stymie that? 06:36:56 * basti_ nods 06:37:11 basti_, Class a => Exists a. a allows each of those 'a's to be different (but instances of that class) BTW that Exists a.a is not valid Haskell syntax 06:37:25 I believe the MS C compiler can generate object files of intermediate code 06:37:59 ah, yes, it just dumps the p code into the .o, doesn't it? 06:38:00 Also, after the worker-wrapper transform, the worker often has known calls with a strict interface, so in many cases it can probably be fully compiled. I plan to take advantage of that. 06:38:36 Anything that moves thunk evaluation closer to thunk creation is good. 06:38:47 * basti_ will read about existential types, then 06:39:37 JaffaCake, the gcc people keep talking about doing something similar, with gcc -O4 it'd dump the intermediate represntation into a seperate section of the .o file and then if you use gcc to link everything then it'll have another go with some global optimisations 06:39:44 --- join: vidvandre (~vidvandre@217-213-130.0502.adsl.tele2.no) joined #haskell 06:39:54 There are also several papers out there on things like doing escape analysis with seperate compilation. some of those techniques might be usable, as they tend to use fixpoint iteration and abstract interpretation too. 06:40:25 --- join: boegel (~boegel@ip-81-11-221-15.dsl.scarlet.be) joined #haskell 06:40:54 ahh, and "forall" is used because it's the dual to "exists" and on the other side of the -> ? 06:41:04 basti_, right 06:41:09 dcouttis :: -O4? 06:41:15 * boegel waves happily 06:42:12 df_, optimisation level 4, was what they were suggesting since they've already got useful meanings for -O1 -O2 and -O3 06:42:19 The good results I was getting from my type class implementation were a complete surprise. I originally implemented it as a stopgap because I didn't feel like implementing dictionaries, but then I started seeing great results when looking at the intermediate code. 06:42:49 oh sorry, thought you were suggesting using it to compile something with, rather than a new propsoal 06:43:23 any idea what you'll do for existentials? I imagine you end up with the dictionary passing scheme in the end 06:43:24 df_, I am a gentoo user, but no :-) 06:43:31 After a little thought, it made sense. I was just moving the transformation grin does, turning higher order functions into case statements, up to the begining. 06:43:33 heh 06:45:01 existentials are no problem, I just pass the type as another argument if it will be examined by a method call. 06:45:07 fair enough 06:45:23 or, I mean store the type in another slot of the data constructor. 06:45:31 * Philippa_ nods 06:45:33 same difference, but yeah 06:45:41 right, I see 06:46:30 had forgotten the global bit because I've been spending too much time thinking about doing silly dynamic stuff with hs-plugins recently :-) 06:46:37 Are there any issues or subtleties around hPutStr? 06:46:49 another strange thing, the standard encoding of data types as higher order functions and the equivalant data types actually eventually compile to the same thing under Grin. it was an interesting (if useless) surprise. 06:46:50 TFK: buffering 06:47:04 Philippa_, well, besides fluing the input. 06:47:04 heh, cool 06:47:15 not that I know of, then 06:47:27 --- quit: boegel ("Leaving") 06:47:28 I guess possibly you might shoot yourself in the foot over encodings, but that goes for all the IO 06:47:47 heh, that makes sense I guess 06:47:50 Plain ascii here :-) 06:48:19 yeah. I briefly considered getting rid of data types alltogether when I saw that. briefly. :) 06:49:00 Well, this is what I found out. "hPutStr inp code" will prevent hscolour from terminating, no matter what I close. 06:49:24 do both inp and code terminate? 06:49:30 (wherever they come from) 06:49:54 inp is the input stream from runInteractiveProcess. code is just text. 06:50:33 Weirder still, it only fails on large input (first buffered chunk?) 06:51:37 TFK: I think ghc had some weird problems with buffering across sockets that manifested as only the first buffer-full getting through. 06:51:44 (and I added hFlush stdout to HsColour.hs, and recompiled, and all) 06:51:52 Can JaffaCake shed any light? 06:51:59 You mean ghc is broken? 06:52:12 :-P 06:52:22 I haven't read up the context - can someone fill me in? 06:52:31 I thought it had been fixed recently. 06:52:58 How recently is recently? I grabbed the binaries for win32 a few weeks ago. 06:53:06 I don't recall that bug 06:53:22 buffering on sockets is block by default, if that's any help 06:53:23 OK, TFK is using runInteractiveProcess to write data from one haskell process to another. 06:53:34 Hold on, I'll paste the code 06:53:48 * basti_ brain explodes on existentials 06:53:49 ok 06:53:55 For some reason, sending a large chunk of input means that the output is truncated. 06:54:14 interesting 06:54:23 basti_: were you trying to pattern match? 06:54:51 larger than a buffer's worth? 06:54:59 hmm no i'm just trying to make sense of it 06:55:29 for example, i can declare a "forall a b c.[a->b->c]" 06:55:32 it doesn't make sense, though. 06:55:42 A list of functions? 06:55:43 JaffaCake: yes, larger than a buffer's worth 06:55:51 so i need to wrap what i want in a class 06:56:12 i just don't see how i should wrap it... 06:56:50 TFK: you're writing into a large string into a pipe, and the program blocks at that point, right? 06:56:50 I want (at some point in the distant future) to have a type of functions inside one type. That is, a, a->a, a->a->a etc. 06:56:54 http://haskell.org/hawiki/HaskellIrcPastePage <--- disregard the placeholder return value 06:57:06 JaffaCake, to a stream, yes. 06:57:13 (Which is the same thing, I suppose) 06:57:23 it's probably because you don't have another process reading from the pipe 06:57:29 hmm but "a" doesnt fit there. 06:57:35 hscolour is reading the input. 06:57:37 the write will block until the pipe buffer is emptied 06:57:41 It reads small inputs, doesn't it? 06:57:50 so i'd need to have at least 2 constructors, "function" and "result" wouldnt i? 06:58:41 Well, hscolour can handle large inputs from regular files. 06:58:45 basti_: try compiling something like data T = forall a. Show a => T a; f t = let (T x) = t in show x 06:58:47 --- quit: Itkovian () 06:58:49 How can I solve this problem, then? 06:59:10 GHC gives the error "My brain just exploded." 06:59:23 if you change hscolor.exe to cat.exe, does it terminate? 06:59:35 skew: hmm 06:59:37 er? why cat? 06:59:54 I just want to make sure that the other process is reading the whole pipe contents 06:59:58 skew: but that's not my problem. I see why this would fail. 07:00:10 I don't know what your hscolor process does 07:00:21 Windows doesn't have cat.exe 07:00:29 So it will give me a 500 error, I suppose. 07:00:33 oh, so it doesn't :) 07:00:46 do you have cygwin? 07:00:50 basti_: You were talking about your brain exploding and existentials too 07:00:52 It's not *my* hscolour, it's malcolm's :-P 07:00:57 ahh. 07:00:57 it works if you use a case, btw 07:01:00 ;) 07:01:07 Nope. But maybe gnuwin32 has a cat.exe somewhere. 07:01:08 * JaffaCake looks at malcolm 07:01:12 * basti_ nods. 07:01:15 why would you expect it to fail? 07:01:50 because there is a "wacko point" in the let... 07:01:57 Well, I've already ensured that hscolour is flushing its output buffer before termination 07:02:00 i mean there is one point where the "forall" has to be resolved 07:02:07 --- join: beschmi (~ry102@tplx4.rz.uni-karlsruhe.de) joined #haskell 07:02:13 malcolm: but is it reading all the input? 07:02:21 I think that's the issue 07:02:23 and this construction makes this happen inside let 07:02:34 (Yup, I did compile with hFlush stdout.) 07:03:02 JaffaCake: I can't see why it wouldn't be. Code is the next part down the page on the IrcPastePage 07:03:08 ah wait - I see 07:03:09 the forall would be resolved just fine by dictionary passing at runtime 07:03:33 You need to read the output too 07:03:39 and I see the types just working out if the rest of the code remembers that x is just some Show type 07:04:01 JaffaCake, stuff <- hGetContents; return stuff doesn't make it terminate. 07:04:03 hmm. 07:04:18 Yes, I think TFK does read the output. There's another chunk of code from TFK a bit further down which does the reading. 07:04:30 That code is just the most minimal example I could create that exhibits this behaviour. 07:04:54 Yeah, only that flushing out instead of inp will get me no output :-P 07:05:20 maybe JaffaCake could explain the problem 07:05:20 --- quit: magr ("Client exiting") 07:05:43 skew: then i do not see why this is a problem. hugs seems to be fine with it. 07:06:49 I think the problem is this: the server process is pushing lots of data to the client, and the client is pushing data back to the server via its stdout, but you have a deadlock: stdout is full, so the client can't write any more, and stdin is full so the server can't write any more 07:07:12 --- join: CosmicRay (~jgoerzen@2002:4463:7269:1:20e:a6ff:fe66:c5a3) joined #haskell 07:07:15 Is the 'Boxy Types' imprecative typing being worked on in GHC HEAD? 07:07:21 it seems very interesting. 07:07:23 basti_: I think that's a different problem :) 07:07:31 JohnMeacham: I think simonPJ is working on it, yes 07:07:42 i do not think "my brain exploded" is a particularly ergonomic message, too. 07:07:47 skew: sorry, I'll get to yours later :) 07:08:10 JaffaCake: Thanks - that makes sense. 07:08:41 cool. The whole nice, simple tying algorithm for rank-n types seems like an amazing advancement in languages. and Boxy types just makes a good thing better. 07:08:58 Not to me, but perhaps the more important question is - how can I solve this problem? 07:09:14 TFK: ok, try this: 07:10:00 add 'forkIO (do s <- hGetContents out; length s `seq` return ())' 07:10:16 right after runInteractiveProcess 07:10:54 wow 07:11:11 You mean, forkIO (do hPutStr inp code; s <- hGetContents out; length s `seq` return ()) 07:11:20 i made hugs call a type variable "_8" 07:11:23 *? 07:11:25 never seen this before =) 07:11:29 nope, the hPutStr stays outside the forkIO 07:11:38 Hmmm, OK, I'll try that. 07:12:14 Won't that make me lose the ouput, though? 07:12:21 yes 07:12:30 I don't want to lose the ouput. 07:12:42 Yes, I think you want forkIO (do s <- hGetContents out; length s `seq` return s) 07:12:49 alternatively... change hPutStr inp code to forkIO (hPutStr inp code) 07:13:19 Ha! Just like the example said originally... the irony. 07:13:53 No wait, 'return s' won't make any difference at the end of the forkIO. Better to fork the hPutStr inp as JaffaCake says. 07:14:59 --- quit: Muad_Dibber (Remote closed the connection) 07:16:03 OK, so back to the threading question. Do I need to scrap them manually? 07:16:40 Hmm, guess I don't have to with this one. 07:18:46 Well, now hscolour won't terminate even on short inputs. 07:19:15 TFK: Let's see. You'll need to close the inp handle to ensure that hscolour terminates, so forkIO (hPutStr inp code >> hClose inp) 07:19:50 I'll assume that '>>' does the magic needed and try to do this :-) 07:20:55 TFK: It's just a desugared do notation. (x>>y) is equivalent to do { x; y} 07:21:23 Great, it works now :-D 07:21:35 Thanks JaffaCake, malcolm (again ;-) 07:22:04 It just shows that concurrency is difficult... :-) 07:22:05 you're welcome ;) 07:22:50 It shows that I should've followed the example through, instead of guesstimating (wrongly) that blocking I/O will work :-/ 07:23:10 in other news, I'd like to complain at JohnMeacham mentioning boxy types - I'm having a hard enough time writing a paper without being pointed at other papers I want to read :-) 07:23:19 (looks cool, but I'm putting off reading it, honest...) 07:23:42 df_: Ahh.. thats why you wanted an English translation! :-) 07:24:01 Palle: Well .. I don't really write german that well.. 07:25:11 I apologize. But in all fairness, I blame SPJ for writing the thing in the first place. :-) 07:25:56 heh, fair enough 07:26:10 he's stolen enough of my time that way :-) 07:28:09 dabian :: yes, i can grok the odd word in german / spanish / french / latin, but my foreign language skills suck. from your image i managed to get mathematician, singer and rockband 07:30:14 df_: :) 07:30:38 df_: Very nice. You were looking at a danish text. :) 07:30:55 JohnMeacham: I'm attempting to write about a somewhat lesser achievement in type systems (one that's kind of implicit in a lot of the writeups of HM(X), for example), but having not written a paper before and not done any real work for a couple of years now I'm having difficulty getting started 07:31:02 OTOH, today I've got further than a title. This is a good thing 07:31:44 --- join: CrewdenX^2 (36133@69-39-98-40.du.midcoast.com) joined #haskell 07:32:44 Philippa_: Well, that is better than me. I have yet to write a paper. 07:33:30 so, I threw together http://perlmonks.org/?node_id=450426 real quick 07:33:34 is there some obvious way to make it faster? 07:35:27 JohnMeacham: a title, a couple of sentances and the start of some rather tedious code isn't much better IMO, but hey 07:35:46 I've really got to get the hang of this though, or I've pretty much nothing to do when I finally succeed in graduating 07:37:02 You could always write perl for a finance company. that is what I am doing at the moment. 07:37:49 Which is probably a big part of the reason I need a suitably challenging hobby like writing experimental compilers for the language of the future. 07:37:50 ouch. Though I suspect I'd rather that than being continually unable to work or study 07:37:52 * Philippa_ nods 07:37:58 the hobby I'm envious of, mind 07:38:21 I barely managed to pull off a toy interpreter for a cut down version with my type system extension 07:38:48 feel free to submit code! or better yet, start another one, competition is good. ghc has been top dog way too long :) 07:39:47 JohnMeacham: btw, before you get too far along, I hope you won't be doing anything like the lame nhc98 practice of officially not supporting 64-bit archs :-) 07:41:05 telnet.o(.text+0x25): In function `__stginit_Main_': 07:41:05 : undefined reference to `__stginit_Network_' 07:41:05 ... 07:41:14 anyone have a clue on that error using ghc6? 07:41:14 JohnMeacham, re: talking about C-- and gcc eariler; it seems the difficulty is in gcc's internal support for tail calls. 07:41:34 if I get round to rummaging in jhc's internals and feel comfortable enough to do so I'd be happy to submit stuff - in practice I suspect this won't happen though 07:41:45 JohnMeacham, Andreas Bauer wrote a thesis on this issue: http://home.in.tum.de/~baueran/thesis/ 07:41:49 Compilation of Functional Programming Languages using GCC -- Tail Calls 07:41:57 * CosmicRay mumbles something about ginsu not yet being darcsified 07:42:42 Palle: You might want -package network or somesuch if not using --make 07:42:52 --- join: chr1s (~chris@118-245.surfsnel.dsl.internl.net) joined #haskell 07:48:17 I have a 64 bit machine :). I know jhc works on x86_64, i386, PowerPC and SPARC. in fact, the same generated C file will compile on all of them just fine. :) ultraportability was a goal. 07:48:19 ahh thanks Igloo :) 07:48:51 JohnMeacham: excellent. 07:48:54 CosmicRay: I know, it's a pain about nhc98 and 64-bits. A prior incarnation (nhc13) did support the alpha, but it was my fault that the ANSI-C bytecode backend I added didn't take it into account. 07:49:22 malcolm: bummer, one of my platforms is the alpha 07:49:29 It seems that since nhc generates a bytecode, you would just need to write a portable interpreter/runtime.. 07:49:33 in fact, all of my regular development machines is 64-bit 07:50:02 JohnMeacham: Can nhc98 compile jhc? 07:50:08 dcoutts_: Yeah, I have read that. it is getting better though. 07:50:13 * JaffaCake likes amd64 a lot 07:50:18 I don't think so. but I havn't tried it. 07:50:26 I use several extensions. 07:50:26 Hmm, OK 07:50:27 JaffaCake: me too. a very nice platform at a very nice price. 07:50:29 The nhc98 runtime/interpreter is probably 64-bit safe. 07:50:42 they made some nice improvements over x86 07:50:53 JohnMeacham: it will be nice when jhc can compile ghc :-) 07:51:18 heh. I want jhc to compile jhc. then I will be getting double-reward for all jhc improvements :) 07:51:21 heh, that's a good goal 07:51:23 JohnMeacham, yes apparently the sibling tail call optimisation for C is in gcc 3.4 07:51:29 JaffaCake: yes, and without doing it in a braindead way like the itanic 07:51:40 --- join: sond (~david@sond.brg.sgsnet.se) joined #haskell 07:51:59 I think if you use nhc98 --noansiC then it might just work OK on a 64-bit platform. 07:52:12 JaffaCake: indeed it is. if you ever tried compiling ghc on aix, you would appreciate having an easier way to bootstrap it. 07:52:13 I guess a jhc Debian source package would want to have the C files in. How ugly. 07:52:22 (but ghc is by no means the only program that's difficult to build on aix) 07:52:22 CosmicRay: I think getting enough memory in your system for jhc to compile ghc would require a 64 bit machine :) 07:52:29 skew: haha 07:52:38 JohnMeacham, but more significantly it means that the gcc folk have to keep tail calls in their intermediate language which should make things better for an FP/C-- front end 07:52:46 But --noansiC means you can't use any FFI code currently. 07:52:59 CosmicRay: what are the main difficulties compared to other platforms? 07:53:24 dcoutts_: right now I output all functions as static in a single .c file. this makes it most likely gcc will properly generate tail-calls. 07:53:55 However, it would not be hard to do the trasformation myself, since I don't have higher order functions to worry about. 07:53:56 JaffaCake: well bootstrapping was quite difficult, since I had no closer machine than x86 for the .hc files... also a lot of configure stuff assumed AIX4 -- 32-bit, and we're on AIX 5, 64-bit. 07:54:20 JaffaCake: so there was some hacking around to make thing work. Then I had some linker troubles. I finally wrote a wrapper script for gcc that got things going 07:54:44 exec /usr/local/bin/gcc -mpowerpc -maix32 -mminimal-toc "$@" 07:54:48 ok, just porting issues then 07:54:50 But a real c-- front end for gcc would be ideal. for a lot of people in the FP community. 07:54:51 yeah 07:55:02 --- join: Huschi (~martin@p213.54.213.51.tisdip.tiscali.de) joined #haskell 07:55:12 JaffaCake: I think I submitted a couple of bugs about it, I never heard of them being closed though IIRC 07:55:28 ah yes 07:56:12 JaffaCake: there was also a lot of fuss with gmp. somehow it was being built ni 64-bit while ghc was building 32-bit (or maybe it was the reverse; this was about 6 months ago) 07:56:16 * JaffaCake looks up the bug database 07:56:55 here's one: 07:56:57 http://sourceforge.net/tracker/index.php?func=detail&aid=1043070&group_id=8032&atid=108032 07:57:42 yes, I remember that one 07:57:54 the patch isn't quite right, IIRC 07:58:03 JaffaCake: you're right 07:58:32 JaffaCake: but like I say in the bug, I don't know how to do it the right way... but I hope this gives you what you need to do it the right way though 07:58:54 trouble is, I can't test it easily 07:58:57 autrijus: that looks pretty good to me. If reverse [1..len `div` 2] needs to build an intermediate list you could count down with [len `div` 2,len `div` 2-1..1] 07:59:09 JaffaCake: I'm happy to test anything you through my way 07:59:29 I'll look into it sometime 07:59:45 JaffaCake: just don't expect too many tests per day. compiling on aix is a slow business. :-( 07:59:55 heh 08:00:18 I don't know why. for a machine this powerful and expensive, one would think it would compile faster than my 7-year-old alpha. oh well. 08:00:37 * JaffaCake stares at the number of bugs in sourceforge and gets depressed 08:01:06 * CosmicRay points out how many people have a good experience with ghc 08:01:38 Are there any other compilers out there that use Pure Type Systems as an intermediate language? I'd like to see some more practically oriented info on it. 08:02:18 Where was that code to get the possible unique combination of some numbers? 08:04:00 The best practical info I have found so far is Roorda's thesis. 08:04:57 * Philippa_ seconds CosmicRay's point 08:05:23 * JaffaCake feels better 08:05:42 and unless you wrote the win32 RTS you're not responsible for the only bug I ever encountered 08:06:12 hmm, I ought to go play with that code again now I've a version of GHC with that one fixed :-) 08:06:33 JaffaCake: I suspect there are quite a few people out there that have a good experience with ghc and don't even know it. Things like darcs, I think, are taking Haskell into the hands of people that don't even know what language darcs is written in. 08:06:41 JaffaCake: btw, how did you make out with your survey? 08:06:46 Hmm.. pretty.. http://repetae.net/lcube.html pretty buggy... let-bound terms keep showing up at the type level. I need to put a stop to that. 08:07:03 CosmicRay: I haven't checked the results lately... I'll go and look 08:09:20 --- join: Arsilan (~Arsilan@x1-6-00-0e-5c-ed-05-63.k695.webspeed.dk) joined #haskell 08:09:43 skew: cool, that's a 5% win 08:10:02 Is there anyway that I could get a tar.gz of the entire raw CVS repository on cvs.haskell.org, for the purposes of experimenting with converting it to darcs? 08:10:30 looks like 500+ complete surveys now 08:10:30 also, does anyone know why there are certain "private" directories that give permission denied errors to pserver trying to get them? 08:10:35 * JaffaCake jumps around a bit 08:10:47 JaffaCake: nice, that's about double what you had when you posted about it on the lists, right? 08:11:01 yeah, thanks to Simon PJ's plea :) 08:11:10 oh, the *other* simon :-) 08:11:32 we publicized it here and on the sequence too. would be nice to get it on www.haskell.org 08:11:40 CosmicRay: re: the CVS repo, sure 08:11:43 I thought you decided that Simon PJ would never be the "other" simon :) 08:11:46 JaffaCake, that's quite a few. You could probably prod some uni people to spread the survey wider. It hasn't been sent round the department mailing lists over here and I know that lots of people use ghc, and wadges of students 08:11:49 --- join: fraxtal (~fraxtal@0-2pool156-251.nas6.savannah2.ga.us.da.qwest.net) joined #haskell 08:13:27 I think hugs is still the usual recommendation at UoN 08:13:31 dunno why these days though 08:13:40 JaffaCake: Where was the right place to look at core for optimization? -ddump-simp? 08:14:01 CosmicRay: if you're interested in experimenting with converting the CVS repo, I can set you up with a cvs.haskell.org account, that's probably the easiest way 08:14:15 skew: yes 08:14:21 JaffaCake, I somehow doubt I'm authorised to email all our students doing FP! But I might be able to persuade someone who is. 08:14:31 JaffaCake: so I'd just ssh in to that machine? 08:14:42 dcoutts_: that would be great, ta 08:14:47 Philippa_, I think we're going to switch to ghci for the start of next year (finally) 08:15:01 dcoutts_: pfft, just create a throwaway hotmail account :-) 08:15:03 CosmicRay: yup, that way I wouldn't have to send you updated tarballs 08:15:38 JaffaCake: sounds good. what do you need frmo me to get that giong? 08:15:54 username and SSH public key 08:16:02 CosmicRay, :-) fortunatly for them it's more a matter of restricted lists 08:16:02 dcoutts_: cool. Was about to ask if you knew a friend of mine who moved here, but realised he's been here the best part of two years already so you probably don't... 08:16:11 there are about 400 students using ghc (and happy/alex) in the second semester course here (karlsruhe) 08:16:21 JaffaCake: right, shall I e-mail that to you? 08:16:29 please do 08:17:34 beschmi, that's a lot! About 8x what we have 08:18:00 about this private directories that aren't readable by pserver -- is there stuff in there that I should take care to not become publically-available, or is the non-readable status just some sort of historic relic? 08:18:55 we haven't put anything in there for a long time, but I think the stuff in those directories is still unlicensed, so you should leave it out of the darcs repo 08:19:07 ok. 08:19:26 mail sent. 08:19:37 --- join: Philippa (~somewhere@cpc2-clif3-5-0-cust210.nott.cable.ntl.com) joined #haskell 08:19:38 --- quit: Philippa_ (Read error: 131 (Connection reset by peer)) 08:20:04 out of curiosity, if a good darcs conversion of the cvs repository is possible, is there any interest among the fptools hackers in switching to darcs? 08:20:34 I'm keen, as long as I can do everything I do now 08:20:38 I would love that. not that I hack fptools much. 08:20:44 dcoutts_: it's a compulsary course for cs students (Informatik 2) and there are some physics/maths students too 08:21:18 JaffaCake: well I thinks it's pretty safe to say that darcs doesn't have any regressions from CVS, but is there anything in particular you're concerned about? 08:21:18 unfortunately, it's the only course where haskell is used here ;( 08:21:24 I think it might be good to split it into a few different darcs repositories if it is too big. 08:21:34 JohnMeacham: which, fptools? 08:21:45 yeah. 08:21:46 beschmi, our's is a compulsary 1st year course and there are some maths/engineering studetnts too. Your's is still bigger :-) 08:21:54 JohnMeacham: I don't think it will pose a problem. 08:21:56 I need emacs support, and cvsweb is nice 08:22:01 okay. 08:22:28 JaffaCake: emacs support is there. there's nothing quite as nice as cvsweb, but there is darcs.cgi which has a nifty interface to "cvs blame" :-) 08:22:34 or the darcs equivolent thereof 08:23:25 and of course darcs repositories are browsable, with the current version anyway, with any http server 08:23:38 ideally we could have a two-way mirror, so we can switch gradually 08:23:41 http://www.scannedinavian.org/DarcsWiki/CategoryEmacs <-- emacs stuff for darcs 08:23:45 autrijus: also, I don't think elems participates in list fustion 08:23:45 JaffaCake: right. 08:23:54 JaffaCake: I know that tailor.py can do that. 08:24:01 just being able to easily create a branch for each little thing you are working on is great... also, being able to accept patches from anyone who can send mail... the default mail address should probably be a mailing list... 08:24:23 sorry. I ramble before I sleep. 08:24:31 JaffaCake: yes, it is **so** much easier for anyone to participate in the project and send patches with darcs than with cvs. 08:24:32 I could be persuaded to switch to darcs for nhc98 too I think probably. 08:24:41 JohnMeacham: why are you awake, anyway? 08:24:51 CosmicRay: right, that's definitely a win 08:25:01 not sure. 08:25:12 Just never went to bed :) 08:25:15 malcolm: well then, nhc98 will be second on my list of things to convert :-) 08:25:30 skew: what, the pure excitement of haskell doesn't keep you awake at night? 08:25:39 which is the best darcs emacs mode? looks like there's at least 3 :-S 08:25:56 CosmicRay: well, I am playing with autrijus code instead of doing stuff with a looming deadline 08:26:02 JaffaCake: I don't know, but I bet you could get at least 3 opinions on #darcs 08:26:16 --- quit: Arsilan ("Leaving") 08:26:26 --- join: astrolabe (~astrolabe@astrolabe.plus.com) joined #haskell 08:26:34 JaffaCake: if you already use vc, then you probably want one of the vc modes 08:26:39 it's just that it's 8:30 in California, and I didn't think John was on my plan of waking up at midnight. 08:26:52 JaffaCake: that will probably make converting from cvs as painless as possible 08:27:13 I *think* I use VC 08:27:20 I've never liked the branching support in CVS, and I presume that this is exactly the sort of thing that is supported much better in darcs? 08:27:26 malcolm: yes 08:27:30 skew: how would you do this, then? 08:27:58 skew: mapM on 1..length? 08:28:15 somehow I think the repeated readArray call is not going to be faster 08:28:23 if we got darcs, the first thing I'd do is move a bunch of files around :) 08:28:23 malcolm: whenever you do a "darcs get", your working directory on your system is actually a fully-functional darcs repository -- a branch from the server's one, in fact. 08:28:33 Hah. I invented that schedule. 08:28:40 malcolm: then you can hack and "darcs record", etc. 08:28:55 malcolm: when you're ready to send things back to the server, "darcs push". To pull things frmo the server, "darcs pull". 08:29:10 malcolm: now, if you actually wanted to create a logical branch, darcs push/pull become your merge commands. 08:29:20 malcolm: it is all very slick and easy. 08:29:32 "darcs get" is the create a branch command. 08:29:49 errm, darcs has major performance and usability regressions from CVS 08:29:53 --- quit: autrijus ("leaving") 08:30:02 --- join: autrijus (~autrijus@220-132-132-105.HINET-IP.hinet.net) joined #haskell 08:30:03 Heffalump: I disagree completely 08:30:07 CosmicRay: yes, I think I gathered all of that from watching some discussions. Just wanted to confirm I had the right impression. 08:30:09 creating a branch on the server is more tricky, though 08:30:28 JaffaCake: you would have to have access to make a new directory on the server, yes 08:30:38 it is supported really really well. I currently have 7 branches open in jhc. I practically open a branch for each independent patch I write. it is just easier that way. 08:30:42 JaffaCake: but anyone with write access to the server probably would (since writing is accomplished by piping over ssh) 08:30:43 whereas I can do it from the client with CVS 08:30:51 --- quit: TFK (""Windows XP crashed./I am the Blue Screen of Death./No one hears your screams." -- Peter Rothman (http://www.infiltec.com/j-c) 08:31:19 --- join: TFK (tfk@IGLD-80-230-34-5.inter.net.il) joined #haskell 08:31:30 JaffaCake: true. otoh, creating a branch is jsut: 1) ssh server, 2) darcs get old new 08:31:49 right, and it hard-links everything in sight 08:31:51 errm, conflict resolution 08:32:00 that's an obvious performance problem 08:32:26 Heffalump: the only case I've found it to be a problem is with resolving conflicts for a situation that cvs can't even handle in the first place 08:32:32 --- quit: fraxtal ("Leaving") 08:32:35 bear in mind I've got to explain this to Simon PJ :) 08:32:38 well, that's not my experience :-) 08:32:39 okay. now I'm really leaving. y'all will love darcs. 08:32:48 Heffalump: (where files were independently added with the same name on two branches, and was renamed on one before pulling) 08:33:06 JaffaCake: :-) 08:33:26 JaffaCake: if you do it in public, I bet everyone including David will help :-) 08:33:28 JohnMeacham: see ya ;) 08:34:09 Heffalump: and you're not thinking of all the performance wins, such as darcs record being instantaneous 08:34:23 darcs changes being instantaneous 08:34:24 etc etc 08:34:31 all the benefits you get from having what amounts to a local cache 08:34:45 would it work to split fptools into separate repos, like the modules we have in CVS? 08:34:53 I've managed to get it just sitting there trying to commute a patch past an identical set of local changes. 08:34:53 JaffaCake: yes 08:35:07 JaffaCake: i thought igloo fixed that. 08:35:09 err 08:35:14 CosmicRay: fptools should certainly split up as you can't only check out part of a darcs repo and I suspect most people don't want half of it (although by size probably a small half) 08:35:14 Heffalump: I thought igloo fixed that. 08:35:24 what happens when you commit your whole tree - does it commit into all the repos? 08:35:29 well, it was happening with 1.0.2 last night. 08:35:38 JaffaCake: well darcs doesn't really support subrepos in an automatic fashion 08:35:54 JaffaCake: so if you are wanting to do a commit across these different parts of fptools, you probably don't want to split it up 08:36:10 just like you can't, say, commit something in cvs that modifies both fptools and hugs98 08:36:32 but I commit things to ghc & libraries together 08:36:42 JaffaCake: There are very few server-side branches though, right? Plus, you could make a script to do it 08:36:57 it also seems very easy to get pending into a bad state 08:36:59 JaffaCake: right. but those are all in the same cvs module (fptools) 08:37:14 CosmicRay: actually ghc & libraries are separate modules 08:37:21 oh? 08:37:26 it's a bit of a hack 08:37:27 * Igloo hasn't solved the commutation problem. That's what the darcs-conflicts list is trying to do 08:37:32 this may explain part of my conversion problem 08:37:47 --- quit: bC (Connection timed out) 08:37:54 lots of projects share the top-level fptools stuff: ghc, happy, alex, haddock etc. 08:37:58 JaffaCake: well in that case, you can use a script like igloo suggested, but you will be committing two changesets instead of one 08:38:20 JaffaCake: For a similar layout I created a record script that looped through all the directories doing a record (and likewise for other commands) 08:38:26 in any case, the fptools source tree seems fairly small to me, compared to some of the stuff I've tried darcs on (kernel) 08:38:53 Even now 2 mails get sent to the list if you commit to ghc and libraries at the same time, so it's already really 2 commits 08:38:57 JaffaCake: right. I see what you mean. Having those in a separate repo would make it easier to pull patches into those various projects. 08:39:22 Igloo: this is CVS, it's a separate commit to each file, really :) 08:39:47 right, and the fact that darcs actually has atomic changesets is a big win, and not just for reliability 08:39:54 Well, yeah, but it does its best to pretend it's not :-) 08:40:13 Igloo: we see through its slimy exterior though :-) 08:40:29 so, do we have separate repos for the top-level fptools, then ghc, happy, alex, etc. 08:40:50 or do we duplicate fptools with each of ghc, happy etc. 08:40:57 Separate repos 08:41:25 so pretty much each top-level dir in fptools becomes its own repo? 08:41:32 Yup 08:41:36 ok, so the downside of that is you need a script to record 08:41:37 k. 08:41:46 JaffaCake: if your commit spans repos. 08:41:51 Yeah, but you can have all that in a root repo, like how fpconfig works now I think 08:41:57 * Palle thinks it's pretty funny my fellow students, don't think you can use haskell for anything.. 08:42:05 --- join: Gahhh (lolz@adsl-63-204-135-89.dsl.snfc21.pacbell.net) joined #haskell 08:42:06 So you darcs get fpconfig; ./get ghc libraries hslibs 08:42:19 Then ./record, ./send, ./push, ./pull etc 08:42:20 Igloo: do you have a public example of a setup like that anywhere? 08:42:21 it's easy to get that impression if you've not been taught to use monads effectively - it feels like you can't even do IO cleanly 08:42:22 ok, sounds reasonable 08:42:37 --- join: kleenest (~lambdawar@devhell.org) joined #haskell 08:43:15 Palle: It's not so amusing, when you've written bindings for Bzlib2, and they still say that. 08:43:30 we quite often only branch part of the tree, anyway 08:43:59 --- join: cptchaos (~cptchaos@e176014050.adsl.alicedsl.de) joined #haskell 08:44:07 CosmicRay: No 08:44:47 Oejet, Well what can I not do in haskell i can use in C? 08:45:07 Palle: You want to read my TMR2 article about that? You would be the perfect proof reader, since it's intended your level of guruness. 08:45:59 --- quit: Bo (Read error: 145 (Connection timed out)) 08:46:21 Oejet, I would really like that :) 08:46:39 I think the fpconfig repo should actually just be a generic metarepo, perhaps with an additional patch that creates an "allrepos" files and "defaultrepos" file 08:46:41 I'll send you a secret link. 08:47:30 With ./get creating myrepos and the others iterating over it (and .) 08:47:48 (unless overridden by args, possibly) 08:47:56 * JaffaCake wonders what a generic metarepo is, but it sounds exciting 08:48:13 Igloo: do you get any issues with push/pull in that scenario, establishing dozens of ssh conections to a server? 08:48:15 I have another CVS hack that I wonder whether it is supported in darcs. 08:48:26 --- join: Bo (~bo@nat.kollegienet.dk) joined #haskell 08:48:30 Just a repo with what I suggested fpconfig should have in 08:49:15 Under nhc98/src, the libraries, cpphs, and maybe some other things are grafted in. 08:49:30 I'm not sure whether this is the same situation as with fptools. 08:49:35 autrijus: using mapM_ over the UArray is a tiny bit faster 08:49:36 sounds like it is 08:49:37 CosmicRay: You'll get n times the number you would with a single repo; I guess you might be able to avoid that with one of those SSH connection sharing doodahs if that's a problem 08:49:55 * CosmicRay googles up ssh connection sharing 08:50:08 we used to use fsh 08:50:22 malcolm: It's basically the same, but the metarepo scripts would have to be slightly cleverer if not everything is at the root 08:50:24 but it just didn't work too often, so I ditched it 08:51:13 * CosmicRay installs fsh and pokes around 08:51:18 What about commit mailing lists? 08:51:42 JaffaCake: you could do that with either cron or a darcs hook, I believe 08:51:47 * Igloo does my commits with darcs send and procmail at the other end, in which case that's easy (just do them with procmail) 08:51:48 I haven't really looked into darcs hooks yet 08:51:59 I don't know if darcs push makes it possible 08:52:13 (If you're going to use darcs send then SSH connections also aren't an issue) 08:53:05 darcs send worries me slightly... I like to know when my patch has been committed 08:53:29 JaffaCake: probably you would not be using it, but perhaps a person like me would -- somebody who sends you a random patch every 6 months 08:53:37 sure 08:53:39 You do get a mail back saying "Patch applied" or giving a failure reason, or do you want to know right away? 08:53:51 JaffaCake: you could run darcs send again and see what isn't applied yet 08:54:03 thanks 08:54:44 Anyway, if push doesn't have suitable hooks then that should just be a SMOP 08:55:17 hmm, I can't find a reference for hokos in darcs 08:55:21 SMOP? 08:55:50 right, I imagine I'd be pushing a lot less often than I commit currently, because commit would mostly be replaced by record 08:55:58 yes 08:55:59 Simple Matter Of Programming 08:56:15 cvs commit is essentially the combination of darcs record and darcs push 08:56:17 I bet I forget to push on a regular basis :) 08:56:40 JaffaCake: cron :-) 08:56:42 I like the darcs send model better, because it obviates the need for commit access 08:57:37 so what tools do people use for accepting patches received via darcs send? 08:57:59 well, dons uses darcs apply for lambdabot 08:58:28 well everyone uses darcs apply at some point 08:58:33 here is a link to david's setup: 08:58:35 http://www.darcs.net/manual/node4.html#SECTION00455000000000000000 08:58:36 I want to just push a button the mail client, preferably 08:59:18 actualy, no, that's his setup to automatically accept gpg-signed patches. 08:59:31 here: http://www.darcs.net/manual/node4.html#SECTION00452000000000000000 08:59:50 "which allows me to apply patches directly from mutt, sending a confirmation email to the person who sent me the patch." 08:59:52 --- nick: Touqen -> Tou[t]qen 08:59:56 does he auto-accept all gpg-signed patches? 09:00:12 SamB: no, only those that verify using a special keyring for this purpose 09:00:34 I have a button that pipes it through gpg --clearsign -u DA155C87 | mail -s patch igloo@darcs.net (currently I select the attachment first, but I suspect I'll remove the need for that when it annoys me :-) 09:01:23 --- quit: martink_ (Remote closed the connection) 09:01:50 * Igloo looks at the URL; Ah, nifty, if that works on the mail itself then mine probably will too 09:03:26 CosmicRay: your cvs.haskell.org account is set up 09:04:15 Is the new IO library allowed to break existing code? 09:05:51 well, that would be pretty devastating 09:06:17 I'd prefer to have it alongside 09:07:28 How about if an OldIO interface could be put on top of it? 09:07:55 new IO library? 09:08:40 Igloo: the question is whether the old interface should be available from System.IO 09:08:56 (I'm thinking Handle should become (Something a => Handle a), instance Something [Char], instance Something [Byte] (or maybe rejig to be H98), type Byte = Word8 and then hGet would give you a Char or Byte as appropriate) 09:08:57 JaffaCake: great, thanks 09:08:57 Igloo, but even if you can layer the old semantics on an implementaion in terms of some new api, what have you gained? just a bit of tidying up underneath. 09:09:16 dcoutts_: You've gained a better API to write new code against 09:09:38 Igloo: Stream rather than Handle, IMO 09:09:56 ok having the new api is great but what's the point in changing the implementation of the old one 09:09:58 that was one design we explored for the Stream library 09:11:03 dcoutts_: Less cruft to carry round. Doesn't really matter, I suppose 09:11:11 what happes to the old one is not terribly important so long as it doesn't change and break existing programs 09:11:36 JaffaCake: Does that mean you rejected it? 09:11:59 --- quit: cptchaos (Read error: 104 (Connection reset by peer)) 09:12:23 the current design has the basic Stream class that you can do I/O with Word8, and TextInputStream/TextOutputStream which support I/O with Chars 09:12:32 --- join: `Sauron (sauron@rrcs-24-153-164-117.sw.biz.rr.com) joined #haskell 09:12:37 Igloo, I think you need to be able to do things like have lists of Handle which you would not be able to do directly with a Handle type class 09:12:45 --- part: `Sauron left #haskell 09:12:52 OK; do you still have FilePath = String? 09:12:53 there doesn't seem to be an obvious place to generalise over the element type 09:13:06 yes 09:13:11 --- join: `Sauron (sauron@rrcs-24-153-164-117.sw.biz.rr.com) joined #haskell 09:13:27 I'm not at all sure what should be done about FilePath 09:14:03 since apparently Unix requires [Word8] and Windows requires [Char] 09:14:28 I've got that problem at the moment, should the gtk2hs file selector API rerturn unicode strings or 'raw' strings? neither is sufficient for all purposes 09:14:46 I think I lost track of that discussion on haskell-cafe :) 09:14:54 I was thinking of an openFile :: Something b => a -> IO (Handle b) in my Something a class 09:15:19 So one instance converts and calls the other 09:15:29 if you try and display a raw string in the gui gtk will get very upset and if you don't then passing the unicode string to readFile is not guaranteed to work 09:15:43 * JaffaCake looks at the clock 09:15:47 heh 09:15:49 I've gotta go 09:15:53 'night :-) 09:16:04 bye folks :) 09:16:07 bye 09:16:10 --- quit: jak (sterling.freenode.net irc.freenode.net) 09:16:14 --- part: JaffaCake left #haskell 09:16:23 --- join: jak (~jak97@holt.doc.ic.ac.uk) joined #haskell 09:17:01 * Igloo has decided I don't object to the current function being discussed, anyway, which is the important thing :-) 09:18:18 Igloo, do you have a moment? if so I'll trot over and plague you with some obscure technical point about a constraint-based type inference algorithm and sets of type variables and substitutions upon them :-) 09:19:57 Damn, I don't have a magic clock that says I can go home. Sure :-) 09:20:18 :-) I'll print something out and be over in a sec... 09:21:13 --- part: `Sauron left #haskell 09:22:52 --- quit: malcolm () 09:22:59 --- quit: Gahhh (Read error: 110 (Connection timed out)) 09:24:56 --- join: chr1s_ (~chris@118-245.surfsnel.dsl.internl.net) joined #haskell 09:25:12 --- quit: chr1s_ (Client Quit) 09:28:08 --- join: skew_ (~brandon@page-148.caltech.edu) joined #haskell 09:28:08 --- quit: Huschi (Read error: 54 (Connection reset by peer)) 09:30:11 --- quit: skew (Nick collision from services.) 09:30:28 --- nick: skew_ -> skew 09:31:49 --- quit: CosmicRay ("Client exiting") 09:33:39 --- part: theorbtwo left #haskell 09:33:55 --- join: theorbtwo (~theorb@84-245-186-27.muc.bpool.celox.de) joined #haskell 09:34:32 --- join: martink (~martin@pD9EB3A8A.dip0.t-ipconnect.de) joined #haskell 09:34:54 --- join: ibo (~ibo@210.213.193.79) joined #haskell 09:37:29 hello, n00b question here. how do i declare a time value in haskell? im currently using hugs. TIA. 09:38:01 Time value? 09:38:19 yep like apr 23 2005 11 pm 09:38:51 getClockTime doesnt seem to work 09:39:24 How does it not work? 09:39:48 like if i type it in hugs... 09:39:51 nothing shows 09:40:10 i only started using haskell days ago.. im lost. 09:40:19 @type fmap System.Time.toUTCTime System.Time.getClockTime 09:40:24 fmap System.Time.toUTCTime System.Time.getClockTime :: IO System.Time.CalendarTi 09:40:24 me 09:40:29 that is odd 09:40:35 try getClockTime >>= print 09:41:16 i'd suggest System.Time.getClockTime >>= print 09:41:23 that's probably the problem.. 09:41:29 oh, looks like the return value from IO actions isn't printed 09:42:20 For some reason I was expecting act :: IO a for any Show a to run in ghci like act >>= print, but that would look really odd for things like print 09:42:30 getClockTime >>= print works 09:43:06 the others shows 'Undefined qualifide variable' 09:43:22 still a n00b.. hehe. i guess im missing a lot of things. 09:43:25 ibo: ghci (and apparently hugs) assume that if you have it evaluate something in IO you just want the side effects, not the result value 09:43:59 skew: GHCi sets 'it' to the result. 09:44:46 ok. but how do i declare a value? im trying to make a simple database using lists and hardcode dates like holidays. :) 09:46:18 You have to write declarations in a file. 09:47:05 Lemmih, could u post it how to do it? :) 09:48:10 Write some declarations in a file and load it in Hugs with ':l [filename]'. 09:49:48 yup, im doing that using simple types like strings, i dunno how to do it with ClockTime, oh well i guess im asking too much. RTFM for me. 09:50:03 unless anyones willing to make it easier for me :)) 09:51:04 @type getClockTime 09:51:06 bzzt 09:51:15 @google Haskell homework help 09:51:16 http://www.haskell.org/humor/homework.html 09:51:54 @type System.Time.getClockTime 09:51:56 System.Time.getClockTime :: IO System.Time.ClockTime 09:53:36 http://www.haskell.org/humor/homework.html <- lolz. hehe. im just a poor kid :) 09:53:42 ibo: The IO type means that getClockTime is not a pure function. 09:53:44 (: 09:54:18 --- join: GunZ (~podderka@host-83-146-13-138.bulldogdsl.com) joined #haskell 09:54:54 --- join: SyntaxNinja (~ijones@cvs.galois.com) joined #haskell 09:55:01 SyntaxNinja: Hey! 09:55:05 Oejet, tnx :) 09:55:35 ibo: Something like this: 09:55:36 do t <- getClockTime 09:55:36 doSomethingWith t 09:56:12 --- nick: eno-zzz -> eno-away 09:57:20 heya Lemmih how's it going? 09:57:47 Great. Got some cabal-get patches ready (: 09:58:03 Oejet, lets say i want a constant time value... 09:58:09 time1 :: ClockTime 09:58:10 Lemmih: cool. should I pull? 09:58:13 timexx = ???? how do i put the month? 10:02:20 SyntaxNinja: Not yet. Gonna check if I forgot any files this time (: 10:03:18 Hey guys what exactly does "somename :: Integer -> Integer" mean? does it mean you input an Integer and an Integer is returned? 10:03:38 GunZ: Yes. 10:03:55 Lemmih: c00 10:03:58 Lemmih: ok so what does Integer -> Integer -> Integer mean? 10:04:06 input two integers? 10:04:18 GunZ: lucky guess! 10:04:26 GunZ: for instance, the type of the plus operator: 10:04:30 @type (+) 10:04:31 (+) :: forall a. (Num a) => a -> a -> a 10:04:43 it's a little more complex, but basically inputs two numbers and outputs a number 10:04:54 ahh ok thx :) 10:05:36 is there a tool for extracting the type sigs of a module into a text file? sorta like a text target for haddock. 10:07:46 why do you want to do that? 10:08:24 SyntaxNinja: ghc --show-iface | some-sed-action-here ? 10:11:25 --- join: sond_ (~david@sond.brg.sgsnet.se) joined #haskell 10:11:34 --- join: mwelsh (~Mike@host140.osu-btc.com) joined #haskell 10:12:32 is there a better (and by better i mean either faster or uses less space or both) way to calculate e = (head $ filter (\n -> (gcd n m) == 1) [2..m]) 10:12:51 --- join: bC (~bC@bing52.brandywine.binghamton.edu) joined #haskell 10:13:42 factorise m and use a sieve? 10:14:21 Shouldn't that terminate when filter returns the first element? Due to laziness and all? 10:14:24 --- quit: sond (Read error: 145 (Connection timed out)) 10:14:34 yea, thats what im hoping for 10:14:36 sorry guys for this... is declaring time in a list possible? 10:14:37 all i want is something like declaring stuff. 10:14:37 type stringstring = [ (String,String) ] -----> [("1st","2nd")] 10:14:37 type timetime = [ (ClockTime,ClockTime) ] -----> [(????,????)] 10:14:45 i was just curious if there was a better way 10:14:50 mwelsh, that's what *should* happen, if I'm not mistaken (I may as well be). 10:15:55 ibo: of course it is. 10:16:11 on a slightly unrelated note... is there any reason to prefer "(f1 . f2) x" over "f1 $ f2 x"? 10:16:47 basti_, still a noob... an example could help... i still dont know how to access stuff like the month, day, etc... 10:16:52 not unless that allows you to eta-expand the e out 10:17:01 IM the x, not the e 10:17:05 and IM eta-contract. 10:17:13 Heffalump, the what in the what?.. 10:17:23 ibo: that would depend on your time type. 10:17:33 who shot who in the what now? 10:17:59 ibo: i do not know about any time types in haskell so i can't help you with that. 10:18:01 ibo: You can checkout the libraries documentation at http://www.haskell.org/ghc/ 10:18:49 ibo: http://www.haskell.org/ghc/docs/latest/html/libraries/index.html to be exact. Look for System.Time 10:19:05 argh, are there any tools other than HaT for finding out what hasn't been evaluated in a stack? 10:19:08 there you go 10:19:08 :) 10:19:19 Lemmih, struggled with that... i guess i better invest in reading more. i cant learn this all in a day. :) 10:19:29 skew: why I want to show the interface: because I want to go over it and edit it to be more ideal :) 10:19:44 Lemmih: thanks 10:20:20 SyntaxNinja: thanks? 10:21:16 --- join: CosmicRay (~jgoerzen@2002:4463:7269:1:20e:a6ff:fe66:c5a3) joined #haskell 10:21:25 SyntaxNinja: Tested and pushed the patch. 10:21:52 Lemmih: about dump iface or whatever... 10:22:20 Lemmih: may not get to work on that 'till this afternoon 10:22:22 CosmicRay: alive? 10:22:38 what do you guys think this machine should be called? it'll be haskell.galois.com, but also something.haskell.org 10:22:54 community.haskell.org and it would include CosmicRay's site 10:23:02 SyntaxNinja: yes 10:23:06 or packages.haskell.org as separate from CosmicRay's site 10:23:15 * Lemmih votes for community.haskell.org 10:23:30 or hackage.haskell.org 10:23:53 --- nick: CrewdenX^2 -> CrewdenX 10:23:53 * CosmicRay leaves the naming of things to others, but if it's something like packages. or hackage., it doesn't make sense to have the sequence "under" that 10:24:06 the sequence could still be hosted on that machine, but at sequence.haskell.org or something 10:25:14 CosmicRay: yeah, agree. 10:26:50 CosmicRay: that's what I was saying... do you think it would make sense to have them both as community.haskell.org/{hackage,sequence} 10:26:52 Didn't community conflict with HC&R? 10:26:54 or would it be better to have separate servers 10:28:01 Igloo: howso? 10:28:20 it would maybe make sense to have commuity.haskell.org/{hackage,sequence,hc&r,hawiki} 10:30:00 SyntaxNinja: that sounds fine 10:30:16 SyntaxNinja: though the urls get a bit longish 10:30:34 SyntaxNinja: I dunno, on the one hand doing that implies a erlationship between them 10:30:43 on the other hand, all of those have dramatically different layouts, etc. 10:30:47 but it's no big deal 10:31:04 Confusion between that and http://www.haskell.org/communities 10:32:19 ah, true 10:33:34 hmm, what's the path to the cvs repo on glass? 10:35:28 * CosmicRay finds it 10:42:08 CosmicRay: Do you have a signal.h on AIX? 10:42:15 * CosmicRay checks 10:42:34 yes, both signal.h and sys/signal.h 10:42:46 the former includes the latter 10:43:11 OK, is there any sane way of finding out if (and when) signal.h (possibly indirectly) #includes net/net_globals.h? 10:43:29 well let me see if there's a nest of includes in this... 10:44:29 I wonder of cpp could do that for me. 10:45:21 no, it doesn't appear to. 10:45:28 Ah, echo -e "#include \n psignal(x, y)" | cpp would tell you what happens by defaut, at least 10:45:49 But if that doesn't work you would just have to guess at what defines might help :-/ 10:46:17 psignal does not apepar to be a macro 10:46:30 hmm. 10:46:38 where did I report this? :-) 10:46:40 was it in darcs? 10:46:46 Yes 10:46:54 ok, I remember the problem, just not where it was :-) 10:46:57 bugs.darcs.net, #353 10:47:04 well let me grep around for what might include net_globals 10:47:11 did the prototype I posted look like the right function? 10:47:35 how do I get a login for bugs.darcs.net, or check if I already have one? 10:47:57 net_globals is directly included by sys/socketvar.h, sys/mbuf.h, sys/domain.h, sys/cdli.h, net/if.h 10:48:34 the aix manual doesn't specify a canonical header file for it. 10:48:41 I have a vague feeling you need to e-mail the guy who set it up or DR to get one. But guest/guest allows you to view bugs, at least 10:48:54 Igloo: I submitted mine as guest 10:49:36 CosmicRay: I'm hoping we just need to #define something 10:50:24 CosmicRay: Any chance you could find out in some AIX forum? 10:50:42 Igloo: fwiw, the code works as it is 10:50:54 * Heffalump wonders how to find any bugs at all 10:51:00 Igloo: last I looked, I couldn't track down any good ones but I could try again 10:51:12 it seems that techies all seem to try their best to avoid aix like the plague :-) 10:51:31 I found some by searching for new or open ones, I think 10:51:36 It wasn't very intuitive for me 10:51:54 http://bugs.darcs.net/.//Ticket/Display.html?id=353 is the one we're talking about 10:51:55 * basti_ thinks he doesn't even need existentials 10:52:15 I just want to check if the one I was discussing has been reported 10:52:35 rt is very nice but its default configuration needs to be adjusted a bit more to be useful like this 10:52:50 log in, then go to tickets -> search 10:52:55 from there it should be obvious enough 10:53:16 you can also click on darcs under queue and see a full list 10:53:30 it wasn't obvious how to do a search that finds anything 10:53:43 well you can search by subject line or body, for isntance 10:53:46 CosmicRay: what was that thing about prolog yesterday evening? ;) 10:53:55 if you just do that and leave everythign else blank, you shoudl be ok 10:54:00 CosmicRay: yes, I finally found that 10:54:14 where is 'Queue'? 10:54:14 basti_: I piped my haskell program through tac :-) 10:54:24 on the right under quick search 10:54:26 on the homepage 10:54:30 What "Created before" expected as an argument wasn't obvious to me either 10:54:36 whats tac? 10:54:45 CosmicRay: Can you tell whoever runs it how to configure it better? 10:54:47 basti_: it's like cat, but reverses the order of lines in your program :-) 10:54:55 ah, that's a link 10:54:58 uhm... 10:55:06 basti_: never mind, I was joking 10:55:10 okayyyy. 10:55:12