- web-devel - Haskell.org

[Yesod] Nesting widgets
by Aren Olson 07 Jun '11

07 Jun '11

In Yesod, if I have two Widgets, how can I 'nest' the content of one widget inside one of the tags of the other? In effect, I want to be able to do something like widget <- do addHamlet [hamlet| some html |] addCassius [cassius| some css |] otherwidget <- do addHamlet [hamlet| <div ${widget} ] and end up with the body contents from widget inside otherwidget's <div> tag, while widget's cassius data still ends up in the page's <head> as normal. I can't find any documentation or examples of this, and nothing I tried would compile. Is this doable? If so, how? Thanks, -Aren

4 12

API change request for WAI
by Kazu Yamamoto 07 Jun '11

07 Jun '11

Hello, I would like ask to change WAI API a bit. Please include the following data constructor for Response: ResponseIO Status ResponseHeaders (Socket -> IO Bool) # Please choose better name than ResponseIO The function whose type is Socket -> IO Bool is to send a HTTP body to the socket and returns keepalive-or-not. This opens possibilities to find a better sending scheme than that which Warp adopts by default. I'm implementing a classical web server library on WAI (wai-app-file-cgi). It sends files to clients with ResponseFile. Warp uses the sendfile library for ResponseFile. The sendfile library uses (unnecessary) hSeek and hFileSize which call system calls. System calls causes context switches. Since GHC7's IO manager uses a single kernel thread, all Haskell threads stops. Calling system calls gives significant performance impact. ResponseIO enables to choose a function which sends files with minimum system calls for WAI users. I have already implemented this both in wai and warp, and confirmed that this works well. --Kazu

3 6

problem with radioField from yesod.Forms
by Michael Litchard 06 Jun '11

06 Jun '11

I am working from the widget example from the Yesod web site. I was able to display a column of check boxes, and am able to generate a [Bool], which is enough for now, as far as the check boxes go. Now, I would like a column of radioFields. I will worry about the CSS and Ajax stuff later. The problem is that radioField uses a slightly different type. I admit I don't understand some of these types, but I can exploit my pattern recognition skills well enough. Below is my last attempt. The type for radioField is radioField :: (Eq x, IsForm f, FormType f ~ x) => [(x, Text)] -> FormFieldSettings -> Maybe x -> f The type for boolField is boolField :: (IsForm f, FormType f ~ Bool) => FormFieldSettings -> Maybe Bool -> f It's the [(x,Text)] that is tricking me. I suspect the problem may be me not understanding the Applicative style well enough. Could someone offer some feedback to send me on the right track? > handleFormR = do > (res, form, enctype, nonce) <- runFormPost $ fieldsToTable $ (,,,,,,,,) > <$> boolField "Server One" Nothing > <*> boolField "Server Two" Nothing > <*> boolField "Server Three" Nothing > <*> boolField "Server Four" Nothing > <*> boolField "Server Five" Nothing > <*> boolField "Server Six" Nothing > <*> boolField "Server Seven" Nothing > <*> boolField "Server Eight" Nothing > <*> radioField [(1, "Test 1"), (2, "Test 2")] "Pick a Test" Nothing mlitchard@apotheosis:~/playground/yesod-examples-0.8.0.1/src$ runhaskell nwidgets.lhs nwidgets.lhs:46:7: The last statement in a 'do' construct must be an expression: (res, form, enctype, nonce) <- runFormPost $ fieldsToTable $ (,,,,,,,,) <$> boolField "Server One" Nothing <*> boolField "Server Two" Nothing <*> boolField "Server Three" Nothing <*> boolField "Server Four" Nothing <*> boolField "Server Five" Nothing <*> boolField "Server Six" Nothing <*> boolField "Server Seven" Nothing <*> boolField "Server Eight" Nothing <*> radioField [(1, "Test 1"), (2, "Test 2")] "Test 1" Nothing

1 1

Fwd: Sending SMTP email
by Dmitry Olshansky 06 Jun '11

06 Jun '11

Hi, On Windows I use HaskellNet. Dmitry 2011/6/2 Aur Saraf <sonoflilit(a)gmail.com> > Hi, > > Michael wrote the mime-mail package that works with an external sendmail > binary. > > http://hackage.haskell.org/package/mime-mail-0.3.0 > > I'm using it and it's doing fine. > > > Cheers, > Aur > > On Thu, Jun 2, 2011 at 4:46 PM, Neil Mitchell <ndmitchell(a)gmail.com> > wrote: > > Hi > > > > I want to send an email with SMTP. I previously used hsmtpclient with > > the NoSMTPAuth option, but that library is no longer maintained by the > > original author and doesn't work with GHC 7. What do people recommend > > for sending SMTP mail? I'm not looking for anything fancy, and could > > probably fix up hsmtpclient if I needed to, but I'd rather stick to > > something some else supports. > > > > Thanks, Neil > > > > _______________________________________________ > > web-devel mailing list > > web-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/web-devel > > > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel >

2 2

Fwd: [hamlet] Clearer error for mixed spaces / tabs nesting in cassius (#2)
by Michael Snoyman 03 Jun '11

03 Jun '11

I don't have a strong opinion on tabs/spaces for Hamlet and Cassius (the discussion isn't relevant for Julius or Lucius). So I thought I'd just throw this to the web-devel list: what do you guys think? Currently, 1 tab = 4 spaces for indentation purposes. I personally never use hard tabs for Haskell, so the question doesn't affect me. Michael ---------- Forwarded message ---------- From: Shimuuar <reply+i-326148-baa0eff244395e870f290821538bf79d83ec1190(a)reply.github.com> Date: Wed, Jun 1, 2011 at 7:33 PM Subject: Re: [hamlet] Clearer error for mixed spaces / tabs nesting in cassius (#2) To: michael(a)snoyman.com I'd vote to ban tabs. They may change meaning of program silently. If your editor and hamlet/cassius have different tab width it may lead either to error or it could be parsed not as you expected. Second case is real. I encountered it. IMHO mixing tabs and significant indentation is generally bad idea™ -- Reply to this email directly or view it on GitHub: https://github.com/snoyberg/hamlet/issues/2#comment_1275487

3 3

[Yesod] Error occured in dist/devel.hs
by Katsutoshi Itoh 02 Jun '11

02 Jun '11

Hi. I converted my yesod app 0.7 to 0.8, and success to compile and run the program. but, could not run by yesod devel. ----------------------------------------- $ yesod devel (snip) Configuring kestrel-0.1... Testing files... Rebuilding app yesod: bind: resource busy (Address already in use) Preprocessing executables for kestrel-0.1... Building kestrel-0.1... Installing executable(s) in /home/cutsea110/.cabal/bin No package to register Calling runghc... dist/devel.hs:2:0: Failed to load interface for `Controller': it is not a module in the current program, or in any known package. Testing files... Testing files... Testing files... ----------------------------------------- This means what? Incidentally, ghc 6.12.3, cabal 0.8.2, haskell-platform-2010.2.0.0, yesod-0.8.1. thanks.

2 1

Sending SMTP email
by Neil Mitchell 02 Jun '11

02 Jun '11

Hi I want to send an email with SMTP. I previously used hsmtpclient with the NoSMTPAuth option, but that library is no longer maintained by the original author and doesn't work with GHC 7. What do people recommend for sending SMTP mail? I'm not looking for anything fancy, and could probably fix up hsmtpclient if I needed to, but I'd rather stick to something some else supports. Thanks, Neil

2 1

[Yesod] What is ContentFile's second argument?
by Katsutoshi Itoh 02 Jun '11

02 Jun '11

Hi Now, I'm converting my yesod app 0.7 to 0.8 I'm facing to the code like this. return $ RepHtml $ ContentFile path I looked up ContentFile has 2 arguments, on 0.8. the second argument of this is Maybe FilePart. If I write this Nothing, what does it mean? thanks.

2 1

Re: [web-devel] DTD types
by Yitzchak Gale 02 Jun '11

02 Jun '11

I wrote: >> "Note that DTD-based validation is not namespace-aware in the >> following sense: a DTD constrains the elements and attributes >> that may appear in a document by their uninterpreted names, >> not by (namespace name, local name) pairs." >> >> So in the DTD, the prefix *is* semantically significant. >> And Clark notation is irrelevant, because there is no use >> for the URI in the DTD. John Millikin wrote: > If I'm reading that paragraph correctly, the prefix is not > significant, or even present, in a DTD. You only use the local name. No, the spec is quite clear about that. Element names and attribute names are "qualified names", but their namespaces are not "interpreted"; those terms are defined precisely earlier in the spec. In order for that to produce XML documents that make sense, the spec recommends that you use #FIXED for the xmlns:foo attribute in the appropriate places in the DTD. Thanks, Yitz

1 0

Fwd: DTD types
by Yitzchak Gale 02 Jun '11

02 Jun '11

Sorry, forgot to include the list as a recipient. ---------- Forwarded message ---------- From: Yitzchak Gale Date: Wed, Jun 1, 2011 at 10:50 AM Subject: Re: DTD types To: John Millikin I wrote: >>>> For example, I couldn't use name, because for DTD namespaces >>>> *are* significant so they need a different Eq instance. I ended up >>>> just using Text." John Millikin wrote: >>> I don't understand what this means; the xml-types Eq instance >>> for Name compares both the namespace and local name >> Ah, OK. I misunderstood the docs - it says that the "prefix" >> is not used in the Eq instance, so I took that to mean >> that namespaces prefixes were not used. > Lets say you have a document like this: > > <foo:doc xmlns:foo="http://my/namespace/here">bar</foo:doc> > > The name of the element will have the components: > > prefix = "foo" > namespace = "http://my/namespace/here" > local name = "doc" > > The prefix is not semantically important; all names are identified by > the (namespace, local name) pair. Thus, comparing two names ignores > the prefix. Hmm. Then I was right in the first place. I can't use the xml-types Name type for DTDs. The XML Namespaces spec states: "Note that DTD-based validation is not namespace-aware in the following sense: a DTD constrains the elements and attributes that may appear in a document by their uninterpreted names, not by (namespace name, local name) pairs." So in the DTD, the prefix *is* semantically significant. And Clark notation is irrelevant, because there is no use for the URI in the DTD. I already uploaded a new version of dtd-types, 0.1.0.0, to Hackage, with a number of fixes, including using Name in a few places. Before I announce, I'm going to have to remove Name and uploaded another version. Thanks, Yitz

1 0