February 2009 - Haskell-Cafe

Does gtk2hs support VTE?
by Magicloud Magiclouds 17 Feb '09

17 Feb '09

Hi, I always see a file named vte something in "doc" folder, but I never see vte in reference or source. So I wonder if gtk2hs actually supports VTE. And I'd like to have that supporting.... -- 竹密岂妨流水过山高哪阻野云飞

2 1

ANN : Crypto 4.2.0 & Related News
by Creighton Hogg 16 Feb '09

16 Feb '09

Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage & that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Cheers, Creighton

3 3

Complex C99 type in Foreign
by Maurício 16 Feb '09

16 Feb '09

Hi, Are there plans to include C99 'complex' type in Foreign, maybe as CFloatComplex, CDoubleComplex and CLongDoubleComplex? This seems an easy addition to the standard and would allow binding of a few interesting libraries, like GSL. Best, Maurício

3 8

Low-level high-level languages?
by Maurício 16 Feb '09

16 Feb '09

Hi, I've checked this 'BitC' language (www.bitc-lang.org) It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Thanks, Maurício

7 6

Re: [Haskell-cafe] Functional GUIs again
by Fraser Wilson 16 Feb '09

16 Feb '09

Oh, cheers! Newtype deriving is more general than I expected. Thanks for the comment. I've requested a hackage account, so I expect it to be there shortly :-) cheers, Fraser. On Mon, Feb 16, 2009 at 9:12 PM, Ryan Ingram <ryani.spam(a)gmail.com> wrote: > Tiny code-review comment: > > > data Style = Style [(String, StyleValue)] > > deriving (Read, Show) > > > instance Monoid Style where > > mempty = Style [] > > mappend (Style xs) (Style ys) = Style (xs ++ ys) > > => > > > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > > > > newtype Style = Style [(String, StyleValue)] > > deriving (Read, Show, Monoid) > > Also, put it on hackage! :) It looks pretty cool. > > -- ryan > > 2009/2/16 Fraser Wilson <blancolioni(a)gmail.com>: > > Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is > > ... not what I expect from a beautiful program, and because what I often > > need is a GUI that manipulates a state, and because I don't understand > > arrows, and having been intrigued by a recent cafe thread, I threw > together > > a prototype GUI library with the following features: > > > > - the GUI is defined on three levels: gadgets, widgets and styles > > - gadgets are functions on a state > > - widgets are data structures which define the layout > > - styles are ways to modify the appearance of widgets > > > > The following quick example shows a text box and a button. Clicking on > the > > button reverses the text in the text box. > > > >> module Main where > > > >> import Barrie > > > >> demoWidget :: Widget > >> demoWidget = vbox [ui "demo entry" textBox, > >> ui "demo command" (labelButton "click me")] > > > >> type DemoState = String > > > >> type DemoGadget = Gadget DemoState > > > >> demoGUI :: DemoGadget > >> demoGUI = localG "demo gui" [editorG "demo entry" id const, > >> commandG "demo command" reverse] > > > >> main = gtkMain demoGUI demoWidget "Hello, world" > > > > Two gadgets are used: > > > > editorG :: String -> (a -> b) -> (b -> a -> a) -> Gadget a > > commandG :: String -> (a -> a) -> Gadget a > > > > The editor gadget can show a value from a state, and update a state with > a > > value. The command gadget can transform a state to a new state. gtkMain > > connects the gadgets to a widget, which specifies layout using the vbox, > > attaching the editor gadget to a text box, and the command gadget to a > > button. > > > > Well, that's all pretty trivial. The key thing for me was that I can > easily > > slap a GUI onto the the front of a class of applications, which happen to > be > > the sort of applications I've been writing lately. Also, arbitrary parts > of > > the GUI can respond to things that happen miles away, without really > having > > to worry about it too much. In barrie-0.1 and 0.2, which used > stream-based > > approaches, the problem of getting state from one end of the application > to > > the other was non-trivial. > > > > I'll sketch another quick example: > > > >> data BridgeGame = ... > > > > And a bunch of things you can do with the state: > > > >> makeBid :: Bid -> BridgeGame -> BridgeGame > >> playCard :: Card -> BridgeGame -> BridgeGame > > > > For bidding, each bid is represented by a gadget: > > > >> bidG :: Bid -> Gadget BridgeGame > >> bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid) > > > > 'enabled' switches the gadget on if its first argument returns true when > > applied to the current state. However, the decision about what to do > with a > > disabled gadget is made by its corresponding widget. > > > > We get one button for each bid: > > > >> biddingG :: Gadget BridgeGame > >> biddingG = localG "bidding" (map bidG allBids) > > > > And they can be displayed in any old order using a widget: > > > >> biddingW :: Widget > >> biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids]) > >> where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7] > >> ntBids = hbox $ map (bidButton . NT) [1 .. 7] > >> bidButton bid = ui (show bid) $ labelButton (show bid) > > > > (You're right, double, redouble and pass are not represented. They make > the > > lines too long). > > > > Screenshot here: http://thewhitelion.org/images/4D.png > > > > I've just bid four diamonds, so everything lower than that is > automatically > > disabled. > > > > Currently, Barrie implements buttons, text boxes, labels, > > vertical/horizontal layout, single-column lists and drop lists. It > current > > uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first > > renderer was putStrLn/getLine). > > > > You can have a look by using darcs: > > darcs get http://thewhitelion.org/darcs/barrie > > > > Or get the tarball at > > http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz > > > > One note: this is not intended to be a theoretically sound approach, > merely > > a way of getting something done quickly. I would expect it to be most > > useful in putting a GUI front-end onto an existing application, in > > particular, an application that is driven by user actions which update a > > state; e.g. a calculator, a bridge game, a 4th edition D&D character > creator > > (but that leads to a critical mass of nerdiness, so it's off the table > for > > now) > > > > cheers, > > Fraser. > > > > -- > > http://thewhitelion.org/mysister > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- http://thewhitelion.org/mysister

