From john at repetae.net Wed Feb 18 03:46:16 2009 From: john at repetae.net (John Meacham) Date: Wed Feb 18 03:35:40 2009 Subject: [jhc] darcs patch: fix compatability with ghc 6.10 due to D... (and 1 more) Message-ID: <20090218084617.AC8A4B80DC@sliver.repetae.net> Wed Feb 18 00:08:13 PST 2009 John Meacham * fix compatability with ghc 6.10 due to Data.Map.lookup type change Ignore-this: 6383f410fc69c2791a2a1184bea3dd70 Wed Feb 18 00:08:47 PST 2009 John Meacham * don't abort if DrIFT is not installed Ignore-this: a1d3ecf56256f5d7164998f8d5a142f2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2694 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20090218/f61cd9ad/attachment.bin From john at repetae.net Wed Feb 18 08:32:09 2009 From: john at repetae.net (John Meacham) Date: Wed Feb 18 08:21:30 2009 Subject: [jhc] darcs patch: support Win32 target. (and 5 more) Message-ID: <20090218133209.4107A88043@sliver.repetae.net> Wed Feb 18 01:33:23 PST 2009 John Meacham * support Win32 target. Wed Feb 18 02:19:48 PST 2009 John Meacham * add E/Show.hs-boot to the list of hs-boot files Ignore-this: a4243c6a2209237d7c245f409d19f857 Wed Feb 18 02:36:53 PST 2009 John Meacham tagged todthicedal Ignore-this: 20a12b57a2c88ffdf4e31fea33a2a4fc Wed Feb 18 02:36:57 PST 2009 John Meacham * update datestamp Ignore-this: 38a19570744139ee668fefb24e83a5be Wed Feb 18 03:27:20 PST 2009 John Meacham * update documentation Ignore-this: dbfff88da59670d189f90e599f1fd5a7 Wed Feb 18 04:45:59 PST 2009 John Meacham * add --print-hsc-options option to jhc Ignore-this: 40b9055b3a4e599bda630f3cfbdaa958 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 17995 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20090218/c38cf49a/attachment-0001.bin From taralx at gmail.com Wed Feb 18 19:36:12 2009 From: taralx at gmail.com (Taral) Date: Wed Feb 18 19:25:32 2009 Subject: [jhc] darcs patch: fix compatability with ghc 6.10 due to D... (and 1 more) In-Reply-To: <20090218084617.AC8A4B80DC@sliver.repetae.net> References: <20090218084617.AC8A4B80DC@sliver.repetae.net> Message-ID: On Wed, Feb 18, 2009 at 12:46 AM, John Meacham wrote: > Wed Feb 18 00:08:47 PST 2009 John Meacham > * don't abort if DrIFT is not installed > Ignore-this: a1d3ecf56256f5d7164998f8d5a142f2 Do you think it would be possible to move away from DrIFT yet? 6.10+TH should cover the cases, no? -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From john at repetae.net Thu Feb 19 02:15:39 2009 From: john at repetae.net (John Meacham) Date: Thu Feb 19 02:04:57 2009 Subject: [jhc] darcs patch: fix compatability with ghc 6.10 due to D... (and 1 more) In-Reply-To: References: <20090218084617.AC8A4B80DC@sliver.repetae.net> Message-ID: <20090219071539.GH22261@sliver.repetae.net> On Wed, Feb 18, 2009 at 04:36:12PM -0800, Taral wrote: > On Wed, Feb 18, 2009 at 12:46 AM, John Meacham wrote: > > Wed Feb 18 00:08:47 PST 2009 John Meacham > > * don't abort if DrIFT is not installed > > Ignore-this: a1d3ecf56256f5d7164998f8d5a142f2 > > Do you think it would be possible to move away from DrIFT yet? 6.10+TH > should cover the cases, no? A goal of jhc is to be self hosting sooner rather than later, I am trying to keep usage of extensions to a minimum and even then restricted to what is very likely to be in haskell'. Template Haskell is not something I am ready to depend on just yet. DrIFT is pure haskell 98 and can be removed as a dependency by including the generated files in the tarball. Though, eventually, I'd like to see a standalone implementation of template haskell, which would change things around. In any case, with my recent changes, DrIFT isn't required to compile any more[1] unless you do a 'make maintainer-clean' to really really clean things up, so it shouldn't be an issue for end users. John [1] http://repetae.net/computer/jhc/building.shtml -- John Meacham - ?repetae.net?john? From john at repetae.net Fri Feb 20 18:09:00 2009 From: john at repetae.net (John Meacham) Date: Fri Feb 20 17:58:21 2009 Subject: [jhc] moving to darcs-2 format Message-ID: <20090220230859.GN22261@sliver.repetae.net> I have migrated the repository to the darcs-2 hashed repository format. Jhc has a long history and the more robust format will be helpful in the long run. The repository is still at the same location http://repetae.net/repos/jhc and the old darcs 1 repository at the point of crossover is at http://repetae.net/repos/jhc_old enjoy! John -- John Meacham - ?repetae.net?john? From john at repetae.net Sat Feb 21 20:24:58 2009 From: john at repetae.net (John Meacham) Date: Sat Feb 21 20:14:07 2009 Subject: [jhc] darcs patch: add bang pattern strictness annotations (and 3 more) Message-ID: <20090222012458.5C4E980004@sliver.repetae.net> Sat Feb 21 02:52:17 PST 2009 John Meacham * add bang pattern strictness annotations Sat Feb 21 06:46:38 PST 2009 John Meacham * add some more useful regression tests Sat Feb 21 16:11:05 PST 2009 John Meacham * fix warnings Sat Feb 21 17:18:36 PST 2009 John Meacham * clean up and commend id system more, close last holes in the ADT, create a more efficient binary representation for Ids -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 46608 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20090221/469a80d6/attachment-0001.bin From john at repetae.net Sat Feb 21 20:27:07 2009 From: john at repetae.net (John Meacham) Date: Sat Feb 21 20:16:17 2009 Subject: [jhc] darcs patch: add bang pattern strictness annotations (and 3 more) In-Reply-To: <20090222012458.5C4E980004@sliver.repetae.net> References: <20090222012458.5C4E980004@sliver.repetae.net> Message-ID: <20090222012707.GV22261@sliver.repetae.net> Just a note, the last patch dealing with Ids changes the binary representation (using 1 byte instead of 5 for many cases, and is simpler to boot), so you will need to rebuild your ho and hl files if you pull said patch. John -- John Meacham - ?repetae.net?john? From rick.richardson at gmail.com Sun Feb 22 11:44:25 2009 From: rick.richardson at gmail.com (Rick R) Date: Sun Feb 22 11:33:33 2009 Subject: [jhc] Emitting Optimal C Message-ID: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> I have been looking for a functional language that compiles to efficient C/C++ to fufill two rather odd criteria. 1. To conform to the requirements of the iPhone Developers Program. Code must compile in XCode and be either C/C++/Obj-C. Garbage collection is mostly disallowed. Program size and memory must fit below a threshold. 2. Separately, to perform Naive Bayes computation across huge datasets. What is required is function inlining as well as use of SIMD instructions. I would provide the inlined functions via .h's and compile them in with gcc. I really don't know much about language design and development, so I might be way off base here. For the GC, I guess this would imply that there would be a way to fix the scope of closures and other structures that are referenced/collected. With jhc taking a 'full program' approach to analysis and optimization, I thought that this might be possible. Or perhaps there is a way to use ref counting for objects of an indeterminate lifespan instead of incremental (or whichever) garbage collection. I see that jhc see offers a way to specify unboxed values and tuples. And I'm sure there is a way to manage large native arrays as well. Is there a way to pass that data directly to an inline C function that would be compiled in by gcc? (i.e. not loaded from a library through FFI) I've looked through most of the jhc mailing list archives and haven't found any such discussions. Would this be something that would be achievable somewhere in the jhc roadmap, or at least conceivable with a few hacks? -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/jhc/attachments/20090222/255b677c/attachment.htm From ml at isaac.cedarswampstudios.org Sun Feb 22 17:19:12 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sun Feb 22 17:08:29 2009 Subject: [jhc] Emitting Optimal C In-Reply-To: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> References: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> Message-ID: <200902221719.12443.ml@isaac.cedarswampstudios.org> Rick R wrote: > I have been looking for a functional language that compiles to efficient > C/C++ to fufill two rather odd criteria. > > 1. To conform to the requirements of the iPhone Developers Program. Code > must compile in XCode and be either C/C++/Obj-C. Garbage collection is > mostly disallowed. Program size and memory must fit below a threshold. In what way is "garbage collection mostly disallowed"? Is there a technical restriction (rather than just documentation saying "we don't want you to use garbage collectors")? Is the issue the one you mention in the next sentence ("Program size and memory must fit below a threshold") in that most garbage collectors are complicated? -Isaac From rick.richardson at gmail.com Sun Feb 22 17:41:43 2009 From: rick.richardson at gmail.com (Rick R) Date: Sun Feb 22 17:30:50 2009 Subject: [jhc] Emitting Optimal C In-Reply-To: <200902221719.12443.ml@isaac.cedarswampstudios.org> References: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> <200902221719.12443.ml@isaac.cedarswampstudios.org> Message-ID: <9810b81b0902221441s5d94a431t91903d1d481fa188@mail.gmail.com> It doesn't explicitly forbid GC in the Developer agreement. However, cocoa's own garbage collector is removed in the iPhone SDK. In the docs describing the API, it indicates that using Apple's your own GC is disallowed. This means its not part of the official agreement, however, since they're allowed to reject apps for any reason, I don't feel comfortable using it. Ref counting is the official and most common form of memory management on the iPhone. Somewhere there are official specs on how many resources are provided to your app. I can't find them now, but they seemed quite reasonable for a phone. On Sun, Feb 22, 2009 at 5:19 PM, Isaac Dupree wrote: > Rick R wrote: >> I have been looking for a functional language that compiles to efficient >> C/C++ to fufill two rather odd criteria. >> >> 1. To conform to the requirements of the iPhone Developers Program. Code >> must compile in XCode and be either C/C++/Obj-C. Garbage collection is >> mostly disallowed. Program size and memory must fit below a threshold. > > In what way is "garbage collection mostly disallowed"? Is there a technical > restriction (rather than just documentation saying "we don't want you to use > garbage collectors")? Is the issue the one you mention in the next sentence > ("Program size and memory must fit below a threshold") in that most garbage > collectors are complicated? > > -Isaac > > -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein From john at repetae.net Mon Feb 23 18:44:07 2009 From: john at repetae.net (John Meacham) Date: Mon Feb 23 18:33:10 2009 Subject: [jhc] Emitting Optimal C In-Reply-To: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> References: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> Message-ID: <20090223234406.GC22261@sliver.repetae.net> On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote: > I have been looking for a functional language that compiles to efficient > C/C++ to fufill two rather odd criteria. > > 1. To conform to the requirements of the iPhone Developers Program. Code > must compile in XCode and be either C/C++/Obj-C. Garbage collection is > mostly disallowed. Program size and memory must fit below a threshold. Hmm.. interesting. What compiler is XCode based on? If it is a gcc derivitive, I don't see any reason this wouldn't work. It is actually quite easy to compile programs for OSX or windows with jhc if you have something like IMCROSS[1] installed. you just do jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe I was able to compile programs for the iPhone the same way, but I had a jailbroken phone so didn't need to conform to their other standards. I am not sure what they could mean by 'no GC', is it simply because they require C/C++ or ObjC? I mean, when you write a C program, clearly you need to write in some mechanism to deal with garbage. Hmm.. you might want to ask them whether it is okay to link against the boehm gc. although not ideal (very not ideal speed-wise), jhc works with that, but if they allow it, then I imagine the more advanced gc options will be okay too. > 2. Separately, to perform Naive Bayes computation across huge datasets. What > is required is function inlining as well as use of SIMD instructions. > I would provide the inlined functions via .h's and compile them in with gcc. How huge of a dataset? Are you working on a better song recommendation wizard? Something you might want to look into is that I am pretty sure the iPhone has sqlite as standard equipment, I think you can extend it with your own operations, perhaps a bayes computation operation or something. hmm... but the sqlite overhead might kill you. hard to say. > I see that jhc see offers a way to specify unboxed values and tuples. And > I'm sure there is a way to manage large native arrays as well. Is there a > way to pass that data directly to an inline C function that would be > compiled in by gcc? (i.e. not loaded from a library through FFI) When you import something via the FFI, say something like foreigin import ccall foo :: CInt -> CInt then nothing special happens other than calls to foo(x) will appear in the source. now, you can provide that function however you want, via a library, or via direct linking against the C code, jhc doesn't really care. Hmm.. if you want to actually have them be inlined functions, I will probably have to give you a way to specify that the definition actually might appear in the header file, not just a prototype (since prototypes arn't needed in general) so a pragma might be in order to say "I really need this file #included.". It should be easy to implement. When you come across the issue post it on the list and we can figure out what the best solution is. A trivial workaround would be to just postprocess the c code produced by jhc itself until a built in mechanism is created. > I've looked through most of the jhc mailing list archives and haven't found > any such discussions. Would this be something that would be achievable > somewhere in the jhc roadmap, or at least conceivable with a few hacks? Nothing sounds like a showstopper. jhc is great at cross compiling, so embedded targets like phones are a natural match with it. John -- John Meacham - ?repetae.net?john? From rick.richardson at gmail.com Mon Feb 23 19:03:46 2009 From: rick.richardson at gmail.com (Rick R) Date: Mon Feb 23 18:52:50 2009 Subject: [jhc] Emitting Optimal C In-Reply-To: <20090223234406.GC22261@sliver.repetae.net> References: <9810b81b0902220844i10208cf7hc5c6521899939946@mail.gmail.com> <20090223234406.GC22261@sliver.repetae.net> Message-ID: <9810b81b0902231603h3e7e04e9nc9bd42638a5dfc85@mail.gmail.com> Thanks for that info. The iPhone app and the bayes stuff are separate. I will likely use jhc for for the bayes stuff. Once I get to the point where I'd like tight C++ integration, I'll be sure to yell. However, for the iPhone, Pre-Scheme fits my needs almost perfectly. Since Apple can (and does) reject apps for any reason, I would like to make my apps as conformant as possible. Which building C/Obj-C start to finish within X-code, only statically linking, and only using their libs. Dynamically linking is expressly forbidden, and GC is a gray area in which I'd rather not tread. On Mon, Feb 23, 2009 at 6:44 PM, John Meacham wrote: > On Sun, Feb 22, 2009 at 11:44:25AM -0500, Rick R wrote: >> I have been looking for a functional language that compiles to efficient >> C/C++ to fufill two rather odd criteria. >> >> 1. To conform to the requirements of the iPhone Developers Program. Code >> must compile in XCode and be either C/C++/Obj-C. Garbage collection is >> mostly disallowed. Program size and memory must fit below a threshold. > > Hmm.. interesting. What compiler is XCode based on? If it is a gcc > derivitive, I don't see any reason this wouldn't work. It is actually > quite easy to compile programs for OSX or windows with jhc > if you have something like IMCROSS[1] installed. you just do > > jhc --progc i386-mingw32-gcc HelloWorld.hs -o hello.exe > > I was able to compile programs for the iPhone the same way, but I had a > jailbroken phone so didn't need to conform to their other standards. > > I am not sure what they could mean by 'no GC', is it simply because they > require C/C++ or ObjC? I mean, when you write a C program, clearly you > need to write in some mechanism to deal with garbage. > > Hmm.. you might want to ask them whether it is okay to link against the > boehm gc. although not ideal (very not ideal speed-wise), jhc works > with that, but if they allow it, then I imagine the more advanced gc > options will be okay too. > > >> 2. Separately, to perform Naive Bayes computation across huge datasets. What >> is required is function inlining as well as use of SIMD instructions. >> I would provide the inlined functions via .h's and compile them in with gcc. > > How huge of a dataset? Are you working on a better song recommendation > wizard? Something you might want to look into is that I am pretty sure > the iPhone has sqlite as standard equipment, I think you can extend it > with your own operations, perhaps a bayes computation operation or > something. hmm... but the sqlite overhead might kill you. hard to say. > >> I see that jhc see offers a way to specify unboxed values and tuples. And >> I'm sure there is a way to manage large native arrays as well. Is there a >> way to pass that data directly to an inline C function that would be >> compiled in by gcc? (i.e. not loaded from a library through FFI) > > When you import something via the FFI, say something like > > foreigin import ccall foo :: CInt -> CInt > > then nothing special happens other than calls to foo(x) will appear in > the source. now, you can provide that function however you want, via a > library, or via direct linking against the C code, jhc doesn't really > care. > > Hmm.. if you want to actually have them be inlined functions, I will > probably have to give you a way to specify that the definition actually > might appear in the header file, not just a prototype (since prototypes > arn't needed in general) so a pragma might be in order to say "I really > need this file #included.". It should be easy to implement. When you > come across the issue post it on the list and we can figure out what the > best solution is. A trivial workaround would be to just postprocess the > c code produced by jhc itself until a built in mechanism is created. > > >> I've looked through most of the jhc mailing list archives and haven't found >> any such discussions. Would this be something that would be achievable >> somewhere in the jhc roadmap, or at least conceivable with a few hacks? > > Nothing sounds like a showstopper. jhc is great at cross compiling, so > embedded targets like phones are a natural match with it. > > John > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > jhc mailing list > jhc@haskell.org > http://www.haskell.org/mailman/listinfo/jhc > -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein From john at repetae.net Tue Feb 24 05:57:10 2009 From: john at repetae.net (John Meacham) Date: Tue Feb 24 05:46:12 2009 Subject: [jhc] darcs patch: TAG hichyodoteut (and 10 more) Message-ID: <20090224105711.00E2780004@sliver.repetae.net> Sat Feb 21 17:31:17 PST 2009 John Meacham tagged hichyodoteut Sat Feb 21 17:55:32 PST 2009 John Meacham * improve main web page Sun Feb 22 05:31:19 PST 2009 John Meacham * get rid of showId in favor of using Id show instance directly Sun Jan 25 19:40:47 PST 2009 Samuel Bronson * Error message layout wibble in E.TypeCheck Sun Feb 22 06:04:25 PST 2009 John Meacham * clean up use of anonymous ids Mon Feb 23 05:12:24 PST 2009 John Meacham * improve documentation on core type system Mon Feb 23 20:27:11 PST 2009 John Meacham * use new associative pretty printer Mon Feb 23 21:41:01 PST 2009 John Meacham * honor precedence in the type pprint instance Tue Feb 24 00:00:21 PST 2009 John Meacham * when matching expressions, look inside newtypes and pull apart literals to match against applications of variables Tue Feb 24 00:37:00 PST 2009 John Meacham * when creating instance rules, use true unification to determine how to pass arguments to the rule body in favor of assuming they appear in a certain order Tue Feb 24 02:43:52 PST 2009 John Meacham * when devolving grin, iterate until fixpoint is reached when deciding what arguments need to be lifted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 41972 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20090224/771bbb87/attachment-0001.bin From john at repetae.net Thu Feb 26 06:55:09 2009 From: john at repetae.net (John Meacham) Date: Thu Feb 26 06:44:05 2009 Subject: [jhc] darcs patch: TAG shlamasfasp (and 20 more) Message-ID: <20090226115509.C532FF8259@sliver.repetae.net> Tue Feb 24 03:43:38 PST 2009 John Meacham tagged shlamasfasp Tue Feb 24 03:43:57 PST 2009 John Meacham * update datestamp Tue Feb 24 14:21:28 PST 2009 John Meacham * include jhc.spec in the generated tarball so rpmbuild -ta will work Tue Feb 24 14:40:37 PST 2009 John Meacham * allow empty top level declarations Tue Feb 24 14:52:06 PST 2009 John Meacham * add 'nbody' shootout entry to regression test, integrate Kleisli failing case to KindInference test Tue Feb 24 15:00:28 PST 2009 John Meacham * clean out environment in regression testing script. only pass '-v' to jhc when -v passed to regression tester Tue Feb 24 17:06:30 PST 2009 John Meacham * fix some compile warnings Wed Feb 25 20:48:18 PST 2009 John Meacham * simplify id choosing code in E.SSimplify, get rid of some unused exports in Name.Id Wed Feb 25 21:10:15 PST 2009 John Meacham * use 'Integer' when printing C types to avoid overflow on 32 bit ghcs Wed Feb 25 22:01:35 PST 2009 John Meacham * improve show instance for MetaVar Wed Feb 25 22:11:36 PST 2009 John Meacham * add a rountine to quantify over several types at once Wed Feb 25 22:12:50 PST 2009 John Meacham * use quantify_n when typing mutually recursive binding groups Thu Feb 26 00:13:53 PST 2009 John Meacham * improve printing of CPR annotations, trim annotations to 5 levels deep to avoid slowdown with large amounts of constant data Thu Feb 26 00:23:36 PST 2009 John Meacham * various cleanups to E.Demand Thu Feb 26 00:46:03 PST 2009 John Meacham * remove some information from demand analysis results to help speed up jhc Thu Feb 26 01:34:04 PST 2009 John Meacham * allow empty field patterns Thu Feb 26 02:58:27 PST 2009 John Meacham * added some new library modules, Data.Function Control.Monad.Fix Control.Monad.Instances Thu Feb 26 03:15:08 PST 2009 John Meacham * improve handling of conversion between the arrow constructor and the arrow function Thu Feb 26 03:35:47 PST 2009 John Meacham * bring in Data.Monoid from the ghc libraries for compatability Thu Feb 26 03:45:34 PST 2009 John Meacham * add Data.Unique module to library Thu Feb 26 03:53:08 PST 2009 John Meacham * add 'applicative' package, which has Control.Applicative, Control.Arrow Control.Category Data.Foldable and Data.Traversable -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 107161 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/jhc/attachments/20090226/e58bcc17/attachment-0001.bin