- web-devel - Haskell.org

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 10 Sep '12

10 Sep '12

On Sun, Sep 9, 2012 at 5:48 PM, Arthur Clemens <arthurclemens(a)gmail.com>wrote: > You'll need the AdminR constructor: AdminR AdminRootR. > > > It doesn't work in the scaffolded site, whereas it works as expected in a > single file site like > https://github.com/yesodweb/yesod/wiki/Hierarchical-routes-and-breadcrumbs > > I created a new scaffolded site, used add-handler to create > Handler/Admin.hs, and changed the route in config/routes to > > /admin AdminR: > / AdminRootR GET > > yesod devel results in Application.hs:27:1: Not in scope: data > constructor `AdminRootR' > > changing that to > > /admin AdminRootR GET > > runs without errors. > > > Just to confirm: does your `cabal` file state Yesod version 1.0 or 1.1? > If you use > -ddump-splices when compiling, GHC will spit out the generated > code/data types, which should give a good idea of what's going on > under the surface. > > > I can't, it results in > > Import.hs:10:2: lexical error at character 'i' > > Using ghc -cpp -ddump-splices main.hs > > results in Model.hs:13:1: Parse error: naked expression at top level > > Arthur > > Sorry, I should have clarified: you can do something like: cabal configure --ghc-option=-ddump-splices Then `cabal build` will pass in that option. You get the "naked expression" error because TemplateHaskell isn't enabled. Michael

1 1

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 09 Sep '12

09 Sep '12

On Sun, Sep 9, 2012 at 2:15 PM, Arthur Clemens <arthurclemens(a)gmail.com> wrote: > /admin AdminR: > /product/#ProductId AdminProductR GET POST > ... > > > So if I have: > > /admin AdminR: > / AdminRootR GET > /categories AdminCategoriesR GET > > and the handlers are specified as: > > getAdminRootR :: Handler RepHtml > getAdminRootR = do > .. > > getAdminCategoriesR :: Handler RepHtml > getAdminCategoriesR = do > .. > > what more is needed to create links? > Currently I use <a href=@{AdminRootR}> but that results in > > Handler/Admin.hs:14:22: > Not in scope: data constructor `AdminRootR' > > Arthur You'll need the AdminR constructor: AdminR AdminRootR. If you use -ddump-splices when compiling, GHC will spit out the generated code/data types, which should give a good idea of what's going on under the surface. Michael

1 0

Re: [web-devel] [Yesod] Abstracting permissions with Yesod
by Michael Snoyman 09 Sep '12

09 Sep '12

On Sun, Sep 9, 2012 at 1:36 PM, Arthur Clemens <arthurclemens(a)gmail.com> wrote: > It would be nice if there was the possibility to give an entire site section > permissions. What I have now very easily creates bugs, exactly what you > don't want in restricted site parts: > > data Permission = Admin | Public > > permissionsRequiredFor :: Route App -> Bool -> [Permission] > permissionsRequiredFor AdminR False = [Admin] > permissionsRequiredFor AdminCategoriesR False = [Admin] > permissionsRequiredFor AdminAddCategoryR False = [Admin] > permissionsRequiredFor (AdminEditCategoryR _) False = [Admin] > permissionsRequiredFor (AdminCategoryR _) False = [Admin] > permissionsRequiredFor AdminEmailsR False = [Admin] > permissionsRequiredFor AdminProductsR False = [Admin] > permissionsRequiredFor (AdminProductR _) False = [Admin] > permissionsRequiredFor AdminAddProductR False = [Admin] > permissionsRequiredFor (AdminEditProductR _) False = [Admin] > permissionsRequiredFor _ _ = [] > > -- > Arthur Starting with Yesod 1.1, hierarchical routes are now available. So you can do something like: /admin AdminR: /product/#ProductId AdminProductR GET POST ... And then permissionsRequiredFor AdminR{} False = [Admin] Michael

1 0

[ANNOUNCE] esqueleto, a type-safe EDSL for SQL queries
by Felipe Almeida Lessa 06 Sep '12

06 Sep '12

Hey! Just in case someone missed this: http://blog.felipe.lessa.nom.br/?p=68. All kinds of feedback are very welcome =). Cheers, -- Felipe.

1 0

new fast-logger and date-cache
by Kazu Yamamoto 05 Sep '12

05 Sep '12

