Re: [Haskell-cafe] GSoC proposal: Units for GHC
This sounds pretty cool and useful. How much of this can be implemented in a library and how much of this would need to be supported on a compiler level? Ideally, most of this would be solved on the library level. Jurriën On 4 Apr 2012, at 13:38, Nils Schweinsberg wrote: Hi Haskell-Cafe GHC-users! I'm looking to apply for the GSoC and since I've worked on GHC before I'd like to continue to do so. My proposal would be something that tempted me (as a physics student) for a while: Units for Haskell/GHC. This project has been suggested for a long time on the GHC wiki, and there is already a lot of work done for other languages like ML, F# etc[1]. I have tried to implement e.g. the unification algorithm from the Types for Units-of-Measure in F# talk[2] for an abstract syntax tree[3] and it was pretty much straight forward. As I see it, the project would consist of: 1.) Find appropriate rules/algorithms for unit analysis. Most (if not all?) of this should be covered in those papers/talks on [1]. 2.) Applying the rules to the Haskell syntax tree used in GHC. I have approximately 3 years of experience with Haskell, I worked for the database research group[4] at the University of Tübingen (Germany) on the Database Supported Haskell[5] library. I've done most of the coding for the monad comprehension[6] extension, which has been added to the latest GHC release version. I'm already quite familiar with the GHC internals of the compiler/typechecker, and even though I'd have to look up how exactly type interference etc. works in GHC (as I've only *used* it, but never tried to understand/modify it) I'm confident that the work on GHC itself should be doable in the given timeframe. So my questions would be: Do you think this is a appropriate GSoC project? What should I include in the application/project proposal? Anything else? Opinions, suggestions? I realize that I'm kind of late and probably should have written this email a long time ago. But there are still 2 days left for the student application and hopefully I'll get some good feedback by then. - Nils [1]: http://research.microsoft.com/en-us/um/people/akenn/units/index.html [2]: http://research.microsoft.com/en-us/um/people/akenn/units/MLWorkshop2008.pdf [3]: https://github.com/mcmaniac/units/blob/master/src/Unification.hs [4]: http://db.inf.uni-tuebingen.de/team [5]: http://hackage.haskell.org/package/DSH [6]: http://db.inf.uni-tuebingen.de/files/giorgidze/haskell2011.pdf ___ 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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
The link I mentioned in my previous email contains pretty much all of the currently available public information about the UHC JS backend (the Improving the UHC JavaScript Backend report is already slightly outdated, due to an API change, though). My report also contains some ideas for future work where this idea is also briefly mentioned. In addition to that, I have a yet unpublished paper that is very relevant to the UHC JS backend, but I don't think I can make that public yet, hence the contact me part :) Also, I have added it to the project list: http://hackage.haskell.org/trac/summer-of-code/ticket/1610 Jurriën On 11 Mar 2012, at 11:55, Alejandro Serrano Mena wrote: That sound like a really cool project. Where could I get more information about what could I do? You mention about contacting but I think it's better to keep the discussion open for everybody. Alejandro 2012/3/11 Jurriën Stutterheim j.stutterh...@me.com While I might be a bit biased (I spent a good deal of time working on improving the UHC JS backend), I think there are a lot of opportunities to get Haskell as a client-side language via the UHC, as Heinrich suggested. Alessandro Vermeulen recently wrote an entire front-end application using the UHC JS backend, so we know that it's capable of producing working front-end applications. See also[1]. Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. This would go a long way to make the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, you will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. You would also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, you will only need one cabal file for an entire web application; for both the front-end and backend. I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. Jurriën [1] http://uu-computerscience.github.com/uhc-js/ On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: Chris Smith wrote: My first impression on this is that it seems a little vague, but possibly promising. My impression is also that this project proposal is rather vague. The general goal Haskell as client-side language for websites is clear and worthwhile, but I can't tell from the proposal whether the project will succeed or not, or, more importantly, *what* it will succeed at. The way I see it is that a successful GSoC proposal has to embody four key points: 1. One specific goal - I want to compile Haskell to JS via UHC's backend 2. in a larger context - as a step towards Haskell as a client-side language for websites. 3. that is accompanied by a successful example - To demonstrate that this works, I will write a small Asteroids game with HTML5 and Haskell 4. and that others can build upon - Moreover, I want to make it really easy for others to use the Haskell-JS compilation from cabal. The last point is extremely important: you don't want to build a hobbled prototype that languishes in a dark corner of github, you want to build a great software that changes the world by solving an important problem and making this solution really easy to use! Alejandro, your proposal mentions several different specific goals, each of which can be the basis for a successful GSoC project: * Make UHC's Haskell-JS compilation easy to use. * Design combinators for DOM manipulation in functional style, f.i. zippers. Note that this goal does *not* involve running Haskell on the client-side, the focus is solely on the design of combinators. This means that you'd have to use another example, for instance XML parsing. Of course, the idea is that this can be reused when someone else manages to run Haskell on the client. * Design combinators for remote procedure calling via HTTP/AJAX. Again, there is no Haskell running in the browser
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
While I might be a bit biased (I spent a good deal of time working on improving the UHC JS backend), I think there are a lot of opportunities to get Haskell as a client-side language via the UHC, as Heinrich suggested. Alessandro Vermeulen recently wrote an entire front-end application using the UHC JS backend, so we know that it's capable of producing working front-end applications. See also[1]. Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. This would go a long way to make the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, you will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. You would also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, you will only need one cabal file for an entire web application; for both the front-end and backend. I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. Jurriën [1] http://uu-computerscience.github.com/uhc-js/ On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: Chris Smith wrote: My first impression on this is that it seems a little vague, but possibly promising. My impression is also that this project proposal is rather vague. The general goal Haskell as client-side language for websites is clear and worthwhile, but I can't tell from the proposal whether the project will succeed or not, or, more importantly, *what* it will succeed at. The way I see it is that a successful GSoC proposal has to embody four key points: 1. One specific goal - I want to compile Haskell to JS via UHC's backend 2. in a larger context - as a step towards Haskell as a client-side language for websites. 3. that is accompanied by a successful example - To demonstrate that this works, I will write a small Asteroids game with HTML5 and Haskell 4. and that others can build upon - Moreover, I want to make it really easy for others to use the Haskell-JS compilation from cabal. The last point is extremely important: you don't want to build a hobbled prototype that languishes in a dark corner of github, you want to build a great software that changes the world by solving an important problem and making this solution really easy to use! Alejandro, your proposal mentions several different specific goals, each of which can be the basis for a successful GSoC project: * Make UHC's Haskell-JS compilation easy to use. * Design combinators for DOM manipulation in functional style, f.i. zippers. Note that this goal does *not* involve running Haskell on the client-side, the focus is solely on the design of combinators. This means that you'd have to use another example, for instance XML parsing. Of course, the idea is that this can be reused when someone else manages to run Haskell on the client. * Design combinators for remote procedure calling via HTTP/AJAX. Again, there is no Haskell running in the browser, the showcase would be two Haskell processes that communicate with each other via HTTP/AJAX. Each of these goals is a tangible improvement on the status quo and specific enough to be completed in a single GSoC project. Of course, the one specific goal is not supposed to be a limit, it is meant to be a foundation. If there is time remaining, the student is free to work on whatever he dreams of. By all means, don't hesitate to reach for the sky, but help us climb to the tree top first. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ 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
Re: [Haskell-cafe] Haskell compilers targeting VMs
The UHC can compile to JVM[1, 2], but the backend is far from production-ready. Also, I don't believe anyone is working on the backend currently. Jurriën [1] http://www.cs.uu.nl/wiki/bin/view/Ehc/Documentation [2] http://www.cs.uu.nl/groups/ST/Projects/ehc/ehc-jazy-doc.pdf On 23 Feb 2012, at 13:41, ARJANEN Loïc Jean David wrote: Hello, Does any one knows of an Haskell compiler targeting the JVM ? And of one targeting the .Net virtual machine ? Regards, ARJANEN Loïc ___ 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
Re: [Haskell-cafe] HDBC SQLite error
I have just tried your suggestion (I explicitly committed right after opening a
connection), but unfortunately it did not solve my problem. I've also tried
compiling my app without threading, but it didn't seem to have any effect
either.
On 1 Nov 2011, at 19:03, Alexander Danilov wrote:
01.11.2011 20:30, Jurriën Stutterheim пишет:
Hi all,
I have recently switched one of my web applications to SQLite via HDBC. I
use it to store some user credentials and data. Initially it seemed to work
fine, until I tried logging in from two different browsers. That's when I
got the following error when trying to log in:
SqlError {seState = , seNativeError = 5, seErrorMsg = step: database is
locked}
My application only uses two functions (query and query', see [1]) directly,
and the authentication code[2] uses HDBC directly. I'm not sure why I'm
getting this error, because as far as I can see, I'm not keeping any
transactions open longer than I have to in the auth code. Does anyone have
an idea what might be wrong and how to fix it?
Cheers,
This is a problem of hdbc-sqlite package, author think, than it can't work
correctly without open transaction, so just commit after open database or
modify hdbc-sqlite like this:
--- a/Database/HDBC/Sqlite3/Connection.hs
+++ b/Database/HDBC/Sqlite3/Connection.hs
@@ -75,7 +75,7 @@ genericConnect strAsCStrFunc fp =
mkConn :: FilePath - Sqlite3 - IO Impl.Connection
mkConn fp obj =
do children - newMVar []
- begin_transaction obj children
+-- begin_transaction obj children
ver - (sqlite3_libversion = peekCString)
return $ Impl.Connection {
Impl.disconnect = fdisconnect obj children,
___
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] HDBC SQLite error
Hi all,
I have recently switched one of my web applications to SQLite via HDBC. I use
it to store some user credentials and data. Initially it seemed to work fine,
until I tried logging in from two different browsers. That's when I got the
following error when trying to log in:
SqlError {seState = , seNativeError = 5, seErrorMsg = step: database is
locked}
My application only uses two functions (query and query', see [1]) directly,
and the authentication code[2] uses HDBC directly. I'm not sure why I'm getting
this error, because as far as I can see, I'm not keeping any transactions open
longer than I have to in the auth code. Does anyone have an idea what might be
wrong and how to fix it?
Cheers,
Jurriën
[1]
https://github.com/norm2782/snaplet-hdbc/blob/master/src/Snap/Snaplet/Hdbc.hs#L155
[2]
https://github.com/norm2782/snaplet-hdbc/blob/master/src/Snap/Snaplet/Auth/Backends/Hdbc.hs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Next European Hackathon
I support the idea of a hackathon in Utrecht and I am willing to help organise it. I have also heard some people talk about the option to host a hackathon in Germany, but I am not aware of any concrete plans. Jurriën On 7 Sep 2011, at 20:12, Christopher Done wrote: ‘Ello! Any plans for the next European hackathon location that will presumably be in 6~ months? I need time to reap potential participants. Wonder if we could arrange an Italian hackathon? Verohac? Hm. :-) Maybe Utrecht? Hac6? Ciao! ___ 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
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ 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
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) On 18 May, 2011, at 20:25 , Tom Murphy wrote: On 5/18/11, Donn Cave d...@avvanta.com wrote: Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom ___ 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
Re: [Haskell-cafe] possible bug for ghc 7 + xcode 4 on snow leopard?
There is no guarantee that /Developer-old/ is still on the system, so depending on it for symlinking is probably not a good idea. So far I have had no problems symlinking /Developer/SDKs/MacOSX10.6.sdk to /Developer/SDKs/MacOSX10.5.sdk. This could be one alternative. However, separate Snow Leopard builds would be preferable, since they would not depend on a workaround to function. Jurriën On 11 Mar, 2011, at 10:00 , steffen wrote: ok, now I've installed XCode 4 and run into the very same problems. As already said, XCode 4 targets snow leopard only. That's why the MacOSX10.5.sdk is missing. unfortunately the ghc packages for snow leopard are configured to support leopard still. See: /Library/Frameworks/GHC.framework/Versions/Current/usr/share/doc/ghc/html/libraries/ghc-7.0.2/src/Config.html So we either have to copy or symling /Developer-old/SDKs/MacOSX10.5.sdk to /Developer/SDKs or someone is going to recompile ghc with snow leopard only in mind. - Steffen ___ 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
