Re: [Haskell-cafe] Generating Code
On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote: The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH. On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote: For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal, specification. In a sense I'm compiling to Haskell. This answer is for both the above quotes. While TH is not perfect (and sometimes tedious/difficult to write in), it's not restricted to simply generate code based on some parameters in an existing Haskell file. It cannot generate modules, true, but other than that you could have a module simply like this: module Foo where import … $(myBuilder) Where myBuilder doesn't take any parameters, just reads some external (XML, text file, whatever) and build the code from scratch. I might misunderstand the problem, but I think that you _could_ use TH for compiling to Haskell, as long as you have a Haskell parser for the external/formal spec. regards, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Alternative STM implementation
Hi, This morning I have written an STM implementation as a learning exercise. I thought I'd share it here to get some critique and because it might be useful to others (consider it as being in the public domain). I haven't tested it thoroughly, so there may be edge cases that haven't been thought through. It should be a drop-in replacement (so long as you only use TVars), if anyone has any STM benchmarks already made, I'd love to see how it compares. Here it is: https://gist.github.com/1454995 Thanks, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On 12/10/2011 09:38, Iustin Pop wrote: On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote: The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH. On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote: For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal, specification. In a sense I'm compiling to Haskell. This answer is for both the above quotes. While TH is not perfect (and sometimes tedious/difficult to write in), it's not restricted to simply generate code based on some parameters in an existing Haskell file. It cannot generate modules, true, but other than that you could have a module simply like this: module Foo where import … $(myBuilder) Where myBuilder doesn't take any parameters, just reads some external (XML, text file, whatever) and build the code from scratch. I might misunderstand the problem, but I think that you _could_ use TH for compiling to Haskell, as long as you have a Haskell parser for the external/formal spec. regards, iustin There are the haskell-src-exts-qq and haskell-src-meta packages on hackage that will get you partway to generating source code for a Haskell module. Full support for Haskell quasiquotation would require a modified version of haskell-src-exts (to properly handle antiquotation). The problem with TH is that it runs when the module is compiled. Reading a spec in from a file within a TH quote is possible, but it would be much nicer to be able to write a code generator, which a full Haskell quasiquoter would allow. Maybe someone is interested in a side-project? :) Geoff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On 12/09/2011 21:47, Stephen Tetley wrote: Geoffrey Mainland did significant work generating C with his GHC quasi quote extension. I'm not sure the status or availability of the code but there was a good Haskell Workshop paper describing it. In case anybody is interested, language-c-quote on hackage is the current version of the C quasiquoting library from the workshop paper. Geoff For the specific problem of OpenGL - as the package already exists I'm not sure a generative approach would actually pay its way ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Beginning Data.Lens tutorial
Dear Group, If you haven't used lenses before, (as I hadn't until recently) you may find this helpful: http://www.nadineloveshenry.com/haskell/lensExamples.html Best wishes, Henry Laxen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Sat, Dec 10, 2011 at 11:12 AM, Vo Minh Thu not...@gmail.com wrote: 2011/12/9 Stephen Tetley stephen.tet...@gmail.com: Geoffrey Mainland did significant work generating C with his GHC quasi quote extension. I'm not sure the status or availability of the code but there was a good Haskell Workshop paper describing it. For the specific problem of OpenGL - as the package already exists I'm not sure a generative approach would actually pay its way I believe it is the right approach, and the one used originally. Whenever you will want to add appearing functionalities (from later OpenGL specs) or modify something (debugging facilities), having a generative approach will pay. Actually, from the OpenGL spec files, there is a lot that can be done, not just OpenGL bindings. As for the OP original question, I wonder why he wants to add comments in the generated code. That code should be a straightforward mapping to the original C API. No need to document it. Documentation would be good for higher-level bindings but not for one corresponding tightly to the specs files. Of course some documentation about the used conventions and other generic properties of the bindings would be usefull, but I don't see any reason to generate documentation as part of the generated code. Cheers, Thu Indeed generating documentation for OpenGLRaw is not really a problem, it could be a nice feature to add a link to the OpenGL documentation for each imported function. Furthermore, the lack off good support for documentation makes it impossible to use haskell-src-exts to use documented haskell code and modify it without losing relevant documentation. The lack of CPP and antiquotation (as is pointed to by Geoff) are just examples of haskell-src-exts being non extenable. For reading and processing haskell is the rigid syntax structure no problem, as you only need valid haskell syntax. But when you try to add or modify the source this will turn into a real problem. The use of template haskell doesn't solve this, and in my opinion makes the problems even worse. Code generated by TH can't really be documented as there is no code yet, nor can it's source be read as simply as pure code. And last but not least it's not really portable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating Code
On Sat, Dec 10, 2011 at 1:59 PM, Geoffrey Mainland mainl...@apeiron.net wrote: On 12/10/2011 09:38, Iustin Pop wrote: On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote: The major set of problems for using template haskell is that it doesn't have the correct features, or better said it tries to solve another problem. Template haskell generates code into an existing module, while for this problem there is no module yet to generate it into. Of course I could generate those modules and let template haskell make the FFI imports, but then the problem remains how to generate those modules. So template haskell seems (as I see it) to solve the problem of writing almost the same code twice by generating it from some parameters coded in some source file. Another problem is that the export and import lists of the modules need to be generated too and this seems not an option for TH. On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote: For my case, template haskell can't create modules, and template haskell solves a different problem - I've not interested in creating Haskell declarations from Haskell declarations - I'm interested in creating Haskell modules from an external, formal, specification. In a sense I'm compiling to Haskell. This answer is for both the above quotes. While TH is not perfect (and sometimes tedious/difficult to write in), it's not restricted to simply generate code based on some parameters in an existing Haskell file. It cannot generate modules, true, but other than that you could have a module simply like this: module Foo where import … $(myBuilder) Where myBuilder doesn't take any parameters, just reads some external (XML, text file, whatever) and build the code from scratch. I might misunderstand the problem, but I think that you _could_ use TH for compiling to Haskell, as long as you have a Haskell parser for the external/formal spec. regards, iustin There are the haskell-src-exts-qq and haskell-src-meta packages on hackage that will get you partway to generating source code for a Haskell module. Full support for Haskell quasiquotation would require a modified version of haskell-src-exts (to properly handle antiquotation). The problem with TH is that it runs when the module is compiled. Reading a spec in from a file within a TH quote is possible, but it would be much nicer to be able to write a code generator, which a full Haskell quasiquoter would allow. Maybe someone is interested in a side-project? :) Geoff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I hadn't really considered using quasi quotation for the generating part, but reading some things about it it seems to be nice use. In absence of quasi quotation I've, just as Antoine Latter, made a library of several helper functions to make code generating easier. Thank you for bringing quasi quotation to my attention. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parallel Matrix Multiplication
Hello all I am trying to learn parallel Haskell and I have gone through couple of resources ( Real world Haskell and http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/AFP08-notes.pdf ). I understood par and pseq and I wrote matrix multiplication using these two function but it does not look. Although I did not get all these details but none of the sparks converted which is really important for parallel programming. Could some one please tell me how to improve this. Also kindly recommend me some literature for parallel programming in Haskell. Regards Mukesh Tiwari import Data.List import Control.Parallel parHelp :: ( Num a ) = [ a ] - [ a ] - a parHelp [] [] = 0 parHelp ( x : xs ) ( y : ys ) = ret where ret = par a ( pseq a ( a + parHelp xs ys ) ) where a = x * y helpMult :: ( Num a ) = [ a ] - [ [ a ] ] - [ a ] helpMult _ [] = [] helpMult x ( y : ys ) = ret where ret = par a ( pseq a ( a : helpMult x ys ) ) where a = parHelp x y mult :: ( Num a ) = [ [ a ] ] - [ [ a ] ] - [ [ a ] ] mult [] _ = [] mult ( x : xs ) ys = ret where ret = par a ( pseq a ( a : mult xs ys ) ) where a = helpMult x ys main = print $ mult [[1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4] ] ( transpose [[1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4] ]) [user@haskell Programming]$ ghc -O2 -threaded -rtsopts Matpar.hs [1 of 1] Compiling Main ( Matpar.hs, Matpar.o ) Linking Matpar ... [user@haskell Programming]$ ./Matpar +RTS -N2 -s ./Matpar +RTS -N2 -s [[10,20,30,40],[10,20,30,40],[10,20,30,40],[10,20,30,40]] 85,480 bytes allocated in the heap 5,216 bytes copied during GC 47,328 bytes maximum residency (1 sample(s)) 22,304 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 0 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed Parallel GC work balance: -nan (0 / 0, ideal 2) MUT time (elapsed) GC time (elapsed) Task 0 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 1 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 2 (bound) :0.00s( 0.00s) 0.00s( 0.00s) Task 3 (worker) :0.00s( 0.00s) 0.00s( 0.00s) * SPARKS: 84 (0 converted, 0 pruned)* INIT time0.00s ( 0.00s elapsed) MUT time0.00s ( 0.00s elapsed) GCtime0.00s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time0.00s ( 0.00s elapsed) %GC time 33.3% (13.5% elapsed) Alloc rate42,761,380 bytes per MUT second Productivity 33.3% of total user, 45.0% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync_large_objects: 0 gen[1].sync_large_objects: 0 [user@haskell Programming]$ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hexpat: Lazy I/O problem with huge input files
Hi Aleks, Did you (or anyone) ever resolve this? I'm having precisely the same problem. Eric Aleksandar Dimitrov wrote Hello Daniel, I don't know Hexpat at all, so I can only guess. Perhaps due to the laziness of let-bindings, mError keeps a reference to the entire tuple, thus preventing tree from being garbage collected as it is consumed by print. Thanks for your input. I think you are right, the parse tree isn't freed as the parse proceeds if mError is forced later on in the program (anywhere.) I don't think it has something to do with the tuple constructor or 'let' itself, but I'm also not very proficient at figuring these kinds of things out, so I may be very wrong. I did do the following test to support my hypothesis: import Text.XML.Expat.Tree import System.Environment (getArgs) import Control.Monad (liftM) import qualified Data.ByteString.Lazy as C · -- This is the recommended way to handle errors in lazy parses main = do f - liftM head getArgs = C.readFile let (_, mError) = parse defaultParseOptions f :: (UNode String, Maybe XMLParseError) case mError of Just err - putStrLn $ It failed : ++show err Nothing - putStrLn Success! I.e., keeping the parse tree is forced by the evaluation of mError. There is not a single reference to the parse tree within the program itself (unless I'm not noticing some sort of do-notation magic in the whole thing here...) It is interesting (and rather unfortunate) that just evaluating a potential error seems to block garbage collection. If I'm correct (and I hope I'm not!) this seems to prevent using lazy I/O in Hexpat if you want to know if there's a parse error (and if so, what that would be.) I'll contact the author, maybe it's a genuine bug? Thanks again :-) Aleks ___ Haskell-Cafe mailing list Haskell-Cafe@ http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Hexpat-Lazy-I-O-problem-with-huge-input-files-tp3211223p5064790.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Munich Haskell Meeting
Dear all, the doodle poll for the next Haskell get-together indicates, that we should meet on Tuesday, 13 Dec 2011, 19h30 at Cafe Puck: http://www.doodle.com/x6x4sgnemc35myq3 I will reserve tables. For all those who cannot join, sorry, but we hope to meet you next year. Check out the dates: http://www.haskell-munich.de/dates So, let's meet at Tuesday for the last time this year. Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
I'm happy to announce the release of xmobar 0.14. Xmobar is a text-based, minimalistic status bar for linuxy systems, written in Haskell. See http://projects.haskell.org/xmobar for details. Many, many thanks to the many, many contributors, and apologies for taking so long to put their code and fixes under a new release. In this episode: _New features_ - New brightness monitor, courtesy of Martin Perner. - New DateZone plugin, for configurable timezone and localized datetimes, also by Martin. - New keyboard layout monitor (Kbd). Yes, by Martin. - Rewrite of the event handling ([issue 53], [issue 57]), you guessed it. - Cpu monitor now also reports `iowait` field ([issue 55]). - Battery monitor: the full charge file is now settable in the monitor arguments (olpc systems use `charge_full_design`; see [issue 62]). _Bug fixes_ - [issue 45]: Fix for crashes with AC status changes in battery monitor. - [issue 48]: The quality field of Wireless behaves like a percentage. - [issue 50]/[issue 61]: `MPD` monitor now works with libmpd 0.6. - [issue 60]: Fixes for crashes on power resume for battery monitor. - Template sections without fields are now correctly displayed. - Catch errors when reading battery status (Ben Boeckel). - Compilation issues with ghc 7.x (Sergei Trofimovich). - Fixes for CoreTemp monitor in new kernels (Norbert Zeh). - Fix for pulseaudio problems in volume monitor (Martin Perner). - Fix for parsing errors when a `Run` entry ended in an array (Martin). - Fixed compilation in OpenBSD (Ivo van der Sangen). [issue 45]: http://code.google.com/p/xmobar/issues/detail?id=45 [issue 48]: http://code.google.com/p/xmobar/issues/detail?id=48 [issue 50]: http://code.google.com/p/xmobar/issues/detail?id=50 [issue 53]: http://code.google.com/p/xmobar/issues/detail?id=53 [issue 55]: http://code.google.com/p/xmobar/issues/detail?id=55 [issue 57]: http://code.google.com/p/xmobar/issues/detail?id=57 [issue 60]: http://code.google.com/p/xmobar/issues/detail?id=60 [issue 61]: http://code.google.com/p/xmobar/issues/detail?id=61 [issue 62]: http://code.google.com/p/xmobar/issues/detail?id=62 Cheers, jao ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel Matrix Multiplication
I changed it bit and use pseq to force the computation but still its non of the sparks are converting. import Data.List import Control.Parallel parHelp :: ( Num a ) = [ a ] - [ a ] - a parHelp [] [] = 0 parHelp ( x : xs ) ( y : ys ) = ret where ret = par a ( pseq b ( a + b ) ) where a = x * y b = parHelp xs ys helpMult :: ( Num a ) = [ a ] - [ [ a ] ] - [ a ] helpMult _ [] = [] helpMult x ( y : ys ) = ret where ret = par a ( pseq b ( a : b ) ) where a = parHelp x y b = helpMult x ys mult :: ( Num a ) = [ [ a ] ] - [ [ a ] ] - [ [ a ] ] mult [] _ = [] mult ( x : xs ) ys = ret where ret = par a ( pseq b ( a : b ) ) where a = helpMult x ys b = mult xs ys main = print $ mult [[1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4] ] ( transpose [[1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4 ] , [ 1 .. 4] ]) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
Hi Jose, I'm happy to announce the release of xmobar 0.14. previous versions of xmobar used to compile fine with GHC 6.10.4, but the new version no longer does: src/Parsers.hs:163:52: Couldn't match expected type `Char' against inferred type `[Char]' Expected type: GenParser Char st Char Inferred type: GenParser Char st String In the second argument of `($)', namely `wrapSkip $ string Run' In a stmt of a 'do' expression: notFollowedBy $ wrapSkip $ string Run The complete log is at http://hydra.nixos.org/build/1603134/nixlog/1/raw, just in case there happens to be an easy fix for that error. Thank you very much for your efforts! Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sat, Dec 10, 2011 at 18:25, Peter Simons sim...@cryp.to wrote: previous versions of xmobar used to compile fine with GHC 6.10.4, but the new version no longer does: src/Parsers.hs:163:52: Couldn't match expected type `Char' against inferred type `[Char]' Expected type: GenParser Char st Char Inferred type: GenParser Char st String In the second argument of `($)', namely `wrapSkip $ string Run' In a stmt of a 'do' expression: notFollowedBy $ wrapSkip $ string Run xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] web-routes-quasi: Generating a route type
Hi, web-routes-quasi is actually unmaintained. Yesod no longer uses it, instead using some internal code. If you'd like to use it, feel free. If you need to make any changes, you can feel free to release new versions of it as well. FWIW, I think you're looking for the createRoutes function. Michael 2011/12/9 Ertugrul Söylemez e...@ertes.de: Hello there, I'm trying to use the web-routes-quasi package outside of Yesod. Is there any documentation on how to use TH to generate a route type just like Yesod does? Or is that a Yesod-specific feature? I don't need the actual automatic dispatch or anything, just a type to work with. If it's not possible, I will just go ahead and (ab-) use the constructor strings. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Summers of Code retrospective (updated for 2011)
The Wheel turns, and months come and pass, leaving blog posts that fade into 404s; a wind rose in Mountain View, whispering of the coming Winter... Tonight I sat down and finally looked into the 2011 SoCs to see how they turned out and judge them according to my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-1 They turned out pretty much as I predicted - but then I *would* say that, wouldn't I? (Also submitted to /r/haskell for those who swing that way: http://www.reddit.com/r/haskell/comments/n82ln/summer_of_code_2011_retrospective/ ) -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Anansi 0.4.2 (literate programming pre-processor)
Anansi is a preprocessor for literate programs, in the model of NoWeb
or nuweb. Literate programming allows both computer code and
documentation to be generated from a single unified source.
Home page: https://john-millikin.com/software/anansi/
Hackage: http://hackage.haskell.org/package/anansi-0.4.2
-
This release has a couple cool new features, suggested by Dirk Laurie.
Markdown loom
===
Markdown, a lightweight markup language similar to ReStructuredText,
is used often on web forums. Use [[ :loom anansi.markdown ]] in your
documents to enable.
User-defined line pragmas
Users can now add, modify, and disable line pragmas in tangled output
based on file extension. This makes it much easier to combine code and
data in a single source file. By default, line pragmas are enabled for
the C, C++, C#, Haskell, Perl, and Go languages.
Customizing the pragma format is easy. Use the ${line}, ${path}, and
${quoted-path} substitutions in an :option. This example code will
insert comments into tangled Python code:
---
:# Insert comments into any tangled output file with a name ending in .py
:option anansi.line-pragma-py=# Generated from ${path} line ${line}
---
To disable line pragmas for a particular file type, just set its
pragma format to an empty string:
---
:option anansi.line-pragma-pl=
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HaXml 1.13 - 1.22 upgrade
I'm trying to migrate one my programs from the old HaXml API to the new. Please, someone save me. I'm currently stuck with this, which works in 1.13. All of the filters work on Content, so I make some from the root element with the root_elem = CElem root line. -- |Takes an XML String as an argument, and returns the -- status that was parsed from it. Should only be used -- on XML string where a status is a top-level element. parse_status :: String - [Status] parse_status xml_data = catMaybes maybe_status where (Document _ _ root _) = xmlParse xml_file_name xml_data root_elem = CElem root status_element = (single_status root_elem) maybe_status = map status_from_content status_element In the new API, xmlParse returns the root element with type (Element i) rather than just Element. And the Content constructor I have to use is (CElem (Element i) i), but I have no way to pass the correct 'i' to it. I just want to parse a few elements from an XML file. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaXml 1.13 - 1.22 upgrade
On Sun, Dec 11, 2011 at 12:08 AM, Michael Orlitzky mich...@orlitzky.com wrote: I'm trying to migrate one my programs from the old HaXml API to the new. Please, someone save me. I'm currently stuck with this, which works in 1.13. All of the filters work on Content, so I make some from the root element with the root_elem = CElem root line. -- |Takes an XML String as an argument, and returns the -- status that was parsed from it. Should only be used -- on XML string where a status is a top-level element. parse_status :: String - [Status] parse_status xml_data = catMaybes maybe_status where (Document _ _ root _) = xmlParse xml_file_name xml_data root_elem = CElem root status_element = (single_status root_elem) maybe_status = map status_from_content status_element In the new API, xmlParse returns the root element with type (Element i) rather than just Element. And the Content constructor I have to use is (CElem (Element i) i), but I have no way to pass the correct 'i' to it. It looks like the function 'xmlParse' returns a value of type 'Document Posn', according to the API docs. I'm guessing the 'Posn' value is used to annotate the position in the source document a particular piece of XML came from, so you can report errors better. Since the pretty-printing functions ignore it, you can replace it with whatever you want, even with a value of a different type if you have a need to annotate the tree. I just want to parse a few elements from an XML file. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCEMENT] xmobar 0.14
On Sun, Dec 11 2011, Brandon Allbery wrote: [...] xmobar currently requires parsec 3.x; the above is the symptom of building it against 2.x. Aha, thanks for pointing this out, guys. Peter, would using parsec 3.x be an acceptable solution to you? Cheers, jao -- Life isn't about finding yourself. Life is about creating yourself. -George Bernard Shaw, writer, Nobel laureate (1856-1950) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