1 0

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 16 Feb '09

16 Feb '09

Am Montag, 16. Februar 2009 19:27 schrieben Sie: > Ah. Copy, don't darcs get. If you copy a repository which was itself fetched from somewhere using this lazy patch fetching feature, you’ll probably experience problems too. If it’s the repository you work in and you never fetched any patches into it, you might be successful. This is how I understand it. We see that this lazy patch fetching thing is dangerous. ;-) > If you want to take a look, I'd love to hear your thought. > demos/BarrieCalc has some commentary, and the other applications in demos > are all very simple. I just executed the demos. At the moment, I have no time to look at the code but I think I will have a look in the future. Best wishes, Wolfgang

1 0

Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
by Fraser Wilson 16 Feb '09

16 Feb '09

(Wolfgang is probably wondering why I sent him an email about how great Utrecht is) Oh, yeah, that's coming up, isn't it? Utrecht finally gets the glory she deserves (for those who aren't aware, Utrecht has the most beautiful canals in the Netherlands, which is saying something, and is largely undiscovered by English bachelor parties, which is why it's such a great place to live). I think your footnote with what I assume is a link got lost, so here it is: http://haskell.org/haskellwiki/Hac5 I'd love to hack on Grapefruit. I'll do some study (and take a break from my own world-changing functional GUI :-) cheers, Fraser. On Mon, Feb 16, 2009 at 5:56 PM, Wolfgang Jeltsch < g9ks157k(a)acme.softbase.org> wrote: > Am Montag, 16. Februar 2009 17:46 schrieb Wolfgang Jeltsch: > > Am Montag, 16. Februar 2009 16:27 schrieb Gour: > > > Do you anticipate that Grapefruit will be capable for writing > real-world > > > GUI apps quit soon? > > > > I have no concrete anticipation. It depends very much on the community. > If > > there is notable interest and this interest makes people hacking on > > Grapefruit then it might not take so long until you can write real-world > > apps in Grapefruit. > > By the way, are there people out there who would like to hack on Grapefruit > during the Utrecht Hackathon [1]? > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://thewhitelion.org/mysister -- http://thewhitelion.org/mysister

