Re: [Haskell] Current XML libraries status

[Marc A. Ziegert]

there was a thread about xml parsing, one month ago.

well, i don't know much about xml, except what it looks like;
but i know about that interesting parsing problem behind it.
maybe Lev Walkin has fixed that in HXML. at least he wrote this patch...


- marc


-
sometimes i think, i should write a paper about it. but then... naah, i'm like 
haskell: non-strict.




Am Donnerstag, 23. Oktober 2008 schrieb Krasimir Angelov:
> Hi,
> 
> Does some one have made performance tests on the different XML libraries for
> Haskell? I have a 20MB xml file that I want to read. I remember from my
> earlier experiments (years ago) that all libraries were too slow and were
> consuming too much memory. I hoped that this situation had changed but maybe
> not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and
> is still very slow. libxml is unfinished binding to the C library. Currently
> it only allows to create documents. HXML seems to be very promising. It
> works fast and it doesn't eat memory. Unfortunately it is that it seems to
> be rather old. It uses its own Arrow and Tree libraries instead of the
> standard libraries. I have not jumped into HXT yet because it seems to be
> very large library. Could someone recomend which one is the state of the
> art?
> 
> Best Regards,
>   Krasimir
>


signature.asc
Description: This is a digitally signed message part.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: colour 0.0.0

[Sebastian Sylvan]

On Fri, Oct 24, 2008 at 8:12 PM, <[EMAIL PROTECTED]> wrote:

