- Haskell-Cafe - Haskell.org

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

HaskellDB is alive?
by Felipe Lessa 16 Feb '09

16 Feb '09

Hello! There was a new HaskellDB release, but I didn't see any announcement here. Is it back alive? What happened to 0.11? Thanks =) -- Felipe.

4 3

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

16 Feb '09

[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: > One more thing, would Grapefruit work with files created by Glade (UI > builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. Best wishes, Wolfgang

2 1