2 3

Arch Haskell News: Feb 16 2009
by Don Stewart 16 Feb '09

16 Feb '09

Arch now has 926 Haskell packages in AUR. That’s an increase of 27 new packages in the last 8 days, or 3.38 new Haskell apps a day. This weekly news includes: * Noteworthy updates: grapefruit, haskelldb, gtk2hs * A video on how to use Arch packages * Updated releases by category Read it all: http://archhaskell.wordpress.com/2009/02/16/arch-haskell-news-feb-16-2009/ Enjoy! -- Don

1 0

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 16 Feb '09

16 Feb '09

[redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: > Great, does it run well on Windows and Mac platforms in addition to Linux > platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) > I am planning to create video phone software and I was looking for > good GUI toolkit that supports FRP so it looks like it is right time to > use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. > Thanks > > Jamie Best wishes, Wolfgang

5 12

hslogger bugs or features?
by Marc Weber 16 Feb '09

16 Feb '09

Following the advice on the hslogger wiki (http://software.complete.org/software/wiki/hslogger) I'm posting my thoughts about hslogger here: What is wired? This piece of code (src/System/Log/Logger.hs): parentHandlers name = let pname = (head . drop 1 . reverse . componentsOfName) name in do [...] next <- parentHandlers pname return ((handlers parent) ++ next) Why? Because when logging to "A.B.C" it splits the String once to get ["A","B","C"], then it drops the last part and runs the same again for "A.B" and so on.. So A string is split > 3 times for one logging action. I think this is a waste of cpu cycles.. I'm going to improve this. While reading the code i noticed two issues: ====================================================================== issue 1 That's not the most awkward thing: When logging to "A.B.C" hslogger does add 3 loggers to the global logger Map: "A" "A.B" "A.B.C" all three inheriting the default priority level of the default rootLogger "" A test application illustrating this (feature ?) module Main where -- packages: hslogger import System.Log.Logger as HL import System.Log.Handler.Simple as HL main = do -- the default logger logs to stderr level WARNING -- that's why the following message should be shown -- a) logM "A.B.C" HL.ALERT "ALERT test, should be shown and should create the sublogger" -- b) updateGlobalLogger rootLoggerName (setLevel EMERGENCY) logM "A.B.C" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" which prints: tmp %./test1 /tmp nixos ALERT test, should be shown and should create the sublogger ALERT test, should not be shown cause we have changed to EMERGENCY which is quite confusing because I haven't told hslogger explicitely to use a log level printing ALERTs on "A.B.C". so I'd expect that only the first message is shown. This behaviour is explained by the inheritance of the loglevel when hslogger creates them (without attaching handlers) automatically. I don't want the logging behaviour depend on wether a log line has been emitted before or not. Do you agree? Have I missed something? solution: replacing data Logger = Logger { level :: Priority, handlers :: [HandlerT], name :: String} type LogTree = Map.Map String Logger by a real log tree: data LogTree = LogTree { level :: Priority, -- level only applies to handlers, not to subLoggers handlers :: [HandlerT], subLoggers :: Map.Map String LogTree } ====================================================================== issue 2 The second ineresting point is (bug or feature?) that you can make the root logger shut up by setting different log levels to sub loggers: this sample does illustrate it: module Main where -- packages: hslogger import System.Log.Logger as HL import System.Log.Handler.Simple as HL main = do updateGlobalLogger "" (setLevel DEBUG) updateGlobalLogger "A" (setLevel EMERGENCY) logM "A" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" It doesn't print anything although the default log handler on root (="") is set to loglever DEBUG. So there is no way to get all logmessages without removing all all setLevel calls to subloggers? Is this desirable? ====================================================================== my conclusion: About issue 1 I think its a bug About issue 2 I don't know. I think there should be a way to get all log messages. So I feel this is a bug as well. I neither have checkeg the logcxx nor log4j nor the reference implementation in python. Thoughts? Sincerly Marc Weber

3 12