Re: [Haskell-cafe] [web-devel] Automatic error traces
That's great. We should collaborate on this. I wrote the file-location package and Michael Snoyman wrote monad-logger: both of these give file location information. I also added command tracing to Shelly (which could also benefit from this kind of thing) and recently released rollbar for error notification and would like to have as much line info as possible for that. On Tue, Jul 16, 2013 at 5:45 AM, Alberto G. Corona wrote: > It is important to have execution traces in case of error. specially in > server applications that run 24/7 such are web applications > > Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can > generate a complete execution trace in case of error. > > The control-monad-exception uses monadLoc to generate stack traces, but > MFlow makes use of his backtracking mechanism to generate a complete > execution trace. > > Here I explain what and how: > > > http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation-in.html > > The MFlow version that implements this is in gitHub. Not in hackage yet. > > https://github.com/agocorona/MFlow > > I´m quite proud of it since it is one of the things closest to magic that > I have done. > > Feedback? > > I do not want to keep MFlow as a single person development. I think that > it has many unique and nice features not available in other languages and > frameworks, and it can be raised to a serious exploitation level by > the Haskell community. This will attract people working in Industrial Web > development to Haskell thanks to the edge in expressiveness and safety > necessary for creating industrial solutions that Haskell has over other > languages. > > It uses most other Haskell web developments blaze, wai, hamlet etc > and there are many other things to come. > > monadLoc : http://hackage.haskell.org/package/monadloc > > -- > Alberto. > > ___ > web-devel mailing list > web-de...@haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shake, Shelly, & FilePath
Shelly is using system-filepath which was created as an improvement over using a simple String. For a build system in which you name all your files you may not care about the upside. If you want a version of Shelly that uses String you can try Shellish, its predecessor. Otherwise the shim should be written for Shake to use system-filepath. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
so how can I update the documentation? I asked some of the most experienced Haskell users at the Hackathon about this, and looked through any documentation I could find and there was nothing indicating I could do what you sent in your last message. On Sun, Apr 22, 2012 at 8:15 AM, Markus Läll wrote: > The core of it is in the GHC docs' overloaded strings section [1]. > > It could be clearer though -- reading about defaulting in the reports, > in the type defaulting section of GHC docs and in [1] can be a bit > confusing. > > [1] > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings > > On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber wrote: >> Thanks Markus, I think you have saved the day! >> Even after googling for this extension and searching in the manual I >> am still coming up pretty blank. >> Is there somewhere I missed where this is documented or somewhere I >> can contribute documentation? >> >> On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll wrote: >>> ExtendedDefaultRules > > > > -- > Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
Thanks Markus, I think you have saved the day! Even after googling for this extension and searching in the manual I am still coming up pretty blank. Is there somewhere I missed where this is documented or somewhere I can contribute documentation? On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll wrote: > ExtendedDefaultRules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSOC Proposal 2012 : HDBC
Hi Pranjal, We are glad you are interested in the GSoC. Please take a look at persistent: http://www.yesodweb.com/book/persistent It performs queries and serialization based on Haskell records. It also uses native drivers rather than HDBC. I created a proposal outline [1] and there is a student submission for it [2] [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 [2] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 Let me know if you are interested in that or need help coming up with a proposal Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Modest Records Proposal
Obviously Gregory is not familiar with Homotopy. In fact, its
isomorphism predicts that if someone named Greg is involved in a
discussion, someone named Gregory will also become involved.
Or that is what I get for responding to an e-mail without reading it
on April 1st :)
On Sun, Apr 1, 2012 at 7:40 AM, Gregory Collins wrote:
> Whoosh? :-)
>
> On Sun, Apr 1, 2012 at 3:54 PM, Greg Weber wrote:
>>
>> Hi Gershom,
>>
>> This sounds very interesting even if I have no idea what you are
>> talking about :)
>> Please create a proposal linked from this page:
>> http://hackage.haskell.org/trac/ghc/wiki/Records
>> The first thing you should probably do is explain the programmer's
>> point of view. That ensures that we are all going through the
>> requirements phase correctly.
>> I can assure you that haskell prime would not accept a records change
>> until it is first implemented in GHC or another Haskell compiler.
>>
>> Thanks,
>> Greg Weber
>>
>> On Sat, Mar 31, 2012 at 11:14 PM, Gershom B wrote:
>> > The records discussion has been really complicated and confusing. But
>> > I have a suggestion that should provide a great deal of power to
>> > records, while being mostly[1] backwards-compatible with Haskell 2010.
>> > Consider this example:
>> >
>> > data A a = A{a:a, aa::a, aaa :: a -> A (a -> a)}
>> > data B a = B{aaa :: a -> A (a -> a), a :: A}
>> >
>> > Now what is the type of this?
>> >
>> > a a aa = a{a = a, aaa = aa}
>> >
>> > Using standard Haskell typeclasses this is a difficult question to
>> > answer. The types of for A and B do not unify in an obvious way.
>> > However, while they are intensionally quite distinct, they unify
>> > trivially extensionally. The obvious thing to do is then to extend the
>> > type system with extensional equality on record functions.
>> >
>> > Back when Haskell was invented, extensional equality was thought to be
>> > hard. But purity was thought to be hard too, and so were Monads. Now,
>> > we know that function existentionality is easy. In fact, if we add the
>> > Univalence Axiom to GHC[2], then this is enough to get function
>> > existensionality. This is a well-known result of Homotopy Type
>> > Theory[3], which is a well-explored approach that has existed for at
>> > least a few years and produced more than one paper[4]. Homotopy Type
>> > Theory is so sound and well understood that it has even been
>> > formalized in Coq.
>> >
>> > Once we extend GHC with homotopies, it turns out that records reduce
>> > to mere syntactic sugar, and there is a natural proof of their
>> > soundness (Appendix A). Furthermore, there is a canonical projection
>> > for any group of fields (Appendix B). Even better, we can make "."
>> > into the identity path operator, unifying its uses in composition and
>> > projection. In fact, with extended (parenthesis-free) section rules,
>> > "." can also be used to terminate expressions, making Haskell friendly
>> > not only to programmers coming from Java, but also to those coming
>> > from Prolog!
>> >
>> > After some initial feedback, I'm going to create a page for the
>> > Homotopy Extensional Records Proposal (HERP) on trac. There are really
>> > only a few remaining questions. 1) Having introduced homotopies, why
>> > not go all the way and introduce dependent records? In fact, are HERP
>> > and Dependent Extensional Records Proposal (DERP) already isomorphic?
>> > My suspicion is that HERP is isomorphic, but DERP is not. However, I
>> > can only get away with my proof using Scott-free semantics. 2) Which
>> > trac should I post this too? Given how well understood homotopy type
>> > theory is, I'm tempted to bypass GHC entirely and propose this for
>> > haskell-prime. 3) What syntax should we use to represent homotopies?
>> > See extend discussion in Appendix C.
>> >
>> > HTH HAND,
>> > Gershom
>> >
>> > [1] To be precise, 100% of Haskell 2010 programs should, usually, be
>> > able to be rewritten to work with this proposal with a minimal set of
>> > changes[1a].
>> >
>> > [1a] A minimal set of changes is defined as the smallest set of
>> > changes necessary to make to a Haskell 2010 program such that it works
>> > with this proposal. We can arrive at these changes by the following
>> > procedure: 1) Pick a change[1
Re: [Haskell-cafe] A Modest Records Proposal
Hi Gershom,
This sounds very interesting even if I have no idea what you are
talking about :)
Please create a proposal linked from this page:
http://hackage.haskell.org/trac/ghc/wiki/Records
The first thing you should probably do is explain the programmer's
point of view. That ensures that we are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B wrote:
> The records discussion has been really complicated and confusing. But
> I have a suggestion that should provide a great deal of power to
> records, while being mostly[1] backwards-compatible with Haskell 2010.
> Consider this example:
>
> data A a = A{a:a, aa::a, aaa :: a -> A (a -> a)}
> data B a = B{aaa :: a -> A (a -> a), a :: A}
>
> Now what is the type of this?
>
> a a aa = a{a = a, aaa = aa}
>
> Using standard Haskell typeclasses this is a difficult question to
> answer. The types of for A and B do not unify in an obvious way.
> However, while they are intensionally quite distinct, they unify
> trivially extensionally. The obvious thing to do is then to extend the
> type system with extensional equality on record functions.
>
> Back when Haskell was invented, extensional equality was thought to be
> hard. But purity was thought to be hard too, and so were Monads. Now,
> we know that function existentionality is easy. In fact, if we add the
> Univalence Axiom to GHC[2], then this is enough to get function
> existensionality. This is a well-known result of Homotopy Type
> Theory[3], which is a well-explored approach that has existed for at
> least a few years and produced more than one paper[4]. Homotopy Type
> Theory is so sound and well understood that it has even been
> formalized in Coq.
>
> Once we extend GHC with homotopies, it turns out that records reduce
> to mere syntactic sugar, and there is a natural proof of their
> soundness (Appendix A). Furthermore, there is a canonical projection
> for any group of fields (Appendix B). Even better, we can make "."
> into the identity path operator, unifying its uses in composition and
> projection. In fact, with extended (parenthesis-free) section rules,
> "." can also be used to terminate expressions, making Haskell friendly
> not only to programmers coming from Java, but also to those coming
> from Prolog!
>
> After some initial feedback, I'm going to create a page for the
> Homotopy Extensional Records Proposal (HERP) on trac. There are really
> only a few remaining questions. 1) Having introduced homotopies, why
> not go all the way and introduce dependent records? In fact, are HERP
> and Dependent Extensional Records Proposal (DERP) already isomorphic?
> My suspicion is that HERP is isomorphic, but DERP is not. However, I
> can only get away with my proof using Scott-free semantics. 2) Which
> trac should I post this too? Given how well understood homotopy type
> theory is, I'm tempted to bypass GHC entirely and propose this for
> haskell-prime. 3) What syntax should we use to represent homotopies?
> See extend discussion in Appendix C.
>
> HTH HAND,
> Gershom
>
> [1] To be precise, 100% of Haskell 2010 programs should, usually, be
> able to be rewritten to work with this proposal with a minimal set of
> changes[1a].
>
> [1a] A minimal set of changes is defined as the smallest set of
> changes necessary to make to a Haskell 2010 program such that it works
> with this proposal. We can arrive at these changes by the following
> procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
> are we done? If not, make another change.
>
> [1b] To do this constructively, we need an order. I suggest the lo
> mein, since noodles give rise to a free soda.
>
> [2] I haven't looked at the source, but I would suggest putting it in
> the file Axioms.hs.
>
> [3] http://homotopytypetheory.org/
>
> [4] http://arxiv.org/
>
>
> *Appendix A: A Natural Proof of the Soundness of HERP
>
> Take the category of all types in HERP, with functions as morphisms.
> Call it C. Take the category of all sound expressions in HERP, with
> functions as morphisms. Call it D. Define a full functor from C to D.
> Call it F. Define a faithful functor on C and D. Call it G. Draw the
> following diagram.
>
> F(X)F(Y)
> | |
> | |
> | |
> G(X)G(Y)
>
> Define the arrows such that everything commutes.
>
>
> *Appendix B: Construction of a Canonical Projection for Any Group of Fields.
>
> 1) Take the fields along the homotopy to an n-ball
[Haskell-cafe] good lightweight web-framework like sinatra?
WAI has CGI handlers, so you should be able to deploy a WAI-based framework like Yesod to CGI. If you want a simple framework, you can just use WAI directly. Scotty is a WAI framework that mimics Sinatra. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena wrote: > I agree with you that maybe this proposal is vague for a GSoC, but I don't > think that websockets is a good option either, because not all browsers > support them. We already have a websockets library, but like you say it is not very useful by itself because it may not be supported in all browsers. The GSoC proposal is to create a library that will use appropriate fallbacks on all browsers, which is how websockets are normally used. > > > 2012/3/7 Greg Weber >> >> This is obviously a great concept. However, it may not be appropriate >> for a GSoC. The design space is far too open, and it is not clear if >> anything in that space will end up beating plain old javascript. >> >> I think my proposal for an awesome websockets library [1] shows that >> this is putting the cart before the horse. For some of the potential >> javascript solutions, websockets is a dependency anyways. Without >> being able to hold open a connection to the server, required server >> interaction will be too slow. >> Yesod has been successful by explicitly avoiding any new radical >> paradigms, but by instead just trying to get the basics of web >> development established correctly. Without websockets, we don't have >> the basics down for fluid client-side interaction. >> The groundwork for this ticket has been laid: it should be easy to >> accomplish with time left over. >> So we are guaranteed a clear win for the community. With the time left >> over, a solution to the javascript problem can be attempted. But there >> is no burden for it to be solved within the summer. Next year the >> landscape will be more mature and we can try to come up with a solid >> proposal for the javscript problem if the community hasn't already >> created a solution. >> >> [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
Hi Deian, Thanks for bringing this to our attention - this is a neat project! It actually looks *exactly* like persistent - I can't actually discern a meaningful difference, although likely your internals are slightly simpler if you only support MongoDB. If your goals are to support multiple backends then it seems your goals are *exactly* the same as Persistent. Lets collaborate on this off of the mail list. The url listed on hackage for the git repo points to Stanford, not github. Greg Weber On Tue, Feb 14, 2012 at 11:17 AM, Deian Stefan wrote: > On Mon, Feb 13, 2012 at 11:52, Greg Weber wrote: >> That being said, I would like to have a Template Haskell interface >> instead of just a QQ interface. The reason why we haven't bothered >> with doing that ourselves is because the record name-spacing issue >> makes the current QQ interface much more convenient. I am actively >> working to solve the namespace issue. This all brings up a great point >> though: as part of the GSoC we should create a Template Haskell >> interface (similar to acid-state as you mention). Given the structure >> of things that Michael has already pointed out, and that we are >> already using Template Haskell with the DSL, this should only be a few >> day's work. > > I'm joining this thread slightly late, but thought I point to a > similar TH approach: > > http://hackage.haskell.org/package/structured-mongoDB > > The implementation is very much MongoDB-specific, but we're working on > targeting different backends (package is on github, so we welcome other > hackers). Of course, some of the issues that have been > brought up (e.g., no support for projection) still exist in > structured-mongoDB, but our goals have been more relaxed: > 1) provide a type-safe interface to MongoDB, 2) to avoid QQ DSL > approach if possible, and 3) support a HaskellDB-like query interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How do I get official feedback (ratings) on my GSoC proposal?
http://hackage.haskell.org/trac/summer-of-code/report/1 There is a column 'Priority'. And there are now several unrated proposals. On Mon, Feb 13, 2012 at 3:40 PM, Johan Tibell wrote: > On Mon, Feb 13, 2012 at 3:20 PM, Greg Weber wrote: >> >> Other than changing the status myself, how do I get a priority >> attached to my GSoC proposal? > > > What priorities are you referring to? > > -- Johan > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How do I get official feedback (ratings) on my GSoC proposal?
Other than changing the status myself, how do I get a priority attached to my GSoC proposal? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
>> This proposal is vague and we would need to work with you to narrow >> things down a bit. > > Yes, that would be cool :-) Since I'm not familiar with Persistence at > all (unfortunately :-( ), do you have some suggestions for me to start > with? > > I've found this http://www.yesodweb.com/book/persistent and I'm going > to get familiar with it in the first place. I hope it won't take me > much longer than a couple days. That is definitely the best place to start. If you want to look at more example usage code you can look at the test suite in the persistent-test folder of the repository. Perhaps you have a Haskell program that could benefit from persisting data (and maybe already does in a flat file) and you could try integrating Persistent with it. > I am rather far away from Web programming, so, unfortunately, I am not > sure whether it would be relevant if I volunteered to contribute to > Yesod directly. In my perspective, there are possibilities for a > non-Web programmer to contribute to Yesod, though, so, if I am not too > much off with my perspectives, I'll be glad to work on Yesod as well. I also opened up a GSoC ticket for making Haskell ready for the "real-time" web. This is also another somewhat self-contained project that does not really require web development experience. More and more programs would like to have a web interface or at least speak some HTTP at some point. Most web programmers don't have a great understanding of the internals of web development that they are abstracted from. I wouldn't shy away from something web related because you are afraid you won't be able to hack it. The only problem would be that you might not be able to judge the project well before starting the project. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
ith you to > Greg> narrow things down a bit. > > Greg> I am biased, but I believe the Yesod project is one of the most > Greg> compelling in the Haskell ecosystem. There are a lot of different ways > Greg> a GSoC project could help make things even better besides improving > Greg> the associated Persistent library, and we would really like to mentor > Greg> at least one GSoC student. I would open more tickets for this in the > Greg> system, but I am not sure how helpful it will be. It seems that we > Greg> need to reach out to more students like yourself, but I am not sure > Greg> how to do that unless I see messages like these first. > > Greg> Greg Weber > > -- > Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subject: A universal data store interface
Persistent is a database abstraction layer with no dependencies on Yesod. Those that need a persistence layer have the same needs to interface with the database in a type-safe way, regardless of whether their program presents a web interface. Have you tried using Persistent? We have never heard a report from a user that the Persistent DSL schema syntax is confusing. These complaints always seem to be from someone that hasn't actually tried it but is adverse to quasi-quoting. The DSL is basically the exact same as Haskell record syntax. I am not sure who the mythical users are that can figure out Haskell but can't understand dead-simple DSL's. That being said, I would like to have a Template Haskell interface instead of just a QQ interface. The reason why we haven't bothered with doing that ourselves is because the record name-spacing issue makes the current QQ interface much more convenient. I am actively working to solve the namespace issue. This all brings up a great point though: as part of the GSoC we should create a Template Haskell interface (similar to acid-state as you mention). Given the structure of things that Michael has already pointed out, and that we are already using Template Haskell with the DSL, this should only be a few day's work. On Mon, Feb 13, 2012 at 11:40 AM, Tom Murphy wrote: > It seems that all tutorials and resources for Persistent use Template > Haskell along with several Yesod specifics. > > But, I could be wrong, or new tutorials could be written. > > Tom > > On 2/13/12, Michael Snoyman wrote: >> Actually, Persistent is fully usable without any special syntax, DSLs, >> or Template Haskell. In fact, Persistent itself has no >> template-haskell dependencies, specifically so that it can be built on >> ghc-iphone. Additionally, the Persistent DSL syntax is completely >> separate from any other Yesod DSL syntaxes that exist, so it's not >> like you have to learn five new things to get the automatic code >> generation. >> >> On Mon, Feb 13, 2012 at 9:30 PM, Tom Murphy wrote: >>> With respect, I don't think that Persistent is a natural choice >>> as the go-to tool for Haskell users, simply because it requires >>> knowledge of a lot of Yesod-EDSL syntax. >>> The set of users with persistent data needs seems a very >>> different set than that of those who are familiar with Yesod, and I >>> think the syntax is quite confusing without fuller understanding of >>> Yesod. >>> >>> The syntax of acid-state (not familiar with this one), and >>> swapper (https://github.com/roman-smrz/swapper/blob/master/test/) seem >>> to have a much more linear learning curve for an intermediate Haskell >>> user. >>> >>> amindfv / Tom >>> >>> On 2/13/12, Greg Weber wrote: >>>> Hi Sergiu, >>>> >>>> Thanks you for your interest in that proposal. I rushed it off a year >>>> ago. Since then we have made a lot of improvements to Persistent and >>>> the library forms a basic building block for most Yesod users and >>>> other Haskellers. Persistent offers a level of type-safety and >>>> convenience not available elsewhere (except perhaps for libraries like >>>> acid-state that are limited to in-memory storage). That being said, >>>> there are still a lot of improvements that could be made. With the >>>> effort of a GSoC volunteer we could probably get it to the point of >>>> being the go-to data storage library for Haskellers, at least those >>>> planning on using the subset of backends (likely SQL) with great >>>> support. This proposal is vague and we would need to work with you to >>>> narrow things down a bit. >>>> >>>> I am biased, but I believe the Yesod project is one of the most >>>> compelling in the Haskell ecosystem. There are a lot of different ways >>>> a GSoC project could help make things even better besides improving >>>> the associated Persistent library, and we would really like to mentor >>>> at least one GSoC student. I would open more tickets for this in the >>>> system, but I am not sure how helpful it will be. It seems that we >>>> need to reach out to more students like yourself, but I am not sure >>>> how to do that unless I see messages like these first. >>>> >>>> Greg Weber >>>> >>>> ___ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subject: A universal data store interface
Hi Sergiu, Thanks you for your interest in that proposal. I rushed it off a year ago. Since then we have made a lot of improvements to Persistent and the library forms a basic building block for most Yesod users and other Haskellers. Persistent offers a level of type-safety and convenience not available elsewhere (except perhaps for libraries like acid-state that are limited to in-memory storage). That being said, there are still a lot of improvements that could be made. With the effort of a GSoC volunteer we could probably get it to the point of being the go-to data storage library for Haskellers, at least those planning on using the subset of backends (likely SQL) with great support. This proposal is vague and we would need to work with you to narrow things down a bit. I am biased, but I believe the Yesod project is one of the most compelling in the Haskell ecosystem. There are a lot of different ways a GSoC project could help make things even better besides improving the associated Persistent library, and we would really like to mentor at least one GSoC student. I would open more tickets for this in the system, but I am not sure how helpful it will be. It seems that we need to reach out to more students like yourself, but I am not sure how to do that unless I see messages like these first. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name
Hi guys, There is an effort underway to make Haskell's Records better. The discussion is ongoing on the ghc-users mail list, feel free to join, or at least read on gmane. The wiki pages are up to date. Please note that we are moving in the direction of making the most minimal changes possible to achieve some simple record name-spacing. Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
great! I am wondering if you can provide even higher-level APIs for the common case: hash <- runResourceT $ hashFile "my-file" and possibly something that runs the ResourceT transformer: hash <- runHashFile "my-file" On Sat, Jan 7, 2012 at 12:16 AM, Felipe Almeida Lessa < felipe.le...@gmail.com> wrote: > Hello! > > I'm pleased to announce the first release of crypto-conduit [1]! The > crypto-api [2] package provides APIs for many cryptographic > operations, such as cryptographic hashes and block ciphers. This new > crypto-conduit package allows you to use many of these operations with > conduits [3], giving you safe I/O using constant memory and no leaks. > > As an example, here's how you could get the SHA1 hash a file: > > import Crypto.Conduit -- from crypto-conduit > import Crypto.Hash.SHA1 (SHA1) -- from cryptohash > import Data.Conduit -- from conduit > import Data.Conduit.Binary (sourceFile) -- from conduit > > main = do >hash <- runResourceT $ sourceFile "my-file" $$ sinkHash >print (hash :: SHA1) > > The code snippet above, despite having only "sourceFile ... $$ > sinkHash" on its core, guarantees that the file handle is not kept > open and uses a constant amount of memory. Sweet! > > Please break this package! Although it comes with a test suite, it > has just seen the light of the day. > > Cheers, =) > > [1] http://hackage.haskell.org/package/crypto-conduit > [2] http://hackage.haskell.org/package/crypto-api > [3] http://hackage.haskell.org/package/conduit > > -- > Felipe. > > ___ > web-devel mailing list > web-de...@haskell.org > http://www.haskell.org/mailman/listinfo/web-devel > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking
yes it worked after your updates shortly after this. Thank you very much for checking up, and also for continuing to develop this - I may be able to replace xournal with it now. On Tue, Dec 27, 2011 at 10:03 AM, Ian-Woo Kim wrote: > Hi, Greg, > > Sorry that I just missed to read your reply. > Since hxournal has a configuration file to specify input device and > also is activated on the toggle menu item "Use X Input," you should be > able to experiment pen drawing now. > > Did you succeed in using the latest version of hxournal? > I appreciate your report. > > Thanks very much. > > best, > Ian-Woo > > On Tue, Dec 13, 2011 at 5:22 AM, Greg Weber wrote: > > I got the program installed after creating the libstdc++.so symlink. > > No ink shows up from my drawing though. I am on a Thinkpad X201 Tablet > and > > xournal works. > > > > I am glad you are experimenting with window splits. I think the worst > part > > of xournal is it constrains you to a notebook-width piece of paper. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking
I got the program installed after creating the libstdc++.so symlink. No ink shows up from my drawing though. I am on a Thinkpad X201 Tablet and xournal works. I am glad you are experimenting with window splits. I think the worst part of xournal is it constrains you to a notebook-width piece of paper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get a file path to the program invoked?
In addition to argv[0] http://hackage.haskell.org/packages/archive/system-argv0/0.1/doc/html/System-Argv0.html There is also this package: http://hackage.haskell.org/packages/archive/FindBin/0.0.5/doc/html/System-Environment-FindBin.html System-Argv0 has special cases for windows- FindBin may not work there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Chell: A quiet test runner (low-output alternative to test-framework)
I am confused also, as to both what output you don't like that motivated chell and what exactly hspec silences :) Suffice to say I am able to get a small relevant error message on failure with hspec. I am adding the hspec maintainer to this e-mail- he can answer any of your questions. On Thu, Aug 11, 2011 at 8:03 AM, John Millikin wrote: > On Thu, Aug 11, 2011 at 07:52, Greg Weber wrote: > > It silences HUnit's output, but will tell you what happens when there is > a > > failure- which I think is what you want. There are a few available output > > formatters if you don't like the default output, or you can write your > own > > output formatter. > > I'm a bit confused. From what I can tell, HUnit does not output > *anything* just from running a test -- the result has to be printed > manually. What are you silencing? > > > BDD is really a red herring. Instead of using function names to name > tests > > you can use strings, which are inherently more descriptive. In chell you > > already have `assertions "numbers"`, in hspec it would be `it "numbers"`. > > The preferred style it to remove `test test_Numbers and the test_Numbers > > definition` which are redundant in this case, and instead place that > inline > > where you define the suite, although that is optional. > > So I really can't tell any difference betwee "BDD" and "pass/fail > > assertions". You still just use assertions in hspec. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Chell: A quiet test runner (low-output alternative to test-framework)
It silences HUnit's output, but will tell you what happens when there is a failure- which I think is what you want. There are a few available output formatters if you don't like the default output, or you can write your own output formatter. BDD is really a red herring. Instead of using function names to name tests you can use strings, which are inherently more descriptive. In chell you already have `assertions "numbers"`, in hspec it would be `it "numbers"`. The preferred style it to remove `test test_Numbers and the test_Numbers definition` which are redundant in this case, and instead place that inline where you define the suite, although that is optional. So I really can't tell any difference betwee "BDD" and "pass/fail assertions". You still just use assertions in hspec. On Thu, Aug 11, 2011 at 7:36 AM, John Millikin wrote: > I have, but it's not quite what I'm looking for: > > - I don't want to silence HUnit's output, I just don't want anything > to show on the console when a test *passes*. Showing output on a > failure is good. > > - I'm not interested in BDD. Not to say it's not useful, but it > doesn't match my style of testing (which uses mostly pass/fail > assertions and properties). > > On Thu, Aug 11, 2011 at 07:18, Greg Weber wrote: > > Hi John, > > I am wondering if you have seen the hspec package? [1] It seems to solve > all > > the problems you are with chell, including that it silences Hunit output. > We > > are using it for all the Yesod tests now. > > Thanks, > > Greg Weber > > [1]: > http://hackage.haskell.org/packages/archive/hspec/0.6.1/doc/html/Test-Hspec.html > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Chell: A quiet test runner (low-output alternative to test-framework)
Hi John, I am wondering if you have seen the hspec package? [1] It seems to solve all the problems you are with chell, including that it silences Hunit output. We are using it for all the Yesod tests now. Thanks, Greg Weber [1]: http://hackage.haskell.org/packages/archive/hspec/0.6.1/doc/html/Test-Hspec.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: file-location 0.2.4
I realized I should have made a bigger version bump: Announcing version
0.3.0
http://hackage.haskell.org/package/file-location
On Wed, Aug 10, 2011 at 5:53 PM, Greg Weber wrote:
> Were you excited when Simon Marlow announced he might be able to add stack
> traces to Haskell? Would you settle for just the first line of the stack
> trace? It is a little known fact that template haskell exposes the file and
> line number information.
>
> file-location contains common debugging/error/exception functions and
> template haskell versions that give file location information.
>
> > $(err "OH NO!")
> main:Main main.hs:16:1 OH NO!
>
> > debug [1,2,3]
> DEBUG: [1,2,3]
> [1,2,3]
>
> > $(dbg) [1,2,3]
> DEBUG main:Main main.hs:1:3 [1,2,3]
> [1,2,3]
>
> ($(thrwIO) AException) `catch` \e -> putStrLn ("Caught " ++ show (e ::
> AException))
> Caught AException "main:Main test/main.hs:25:6"
>
>
> Don't like the exception dependency? Use version 0.2.3 for now until the
> exceptions are split into a separate package.
> Just want the debug helpers (like the debug function) but not interested in
> the template haskell? The library is already split into modules based on
> dependencies. The near future plan is to separate this into separate
> packages, including one with the non-TH debug helpers.
>
> Also see the github README for more examples:
> https://github.com/gregwebs/FileLocation.hs
>
> I think haskell could use a few more debug helpers. Perhaps some of these
> could be pushed back into the standard distribution.
>
> Thanks, and I am looking forward to your feedback,
> Greg Weber
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: file-location 0.2.4
Were you excited when Simon Marlow announced he might be able to add stack
traces to Haskell? Would you settle for just the first line of the stack
trace? It is a little known fact that template haskell exposes the file and
line number information.
file-location contains common debugging/error/exception functions and
template haskell versions that give file location information.
> $(err "OH NO!")
main:Main main.hs:16:1 OH NO!
> debug [1,2,3]
DEBUG: [1,2,3]
[1,2,3]
> $(dbg) [1,2,3]
DEBUG main:Main main.hs:1:3 [1,2,3]
[1,2,3]
($(thrwIO) AException) `catch` \e -> putStrLn ("Caught " ++ show (e ::
AException))
Caught AException "main:Main test/main.hs:25:6"
Don't like the exception dependency? Use version 0.2.3 for now until the
exceptions are split into a separate package.
Just want the debug helpers (like the debug function) but not interested in
the template haskell? The library is already split into modules based on
dependencies. The near future plan is to separate this into separate
packages, including one with the non-TH debug helpers.
Also see the github README for more examples:
https://github.com/gregwebs/FileLocation.hs
I think haskell could use a few more debug helpers. Perhaps some of these
could be pushed back into the standard distribution.
Thanks, and I am looking forward to your feedback,
Greg Weber
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Github support for cabal files
I think the haddock description field is a great barrior to documentation. I don't want to clutter my cabal file with lengthy documentation. Michael Snoyberg and I could not figure out how to document the Hamlet syntax because there is no way (as far as I know) to have literal unescaped, uninterpreted text. [1] When I go to a github repo, I expect that I can scroll down to the README and I will get a good overview. When I go to hackage, I expect nothing more than a synopsis, and I hope I can follow several links to find the information I am looking for. It is suggested that the description field should point to a top level module with all the documentation, but although haddock is good for documenting code, it is not an ideal overview style, and not all packages lend themselves well to having one top-level module. I would like a description field that just points to an external (README) file. Cabal could either use the pandoc library, or to avoid that dependency directly it could use the pandoc executable (that would have to be installed first by those of us that want this feature). Alternatively it could just allow an html file for the description and make me responsible for writing a script that runs pandoc and then invokes sdist. [1] http://hackage.haskell.org/package/hamlet ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and Databases
Hi Tobias, Have you seen DSH [1]? You might also be interested in Persistent [2], but it sounds like it has different goals than what you are after. [1] http://hackage.haskell.org/package/DSH [2] http://www.yesodweb.com/book/persistent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskellwiki slow/unresponsive
> > Those are definitely valid concerns. Has anyone made a wiki-like site with > Yesod? I hadn't heard of Yesod until I joined this mailing list, but I've > seen quite a bit of buzz around it since then. If a large enough chunk of > the community is backing a framework and focusing on making it secure and > reliable, then it should be possible to build applications with it (wikis, > blogs, etc.) that draw on the framework's strength and security. You may > still have security issues, but if they're continually addressed and > maintained at the framework level it benefits everyone building > applications > on top of that framework. I'm still relatively new to the Haskell > community > so I apologize if much of this has been addressed before! It is dead-simple to deploy a fast haskell web app, so haskell *might* have a chance at solving the problem, but likely it can be fixed much faster by doing a better job configuring the server or adding more resources. I think that security issues are a bit of a red herring. You can go through potential security issues one-by-one and basically make them impossible in a web/wiki framework (as we are doing in Yesod). Of course this is easier to do with a type system in Haskell. And of course some security is outside the scope of the software and needs to be established by procedure (admin server access should only be through ssh key, etc). Gitit uses darcs or git to store data, but through the command line interfaces. Unfortunately to my knowledge darcs does not expose a library interface. Gitit could be made faster and more secure by interfacing with libgit2. Even though it is may not be socially acceptable to state it, it is likely that gitit or any haskell library would be more secure in practice because it is more obscure. And the kind of security we really care about in the wiki- the wiki page content- can be easily replicated and restored. I definitely agree that the hard and boring part of switching to a haskell wiki is converting existing MediaWiki content and configuration to a new system- that would have to be investigated first. Unfortunately this is probably all bike-shedding and my original question of how can the community speed up the wiki hasn't been answered :) Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskellwiki slow/unresponsive
I have been trying to make a few edits to the haskell wiki and find it an excruciating process when I press save and then have to wait a long time to see if the save will go through. I just clicked on the introduction page and it may have took an entire minute to load. Can we put at the top: this wiki written in php, not haskell! Seriously though, the wiki has performed poorly for a long time now. It gives a bad impression to newcomers and deters contributions. Can I (and others!) donate money so someone can make the wiki responsive? Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Light and fast http server
> > snap or warp/yesod. maybe in a few years we will have a winner for the platform... > --dons > On Friday, March 11, 2011, Vo Minh Thu wrote: > 2011/3/11 Victor Oliveira : >> Hi cafe, >> >> There are a lot of http servers in hackage. I didn't have used none. >> I would like to know if one of them is something closer of the nginx. >> I need some light and fast. It don't need support all http, just the > basics is fine. >> Suggestions? > > Snap and Warp come to mind. Have a look at this reddit thread: > > http://www.reddit.com/r/programming/comments/flpao/the_haskell_high_performance_server_shootout/ > > Cheers, > Thu To be clear, Yesod and Snap are web frameworks. If you want just a web server, then your main options are snap-server or Warp as has been pointed out. The happstack framework also has a server, but they are planning on switching it out in the future. As for speed, warp is at least twice as fast as snap-server. As for lightness- * snap-server and Warp support a similar feature set, with some differences that might be important, depending on your needs. * Warp has a much smaller code base * lightness may be a perception of how you interface with the server. I don't know how you would interface with snap-server except through the Snap framework. Warp can be used with Yesod, but runs on the WAI interface. The WAI inteface allows you to change your mind and deploy to a different server in the future. Hopefully it will also allow you to use different frameworks in the future, although this is not the case yet. But just as important, it is also designed to support easy and re-usable low-level web programming. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal dependency on code repositories.
On Sun, Dec 19, 2010 at 5:01 PM, Duncan Coutts wrote: > On 19 December 2010 17:44, Greg Weber wrote: > > Michael Snoyman and I were discussing the need for beta releases of Yesod > > and he encourage me to post this to the cafe. Beta releases could be > built > > into the hackage system. However, this can be viewed as a more general > > problem of distributing multiple versions of code (stable vs. > experimental, > > forks, etc). This is a problem that has been largely solved by version > > control, but in this instance just needs some integration with an > installer > > system. > > The first system I want to add is to allow cabal-install to install > from tarballs identified by a URL, e.g. > > cabal install http://example.org/~me/foo-1.0.tar.gz > > > As you know, .cabal files can specify source repos so in principle one > could write a tool to install from a source repo. In practice there > are a number of things to solve involving how you manage local caches > of remote repos etc. The easiest thing to get working first is > installing from tarball URLs, but I would welcome patches for the > source repo feature, in particular a specific plan for how users > interact with the system. > > Duncan > Being able to install a tarball is a great first step and would provide a mechanism for taking care of some of the use cases. In terms of specific user interaction plans for installing from a repo, I would point again to ruby's Bundler as a starting point. Basically instead of putting in a version number constraint one can put in a git url. That url points to a repo with a gemspec (.cabal file) which has the version number. It is important to note that Bundler operates and a project-focused manner. Bundler also creates a file 'Gemfile.lock' which lists every package being used for the project and its exact version. This helps when working in a team or deploying- by checking in this file one can ensure that everyone else (and the production server) is using the *exact* same versions of packages. For library development it is not recommended to check in the lock file. Changing the Gemfile (cabal file) and installing (cabal configure) will update the lock file. This functionality is similar to the tool capri in some ways, but instead of having a project private package set it just has a lockfile that specifies exact versions. I think haskell may require a project private repo because it compiles packages instead of interpreting them. For a project private package set in Ruby there is a tool called RVM which has a feature called 'gemsets'. The main purpose of RVM though, is actually to be able to easily switch between multiple versions of Ruby (and it does this amazingly well by operating at the shell level). I am rambling now, but the end user interaction is essentially just editing the Cabal file with the proper git url and re-compiling. The releaser does not have to do anything either- they don't even have to change the version number in the cabal file. Ruby Gems and Bundler use the git hash of the repo as the version number. However, Bundler still knows the package version number for dependency resolution. Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal dependency on code repositories.
Michael Snoyman and I were discussing the need for beta releases of Yesod and he encourage me to post this to the cafe. Beta releases could be built into the hackage system. However, this can be viewed as a more general problem of distributing multiple versions of code (stable vs. experimental, forks, etc). This is a problem that has been largely solved by version control, but in this instance just needs some integration with an installer system. In the ruby world there is a tool called bundler that is now the standard installer- basically bundler combined with rubygems it is like cabal combined with hackage. In addition to referencing a published library version, with bundler one can reference a git repository, and even reference a particular branch or revision. Essentially with beta releases you are trying to release multiple branches of your repository. This is also very useful for dealing with multiple forks of a package. If I have problems with a package I can look at the github repo and look for forks with bug fixes, and then point the Gemfile (cabal file) to that repo. The repo must have a gemspec (cabal file). Essentially this removes the step of the code writer of needing to edit the cabal file or publish to hackage. This is good because many code writers do not want to publish their minor variations of packages on hackage or do not want to publish new packages that they feel are of low quality. This is also good from the perspective of the code user- I normally don't want to see minor variations on hackage. If I am interested in minor variations I will go to the github repo and look at the different branches and forks where it will be clear to me what the difference is- it would be difficult to accurately portray this information on hackage. Productivity in modern programming is largely about code re-use, and I only see this as becoming more important. Type safety and Cabal do a great job facilitating code re-use. I think we can make cabal even more useful here. Has this ability been discussed before for cabal? t would be great if it could at least be worked on for the next Google Summer of Code. Sorry if I offended anyone by exclusively mentioning git, but that is the only version control system used by Rubyists :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
