date:20110519

[Haskell-cafe] Status of Haskell + Mac + GUIs graphics

2011-05-19 Thread Dummy

Hi,
 
i am really happy about this lively discussion around Haskell (Mac) GUIs.
 
I might hint to two other options:
 
1) Eclipse's SWT wraps the native platform's toolkits quite sucessfully.
The platform-dependent bindings are mostly automatically generated, afaik.
Some time ago i summarized my thoughts about extending SWT's infrastructure/code
for Haskell here:
http://www.reddit.com/r/haskell_proposals/comments/9w7nk/adjust_the_swt_binding_generators_for_haskell/
 
2) Ruby's Shoes provides simple native wrappers as i've pointed out on Reddit:
http://www.reddit.com/r/haskell/comments/he8pl/status_of_haskell_mac_guis_graphics/

Bye,
Lenny ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics

2011-05-19 Thread Sam Martin

 My conclusion was that GLFW-b (on hackage) is the best we have right
 now.  I think we could do even better than the C libraries out there
 by writing the GLUT/GLFW/etc implementation purely in Haskell.  We
 already have x11 and gtk bindings for the linux support.  We have
 win32 api bindings for windows support.  What we are lacking is good
 low level support for OSX GUI programming.  Once we have that it's not
 too much of a stretch to use cabal to glue it together into a cross
 platform library.  I believe that's the right way to go for the long
 term.  Improving GLFW-b is a good short-term route.

I agree with your approach. Although getting a window on screen really isn't 
much code, so I'd vote for going straight to a Haskell replacement for GLUT et 
al. 

 And just to say it one more time, I can use all the help I can get.

I don't have much time, but if someone started a github project for a Haskell 
GLUT replacement I could probably chip in here and there. 

Ta,
Sam

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