> On Fri, 24 Oct 2008, Sebastian Sylvan wrote:
>
>  It would be nice if we could customize the gamma curve. Different devices
>> have different gamma.
>> Some hardware even approximates the gamma curve with piecewise linear
>> functions. This can make a
>> massive difference if you, e.g. degamma the image assuiming a gamma of 2.2
>> (typical office LCD
>> screen), do some work on it, then convert to a gamma of 2.5 (typical TV -
>> they assume TVs will be
>> in a darker background setting), then the graphics card reads this as sRGB
>> with its own piecewise
>> linear approximation, then does some more work on it, and converts it
>> back. Long story short, if
>> you can't get all of those steps right the errors can add up quickly and
>> becomes very noticable.
>>
>
> That is a fair point.  I've only just started thinking about colour
> correction due to viewing environments.  I remembered that dealing with
> colour was difficult (which is why I'm writing this library), but I forgot
> exactly how difficult it was.
>
> I just finished user defined linear RGB spaces in my development version.
> Allowing user defined non-linear RGB spaces would be a reasonable addition.


Another useful predefined space which I didn't see is the YCoCg space, which
is used in lots of compression schemes (like H.264 IIRC).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: colour 0.0.0

[roconnor]

On Fri, 24 Oct 2008, Sebastian Sylvan wrote:


It would be nice if we could customize the gamma curve. Different devices have 
different gamma.
Some hardware even approximates the gamma curve with piecewise linear 
functions. This can make a
massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 
(typical office LCD
screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they 
assume TVs will be
in a darker background setting), then the graphics card reads this as sRGB with 
its own piecewise
linear approximation, then does some more work on it, and converts it back. 
Long story short, if
you can't get all of those steps right the errors can add up quickly and 
becomes very noticable.


That is a fair point.  I've only just started thinking about colour 
correction due to viewing environments.  I remembered that dealing with 
colour was difficult (which is why I'm writing this library), but I forgot 
exactly how difficult it was.


I just finished user defined linear RGB spaces in my development version. 
Allowing user defined non-linear RGB spaces would be a reasonable 
addition.



If it could read photoshop colour profiles that would be even better.


Perhaps ICC profiles would do?  Or are they the same thing?

--
Russell O'Connor  
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Current XML libraries status

[David F. Place]

I tried to use HXT's  readDocument with its  tagsoup option for my  
application.   I couldn't find a way to construct the operation that  
didn't run out of memory.   I'll attach some code using HaXml's  
saxParse so you can see what I want.   Is that easy to do in HXT? 
I simply want the text of  and  elements.




phase1.hs
Description: Binary data



Please feel free to bounce this to Haskell Cafe if you feel it is  
more appropriate.


On Oct 24, 2008, at 12:44 PM, Uwe Schmidt wrote:


What you can try with HXT is to use the readDocument arrow
with the option to use the tagsoup parser for parsing.
Then HXT really does lazy input.


_
David F. Place
[EMAIL PROTECTED]



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: colour 0.0.0

[Sebastian Sylvan]

On Wed, Oct 22, 2008 at 1:12 AM, <[EMAIL PROTECTED]> wrote:

> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0
>
> I hope for this library to become the standard colour library for Haskell.
> Most software does not properly blend colours because they fail to
> gamma-correct the colours before blending.  Hopefully by using this library,
> Haskell programs dealing with colour blending will avoid this problem.
>
> I am making an early release of my colour library to get some feedback. I
> am especially interested in getting feedback on the interfaces: should
> functions be renamed, should functions be moved, etc. Should I put black and
> white colours into Data.Colour?  Which is better form making a colour: (sRGB
> r g b) or (sRGB (r,g,b))?
>
> Bug reports and any patches are also welcome.  Be warned, I haven't
> extensively tested this library yet.
>

It would be nice if we could customize the gamma curve. Different devices
have different gamma. Some hardware even approximates the gamma curve with
piecewise linear functions. This can make a massive difference if you, e.g.
degamma the image assuiming a gamma of 2.2 (typical office LCD screen), do
some work on it, then convert to a gamma of 2.5 (typical TV - they assume
TVs will be in a darker background setting), then the graphics card reads
this as sRGB with its own piecewise linear approximation, then does some
more work on it, and converts it back. Long story short, if you can't get
all of those steps right the errors can add up quickly and becomes very
noticable.

If it could read photoshop colour profiles that would be even better.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Current XML libraries status

[Uwe Schmidt]

Hello Krasimir,

> Thanks to everyone who answered. HXML still seems to be the best for me. It
> is fast and it has good Arrow interface. It is also a small and simple
> library. I tried also HXT with this example:
>
> http://www.haskell.org/haskellwiki/HXT#Getting_started:_Hello_world_example
>s
>
> but it just died with out of memory. HXML just works. I have not tried the
> Light XML library because it doesn't provide Arrow interface.

What you can try with HXT is to use the readDocument arrow
with the option to use the tagsoup parser for parsing.
Then HXT really does lazy input. And there is a memory optimization
for sharing the strings representing element and attribute names.
But there is no DTD processing and no validating functionality with tagsoup. 
Most efficient input encoding is ISO Latin1 (or ASCII).

Cheers

  Uwe

-- 

Uwe Schmidt
Web: http://www.fh-wedel.de/~si/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: Current XML libraries status

[Krasimir Angelov]

Thanks to everyone who answered. HXML still seems to be the best for me. It
is fast and it has good Arrow interface. It is also a small and simple
library. I tried also HXT with this example:

http://www.haskell.org/haskellwiki/HXT#Getting_started:_Hello_world_examples

but it just died with out of memory. HXML just works. I have not tried the
Light XML library because it doesn't provide Arrow interface.

I updated HXML to use more stuff from the standard libraries. Now I can use
the syntax sugar for arrows with it. Is the library maintained? Should I
send a patch to someone?

Best Regards,
  Krasimir



On Thu, Oct 23, 2008 at 10:26 PM, Krasimir Angelov <[EMAIL PROTECTED]>wrote:

> Hi,
>
> Does some one have made performance tests on the different XML libraries
> for Haskell? I have a 20MB xml file that I want to read. I remember from my
> earlier experiments (years ago) that all libraries were too slow and were
> consuming too much memory. I hoped that this situation had changed but maybe
> not. I looked at HaXML, libxml, HXML and HXT. HaXML eats a lot of memory and
> is still very slow. libxml is unfinished binding to the C library. Currently
> it only allows to create documents. HXML seems to be very promising. It
> works fast and it doesn't eat memory. Unfortunately it is that it seems to
> be rather old. It uses its own Arrow and Tree libraries instead of the
> standard libraries. I have not jumped into HXT yet because it seems to be
> very large library. Could someone recomend which one is the state of the
> art?
>
> Best Regards,
>   Krasimir
>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: lhs2tex-1.14

[Andres Loeh]

 lhs2TeX version 1.14
 

We are pleased to announce a new release of lhs2TeX, 
a preprocessor to generate LaTeX code from literate Haskell
sources.

lhs2TeX includes the following features:

* Highly customized output.

* Liberal parser -- no restriction to Haskell 98.

* Generate multiple versions of a program or document from 
  a single source.

* Active documents: call Haskell to generate parts of the 
  document (useful for papers on Haskell).

* A manual explaining all the important aspects of lhs2TeX.

Changes (w.r.t. lhs2TeX 1.13)
-

* Compatible with cabal-1.6; traditional configure/make
  installation should still work.

* Unicode support.

* Support for Agda's lexing rules (via --agda flag).

* Minor bugfixes.

Requirements and Download
-

A source distribution is available from

  http://people.cs.uu.nl/andres/lhs2tex/

and, of course, via Hackage:

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lhs2tex

Should work on all major platforms, but has mainly been
tested on Linux. Binaries will be made available on request.

You need a recent version of GHC (6.8.{2,3} are tested, older versions
might work) to build lhs2TeX, and, of course, you need a TeX
distribution to make use of lhs2TeX's output. The program includes
a configuration that is suitable for use with LaTeX. In theory, 
there should be no problem to generate code for other TeX 
flavors, such as plainTeX or ConTeXt.


  Happy lhs2TeXing,
  Andres Loeh and Ralf Hinze

-- 

Andres Loeh, Universiteit Utrecht

mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.andres-loeh.de
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Current XML libraries status

[Ketil Malde]

"Krasimir Angelov" <[EMAIL PROTECTED]> writes:

> Does some one have made performance tests on the different XML libraries for
> Haskell? I have a 20MB xml file that I want to read. I remember from my 
> earlier
> experiments (years ago) that all libraries were too slow and were consuming 
> too
> much memory.

For my XML needs, I ended up just using the TagSoup library to
extract the parts I wanted.  At least this allows lazy processing of
large files (a typical file is in the 1 to 4 GB range).

Performance is acceptable, and Neil is rumored to have a plan to
improve it further.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell