- web-devel - Haskell.org

A string escape issue with Yesod Julius
by Dmitry Vyal 15 Nov '12

15 Nov '12

Greetings Recently I stumbled upon an unexpected escaping problem. I hoped Shakespeare templates would solve these forever, but looks like it's not the case. For example, look at this snippet: Prelude Text.Julius Data.Text.Lazy Data.Text> let t = "X\"Y\"Z"; j = [julius| str = "a#{t}bc"; |] in putStrLn $ Data.Text.Lazy.unpack $ renderJavascriptUrl (\u env -> Data.Text.pack "") j str = "aX"Y"Zbc"; Clearly we have have a problem here. Can something be done with it? Best wishes, Dmitry

3 3

Upcoming significant change to Cassius
by Michael Snoyman 31 Oct '12

31 Oct '12

Hi all, I've pushed some changes to Github regarding Cassius. Cassius is now simply a whitespace version of Lucius. In other words, when you run Cassius, braces are added in based on indentation level and the code is passed off to Lucius. Why the change? Twofold: 1. It only causes breakage for some incredibly strange corner cases (or so I believe). 2. It reduces the body of code we have to maintain. 3. And most importantly, it adds some really nice features to Cassius: nested blocks, variables, media queries, etc. I would appreciate if users of Cassius could take a little bit of time to pull the code from Github[1] and see how the changes affect them. I'm hoping to make the release next week. Michael [1] https://github.com/yesodweb/shakespeare

1 0

Esqueleto error messages
by Erik de Castro Lopo 25 Oct '12

25 Oct '12

Hi all (and in particular Filipe), I'm looking at Esqueleto and I'm finding that in certain circumstances it can throw out some rather horrid error messages. Consider the correct code fragment taken from the Esqueleto docs: select $ from $ \(b, p) -> do where_ (b ^. BlogPostAuthorId ==. p ^. PersonId) return (b, p) The error occurs if the programmer uses the wrong identifer in the where_ clause. For instance, if PersonId is used instead of BlogPostAuthorId then I get about 100 lines of error message, the majority of which is totally incomprehensible. Is there anything that can be done inside Esqueleto to make these error messages better? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 4

maxListenQueue
by Kazu Yamamoto 16 Oct '12

16 Oct '12

Hello guys, One guy experienced that warp refuses connections when many connections come. He pointed out that it is due to the listen queue. Network.Socket.maxListenQueue is typically 128 since SOMAXCONN is set to 128 in sys/socket.h. So, even if we increase kern.ipc.somaxconn by "sysctl", servers using "listenOn" cannot make use of it. If my understanding is correct, it is safe to specify a large backlog number to listen(). For instance, we can specify 2,000 even if kern.ipc.somaxconn is 128. Q1) I think that the name of maxListenQueue is misleading. What do you think? If people also feel misleading, how to fix it? Is documentation good enough? Q2) listenOn uses maxListenQueue. Should we fix it by specifying a large backlog number? If we don't want to change it, should we document well? P.S. warp relies on network-conduit which uses maxListenQueue. I will fix this anyway. --Kazu

4 6

Yesod User Survey 2012
by Michael Snoyman 10 Oct '12

10 Oct '12

The Yesod team has put together a new user survey: https://docs.google.com/spreadsheet/viewform?formkey=dFNINUgtbnJNSS1DRGw3bG… I strongly encourage anyone interested in Yesod or Haskell web development in general to take the time to respond. The results will help us decide directions to pursue moving forward. Thank you, Michael

1 0

Uniform substitution for URLs, templates, messages and other expressions in Shakespearean templates
by Sebastian Fischer 26 Sep '12

26 Sep '12

