Hi Immanuel,
Are you using Windows or Linux or OSX?
Under Windows, I was able to install it (no need to compile, since the
libraries are bundled).
I could also run some examples from the SOE book, however IMO the GLFW
Haskell wrapper seems to contain some bugs (at least on Windows) that
That helped, thanks!
On 10/2/07, jeeva suresh [EMAIL PROTECTED] wrote:
I had a similar problem, I solved it by using the development version of
hs-plugins (ie. darcs get --set-scripts-executable
http://www.cse.unsw.edu.au/~dons/code/hs-plugins)
On 02/10/2007, Brandon S. Allbery KF8NH
Deborah Goldsmith wrote:
UTF-16 is the native encoding used for Cocoa, Java, ICU, and Carbon, and
is what appears in the APIs for all of them. UTF-16 is also what's
stored in the volume catalog on Mac disks. UTF-8 is only used in BSD
APIs for backward compatibility. It's also used in plain
Hallo,
For fun and learning I'm trying to parse R5RS Scheme with Parsec.
The code to parse lists follows:
--
-- Lists
--
parseLeftList :: Parser [SchDatum]
parseLeftList = do
char '('
many parseDatum = return . filter (/= SchAtmosphere)
parseDottedList :: [SchDatum] - Parser SchDatum
On Oct 2, 2007, at 9:52 , Alex Queiroz wrote:
(parseDottedList ls) | (parseProperList ls)
I've factored out the common left sub-expression in
parseLeftList. The problem is that ... is a valid identifier so when
inside the left of the list the parser sees a single dot, it tries to
match
Hallo,
On 10/2/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
On Oct 2, 2007, at 9:52 , Alex Queiroz wrote:
(parseDottedList ls) | (parseProperList ls)
I've factored out the common left sub-expression in
parseLeftList. The problem is that ... is a valid identifier so when
On Oct 2, 2007, at 10:36 , Alex Queiroz wrote:
This does not work. The parser chokes in parseLeftList, because
it finds a single dot which is not the beginning of
Sorry, just woke up and still not quite tracking right, so I modified
the wrong snippet of code. The trick is to
Hallo,
On 10/2/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
Sorry, just woke up and still not quite tracking right, so I modified
the wrong snippet of code. The trick is to wrap parseLeftList in a
try, so the parser retries the next alternative when it fails.
Since ... can
On Oct 2, 2007, at 5:11 AM, ChrisK wrote:
Deborah Goldsmith wrote:
UTF-16 is the native encoding used for Cocoa, Java, ICU, and
Carbon, and
is what appears in the APIs for all of them. UTF-16 is also what's
stored in the volume catalog on Mac disks. UTF-8 is only used in BSD
APIs for
It seems like the GLFW C binaries wasn't included in your GLFW Haskell
module installed. Did you do the last step by running install.bat or
install.sh instead of runhaskell Setup install?
Regards,
Paul Liu
On 10/2/07, Immanuel Normann [EMAIL PROTECTED] wrote:
Hello,
I have just read the
On Tue, 2007-10-02 at 08:02 -0700, Deborah Goldsmith wrote:
On Oct 2, 2007, at 5:11 AM, ChrisK wrote:
Deborah Goldsmith wrote:
UTF-16 is the native encoding used for Cocoa, Java, ICU, and
Carbon, and
is what appears in the APIs for all of them. UTF-16 is also what's
stored in the
How can I get C-c C-l to first run cpp on a .hsc file and then load
the .hs file?
I checked out the network package from darcs and then did:
Start ghci, C-c C-z, then:
Prelude :set -cpp
And then pressed load, C-c C-l:
Prelude :load
I would like to, again, strongly argue against sacrificing
compatibility
with Linux/BSD/etc. for the sake of compatibility with OS X or
Windows.
Ehm? I've used to think MacOS is a sort of BSD...
___
Haskell-Cafe mailing list
I don't know if this applies to Scheme parsing, but I find it's often
helpful to introduce a tokenizer into the parser to centralize the use
of try to one place::
type Token = String
tokRaw :: Parser Token
tokRaw = {- implement this yourself depending on language spec -}
tok :: Parser Token
tok
On Tue, 2007-10-02 at 22:05 +0400, Miguel Mitrofanov wrote:
I would like to, again, strongly argue against sacrificing
compatibility
with Linux/BSD/etc. for the sake of compatibility with OS X or
Windows.
Ehm? I've used to think MacOS is a sort of BSD...
Cocoa, then.
jcc
On Tue, Oct 02, 2007 at 08:02:30AM -0700, Deborah Goldsmith wrote:
UTF-16 is the type used in all the APIs. Everything else is considered an
encoding conversion.
CoreFoundation uses UTF-16 internally except when the string fits entirely
in a single-byte legacy encoding like MacRoman or
On Tue, Oct 02, 2007 at 11:36:52AM -0300, Alex Queiroz wrote:
Hallo,
On 10/2/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
On Oct 2, 2007, at 9:52 , Alex Queiroz wrote:
(parseDottedList ls) | (parseProperList ls)
I've factored out the common left sub-expression in
I do not believe that anyone was seriously advocating multiple blessed
encodings. The main question is *which* encoding to bless. 99+% of
text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16
better for me?
All software I write professional have to support 40 languages
Am Dienstag, den 02.10.2007, 23:18 +0800 schrieb Paul L:
It seems like the GLFW C binaries wasn't included in your GLFW Haskell
module installed. Did you do the last step by running install.bat or
install.sh instead of runhaskell Setup install?
now it works! ... although I am unfortunately not
On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote:
I do not believe that anyone was seriously advocating multiple blessed
encodings. The main question is *which* encoding to bless. 99+% of
text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16
better for me?
On Oct 2, 2007, at 8:44 AM, Jonathan Cast wrote:
I would like to, again, strongly argue against sacrificing
compatibility
with Linux/BSD/etc. for the sake of compatibility with OS X or
Windows.
FFI bindings have to convert data formats in any case; Haskell
shouldn't
gratuitously break Linux
On Oct 2, 2007, at 3:01 PM, Twan van Laarhoven wrote:
Lots of people wrote:
I want a UTF-8 bikeshed!
No, I want a UTF-16 bikeshed!
What the heck does it matter what encoding the library uses
internally? I expect the interface to be something like (from my own
CompactString library):
Lots of people wrote:
I want a UTF-8 bikeshed!
No, I want a UTF-16 bikeshed!
What the heck does it matter what encoding the library uses internally?
I expect the interface to be something like (from my own CompactString
library):
fromByteString :: Encoding - ByteString - UnicodeString
hoping someone here can help me with a build problem
when going through the hackage build stage, i get numerous errors
like:
HSCurses/Curses.hs::0: invalid preprocessing directive #def
where ranges in lines from 1597 to 1621.
is there a special directive i need for runhaskell? any
i am getting some weird memory usage out of this program:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let sum' = foldl' (+) 0
let list::[Int] = decode $ encode $ ([1..] :: [Int])
print $ sum' list
print done
it goes up to 500M and down to 17M on
On Wed, 2007-10-03 at 00:01 +0200, Twan van Laarhoven wrote:
Lots of people wrote:
I want a UTF-8 bikeshed!
No, I want a UTF-16 bikeshed!
What the heck does it matter what encoding the library uses internally?
+1
jcc
___
Haskell-Cafe
Does it terminate?
Looks like you are summing all the natural numbers. On a turing
machine it should run forever, on a real computer it should run out
of memory. Unless I am missing something obvious :-)
___
Haskell-Cafe mailing list
On Wed, Oct 03, 2007 at 01:22:25AM +0200, Roel van Dijk wrote:
Does it terminate?
Looks like you are summing all the natural numbers. On a turing
machine it should run forever, on a real computer it should run out
of memory. Unless I am missing something obvious :-)
There are only about 4
On Tue, Oct 02, 2007 at 04:08:01PM -0700, Anatoly Yakovenko wrote:
i am getting some weird memory usage out of this program:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let sum' = foldl' (+) 0
let list::[Int] = decode $ encode $ ([1..] :: [Int])
Program1:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let sum' = foldl' (+) 0
let list::[Int] = decode $ encode $ ([1..] :: [Int])
print $ sum' list
print done
vs
Program2:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let
aeyakovenko:
Program1:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let sum' = foldl' (+) 0
let list::[Int] = decode $ encode $ ([1..] :: [Int])
print $ sum' list
print done
vs
Program2:
module Main where
import Data.Binary
import
Maybe what you are observing is that the operational semantics of
undefined is undefined. The program can halt, run forever, use no
memory, use all the memory.
Although I doubt what GHC does with this code is a random process, I
don't think it's too meaningful to ask what are the space usage
On 10/2/07, Don Stewart [EMAIL PROTECTED] wrote:
aeyakovenko:
Program1:
module Main where
import Data.Binary
import Data.List(foldl')
main = do
let sum' = foldl' (+) 0
let list::[Int] = decode $ encode $ ([1..] :: [Int])
print $ sum' list
print done
The encode
servers never terminate, pretend that i have a server that reads a
list encoded with data.binary from a socket, and sums it up and
returns the current sum. i would expect it to run in constant memory,
never terminate, and do useful work.
which is basically the problem that I am facing right now.
On 10/2/07, Don Stewart [EMAIL PROTECTED] wrote:
The encode instance for lists is fairly strict:
instance Binary a = Binary [a] where
put l = put (length l) mapM_ put l
get= do n - get :: Get Int
replicateM n get
This is ok, since typically you
aeyakovenko:
servers never terminate, pretend that i have a server that reads a
list encoded with data.binary from a socket, and sums it up and
returns the current sum. i would expect it to run in constant memory,
never terminate, and do useful work.
which is basically the problem that I
f x = x + x
Is the x use to create a pattern in the definition and when f is
called it's replaced by a value?
Those equation-like definitions are syntactic sugar for lambda
abstractions. f could as well be defined as f = \x - x + x.
Please elaborate
First, the
f x =
part says that f
If its specifically the list instance, where we currently trade laziness
for efficiency of encoding (which may or may not be the right thing),
I'd suggest a fully lazy encoding instance?
Its not really a list, its more of a tree that has shared nodes, so
something like this:
A
/
On Wed, 2007-10-03 at 01:42 +0100, PR Stanley wrote:
f x = x + x
Is the x use to create a pattern in the definition and when f is
called it's replaced by a value?
Those equation-like definitions are syntactic sugar for lambda
abstractions. f could as well be defined as f = \x -
Stefan O'Rear wrote:
On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote:
I do not believe that anyone was seriously advocating multiple blessed
encodings. The main question is *which* encoding to bless. 99+% of
text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16
On Oct 2, 2007, at 21:12 , Isaac Dupree wrote:
Stefan O'Rear wrote:
On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote:
I do not believe that anyone was seriously advocating multiple
blessed
encodings. The main question is *which* encoding to bless. 99+
% of
text I encounter is
On 3 Oct 2007, at 1:42 pm, PR Stanley wrote:
When a function is declared in C the argument variable has an
address somewhere in the memory:
int f ( int x ) {
return x * x;
}
Wrong. On the machines I use, x will be passed in registers and will
never ever have an address in memory. In fact,
i solved this myself - for the sake of documenting the solution, i
obtained the darcs version with
darcs get --set-scripts-executable
http://www.stefanwehr.de/darcs/hscurses/
and then a standard hackage install
and i think the --set-scripts-executable in this case is significant
On Tue, Oct
43 matches
Mail list logo
