Johannes Waldmann writes:
> Andy Stewart gmail.com> writes:
>
>> Just "cabal install" is enough.
>
> Hm. That's what bootstrap.sh does,
> and it builds tools, then glib, but then:
>
> Preprocessing library gio-0.11.0...
> gtk2hsC2hs: Errors during expansion of binding hooks:
>
> ./System/GIO/Ty
On Aug 14, 2:41 am, Brandon S Allbery KF8NH
wrote:
> Efficient for what? The most efficient Unicode representation for
> Latin-derived strings is UTF-8, but the most efficient for CJK is UTF-16.
I think that this kind of programming detail should be handled
internally (even if necessary by swit
On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez wrote:
> Conal Elliott wrote:
>
> > > There are various models. One (the state monad model) of them would
> > > desugar this to:
> > >
> > > \world0 ->
> > > let (x, world1) = getLine world0
> > > world2 = print (x+1) world1
> > >
Hi Bill,
Each quote of the input is on a single line. I want to unwrap lines greater
than 72 characters, i.e., break them into several lines each <= 72 characters,
but I don't want to break up words. and I want to retain the blank lines. So,
my output is correct except for the error message.
M
Hello michael,
Saturday, August 14, 2010, 5:38:46 AM, you wrote:
> The program below takes a text file and unwraps all lines to 72
> columns, but I'm getting an end of file message at the top of my output.
> How do I lose the EOF?
use isEOF function. even better, use interact
--
Best regards
Not sure if I understood what you're trying to do, but development will be
easier if you minimize your IO, e.g. :
maxLineLength :: Int
maxLineLength = 72
wrapLine :: String -> [String]
wrapLine "" = []
wrapLine line
| length line <= maxLineLength= [line]
| otherwise
The program below takes a text file and unwraps all lines to 72 columns, but
I'm getting an end of file message at the top of my output.
How do I lose the EOF?
Michael
== unwrap.hs ==
main = do
line <- getLine
if null line
then do
putStrLn ""
So it's a bug in the garbage collector. It's closing a handle that
clearly is still reachable, otherwise this would not have happened.
On Fri, Aug 13, 2010 at 10:53 AM, Simon Marlow wrote:
> On 12/08/2010 21:59, Yitzchak Gale wrote:
>>
>> Wei Hu wrote:
>>>
>>> nonTermination _ = blackhole where
On Fri, Aug 13, 2010 at 10:01 PM, Dan Doel wrote:
> On Friday 13 August 2010 8:51:46 pm Evan Laforge wrote:
>> I have an app that is using Data.Text, however I'm thinking of
>> switching to UTF8 bytestrings. The reasons are that there are two
>> main things I do with text: pass it to a C API to d
On Friday 13 August 2010 8:51:46 pm Evan Laforge wrote:
> I have an app that is using Data.Text, however I'm thinking of
> switching to UTF8 bytestrings. The reasons are that there are two
> main things I do with text: pass it to a C API to display, and parse
> it. The C API expects UTF8, and the
On Fri, Aug 13, 2010 at 6:41 PM, Brandon S Allbery KF8NH
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 8/13/10 16:37 , Kevin Jardine wrote:
>> Surely efficient Unicode text should always be the default? And if the
>
> Efficient for what? The most efficient Unicode representation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/13/10 16:37 , Kevin Jardine wrote:
> Surely efficient Unicode text should always be the default? And if the
Efficient for what? The most efficient Unicode representation for
Latin-derived strings is UTF-8, but the most efficient for CJK is UTF-1
Conal Elliott wrote:
> > There are various models. One (the state monad model) of them would
> > desugar this to:
> >
> > \world0 ->
> > let (x, world1) = getLine world0
> > world2 = print (x+1) world1
> > world3 = print (x+2) world2
> > in world3
>
> Hi Ertugrul,
>
> This state mon
Jason Dagit writes:
> On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic <
>>
>> So, the real issue here is that there is not yet a good abstraction over
>> what we consider to be textual data, and instead people have to code to
>> a specific data type.
>>
>
> Isn't this the same problem we h
On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer wrote:
>
> That's an unfortunate example. Using the stringsearch package, substring
> searching in ByteStrings was considerably faster than in Data.Text in my
> tests.
>
Daniel, thanks again for bringing up this example! It turned out that quite
a l
On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:
> Kevin Jardine writes:
>
> > Hi Don,
> >
> > With respect, I disagree with that approach.
> >
> > Almost every modern programming language has one or at most two
> > standard representations for strings.
>
Johannes Waldmann writes:
> How is the "cabal" magic that would run hscolour?
>
> I am using "cabal haddock --executables --hyperlink-source"
> and this generates the API docs for all modules,
> and all have source links, but the actual html-ized source
> is only generated for the main module,
"Henk-Jan van Tuyl" writes:
> L.S.,
>
> When I try
> putStrLn "ß"
> (Eszett (sharp S)) in WinGhci, the interpreter seems to have
> disappeared; ctrl-C gives the message "Interrupted" in a separate
> window, but no new prompt.
That's weird; possibly an encoding problem>
> When I start GHCi in
Kevin Jardine writes:
> Hi Don,
>
> With respect, I disagree with that approach.
>
> Almost every modern programming language has one or at most two
> standard representations for strings.
Almost every modern programming language thinks you can whack a print
statement wherever you like... ;-)
>
Thanks so very much Axel and Ivan.
You were both absolutely correct and I can compile Glade apps now fine.
Great help!
The tricky part (for me) would have been looking at the error from
cabal install glade:
"setup.exe: The pkg-config package libglade-2.0 version >=2.0.0
is required but it co
Ketil Malde wrote:
> Haskell does have a standard representation for strings, namely [Char].
> Unfortunately, this sacrifices efficiency for elegance, which gives rise
> to the plethora of libraries.
To have the default standard representation be one that works
so poorly for many common everyday
Kevin Jardine wrote:
> With respect, I disagree with that approach.
>
> Almost every modern programming language has one or at most two
> standard representations for strings.
I think having two makes sense, one for arrays of arbitrary
binary bytes and one for some unicode data format, preferabl
Pierre-Etienne Meunier wrote:
> Hi,
>
> Why don't you use the Data.Rope library ?
> The asymptotic complexities are way better than those of the
> ByteString functions.
What I see as my current problem is that there is already
a problem having two things Sting and ByteString which
represent stri
L.S.,
When I try
putStrLn "ß"
(Eszett (sharp S)) in WinGhci, the interpreter seems to have disappeared;
ctrl-C gives the message "Interrupted" in a separate window, but no new
prompt. When I start GHCi in a shell, the interpreter displays:
Prelude> print "ß"
"\223"
Is this a known is
Hello,
In my company (and I believe many, many companies) they use MOF
heavily: http://en.wikipedia.org/wiki/Meta-Object_Facility MOF seems to be
tightly coupled with object oriented program and has nothing to do with
functional language approach??
Regards,
Vasili
_
Kevin Jardine writes:
> Almost every modern programming language has one or at most two
> standard representations for strings.
> That includes PHP, Python, Ruby, Perl and many others. The lack of a
> standard text representation in Haskell has created a crazy patchwork
> of incompatible librari
Hi Don,
With respect, I disagree with that approach.
Almost every modern programming language has one or at most two
standard representations for strings.
That includes PHP, Python, Ruby, Perl and many others. The lack of a
standard text representation in Haskell has created a crazy patchwork
of
Excerpts from Kevin Jardine's message of Fri Aug 13 16:37:14 -0400 2010:
> I find it disturbing that a modern programming language like Haskell
> still apparently forces you to choose between a representation for
> "mostly ASCII text" and Unicode.
>
> Surely efficient Unicode text should always be
There are many libraries for many purposes.
How to pick your string library in Haskell
http://blog.ezyang.com/2010/08/strings-in-haskell/
kevinjardine:
> I find it disturbing that a modern programming language like Haskell
> still apparently forces you to choose between a representation f
I find it disturbing that a modern programming language like Haskell
still apparently forces you to choose between a representation for
"mostly ASCII text" and Unicode.
Surely efficient Unicode text should always be the default? And if the
Unicode format used by the Text library is not efficient e
Johan Tibell writes:
> Here's a rule of thumb: If you have binary data, use Data.ByteString. If you
> have text, use Data.Text.
If you have a large amount of mostly ASCII text, use ByteString, since
Data.Text uses twice the storage. Also, ByteString might make more
sense if the data is in a byt
On Friday 13 August 2010 21:32:12, Kevin Jardine wrote:
> Surely a lot of real world text processing programs are IO intensive?
> So if there is no native Text IO and everything needs to be read in /
> written out as ByteString data converted to/from Text this strikes me
> as a major performance si
Surely a lot of real world text processing programs are IO intensive?
So if there is no native Text IO and everything needs to be read in /
written out as ByteString data converted to/from Text this strikes me
as a major performance sink.
Or is there native Text IO but just not in your example?
K
On Friday 13 August 2010 19:53:37 you wrote:
> On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer
wrote:
> > That's an unfortunate example. Using the stringsearch package,
> > substring searching in ByteStrings was considerably faster than in
> > Data.Text in my tests.
>
> Interesting. Got a test cas
Andy Stewart gmail.com> writes:
> Just "cabal install" is enough.
Hm. That's what bootstrap.sh does,
and it builds tools, then glib, but then:
Preprocessing library gio-0.11.0...
gtk2hsC2hs: Errors during expansion of binding hooks:
./System/GIO/Types.chs:584: (column 12) [ERROR]
>>> Unkno
On Friday 13 August 2010 19:53:37, Bryan O'Sullivan wrote:
> On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer
wrote:
> > That's an unfortunate example. Using the stringsearch package,
> > substring searching in ByteStrings was considerably faster than in
> > Data.Text in my tests.
>
> Interesting.
Johannes Waldmann writes:
> I'm trying to build gtk2hs on debian/lenny,
> that is, with gtk2 v. 2.12 if I understand this correctly.
>
> I got the gtk2hs sources from darcs (I guess it's 0.11.0)
> and http://www.haskell.org/gtk2hs/ says
> "You need to specify -f-gtk_2_20 for Gtk+ 2.18 etc."
> I w
I'm trying to build gtk2hs on debian/lenny,
that is, with gtk2 v. 2.12 if I understand this correctly.
I got the gtk2hs sources from darcs (I guess it's 0.11.0)
and http://www.haskell.org/gtk2hs/ says
"You need to specify -f-gtk_2_20 for Gtk+ 2.18 etc."
I would love to, but where exactly? (When bo
This back and forth on performance is great!
I often see ByteString used where Text is theoretically more
appropriate (eg. the Snap web framework) and it would be good to get
these performance issues ironed out so people feel more comfortable
using the right tool for the job based upon API rather
On Fri, Aug 13, 2010 at 4:53 AM, Simon Marlow wrote:
> Ah yes, that works too. But other similar versions don't, like this one:
>
> process :: String -> String
> process _ = let x = x in x
>
> Hence why I added the "tail" in my version.
Without "-O", this version doesn't work, but with "-O" it
On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer wrote:
>
> That's an unfortunate example. Using the stringsearch package, substring
> searching in ByteStrings was considerably faster than in Data.Text in my
> tests.
>
Interesting. Got a test case so I can repro and fix? :-)
__
On Friday 13 August 2010 17:57:36, Bryan O'Sullivan wrote:
>3. Some commonly used functions, such as substring searching, are
> *way*faster than their ByteString counterparts.
That's an unfortunate example. Using the stringsearch package, substring
searching in ByteStrings was considerably fa
2010/8/13 Bryan O'Sullivan
> 2010/8/13 Gábor Lehel
>
> How about the case for text which is guaranteed to be in ascii/latin1?
>> ByteString again?
>>
>
> If you know it's text and not binary data you are working with, you should
> still use Data.Text. There are a few good reasons.
>
>1. The
Simon Marlow wrote:
So what happens is this:
- the recursive definition causes the main thread to block on itself
(known as a "black hole")
- the program is deadlocked (no threads to run), so the runtime
invokes the GC to see if any threads are unreachable
- the GC finds that
(a) t
Quoth Sean Leather ,
> Which one do you use for strings in HTML or XML in which UTF-8 has become
> the commonly accepted standard encoding? It's text, not binary, so I should
> choose Data.Text. But isn't there a performance penalty for translating from
> Data.Text's internal 16-bit encoding to UT
2010/8/13 Gábor Lehel
> How about the case for text which is guaranteed to be in ascii/latin1?
> ByteString again?
>
If you know it's text and not binary data you are working with, you should
still use Data.Text. There are a few good reasons.
1. The API is more correct. For instance, if you
On Friday 13 August 2010 17:27:32, Sean Leather wrote:
> Which one do you use for strings in HTML or XML in which UTF-8 has
> become the commonly accepted standard encoding? It's text, not binary,
> so I should choose Data.Text. But isn't there a performance penalty for
> translating from Data.Text
On Friday 13 August 2010 17:25:58, Gábor Lehel wrote:
> How about the case for text which is guaranteed to be in ascii/latin1?
> ByteString again?
If you can be sure that that won't change anytime soon, definitely.
Bonus points if you can write the code so that later changing to e.g.
Data.Text re
Johan Tibell wrote:
> Here's a rule of thumb: If you have binary data, use Data.ByteString. If
> you have text, use Data.Text. Those libraries have benchmarks and have been
> well tuned by experienced Haskelleres and should be the fastest and most
> memory compact in most cases. There are still a
On Fri, Aug 13, 2010 at 4:43 PM, Johan Tibell wrote:
> On Fri, Aug 13, 2010 at 4:24 PM, Kevin Jardine
> wrote:
>>
>> I'm interested to see this kind of open debate on performance,
>> especially about libraries that provide widely used data structures
>> such as strings.
>>
>> One of the more puzz
How is the "cabal" magic that would run hscolour?
I am using "cabal haddock --executables --hyperlink-source"
and this generates the API docs for all modules,
and all have source links, but the actual html-ized source
is only generated for the main module, and missing for all others.
Thanks - J
On Fri, Aug 13, 2010 at 4:24 PM, Kevin Jardine wrote:
> I'm interested to see this kind of open debate on performance,
> especially about libraries that provide widely used data structures
> such as strings.
>
> One of the more puzzling aspects of Haskell for newbies is the large
> number of libra
On Fri, 13 Aug 2010 12:29:52 +0200, Bulat Ziganshin
wrote:
Hello Henk-Jan,
Friday, August 13, 2010, 2:23:58 PM, you wrote:
You can do this with the flag -optl-mwindows; this passes the flag
-mwindows to the linker. Because this is a linker option, you cannot
find
it in the GHC documentat
Hi all,
I'm trying to go through the paper Beautiful Differentiation by Conal
Elliott and got a bit stuck. So I decided to download the VectorSpace
package, which as far as I know implements the paper, and just try and play
around with it. Unfortunately when I tried the simple examples at the
be
I'm interested to see this kind of open debate on performance,
especially about libraries that provide widely used data structures
such as strings.
One of the more puzzling aspects of Haskell for newbies is the large
number of libraries that appear to provide similar/duplicate
functionality.
The
On Fri, Aug 13, 2010 at 4:03 PM, Pierre-Etienne Meunier <
pierreetienne.meun...@gmail.com> wrote:
> Hi,
>
> Why don't you use the Data.Rope library ?
> The asymptotic complexities are way better than those of the ByteString
> functions.
>
> PE
>
For some operations. I'd expect it to be a constant
Hi,
Why don't you use the Data.Rope library ?
The asymptotic complexities are way better than those of the ByteString
functions.
PE
El 13/08/2010, a las 07:32, Erik de Castro Lopo escribió:
> Hi all,
>
> I'm using Tagsoup to strip data out of some rather large XML files.
>
> Since the files
Stephen Tetley wrote:
> Possibly you need to supply extra-include-dirs (and extra-lib-dirs) to cabal.
I tried --extra-include-dirs=/usr/include (the directory where the real
Block.h resides) and there was no change. Adding the -v flag showed
cabal trying to build with this line:
/usr/bin/ghc -I
I would like to announce a small library hswip. It is an analogue of pyswip
[1] python library in haskell.
Hswip allows to embed swi-prolog [2] interpreter into your haskell
applications in a convenient way.
Let't look at an example:
main = do
prologInit ["-q","-nosignals"]
prolog
On Fri, Aug 13, 2010 at 1:47 PM, Michael Snoyman wrote:
> Use qualified imports, like so:
>>
>> import qualified Data.ByteString as B
>>
>
> main = B.putStrLn $ B.pack "test"
>>
>> If you want to pack a String into a ByteString, you'll need to import
> Data.ByteString.Char8 instead.
>
>
Very true.
On Fri, Aug 13, 2010 at 2:42 PM, Johan Tibell wrote:
> Hi Erik,
>
>
> On Fri, Aug 13, 2010 at 1:32 PM, Erik de Castro Lopo
>
> > wrote:
>
>> Since the files are large I'm using ByteString, but that leads me
>> to wonder what is the best way to handle clashes between Prelude
>> functions like put
Hi Erik,
On Fri, Aug 13, 2010 at 1:32 PM, Erik de Castro Lopo
> wrote:
> Since the files are large I'm using ByteString, but that leads me
> to wonder what is the best way to handle clashes between Prelude
> functions like putStrLn and the ByteString versions?
>
> Anyone have any suggestions for
Just import the ByteString module qualified. In other words:
import qualified Data.ByteString as S
or for lazy bytestrings:
import qualified Data.ByteString.Lazy as L
Cheers,
Michael
On Fri, Aug 13, 2010 at 2:32 PM, Erik de Castro Lopo
> wrote:
> Hi all,
>
> I'm using Tagsoup to strip data o
Hi all,
I'm using Tagsoup to strip data out of some rather large XML files.
Since the files are large I'm using ByteString, but that leads me
to wonder what is the best way to handle clashes between Prelude
functions like putStrLn and the ByteString versions?
Anyone have any suggestions for doin
Hello Henk-Jan,
Friday, August 13, 2010, 2:23:58 PM, you wrote:
> You can do this with the flag -optl-mwindows; this passes the flag
> -mwindows to the linker. Because this is a linker option, you cannot find
> it in the GHC documentation. This solution also works for other GUIs, like
> wxHaskell
On Fri, 13 Aug 2010 10:18:22 +0200, Eitan Goldshtrom
wrote:
Hi. I'm working in Windows on an OpenGL application. I finally got
everything working, doing all of my testing through the interpreter.
When I finally compiled and ran the program from an executable for the
first time I noticed that
On 13/08/2010 09:53, Simon Marlow wrote:
On 12/08/2010 21:59, Yitzchak Gale wrote:
Wei Hu wrote:
nonTermination _ = blackhole where blackhole = blackhole
My original example was actually:
process :: String -> String
process = let x = x in x
Ah yes, that works too. But other similar version
On 12/08/2010 21:59, Yitzchak Gale wrote:
Wei Hu wrote:
nonTermination _ = blackhole where blackhole = blackhole
My original example was actually:
process :: String -> String
process = let x = x in x
Ah yes, that works too. But other similar versions don't, like this one:
process :: Stri
Hello,
It's my first time using this mailing list thing so forgive me if I made any
mistakes. I was using Twidge (http://wiki.github.com/jgoerzen/twidge/) and
it's mentioned there is an available support in the Haskell Cafe. I only
have a slight problem with Twidge. It's currently not shortening U
I vaguely recall that there is a way to avoid this if you don't import
any terminal functions or something similar. I don't remember the
specifics though.
Sorry I couldn't be of more help!
On Fri, Aug 13, 2010 at 4:18 PM, Eitan Goldshtrom
wrote:
> Hi. I'm working in Windows on an OpenGL applic
Hi. I'm working in Windows on an OpenGL application. I finally got
everything working, doing all of my testing through the interpreter.
When I finally compiled and ran the program from an executable for the
first time I noticed that before creating my OpenGL window an empty DOS
prompt popped up
Dan Doel wrote:
On Thursday 12 August 2010 7:59:09 pm wren ng thornton wrote:
Not quite. Strong-sigma is a dependent pair where you can project both
elements. Weak-sigma is a dependent pair where you can only project the
first element (because the second is erased). Existentials are dependent
pa
>
> There are various models. One (the state monad model) of them would
> desugar this to:
>
> \world0 ->
> let (x, world1) = getLine world0
> world2 = print (x+1) world1
> world3 = print (x+2) world2
> in world3
>
Hi Ertugrul,
This state monad model does not really work for IO, sin
Woops, nevermind. I WAS looking in the wrong place. I should've known
=P. Sorry for the unnecessary request.
-Eitan
PS.
For anyone interested all of the documentation is in
Graphics.Rendering.OpenGL.GL.PerFragment on hackage
___
Haskell-Cafe mailing
74 matches
Mail list logo
