Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
>
> HJScript is "OK", hpaste.org uses it here:
> https://github.com/chrisdone/amelie/blob/master/src/Amelie/View/Script.hs
> output here: http://hpaste.org/js/amelie.js
>
> Mini-summary of my experience: You're still stuck with JS semantics,
> and it can be a little odd when you confuse what level of code (JS or
> HS) you're working at, but at least it works right now and can be
> well-typed. The library needs a bit of an overhaul, the GADT of
> HJavaScript is simply flawed (take a brief look and you can see it can
> express totally invalid JS in the syntax tree and the pretty printer
> breaks operator/parens), but HJScript sorts the latter out, and I
> would make all HJScript's functions generic upon MonadJS or something,
>
It seems like the unavoidable fact is that HJScript is a library almost
without documentation and without examples/tests. And for an EDSL that
would seem to be an especially big problem, almost, but not quite as bad as
being told to learn Haskell by being given a GHCI prompt and left to trial
and error.
I've been trying to generate the following line of code:
google.load("visualization", "1", {packages:["corechart"]});
I don't know JS, and my reverse engineering of this one line failed in two
places:
callVoidMethod "load" (string "visualization", string "1", JConst
"{packages:[\"corechart\"]}") (TopLvl "google")
First, there are classes like IsDeref and IsClass with no clear recipe for
how to create values and types satisfying them. Hence "TopLvl", which is
my own introduced hack:
data TopLvl = TopLvl String
instance Show TopLvl where
show (TopLvl s) = s
instance IsClass TopLvl
Second, I couldn't figure out how to generate a dictionary/record
expression such as {packages:"core chart"}. It doesn't seem to be part of
the data model of the underlying HJavaScript package:
http://hackage.haskell.org/packages/archive/HJavaScript/0.4.7/doc/html/Language-HJavaScript-Syntax.html
Although it's probably possibly to build up that record in a variable
binding through some series of assignments, though I haven't found it yet...
What would help enormously, in addition to some documentation patches
[which I will try to provide if I use the library further], would be a
parser from JS concrete syntax to the HJavaScript AST.
Anyway, at this point it seems MUCH easier to just produce strings, which
is too bad.
-Ryan
___
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 > 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. >
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
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 > 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 > > > > > > ___
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Jurriën Stutterheim wrote: 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. [..] 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. This sounds like a great GSoC project to me. Maybe you can add it to the list of project suggestions, Jurriën? http://hackage.haskell.org/trac/summer-of-code/report/1 Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ 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
+1, better cabal support for UHC's JS backend would be a big win. Daniel 2012/3/11 Jurriën Stutterheim : > 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/
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] Summer of Code idea: Haskell Web Toolkit
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
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
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. Indeed, web development has gone a long way without contant communication with the server and I think Haskell should support this way of working too. My idea would rather go on the direction of using stablished Haskell concepts to web development. Some ideas are: - use an applicative interface like the one of Yesod for forms validation and sending - see the DOM via a Zipper interface, so widgets will "anchor" themselves in some point of the tree and change things around them - use FRP for Canvas interaction - ... Actually, thinking which Haskell concepts could behave well with client-side development is an interesting discussion by its own :) 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] Summer of Code idea: Haskell Web Toolkit
Doesn't sound overused to me. FWIW, one of the ideas floating around in my head is exactly what you're describing. On Wed, Mar 7, 2012 at 2:41 PM, JP Moresmau wrote: > Maybe I'll sound like an overused meme, but what about JQuery? JQuery > already takes a combinator-like approach to Javascript and DOM > manipulations, so maybe we could have a combinator library that would > mimic the JQuery library. We'd obviously need some extra combinators > for the required parts of Javascript and HTML generation that are not > done via JQuery. > > JP > > On Tue, Mar 6, 2012 at 11:10 PM, Alejandro Serrano Mena > wrote: >> My idea would be reusing some of the already-available tools for compiling >> Haskell to JS (for example, UHC), and develop with any of them a complete >> library for client-side scripting; rather that redevelop a way to compile >> Haskell to JS. >> >> I think it's really a pity not being able to use things like what Yesod >> provides in a client-side context. And both sides would benefit: they can >> share common code for datatypes (as it's done in Google Web Toolkit), and >> autogenerate some code for sending or receiving AJAX requests, for example. >> >> >> 2012/3/6 Michael Snoyman >>> >>> On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena >>> wrote: >>> > Hi, >>> > I'm really looking forward to helping in the Summer of Code, if Haskell >>> > goes >>> > into it this year (something I take for granted :). I would like to >>> > propose >>> > an idea for a project, and I'm looking for suggestions about whether >>> > it's >>> > good, should be improved or it's just unfeasible. >>> > >>> > My idea is to make a client-side Haskell Web Toolkit, in the spirit of >>> > Google Web Toolkit, which would allow to program in Haskell the client >>> > part >>> > of a web application, and would complement the web frameworks already >>> > existing for Haskell (such as Yesod and Snap). The point is coming about >>> > with a Haskell-ish way to program applications, to reuse all the >>> > existing >>> > knowledge for our beloved language. >>> > >>> > I've added more details in a pre-proposal in Google Docs, available >>> > >>> > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >>> > Tell me if you prefer to see it in other format, but I didn't want to >>> > generate a bigger e-mail. >>> > >>> > Thanks in advance. >>> >>> I definitely think the idea has merit. In general I'm wary of >>> solutions which try to compile down to Javascript[1], and I'm not sure >>> if actually providing a full Haskell-to-JS approach is a good idea. >>> Another possibility might be a DSL/combinator library for generating >>> JS. Though at this point, I wouldn't rule out either approach. >>> >>> Yesod is currently wrapping up its 1.0 release (almost certainly >>> out-the-door by the end of April), and after that our main focus is >>> intended to be client-side integration, so we would certainly be happy >>> to discuss design ideas and collaborate in general. >>> >>> Michael >>> >>> [1] I say "compile down to" to mean nontrivial changes, as opposed to >>> something like Coffeescript, which is a fairly simple conversion. >> >> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ ___ 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
Maybe I'll sound like an overused meme, but what about JQuery? JQuery already takes a combinator-like approach to Javascript and DOM manipulations, so maybe we could have a combinator library that would mimic the JQuery library. We'd obviously need some extra combinators for the required parts of Javascript and HTML generation that are not done via JQuery. JP On Tue, Mar 6, 2012 at 11:10 PM, Alejandro Serrano Mena wrote: > My idea would be reusing some of the already-available tools for compiling > Haskell to JS (for example, UHC), and develop with any of them a complete > library for client-side scripting; rather that redevelop a way to compile > Haskell to JS. > > I think it's really a pity not being able to use things like what Yesod > provides in a client-side context. And both sides would benefit: they can > share common code for datatypes (as it's done in Google Web Toolkit), and > autogenerate some code for sending or receiving AJAX requests, for example. > > > 2012/3/6 Michael Snoyman >> >> On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena >> wrote: >> > Hi, >> > I'm really looking forward to helping in the Summer of Code, if Haskell >> > goes >> > into it this year (something I take for granted :). I would like to >> > propose >> > an idea for a project, and I'm looking for suggestions about whether >> > it's >> > good, should be improved or it's just unfeasible. >> > >> > My idea is to make a client-side Haskell Web Toolkit, in the spirit of >> > Google Web Toolkit, which would allow to program in Haskell the client >> > part >> > of a web application, and would complement the web frameworks already >> > existing for Haskell (such as Yesod and Snap). The point is coming about >> > with a Haskell-ish way to program applications, to reuse all the >> > existing >> > knowledge for our beloved language. >> > >> > I've added more details in a pre-proposal in Google Docs, available >> > >> > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >> > Tell me if you prefer to see it in other format, but I didn't want to >> > generate a bigger e-mail. >> > >> > Thanks in advance. >> >> I definitely think the idea has merit. In general I'm wary of >> solutions which try to compile down to Javascript[1], and I'm not sure >> if actually providing a full Haskell-to-JS approach is a good idea. >> Another possibility might be a DSL/combinator library for generating >> JS. Though at this point, I wouldn't rule out either approach. >> >> Yesod is currently wrapping up its 1.0 release (almost certainly >> out-the-door by the end of April), and after that our main focus is >> intended to be client-side integration, so we would certainly be happy >> to discuss design ideas and collaborate in general. >> >> Michael >> >> [1] I say "compile down to" to mean nontrivial changes, as opposed to >> something like Coffeescript, which is a fairly simple conversion. > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ 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 7 March 2012 06:14, Bardur Arantsson wrote:
> We get the output
>
>> function (param0_0){var var_1 = true;return var_1;}(3);
>
> But this is invalid syntax in JavaScript, and should really be
>
>> (function (param0_0){var var_1 = true;return var_1;})(3);
Right, that's one of the ones I picked up in HJavascript. Didn't
realise (or remember) it was present in HJScript, supposing that it
had its own pretty printer. Other stuff like this is present in the
HJavascript GADT.
___
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 03/06/2012 11:38 PM, Christopher Done wrote:
I might as well chime in on this thread as it is relevant to my
interests. I made a write up on a comparison of HJScript (JavaScript
EDSL) and my Ji (control browser from Haskell) library:
https://github.com/chrisdone/ji
HJScript is "OK", hpaste.org uses it here:
https://github.com/chrisdone/amelie/blob/master/src/Amelie/View/Script.hs
output here: http://hpaste.org/js/amelie.js
HJScript (0.5.0) generates invalid Javascript if you try to use
anonymous functions.
(Digs through email archives... Ah, yes:)
snip
Given
> testJS :: HJScript ()
> testJS = do
> f <- function (\(e :: JInt) -> do
> x <- inVar true
> return $ x)
> callProc f (int 3)
> return ()
>
> main :: IO ()
> main = do
> putStrLn $ "JS: " ++ (show $ evalHJScript $ testJS)
We get the output
> function (param0_0){var var_1 = true;return var_1;}(3);
But this is invalid syntax in JavaScript, and should really be
> (function (param0_0){var var_1 = true;return var_1;})(3);
... which works.
snip
Just something to be aware of.
(For my particular usage it was also too strictly typed, but that's
another matter.)
Regards,
___
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
I might as well chime in on this thread as it is relevant to my interests. I made a write up on a comparison of HJScript (JavaScript EDSL) and my Ji (control browser from Haskell) library: https://github.com/chrisdone/ji HJScript is "OK", hpaste.org uses it here: https://github.com/chrisdone/amelie/blob/master/src/Amelie/View/Script.hs output here: http://hpaste.org/js/amelie.js Mini-summary of my experience: You're still stuck with JS semantics, and it can be a little odd when you confuse what level of code (JS or HS) you're working at, but at least it works right now and can be well-typed. The library needs a bit of an overhaul, the GADT of HJavaScript is simply flawed (take a brief look and you can see it can express totally invalid JS in the syntax tree and the pretty printer breaks operator/parens), but HJScript sorts the latter out, and I would make all HJScript's functions generic upon MonadJS or something, if you want a reader transformer or whatnot (i.e. to carry around some state, a JS "object"), it breaks down with any higher-order combinators taking actions as arguments. I also had some problems making things generic AND type-accurate, but I don't recall them well enough now. Problems aside, At Least It's Partially Well Typed. I tried UHC out recently, made a little API for the canvas tag and drew some pretty things. Had a little trouble with timers, though… the callback for the timer /worked/, but the alert[1] printed the same thing every time, as if the thunk forcing is somehow broken. I looked at the outputted code but couldn't quite grok what was wrong with it. Didn't get more time to investigate why. It may just be my code but it looks sound to me, though I'm mostly winging it with the HTML5 part. Anyway, look forward to watching ideas and work in this area. Ciao! [1]: module Main where import Control.Monad import Language.UHC.JScript.Assorted import Language.UHC.JScript.W3C.HTML5 import Language.UHC.JScript.ECMA.String import Language.UHC.JScript.ECMA.Date import Language.UHC.JScript.Types import Language.UHC.JScript.Primitives import Data.IORef main = do doc <- document bodies <- documentGetElementsByTagName doc (toJS "canvas") body <- nodeListItem bodies 0 ctx <- getContext body "2d" setFillStyle ctx "rgb(200,0,0)" start <- newIORef 0 setInterval 1000 $ do st <- readIORef start forM_ [st..st+30] $ \i -> do let ir = fromIntegral i fillRect ctx (20 + 10*round (sin ir)) (i*10) 2 2 writeIORef start (st + 1) alert (show st) return () In HTML5.hs: data Timer foreign import jscript "setInterval(%*)" _setInterval :: FunPtr (IO ()) -> Int -> IO Timer foreign import jscript "wrapper" makeIntervalCallback :: IO () -> IO (FunPtr (IO ())) setInterval delay haskellCallback = do jsCallback <- makeIntervalCallback haskellCallback _setInterval jsCallback delay ___ 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
My issue isn't that you'd need to develop a new set of tools. I just think that using a library approach would allow us to generate more comprehensible code. Hopefully, we could still reuse datatypes, and do lots of other fun stuff. For example, if we used aeson's ToJSON/FromJSON instances for serialization, and some kind of lens library in place of normal record selectors, there's no reason why would couldn't automatically convert: personName person to person.name I know I'm saying a lot of vague stuff here, simply because I haven't had a chance to really solidify my ideas on how to move forward on it. But I'm certainly not ruling out any possibilities at this point, simply stating a preference to avoid a full-blown Haskell-to-JS solution. Michael On Wed, Mar 7, 2012 at 12:10 AM, Alejandro Serrano Mena wrote: > My idea would be reusing some of the already-available tools for compiling > Haskell to JS (for example, UHC), and develop with any of them a complete > library for client-side scripting; rather that redevelop a way to compile > Haskell to JS. > > I think it's really a pity not being able to use things like what Yesod > provides in a client-side context. And both sides would benefit: they can > share common code for datatypes (as it's done in Google Web Toolkit), and > autogenerate some code for sending or receiving AJAX requests, for example. > > > 2012/3/6 Michael Snoyman >> >> On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena >> wrote: >> > Hi, >> > I'm really looking forward to helping in the Summer of Code, if Haskell >> > goes >> > into it this year (something I take for granted :). I would like to >> > propose >> > an idea for a project, and I'm looking for suggestions about whether >> > it's >> > good, should be improved or it's just unfeasible. >> > >> > My idea is to make a client-side Haskell Web Toolkit, in the spirit of >> > Google Web Toolkit, which would allow to program in Haskell the client >> > part >> > of a web application, and would complement the web frameworks already >> > existing for Haskell (such as Yesod and Snap). The point is coming about >> > with a Haskell-ish way to program applications, to reuse all the >> > existing >> > knowledge for our beloved language. >> > >> > I've added more details in a pre-proposal in Google Docs, available >> > >> > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >> > Tell me if you prefer to see it in other format, but I didn't want to >> > generate a bigger e-mail. >> > >> > Thanks in advance. >> >> I definitely think the idea has merit. In general I'm wary of >> solutions which try to compile down to Javascript[1], and I'm not sure >> if actually providing a full Haskell-to-JS approach is a good idea. >> Another possibility might be a DSL/combinator library for generating >> JS. Though at this point, I wouldn't rule out either approach. >> >> Yesod is currently wrapping up its 1.0 release (almost certainly >> out-the-door by the end of April), and after that our main focus is >> intended to be client-side integration, so we would certainly be happy >> to discuss design ideas and collaborate in general. >> >> Michael >> >> [1] I say "compile down to" to mean nontrivial changes, as opposed to >> something like Coffeescript, which is a fairly simple conversion. > > ___ 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
My first impression on this is that it seems a little vague, but possibly promising. I'd make it clearer that you plan to contribute to the existing UHC stuff. A first glance left me with the impression that you wanted to re-implement a JavaScript back end, which would of course be a non-starter as a GSoC project. Since the actual proposal is to work on the build system and libraries surrounding the existing UHC back end, I'd maybe suggest revising the proposal to be clearer about that, and more specific about what parts of the current UHC compiler, build system, and libraries you propose working on. ___ 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
My idea would be reusing some of the already-available tools for compiling Haskell to JS (for example, UHC), and develop with any of them a complete library for client-side scripting; rather that redevelop a way to compile Haskell to JS. I think it's really a pity not being able to use things like what Yesod provides in a client-side context. And both sides would benefit: they can share common code for datatypes (as it's done in Google Web Toolkit), and autogenerate some code for sending or receiving AJAX requests, for example. 2012/3/6 Michael Snoyman > On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena > wrote: > > Hi, > > I'm really looking forward to helping in the Summer of Code, if Haskell > goes > > into it this year (something I take for granted :). I would like to > propose > > an idea for a project, and I'm looking for suggestions about whether it's > > good, should be improved or it's just unfeasible. > > > > My idea is to make a client-side Haskell Web Toolkit, in the spirit of > > Google Web Toolkit, which would allow to program in Haskell the client > part > > of a web application, and would complement the web frameworks already > > existing for Haskell (such as Yesod and Snap). The point is coming about > > with a Haskell-ish way to program applications, to reuse all the existing > > knowledge for our beloved language. > > > > I've added more details in a pre-proposal in Google Docs, available > > in > https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit > > Tell me if you prefer to see it in other format, but I didn't want to > > generate a bigger e-mail. > > > > Thanks in advance. > > I definitely think the idea has merit. In general I'm wary of > solutions which try to compile down to Javascript[1], and I'm not sure > if actually providing a full Haskell-to-JS approach is a good idea. > Another possibility might be a DSL/combinator library for generating > JS. Though at this point, I wouldn't rule out either approach. > > Yesod is currently wrapping up its 1.0 release (almost certainly > out-the-door by the end of April), and after that our main focus is > intended to be client-side integration, so we would certainly be happy > to discuss design ideas and collaborate in general. > > Michael > > [1] I say "compile down to" to mean nontrivial changes, as opposed to > something like Coffeescript, which is a fairly simple conversion. > ___ 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 Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena wrote: > Hi, > I'm really looking forward to helping in the Summer of Code, if Haskell goes > into it this year (something I take for granted :). I would like to propose > an idea for a project, and I'm looking for suggestions about whether it's > good, should be improved or it's just unfeasible. > > My idea is to make a client-side Haskell Web Toolkit, in the spirit of > Google Web Toolkit, which would allow to program in Haskell the client part > of a web application, and would complement the web frameworks already > existing for Haskell (such as Yesod and Snap). The point is coming about > with a Haskell-ish way to program applications, to reuse all the existing > knowledge for our beloved language. > > I've added more details in a pre-proposal in Google Docs, available > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit > Tell me if you prefer to see it in other format, but I didn't want to > generate a bigger e-mail. > > Thanks in advance. I definitely think the idea has merit. In general I'm wary of solutions which try to compile down to Javascript[1], and I'm not sure if actually providing a full Haskell-to-JS approach is a good idea. Another possibility might be a DSL/combinator library for generating JS. Though at this point, I wouldn't rule out either approach. Yesod is currently wrapping up its 1.0 release (almost certainly out-the-door by the end of April), and after that our main focus is intended to be client-side integration, so we would certainly be happy to discuss design ideas and collaborate in general. Michael [1] I say "compile down to" to mean nontrivial changes, as opposed to something like Coffeescript, which is a fairly simple conversion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code Mentors for Language.C
On Tue, Mar 29, 2011 at 3:05 PM, Aaron Tomb wrote: > However, I should mention that the Haskell community has put together a > fairly long list of potential projects, many of which are more widely useful > than Language.C work. This may mean that it would have a relatively low > chance of being accepted. A high-quality proposal would help the odds, > however. :) A high-quality proposal from a student that demonstrates some prior experience, capacity, and knowledge is huge in the decision making process. Motivated students can also turn in more than one proposal, which I would encourage. It can be the case that two talented candidates both applied for the same proposal, or that of a candidate's proposals, one fits much better than the other with what folks are looking to sponsor. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code Mentors for Language.C
Hello Andrew, This is something I've been wanting for a while, and I'd definitely be interested in mentoring the work. We'd want to work together (along with Benedikt Huber, the current maintainer) to define a specific scope that's appropriate for the summer of code. A fully-compliant internal pre-processor could be quite a lot of work, but it may be possible to come up with something that would be close enough to be useful, and have a plan for how to continue working on it after the summer. However, I should mention that the Haskell community has put together a fairly long list of potential projects, many of which are more widely useful than Language.C work. This may mean that it would have a relatively low chance of being accepted. A high-quality proposal would help the odds, however. :) Aaron -- Aaron Tomb Galois, Inc. (http://www.galois.com) at...@galois.com Phone: (503) 808-7206 Fax: (503) 350-0833 On Mar 29, 2011, at 10:48 AM, Andrew Hirsch wrote: > Would anybody be interested in mentoring me for a summer of code project > working on language.c? I want to write an internal pre-processor that saves > information such as comments and potentially some specially defined > annotations, so that code can be analyzed better. > ___ > 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 2009 project idea
Well if you can do all that in a summer then you have been *very* productive :-) Haskell is indeed lacking a good functional 3D render engine (besides Fieldtrip which is more academic), but I'm not sure the community is waiting for this. But personally I am all for it :-) 2009/3/18 Csaba Hruska > Hi! > > I'd like to participate in gsoc2009. > My project idea is to complete my initial render backend ( > http://www.haskell.org/haskellwiki/LambdaCubeEngine) what can be useful > for (possibe more) haskell projects. > I'd like to extend it to support physics (reusing hpysics source code), > etc. > > Current features: > + easy (from user view) model loading and rendering > + definig materials (texture layers, blending setup, shaders, etc) via > readable material scripts > + fast rendering via vertex buffers > > Some planned features: > + skeletal animation (in progress) > + physics (hpysics) integration > + efficient terrain rendering > + some mesh modifier combinators > etc.. > > Do you think is this useful? Or should i think out a more relevant idea? > > Cheers, > Csaba Hruska > > ___ > 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 and spam
magnus: > There seems to be a serious problem with spam on Haskell's SoC page: > > http://tinyurl.com/fl2dw > > Or maybe that's a general problem for hackage? Nope. Why would it be? You have to authenticate yourself to a real person to upload to hackage. The plan for SoC is to update to a non-broken Trac before the SoC starts. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
Google just announced the 2007 SoC http://code.google.com/soc/ On 2/15/07, Chris Kuklewicz <[EMAIL PROTECTED]> wrote: Donald Bruce Stewart wrote: >> If anyone *can* make HsJudy install and work, could you put this information on >> the haskell wiki? >> >> -- >> Chris > > I'd just ping the auhtor, host the repo on darcs.haskell.org, and then > fix it until it builds like any normal cabalised repo. > > It really could be a Data.HashTable killer, given a bit of build > infrastructure love :-) > > -- Don I kludged an install that makes it work in ghci now. But I don't have a tested recipe for this yet. Even downloading from the pugs repository was tricky. I could not see how to use darcs to get just HsJudy (when I tried to do so darcs was grabbing > 3k patches (using --partial!)). So use "wget --no-parent -r", which is hardly a step I could put in a general recipe. -- Chris ___ 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
Donald Bruce Stewart wrote: >> If anyone *can* make HsJudy install and work, could you put this information >> on >> the haskell wiki? >> >> -- >> Chris > > I'd just ping the auhtor, host the repo on darcs.haskell.org, and then > fix it until it builds like any normal cabalised repo. > > It really could be a Data.HashTable killer, given a bit of build > infrastructure love :-) > > -- Don I kludged an install that makes it work in ghci now. But I don't have a tested recipe for this yet. Even downloading from the pugs repository was tricky. I could not see how to use darcs to get just HsJudy (when I tried to do so darcs was grabbing > 3k patches (using --partial!)). So use "wget --no-parent -r", which is hardly a step I could put in a general recipe. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
haskell: > This project may be a success: > > > > > 4. Project: Fast Mutable Collection Types for Haskell > > Caio Marcelo de Oliveira Filho > > > > Completed, and part of pugs. > > http://perlcabal.org/~audreyt/darcs/pugs/third-party/HsJudy/ > > > > > > But there is no way to pull this out of pugs and install it as a library. > > The cabal file depends on being alongside > http://perlcabal.org/~audreyt/darcs/pugs/third-party/judy/Judy-1.0.3 and > while I > can build and install HsJudy this way, I cannot clearly see how to install the > Judy libraries it needs. > > If anyone *can* make HsJudy install and work, could you put this information > on > the haskell wiki? > > -- > Chris I'd just ping the auhtor, host the repo on darcs.haskell.org, and then fix it until it builds like any normal cabalised repo. It really could be a Data.HashTable killer, given a bit of build infrastructure love :-) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
This project may be a success: > > 4. Project: Fast Mutable Collection Types for Haskell > Caio Marcelo de Oliveira Filho > > Completed, and part of pugs. > http://perlcabal.org/~audreyt/darcs/pugs/third-party/HsJudy/ > > But there is no way to pull this out of pugs and install it as a library. The cabal file depends on being alongside http://perlcabal.org/~audreyt/darcs/pugs/third-party/judy/Judy-1.0.3 and while I can build and install HsJudy this way, I cannot clearly see how to install the Judy libraries it needs. If anyone *can* make HsJudy install and work, could you put this information on the haskell wiki? -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
bulat.ziganshin: > Hello Donald, > > Wednesday, February 14, 2007, 1:51:26 AM, you wrote: > > 7 were successful, 2 were unsuccessful. > > can you please name successful projects and their download pages? Most of the projects have been hosted on darcs.haskell.org since the beginning, and students involved in the SoC continue to help out in the community. Here's a quick summary: 1. Project: GHCi based debugger for Haskell Jos? Iborra L?pez Now part of GHC head. Jos? was at the recent Hackathon in Oxford, and the debugger continues to be developed in GHC. He continues to be active in the community and #haskell. 2. Project: haskellnet Jun Mukai Completed, available from http://darcs.haskell.org/SoC/haskellnet/ Recently published a Haskell textbook in Japanese. Can be found on #haskell. 3. Project: Storable a => ByteString a Spencer Janssen Completed, available from http://darcs.haskell.org/SoC/fps-soc/ Spencer's now an active member of the community, and currently working on a new window manager written in Haskell 4. Project: Fast Mutable Collection Types for Haskell Caio Marcelo de Oliveira Filho Completed, and part of pugs. http://perlcabal.org/~audreyt/darcs/pugs/third-party/HsJudy/ 5. Project: A model for client-side scripts with HSP Joel Bj?rnson Completed, available from http://darcs.haskell.org/SoC/hsp.clientside/ 6. Project: Thin out cabal-get and integrate in GHC Paolo Martini Completed, part of Cabal (http://haskell.org/cabal), and the rapidly progressing hackage.haskell.org 7. Project: Port Haddock to use GHC David Waern Completed, and still active, http://darcs.haskell.org/SoC/ghc.haddock/ David also made it to the Hackathon, and is a #haskell regular These last two projects were not completed: 8. Project: Implement a better type-checker for yhc. 9. Project: Implement a parser for Language.C Further analysis and improvements to implement for the upcoming SoC will appear on the SoC website in due course, before the start of this year's SoC. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
bulat.ziganshin: > Hello Bryan, > > Tuesday, February 13, 2007, 2:24:21 AM, you wrote: > > > I am wondering if there are any Summer of Code projects that I would > > be able to do for the Haskell community. > > of 9 projects started last year, only 1 or 2 was successful. so i > think that retaking one of projects selected last year may be a good > idea 7 were successful, 2 were unsuccessful. This was above average for Google SoC (they originally planned for more than 50% failure) and we can be considered very succesful! Some other .orgs had dramatically worse rates. > to Donald: afair, you was written some report about this SoC. can you > please explain status quo of projects started last year? is it > possible to restart unsuccessful ones again? Certainly. > > to all: i think, now it's the good time to start thinking about > projects we need. last year one-week schedule was too fast > > i'm completely agree with Donald in that last year some participants was > Haskell novices and this paid project was the first program they ever > tried to write in Haskell :) As far as I remember, all of the participants had previous haskell knowledge. The point of the SoC though is to bring *new* hackers into the community, who hopefully become core contributors. We had several SoC guys at the recent hackathon, who wouldn't have been there if not for the SoC. You see SoC participants helping out in all sorts of ways in the community now. So it really worked rather well. I'm looking forward to another crop of hackers for this years projects! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
Hello Bryan, Tuesday, February 13, 2007, 2:24:21 AM, you wrote: > I am wondering if there are any Summer of Code projects that I would > be able to do for the Haskell community. of 9 projects started last year, only 1 or 2 was successful. so i think that retaking one of projects selected last year may be a good idea to Donald: afair, you was written some report about this SoC. can you please explain status quo of projects started last year? is it possible to restart unsuccessful ones again? to all: i think, now it's the good time to start thinking about projects we need. last year one-week schedule was too fast i'm completely agree with Donald in that last year some participants was Haskell novices and this paid project was the first program they ever tried to write in Haskell :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code
bryan.burgers: > Hello, > > Yes, I realize it's mid-February right now and the summer is still > months away, but it's probably not too early to think about the > future. > > I am wondering if there are any Summer of Code projects that I would > be able to do for the Haskell community. I will be graduating from my > undergrad program this semester and am hoping to go on to graduate > school in the fall, and I think a good Haskell project would be the > perfect way to spend my transitional summer. > > So, are there any projects that will need a student for the summer? If > this is not the place to ask, where should I be asking? > Here's some general advice for those considering applying for the Summer of Code Haskell projects. We haven't prepared a list yet of desirable features, but going on last year's successful applicants, the following qualities will be required: 1. The project should have: * clear benefit to the Haskell community * there will be an emphasis on new libraries and on new development tools. We really prefer people work on things that the community needs: libraries and development tools. Some suggestions would be the http lib, a binary/bitstream parsec, or a light web framework (that works out of the box), ghc-api integration with emacs/vim. 2. The applicant should have: * demonstrated experience with Haskell programming * demonstrated experience working alone, (e.g. open source experience is a great asset) With over 100 applicants, and 9 positions available, competition is tough. You can stand out by contributing to projects *now* so that you gain experience with the current best Haskell development practices, and get some guidance from the open source hackers in the community about how to work efficiently and with community consensus. Start working now on your own library or app, get it in darcs, publish it, upload it to hackage, and when summer comes around, you'll have massively increased your changes of being selected. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