Hello, I have changed the API of fast-logger and changed its version to v0.3. fast-logger v0.3 and related packages are alreay on Hackage. Since wai-extra requires v0.2, I believe this change does not effect to Yesod. I have already sent a pull request of wai-extra to catch up this change. The old fast-logger implements the caching algorithm of formatted date which was discussed this ML. The assumption at that time is: 1) formatting time to date string is a heavy job, and 2) issuing gettimeofday() is a light job. So, old algorithm is as follows: - When a formatted date is required, first issues getttimeofday(). Then compare it with a cached time. - If they are equal, return its cached formatted date. - Otherwise, format the new time to a new formatted date, cache them, and return the new formatted date. To my experience, the assumption 2) is not right. getttimeofday() is implemented in user land in Linux 3 but it is a system call in Linux 2. So, I fixed fast-logger so that it can choose caching strategy. The pull request above does not change behavior. That is, its strategy is the algorithm above. I also implemented a new strategy. Designated Haskell thread issues gettimeofday() every second, formats the resut time to a date, and cache it. I know that people here pointed out that a Haskell thread is not waken up correctly in heavy load situation. But I think that generating a incorrect date in a log file is not a big problem. The package to implement these two algorithm is "date-cache". This package can be used not only for logging but also generating the Date: header in HTTP Response. Mighty now uses the new algorithm of date-chace both for logging and generating Date:. --Kazu

3 5

WAI sessions
by Stephen Paul Weber 04 Sep '12

04 Sep '12

Are there any WAI middlewares around for session handling? I know Yesod has some stuff, but it seems mostly baked into yesod-core AFAICT. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

Re: [web-devel] new field for Network.HTTP.Types.Status
by Kazu Yamamoto 31 Aug '12

31 Aug '12

Hello, > What if you try just the bang pattern and no unboxing? Here it is: bang for three fields: 41346.8 req/s bang and unpack for Int only: 41761.7 req/s So, the current merged code is the best. --Kazu

2 4

Conduit/Wai proxy, HOWTO?
by Jason Dusek 29 Aug '12

29 Aug '12

Please find below my signature a sketch of a WAI proxy server, which always redirects every request to the same URL. In the sketch, the function `magic' takes care of translating from a Network.HTTP.Conduit.Response body to Network.Wai.ResponseSource body. However, I am a at a loss as to how to write `magic' safely. The body of a Network.HTTP.Conduit.Response is a ResumableSource but the body of Network.Wai.ResponseSource is a plain source and the conversion from one to the other would seem to involve one of: * Connecting the ResumableSource to a Sink, thus regrettably forcing it all into memory, * Unwrapping the resumable source and trying to figure out what to do with the finalizer. I was originally attracted to Wai/Warp/Conduit by the prospect of building a high quality proxy server. I am building an web service that talks to AWS and, for some tasks, must proxy results back to the user. I would be very grateful if someone could explain to me how best to put together a simple, efficient proxy server with Wai and Conduit. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B > {-# LANGUAGE OverloadedStrings > , RecordWildCards > #-} > > import Control.Applicative > import Control.Monad > import Data.ByteString (ByteString) > import qualified Data.ByteString.Char8 as Bytes > > import qualified Blaze.ByteString.Builder as Blaze > import qualified Blaze.ByteString.Builder.Char.Utf8 as Blaze > import Control.Monad.Trans > import qualified Data.Conduit as Conduit > import qualified Data.Conduit.List as Conduit > import qualified Network.Wai as Wai > import qualified Network.HTTP.Conduit as Conduit > import qualified Network.HTTP.Types as HTTP > > wai :: String -> Wai.Application > wai s req@Wai.Request{..} = Conduit.withManager go > where > magic = undefined > go manager = do > request <- liftIO $ Conduit.parseUrl s > Conduit.Response s _ h src <- Conduit.http request manager > return $ Wai.ResponseSource s h (magic src)

1 1

Re: [web-devel] new field for Network.HTTP.Types.Status
by Kazu Yamamoto 29 Aug '12

29 Aug '12

Hello, > I believe unboxing is not possible for ByteString, but it is for the Int > field. I don't really know how much performance gains this brings, not really > a Haskell performance guru. I tried this: data Status = Status { statusCode :: {-# UNPACK #-} !Int , statusAsciiCode :: {-# UNPACK #-} !B.ByteString , statusMessage :: {-# UNPACK #-} !B.ByteString } deriving (Show) Since ByteString has just one constructor, UNPACK for ByteString should work according to GHC manual. This results in 41345.3 req/s while no bangs and no UNPACK results in 43098.6. So, let's not add bangs and UNPACKs. Please merge the current pull request. Thanks in advance. --Kazu

1 0

Re: [web-devel] new field for Network.HTTP.Types.Status
by Kazu Yamamoto 28 Aug '12

28 Aug '12

Hello, > Looks good. Could you please test the performance impact of also making the > fields strict, and of making them strict and unboxed? I think we can make Int unboxed. But what about ByteString? Does the unboxed pragma make ByteString different? --Kazu

1 0