Re: [Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform

2011-05-19 Thread Johan Tibell

Hi Simon,

On Wed, May 18, 2011 at 7:32 PM, Simon Meier iridc...@gmail.com wrote:
In fact, one of my current goals with this work is to polish it such
that it can be integrated into the 'bytestring' library.

We should definitely add a builder monoid in the bytestring package.

Since Write mentions IO, I thought I should point out that we need to
separate any code that mentions IO from the the code that doesn't
(i.e. the pure Builder API). The use of IO is an implementation detail
in bytestring. We should follow the existing bytestring pattern and
put any code that mentions IO in e.g.
Data.ByteString.Lazy.Builder.Internal. This allows the few people who
need to access the internals to do so while making it clear that these
are in fact internals. Long term we'd like to switch bytestring over
from ForeignPtr to ByteArray#, if possible. There are currently some
technical obstacles to such a switch, but factoring out the IO code at
least makes it somewhat easier if we ever get around to switching.

Avoiding IO in the main API means that the main builder type must not
mention IO (or things related to IO, such as Storable).

The core principle used to tackle (1) is avoiding intermediate data
structures. The core abstraction used is the one of a Write (see [1]
for the corresponding library.)

data Write a = Write Int (a - Ptr Word8 - IO (Ptr Word8))

A value `Write bound io :: Write a` denotes an encoding scheme for
values of type `a` that uses at most `bound` bytes space. Given a
values `x :: a` and a pointer `po` to the next free byte `io x po`
encodes `x` to memory starting from `po` and returns the pointer to
the next free byte after the encoding of `x`.

In most cases Writes are used as an abstract datatype. They serve as
an interface between implementors of the low-level bit-twiddling
required to efficiently implement encodings like UTF-8 or Base16 and
the providers of efficient traversal functions through streams of
Haskell values. Hence, typical users of Writes are functions like

fromWrite :: Write a - a - Builder
fromWriteList :: Write a - [a] - Builder
fromWriteUnfoldr :: Write b - (a - Maybe (b, a)) - a - Builder
mapWriteByteString :: Write Word8 - S.ByteString - Builder

We want to allow users to efficiently create new builders, for their
own data type. This is crucial as the bytestring package cannot
provide efficient builders for every possible type, as it would have
to depend on most of Hackage (i.e. on all packages that define types
that we want efficient builders for) to do so. Allowing the user to
get hold of the underlying buffer in a controlled way makes the
builder extensible. This is good.

Write achieves this separation, but it has some costs which I'm not
entirely comfortable with.

First, it leads to lots of API duplication. For every type (e.g. Word)
we want to be able serialize we have two morally identical functions

writeWordhost :: Word - Write
fromWordhost :: Word - Builder

in the API, where the latter simply calls the former and does some
additional wrapping.

See
http://hackage.haskell.org/packages/archive/blaze-builder/0.3.0.1/doc/html/Blaze-ByteString-Builder-Word.html
for examples.

Simon, is the reason for this duplication this comment on top of
Blaze.ByteString.Builder.Word?

Note that for serializing a three tuple (x,y,z) of bytes (or other
word values) you should use the expression

fromWrite $ writeWord8 x `mappend` writeWord8 y `mappend` writeWord z

instead of

fromWord8 x `mappend` fromWord8 y `mappend` fromWord z

The first expression will result in a single atomic write of three
bytes, while the second expression will check for each byte, if
there is free space left in the output buffer. Coalescing these
checks can improve performance quite a bit, as long as you use it
sensibly.

Coalescing of buffer space checks can be achieved without separating
writes into Write and Builder. I've done so in the binary package [1]
using rewrite rules. The rewrite rules fire reliable so that any
syntactic series of puts i.e.

f = do
putWord8 1
putWord8 2
putWord8 3

result in one bounds check, followed by three pokes into the buffer.
To do so all that is needed is to define all builders in terms of

writeAtMost :: Int - (Ptr Word8 - IO Int) - Builder

and create a rewrite rule for append/writeAtMost. writeAtMost is
essentially the same as your Write [2], except it never leads to any
constructors getting allocated.

At the moment, the addition of Write means that

import Blaze.ByteString.Builder

f :: [Word8] - Builder
f xs = fromWriteList writeWord8 xs

is faster than the Data.Binary equivalent

import Data.Binary.Builder

g :: [Word8] - Builder
g [] = mempty
g (x:xs) = singleton x `mappend` g xs

Fortunately this was due to a bug in GHC [3]. After this bug has been
fixed I expect Data.Binary to perform on par with
Blaze.ByteString.Builder,

Re: [Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform

2011-05-19 Thread Henk-Jan van Tuyl

On Wed, 18 May 2011 23:21:27 +0200, Antoine Latter aslat...@gmail.com  
wrote:



I don't have a problem with these extensions being in the Haskell
Platform, as the platform currently only targets GHC, but the
bytestring package itself might have a higher standard of portability.


So you want the packages that use extensions thrown out, as soon as  
another Haskell compiler becomes popular? As one of the targets of the  
Haskell Platform is stability, it is not advisable to target just one  
compiler.


Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

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

Re: [Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform

2011-05-19 Thread Antoine Latter

On May 19, 2011 4:57 AM, Henk-Jan van Tuyl hjgt...@chello.nl wrote:

 On Wed, 18 May 2011 23:21:27 +0200, Antoine Latter aslat...@gmail.com
wrote:

 I don't have a problem with these extensions being in the Haskell
 Platform, as the platform currently only targets GHC, but the
 bytestring package itself might have a higher standard of portability.


 So you want the packages that use extensions thrown out, as soon as
another Haskell compiler becomes popular? As one of the targets of the
Haskell Platform is stability, it is not advisable to target just one
compiler.


Portability and adherence to standards is a goal worth striving for, but the
platform policy stated on the wiki is that packages in the platform should
build on all compilier targets.

I think we need to be pragmatic about what we include - for example
functional dependencies are still controversial, but that doesn't mean that
the 'mtl' package should be tossed out of the platform.

But perhaps it does mean that, for example, the 'containers' package should
be subject to a higher level of scutiny for its public API. The 'bytestring'
package might also be such a package where we prioritize portability.

I'm not active in the maintaince of the platform; perhaps I'm mis-stating
the goals and policies.

Antoine
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics

2011-05-19 Thread Heinrich Apfelmus


Jason Dagit wrote:


As you point out we also need better libraries for creating the OpenGL
context.  I wrote up my searches on that front here:
http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.html

My conclusion was that GLFW-b (on hackage) is the best we have right
now.  I think we could do even better than the C libraries out there
by writing the GLUT/GLFW/etc implementation purely in Haskell.


Not sure about that. I have looked at the GLFW source code, it's the 
cleanest C code I have ever seen and definitely worth contributing to. 
The thing with established cross-platform GUI toolkits is that they 
embed a lot of wisdom about platform quirks (Cocoa is particularly 
annoying) that you would have to solve again.



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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

Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics

2011-05-19 Thread Heinrich Apfelmus


Conal Elliott wrote:

Last I heard, wx still had the problem of crashing its host the second time
one opens a window (which is typical in ghci). And last I heard, Jeremy
O'Donoghue (cc'd) was exploring solutions but had very little time to pursue
them.  - Conal


Last I remember, the latest problem is that ghci is unable to link 
libstdc++. But the crash problem is probably still there.



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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

[Haskell-cafe] Trying to return a map from State monad

2011-05-19 Thread michael rice

I'm not sure what's going on BELOW. Was working with mapAccumL earlier and 
decided to move over to State monad for more control.
:m + Data.Map:m + Data.ListPrelude Data.List Data.Map let f key new old = new 
++ oldPrelude Data.List Data.Map let moby2 = Moby Dick is a great book. Moby 
Dick was a white whale.Prelude Data.List Data.Map fst $ mapAccumL (\ (m,p) w 
- ((insertWithKey' f p [w] m, (snd p, w)),)) (singleton (\n, \n) [], 
(\n,\n)) (words moby2)(fromList 
[((\n,\n),[Moby]),((\n,Moby),[Dick]),((Dick,is),[a]),((Dick,was),[a]),((Moby,Dick),[was,is]),((a,great),[book.]),((a,white),[whale.]),((book.,Moby),[Dick]),((great,book.),[Moby]),((is,a),[great]),((was,a),[white])],(white,whale.))
Michael

BELOW===
import Control.Monad.Stateimport Data.Map
type Prefix = (String,String)type GeneratorState = (Map Prefix 
[String],Prefix,[String])
non_word = \n
f key new old = new ++ old 
buildMap :: GeneratorState (Map Prefix [String])  buildMap = do 
(mp,(pfx1,pfx2),all@(w1:words)) - get              if (Prelude.null all)       
         then  {- No more words. Return final map (adding non_word for prefix). 
-}                  return (insertWithKey' f (pfx1,pfx2) [non_word] mp)         
       else  {- Add word to map at prefix. Continue. -}                  put 
(insertWithKey' f (pfx1,pfx2) [w1] mp, (pfx2,w1), words)                  
buildMap
==
Prelude :l markov3.hs[1 of 1] Compiling Main             ( markov3.hs, 
interpreted )
markov3.hs:11:12:    `GeneratorState' is applied to too many type arguments    
In the type signature for `buildMap':      buildMap :: GeneratorState (Map 
Prefix [String])Failed, modules loaded: none.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Trying to return a map from State monad

2011-05-19 Thread Thedward Blevins

On Thu, May 19, 2011 at 11:03, michael rice nowg...@yahoo.com wrote:
 type GeneratorState = (Map Prefix [String],Prefix,[String])

 buildMap :: GeneratorState (Map Prefix [String])

You are trying to use a type alias (GeneratorState) as a type constructor.

There may be other problems, but that leaps out.

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

Re: [Haskell-cafe] Trying to return a map from State monad

2011-05-19 Thread michael rice

Ok, I see I left out the State word.
Should be:type GeneratorState = State (Map Prefix [String],Prefix,[String])
Thanks,
Michael

--- On Thu, 5/19/11, Thedward Blevins thedw...@barsoom.net wrote:

From: Thedward Blevins thedw...@barsoom.net
Subject: Re: [Haskell-cafe] Trying to return a map from State monad
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe@haskell.org
Date: Thursday, May 19, 2011, 12:22 PM

On Thu, May 19, 2011 at 11:03, michael rice nowg...@yahoo.com wrote:
 type GeneratorState = (Map Prefix [String],Prefix,[String])

 buildMap :: GeneratorState (Map Prefix [String])

You are trying to use a type alias (GeneratorState) as a type constructor.

There may be other problems, but that leaps out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] For Euler 25; What is the first term in the Fibonacci sequence to contain 1000 digits?; the following seems to work.

2011-05-19 Thread KC

For Euler 25; What is the first term in the Fibonacci sequence to
contain 1000 digits?; the following seems to work.


-- For number of digits being 5 or more.
fibNdigits :: Int - Int
fibNdigits nDigits = floor (((fromIntegral nDigits) - 1.0) / (logBase
10 phi)) + 2
  where
sq5 = sqrt 5 :: Double
phi = (1 + sq5) / 2


-- 
--
Regards,
KC

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

Re: [Haskell-cafe] No fish, please

2011-05-19 Thread Andrew Coppin


This is basically the reason I asked. Currently Cabal assumes that
Haddock is the only tool of its kind. If somebody built a better
Haddock, you wouldn't be able to use it. (Unless you named the
executable haddock and made it accept the same command options.)


Or maybe support for that tool would be integrated into Cabal and cabal and
hackage.


I believe the correct approach would be to make it easy to configure 
Cabal to use any tool that might be produced one day, rather than 
integrating support for each specific tool that actually exists.



But even while such a tool is not yet available, it would be worth thinkng
about hackage offering the possibility to display other docs than haddock-
generated ones.


Agreed.


IF you do have better docs, host them somewhere, and put a link
prominently in the .cabal file synopsis.


That works, but it does mean that you can't read the documentation
offline.


Make it downloadable?
Include the docs in the package (extra-source-files: thedocs.tar.gz) and
mention it in the package descripiton for a (less than optimal) workaround.


I thought extra-source-files: is only for Haskell source code?


(It also requires you to have somewhere to host, which not
everybody has.


Haskellwiki, bitbucket, github, ...


BitBucket only works for Mercurial, GitHub only works for Git. The 
Haskell wiki might be OK, and has the nice advantage that other people 
can improve it. (Do we think Hackage will ever get a wiki per package?) 
The other thing is, you can bet as soon as you put your package's 
documentation on the wiki and link it from the package description, the 
URL will change at some point, breaking the link.



Sure, a centralised documentation-hosting would have advantages over
sprinkling over all the free project-hosting services, but the situation is
not unbearably dire as is.


Granted. I'm just saying how it could be better.

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

Re: [Haskell-cafe] No fish, please

2011-05-19 Thread Andrew Coppin


On 18/05/2011 11:25 PM, Ivan Lazar Miljenovic wrote:

On 19 May 2011 08:09, Daniel Fischerdaniel.is.fisc...@googlemail.com  wrote:

On Wednesday 18 May 2011 23:39:47, Andrew Coppin wrote:

(It also requires you to have somewhere to host, which not
everybody has.


Haskellwiki, bitbucket, github, ...


Also if you have a project on code.haskell.org, then you also can have
a website for it on projects.haskell.org


Today is the first time I've seen these domain names mentioned. (They 
appear to be aliases to the same server that runs the rest of 
haskell.org...)


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

[Haskell-cafe] The Lisp Curse

2011-05-19 Thread Andrew Coppin


http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

Some of you might have seen this. Here's the short version:

  Lisp is so powerful that it discourages reuse. Why search for and 
reuse an existing implementation, when it's so trivially easy to 
reimplement exactly what you want yourself? The net result is a maze of 
incompatible libraries which each solve a different 80% of the same problem.


To all the people who look at Hackage, see that there are 6 different 
libraries for processing Unicode text files, and claim that this is 
somehow a *good* thing, I offer the above essay as a counter-example.


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

Re: [Haskell-cafe] For Euler 25; What is the first term in the Fibonacci sequence to contain 1000 digits?; the following seems to work.

2011-05-19 Thread Sebastian Fischer

On Thu, May 19, 2011 at 7:29 PM, KC kc1...@gmail.com wrote:

 For Euler 25; What is the first term in the Fibonacci sequence to
 contain 1000 digits?; the following seems to work.


 -- For number of digits being 5 or more.
 fibNdigits :: Int - Int
 fibNdigits nDigits = floor (((fromIntegral nDigits) - 1.0) / (logBase
 10 phi)) + 2
  where
sq5 = sqrt 5 :: Double
phi = (1 + sq5) / 2



(length . show) is fast enough for me. The following gives the answer in a
fraction of a second.

# cabal install fibonacci
# ghci
ghci import Data.Numbers.Fibonacci
ghci head . filter ((==1000) . length . show) $ map fib [0..]
10700662663827589367649805844573968850836838966321516650132352033753145206046940406218891475824897926578046948881775919574843364666725699595129960304612627480924821861440694330512347744427502737817530875793916661921492591867595539664228371489431130746995034395470019854326097230672901928705264472437261177158218255484911205250132014786129659313817922355596574520395061375514678375432291196021299340482607061753977068470682028954869026661854351245219003694806413574474709117076197669456910700980243934396174741037369125032313655321647736970231677550515951735184605799549194109677783732296657965816465139034881542563101842241902598460880001101862024549393711365165703944762958471454852342595042858242530608354443542821261100899286379504800689433030977321783486454311320576565986845628861680871869383529735064398629764066723562917905207051164077614812491885830945940566688339109350944456576357666151619317753792891661581327159616877487983821820492520348473874384736771934512787029218636250627816
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

60 matches

Mail list logo