Hello, when writing my comparison of Hamlet with Heist and HXT (https://gist.github.com/3757918) I noticed that Hamlet and HXT have similar approaches to variable substitution but Hamlet's uses different syntax for substituting URLs, templates, and other expressions. I'd like to understand why. In HXT Haskell expressions can be substituted using the notation <% ... %>. The rendering of substituted expression is type based and specified separately for attribute- and element-positions via type classes `EmbedAsAttribute` and `EmbedAsChild`. In Hamlet Haskell expressions can be substituted using the notation #{...}. The rendering of substituted expressions is type based and specified via the type class `ToMarkup` from the blaze-html package. URLs are substituted using the notation @{...}, other templates using ^{...} and messages for i18n using _{...}. What are the reasons for providing four different syntaxes for variable subsitution if the substitution is type based? For example, different escaping mechanisms (URL escaping for routes, HTML escaping for strings) could already be accomplished with a single syntactical construct based on different type-class instances to generate markup. Best, Sebastian

3 7

Re: [web-devel] [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5
by Alberto G. Corona 24 Sep '12

24 Sep '12

Hi, This is an difficult problem in which the design principles of MFlow can help to creare a solution amazingly easily. http://haskell-web.blogspot.com.es/2012/09/a.html Alberto 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com> > However if in a tab out of sync the user press refresh, the tab will > refresh to the current state. > I took care not to try to synchronize back as a consequence of a page that > is in a forward state in one tab, as a consequence of navigating back in > other tab. However I may have not considered all the edge extreme cases. > > There is a back detection primitive "goingBack<http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…>" > that allow the programmer to control the back behaviour in some special > cases. > > For example if i want to step over a menu and present a default page, But > if when the user go back i want to present the menu, I can detect this > condition and present this menu, that did not appeared in a normal > navigation: > > This code sets and get a default option in the menu, so the menu is not > shown again in the navigation, except in the case that the user press the > back button. Otherwise, the menu would be never accessible. > > However this is very specialized. normally the back button detection is > not necessary. In a persistent flow even this default entry option would be > completely automatic, since the process would restar at the last page > visited. No setting is necessary. > > > menu= do > mop <- getGoStraighTo > back <- goingBack <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…> > case (mop,back) of > (Just goop,False) -> goop > _ -> do > r <- ask <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo…> option1 <|> option2 > case r of > op1 -> setGoStraighTo (Just goop1) >> goop1 > op2 -> setGoStraighTo (Just goop2) >> goop2 > > > > > > 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com> > >> Hi Jake, >> right, it depends on the identification of the session: >> >> iAll the tabs share the same state because they share the same cookies. >> so if in one tab the use continue the interaction then the other tabs are >> out of sync. If the user goes to these other tabs and press any widget, the >> application will synchronize back to this page. >> >> >> This happens also if the user is logged in different computers. >> >> Alberto. >> >> 2012/9/18 Jake McArthur <jake.mcarthur(a)gmail.com> >> >>> Actually, I meant users that spawn multiple tabs from a single root >>> session. You mentioned that you have some special support for the back >>> button. What happens if I open a couple new tabs in which I may or may >>> not go forward and backward. Do they all share the same state? >>> Different states (how?)? Partially shared states? >>> >>> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona <agocorona(a)gmail.com> >>> wrote: >>> > Oh, I´m stupid. You mean web pages with multiple tabs.... >>> > >>> > I have not tested it. but each tab can be handled easily by a >>> different >>> > server process.. or it can be handled in a single server process, like >>> in a >>> > menu. For example, this code present different options, and the process >>> > renders different things depending on the response. >>> > >>> > The last option is a link to a different process, while the others( >>> wlinks) >>> > are links that return back to the same process. >>> > The operator <|> is the applicative operator. a breakline is >>> prepended to >>> > each link: >>> > >>> > data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read, >>> > Show) >>> > >>> > mainf= do >>> > r <- ask $ wlink Ints (bold << "increase an Int") >>> > <|> br ++> wlink Strings (bold << "increase a String") >>> > <|> br ++> wlink Actions (bold << "Example of a string >>> > widget with an action") >>> > <|> br ++> wlink Ajax (bold << "Simple AJAX example") >>> > <|> br ++> wlink Opt (bold << "select options") >>> > <++ (br +++ linkShop) -- this is an ordinary XHtml link >>> > >>> > case r of >>> > Ints -> clickn 0 >>> > Strings -> clicks "1" >>> > Actions -> actions 1 >>> > Ajax -> ajaxsample >>> > Opt -> options >>> > mainf >>> > where >>> > linkShop= toHtml $ hotlink "shop" << "shopping" >>> > >>> > . >>> > Alberto >>> > >>> > 2012/9/18 Alberto G. Corona <agocorona(a)gmail.com>: >>> > >>> >> Hi Jake >>> >> >>> >> I don´t know what you mean with multiple tabs. The user management is >>> >> simple, anonymous clients are identified with a cookie. if the user >>> >> is logged (MFlow has widgets for logging-validation) the user is the >>> >> identifier. >>> >> >>> >> The state of a process is associated to the client identifier and to >>> >> the path invoked in the url requested. >>> >> >>> >> I don´t know if this answer your question.... >>> >> >>> >> Alberto >>> >> >>> >> 2012/9/18 Jake McArthur <jake.mcarthur(a)gmail.com>: >>> >>> This sounds really cool. >>> >>> >>> >>> How do you handle users having multiple tabs? >>> >>> >>> >>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona < >>> agocorona(a)gmail.com> >>> >>> wrote: >>> >>>> Hi haskellers and specially the web developers. >>> >>>> >>> >>>> http://hackage.haskell.org/package/MFlow-0.1.5.3 >>> >>>> >>> >>>> MFlow is a is a Web framework with some unique, and I mean unique, >>> >>>> characteristics that I find exciting: >>> >>>> >>> >>>> - It is a Web application server that start and restart on-demand >>> >>>> stateful web server processes (not request.-response) >>> >>>> This means that all the page navigation can be coded in a single >>> >>>> procedure. This increases readability of the programmer code. I woul >>> >>>> call it >>> >>>> a anti-node.js. Buit usual request-response (stateless) server >>> >>>> processes are also allowed >>> >>>> >>> >>>> - When the process is invoqued as result of an URL request, the Web >>> >>>> app server not only restart the process but also recover its >>> execution >>> >>>> state. The enclosing Workflow monad provides the thread state >>> >>>> persistence. There are state timeouts and process timeouts defined >>> by >>> >>>> the programmer. Processes with no persistent state (transient) are >>> >>>> possible. >>> >>>> >>> >>>> -The user interface is made of widgets. They are formlets with >>> added >>> >>>> formatting, attributes, validations, modifiers and callbacks, that >>> >>>> are composable, so the pieces are reusable and return type safe >>> >>>> responses to the calling process. Even the links are part of widgets >>> >>>> and return back type safe inputs at compile time to the calling >>> server >>> >>>> process. Tho glue these components, ordinary applicative combinators >>> >>>> and other extra combinators are used. >>> >>>> >>> >>>> - The widgets and the communication don´t make assumptions about the >>> >>>> architecture, so it can be adapted to non-web environments. This >>> >>>> versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and >>> >>>> Haskell Server Pages. >>> >>>> >>> >>>> -The widget rendering can be converted to ByteStrings automatically >>> >>>> with special combinators. A mix of widgets with different formats >>> can >>> >>>> be combined in the same source file. For example Text.Html and HSP >>> >>>> (Haskell server pages) >>> >>>> >>> >>>> -These widgets can be cached, to avoid widget rendering on every >>> >>>> interaction. >>> >>>> >>> >>>> -To handle the back button, and because the processes are stateful, >>> >>>> they can run backwards until the response match. This is transparent >>> >>>> for the programmer, thanks to the embedded FlowM monad. >>> >>>> >>> >>>> -All the code is in pure Haskell. No deployment, special scripts, >>> >>>> formats etc are necessary. >>> >>>> >>> >>>> -Besides automatic state persistence, TCache provides transactions >>> and >>> >>>> user data persistence, that can be configured for SQL databases. >>> >>>> Default persistence in files permit very rapid prototyping. Just >>> code >>> >>>> and run it with runghc. >>> >>>> >>> >>>> -Has AJAX support >>> >>>> >>> >>>> All of this sounds very complicated, but really it is simple!. Most >>> of >>> >>>> these things are transparent. The resulting code is quite readable >>> and >>> >>>> has very little plumbing! >>> >>>> >>> >>>> There is a non trivial example that some of these functionalities >>> >>>> embedded here that you can run: >>> >>>> >>> >>>> >>> >>>> >>> http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo… >>> >>>> >>> >>>> Take a look and tell me your opinion. I hope that you find it as >>> >>>> exciting as me. >>> >>>> >>> >>>> I´m looking for people to collaborate in the development of MFlow. >>> >>>> >>> >>>> Although still it is experimental, it is being used in at least one >>> >>>> future commercial project. So I have te commitment to continue its >>> >>>> development. There are many examples in the documentation and in the >>> >>>> package. >>> >>>> >>> >>>> Alberto >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Haskell mailing list >>> >>>> Haskell(a)haskell.org >>> >>>> http://www.haskell.org/mailman/listinfo/haskell >>> > >>> > >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > Haskell-Cafe(a)haskell.org >>> > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >>> >> >> > -- Alberto.

1 0

Data.Word8 (word8 library)
by Kazu Yamamoto 24 Sep '12

24 Sep '12

Hello, ByteString is an array of Word8 but it seems to me that people tend to use the Char interface with Data.ByteString.Char8 instead of Word8 interface with Data.ByteString. Since the functions defined in Data.ByteString.Char8 converts Word8 to Char and Char to Word8, it has unnecessary overhead. Yes, the overhead is ignorable in many cases, but I would like to remove it for high performance server. Why do people use Data.ByteString.Char8? I guess that there are two reasons: - There are no standard utility functions for Word8 such as "isUpper" - Numeric literal (e.g 72 for 'H') is not readable To fix these problems, I implemented the Data.Word8 module and uploaded the word8 library to Hackage: http://hackage.haskell.org/packages/archive/word8/0.0.0/doc/html/Data-Word8… If Michael and Bas like this, I would like to modify warp and case-insensitive to use the word8 library. What do people think this? My concern is that character names start with "_". Some people would dislike this convention. But I have not a better idea at this moment. Suggestions are welcome. --Kazu

6 21

ANNOUNCE: MFlow-0.1.5
by Alberto G. Corona 18 Sep '12

18 Sep '12

Hi haskellers and specially the web developers. http://hackage.haskell.org/package/MFlow-0.1.5.3 MFlow is a is a Web framework with some unique, and I mean unique, characteristics that I find exciting: - It is a Web application server that start and restart on-demand stateful web server processes (not request.-response) This means that all the page navigation can be coded in a single procedure. This increases readability of the programmer code. I woul call it a anti-node.js. Buit usual request-response (stateless) server processes are also allowed - When the process is invoqued as result of an URL request, the Web app server not only restart the process but also recover its execution state. The enclosing Workflow monad provides the thread state persistence. There are state timeouts and process timeouts defined by the programmer. Processes with no persistent state (transient) are possible. -The user interface is made of widgets. They are formlets with added formatting, attributes, validations, modifiers and callbacks, that are composable, so the pieces are reusable and return type safe responses to the calling process. Even the links are part of widgets and return back type safe inputs at compile time to the calling server process. Tho glue these components, ordinary applicative combinators and other extra combinators are used. - The widgets and the communication don´t make assumptions about the architecture, so it can be adapted to non-web environments. This versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and Haskell Server Pages. -The widget rendering can be converted to ByteStrings automatically with special combinators. A mix of widgets with different formats can be combined in the same source file. For example Text.Html and HSP (Haskell server pages) -These widgets can be cached, to avoid widget rendering on every interaction. -To handle the back button, and because the processes are stateful, they can run backwards until the response match. This is transparent for the programmer, thanks to the embedded FlowM monad. -All the code is in pure Haskell. No deployment, special scripts, formats etc are necessary. -Besides automatic state persistence, TCache provides transactions and user data persistence, that can be configured for SQL databases. Default persistence in files permit very rapid prototyping. Just code and run it with runghc. -Has AJAX support All of this sounds very complicated, but really it is simple!. Most of these things are transparent. The resulting code is quite readable and has very little plumbing! There is a non trivial example that some of these functionalities embedded here that you can run: http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Fo… Take a look and tell me your opinion. I hope that you find it as exciting as me. I´m looking for people to collaborate in the development of MFlow. Although still it is experimental, it is being used in at least one future commercial project. So I have te commitment to continue its development. There are many examples in the documentation and in the package. Alberto

1 0

Re: [web-devel] [database-devel] [ANNOUNCE] esqueleto, a type-safe EDSL for SQL queries
by Felipe Almeida Lessa 12 Sep '12

12 Sep '12

[cross-posting to web-devel] On Wed, Sep 12, 2012 at 6:28 AM, Leon Smith <leon.p.smith(a)gmail.com> wrote: > I am curious to know why persistent is a dependency, given that it sounds > like esqueleto focuses on generating raw SQL. > > Is it to get a more consistent interface across multiple database backends? > To handle schemas or migrations? Something else I'm missing entirely? TL;DR: Mainly the schema. Esqueleto could stop using persistent if we wanted but I don't know how many people would like to see this working and it is by no means trivial. Its main use of persistent is actually on the frontend, on the EDSL that you use. Using persistent we get a type-safe representation of the schema for free: entities and their fields. So when you say where_ (p ^. BlogPostTitle ==. val title) that BlogPostTitle is a constructor representing a field of entity BlogPost, which was created by persistent. The fact that p is a BlogPost is type-checked. The fact that title is, e.g., Text is type-checked. If I didn't use persistent, I'd have to ask the user to write this boilerplate code himself. If I didn't use persistent but the user did, it would be probably just a matter of implementing a lot of type class instances with trivial definitions. If neither I not my user used persistent, you'd probably have to implement a lot more (especially for the next point). It's also very convenient to use persistent on the backend. It already has everything you need to serialize and deserialize fields and entities, and a few bits more (such as escaping). This is also about schema, and we could also drop persistent if we gave the user the responsibility of writing a lot of boilerplate. We decided to use persistent as esqueleto's backend also because that's what we use on our company. We don't know of any other alternative that brings what persistent has for us: semi-intelligent migrations, not so much boilerplate due to TH, good support to MySQL via Bryan O'Sullivan's libraries (this bit is persistent-mysql and we developed the library in-house), type-safety on everything it provides (and now much more due to esqueleto), and non-slowness (I've never seen a benchmark between database APIs, but we know that persistent---and esqueleto---has been written with performance in mind). Even if there was an alternative, it would be very wasteful to change all of our codebase *unless* it brought something nice to the table that persistent does not have. Having said all that, it *may* be possible to abstract persistent out of esqueleto and avoid boilerplate for persistent's users by using the ConstraintKinds extension. All constraints that you see on the EDSL's interface could come from type families inside Esqueleto's type class. In order for this abstraction to be useful, we'd also need to abstract persistent away from the SQL backend, which may require a type class with a lot more internal methods but which persistent users will never need to see. This may be a nice idea should there be anyone wanting to use esqueleto without persistent. But, like I said above, you'd still need to define some boilerplate about your entities. I see two kinds of users that may like such approach: - Users that use completely raw interfaces (such as directly using {mysql,postgresql}-simple libraries). They will need to define a lot boilerplate by themselves, including the SQL backend type class. I'd say that these users should instead define a persistent schema, which will also need some boilerplate but a lot less, and you get persistent for free in the process. - Users of HaskellDB that need to issue a couple of raw queries here and there. It would be technically very interesting to use both approaches at the same time. Given that HaskellDB already has constructors for entities and fields, it would be just a matter of somehow teaching esqueleto how to use it (which may be easy but I never thought about it). However, I wonder how many exist on this category. So, while possible to stop using persistent, I'll probably not do anything in this direction unless I see that there is some interest in doing so (and not only for the sake of abstracting things). However, I'd accept a pull request for this in a heartbeat *if* it didn't add any boilerplate for persistent users. I could also accept something that incurs boilerplate overhead for persistent users, but it would not be in a heartbeat =). Cheers! -- Felipe.

1 0