Re: [Haskell-cafe] Too much inlining on text package
On Sat, Mar 17, 2012 at 1:28 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Mar 16, 2012 at 3:48 PM, Aleksey Khudyakov alexey.sklad...@gmail.com wrote: On 17.03.2012 02:24, Johan Tibell wrote: I suggest you file a bug. :) I'm way too lazy for that. Also I don't want to steal joy of reporting a bug from people who actually suffer from it I meant you as in the collective you who care about this, not you specifically. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe OK, issue created: https://github.com/bos/text/issues/19 If anyone has concrete ideas on how to improve the situation, could you comment on Github and/or send it as a pull request? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] We *have* been accepted into the Google Summer of Code
Sajith T S wrote: Heinrich Apfelmus apfel...@quantentunnel.de wrote: Just for reference, here the direct link that is now online: http://www.google-melange.com/gsoc/org/google/gsoc2012/haskell How up-to-date/relevant are the projects in the ideas page? http://hackage.haskell.org/trac/summer-of-code/report/1 (For example, I believe build multiple Cabal packages in parallel is a successful project from last year's summer of code.) The newly created project suggestions are definitely up-to-date, but the older ones may be outdated. To know for sure, you can ask about specific projects on the mailing list, which is a good idea anyway. I'm sorry that the list is not in top shape, but that's probably because there is no curator. Also, why is Mentor: not-accepted for many (all?) of them? The Mentor field has no significance, simply ignore it. 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] ANN: Haskell Platform Versions Comparison Chart
Hi, I compiled a chart that gives a side-by-side comparison of package versions in various Haskell Platform releases. http://sol.github.com/haskell-platform-versions-comparison-chart/ This includes both, packages that come with ghc and platform packages. Source is on GitHub[1]. Cheers, Simon [1] https://github.com/sol/haskell-platform-versions-comparison-chart ___ 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
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
[Haskell-cafe] Stack overflow while programming imperatively
Hey list. I was recently fixing a space leak by dropping down to imperative programming in a section of my code, when it started developing space leaks of its own. I found the problem though - it was my for loop: http://hpaste.org/65514 Can anyone provide suggestions on why that stack overflows? It seems ridiculously tail recursive. I tried to do it more haskell-like with http://hpaste.org/65517, but it was still spending 75% of its time in GC. Is there any way to write such a loop with ~100% productivity? I don't think there should be _any_ garbage generated, as all values may be stack allocated. Is this a performance regression in GHC? Thanks, - clark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack overflow while programming imperatively
On 18.03.2012 22:32, Clark Gaebel wrote: Hey list. I was recently fixing a space leak by dropping down to imperative programming in a section of my code, when it started developing space leaks of its own. I found the problem though - it was my for loop: http://hpaste.org/65514 Can anyone provide suggestions on why that stack overflows? It seems ridiculously tail recursive. I tried to do it more haskell-like with http://hpaste.org/65517, but it was still spending 75% of its time in GC. Excessive laziness could be cleverly hiding. modifyIORef doesn't modify IORef's value but builds huge chain of thunks. When you try to evaluate it you get stack overflow. Forcing value of IORef will fix this space leak. You could use strict version of modifyIORef: modifyIORef' x f = do a - readIORef x writeIORef x $! f a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Google Summer of Code idea of project application
Dear members of Haskell Cafe, My name is Damien Desfontaines, and I'm currently following a Theoretical Computer Science Major at the École Normale Supérieure in Paris, which is one of the most selective universities in France. To complete my curriculum, I am to find a three-month internship related to something I have learnt, including lambda-calculus, compilers, graph theory, languages theory, and complexity calculability theories. I wish to make it useful for the open-source community, for example by working for the Haskell group through the Google Summer of Code Program. The project I suggest is mainly inspired by Ticket #1555 [1] : I think that would be a great idea to make it possible to call some Haskell code into OCamL. In particular, this would contribute to the spreading of Haskell in countries where OCamL is proeminent, mainly France and Italy. The idea would be the following : building a translator which would turn Haskell code into (purely functional) OCamL code, in order to enable the use of Haskell functions and libraries within OCamL programs, in a human-readable way (the OCamL source code generated would ideally be understandable enough to be manually modified). I am well aware that one of the main issues lies in dealing with the conversion between the two types systems, especially because of Haskell's lazy evaluation and typeclasses. However, such a challenge really motivates me to spend hours looking for the most efficient and usable solution, I would really enjoy spending three months on such problems. However, I sincerely think I have the skills needed to go through such a project. Indeed, I have a long experience with OCamL. I used this language to automatically write the undecidable Gödel proposition in Peano arithmetics, using Tarski's original proof [2]. I have written a mini-Java compiler with it [3], a MISP microprocessor simulator along with three friends [4], and many other things for studies and personal entertainment. My experience of Haskell is shorter, I learnt it with two books, Learn You a Haskell for Great Good ! and Real World Haskell (you are the co-author of this last book, aren't you ? Well, congratulations, it's really well-written and precise !). I use it mainly for mathematical-oriented works, and for coding competitions such as Google Jam or Prologin. I also have a little experience with open-source software : I have been using Debian Linux for 4 years, so I know the basics of UNIX administration. I know how to write a bug report, a man-page, a README, etc. I spend a lot of time helping others on french IRC channels, Linux- or programmation-oriented. I contribute to the Weboob project [5] by writing documentation and new modules. This, in my opinion, makes me quite autonomous, and able to solve issues by myself, by reading documentation, manuals or language specifications. Apart from that, I have never been engaged in development of large projects such as Haskell - but I am ready and excited to start ! I am confident I can interact efficiently with the Haskell community: if you would like me to create a blog syndicated to Planet Haskell, in which I would explain my work every one or two weeks, I can do that. I know how to read a man-page, a language specification or a system documentation, so I consider myself as quite autonomous to answer questions I could ask myself during a project. Furthermore, please let me know if you think my skills could be useful to another Haskell project. I look forward to the opportunity to discuss this idea with one or several developers, Damien Desfontaines [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1555 [2] http://www.eleves.ens.fr/home/desfonta/godel/godel.ml [3] http://www.eleves.ens.fr/home/desfonta/ProjetCompil/ [4] https://github.com/kyoDralliam/CircuitSimulator [5] http://weboob.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell Platform Versions Comparison Chart
That's great! I think, it would be useful to include the version of the shipped gcc (where applicable). Would that be complicated to add? For windows, I looked them up once: 2011.4.0.0 - 4.5.0 2011.2.0.1 - 4.5.0 2011.2.0.0 - 4.5.0 2010.2.0.0 - 3.4.5 Cheers, Sönke Simon Hengel wrote: Hi, I compiled a chart that gives a side-by-side comparison of package versions in various Haskell Platform releases. http://sol.github.com/haskell-platform-versions-comparison-chart/ This includes both, packages that come with ghc and platform packages. Source is on GitHub[1]. Cheers, Simon [1] https://github.com/sol/haskell-platform-versions-comparison-chart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell Platform Versions Comparison Chart
That's great! I think, it would be useful to include the version of the shipped gcc (where applicable). I think this only applies to windows**; and I'd tend to put it into a separate table. But yes, open a ticket or send me a pull request (preferred!). Cheers, Simon ** Not really suer about Mac OS X, but I think it requires Xcode, can someone confirm this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack overflow while programming imperatively
Yay, that fixed it. Thanks! On Sun, Mar 18, 2012 at 2:50 PM, Aleksey Khudyakov alexey.sklad...@gmail.com wrote: On 18.03.2012 22:32, Clark Gaebel wrote: Hey list. I was recently fixing a space leak by dropping down to imperative programming in a section of my code, when it started developing space leaks of its own. I found the problem though - it was my for loop: http://hpaste.org/65514 Can anyone provide suggestions on why that stack overflows? It seems ridiculously tail recursive. I tried to do it more haskell-like with http://hpaste.org/65517, but it was still spending 75% of its time in GC. Excessive laziness could be cleverly hiding. modifyIORef doesn't modify IORef's value but builds huge chain of thunks. When you try to evaluate it you get stack overflow. Forcing value of IORef will fix this space leak. You could use strict version of modifyIORef: modifyIORef' x f = do a - readIORef x writeIORef x $! f a ___ 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] ANN: Haskell Platform Versions Comparison Chart
On Sun, Mar 18, 2012 at 20:28, Simon Hengel s...@typeful.net wrote: ** Not really suer about Mac OS X, but I think it requires Xcode, can someone confirm this. Yes, the platform on Mac OS X requires Xcode, which includes gcc. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell Platform Versions Comparison Chart
** Not really suer about Mac OS X, but I think it requires Xcode, can someone confirm this. Yes, the platform on Mac OS X requires Xcode, which includes gcc. Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best way to use the google visualization (javascript) API rather than static image charts (hs-gchart)?
Thanks David,
As an update, HJScript is a bit of a nightmare to figure out (missing
documentation, examples). And the model of JS values:
http://hackage.haskell.org/packages/archive/language-javascript/0.4.10/doc/html/Language-JavaScript-Parser.html#t:Node
Seems less human comprehensible than, for example, WebBits':
http://hackage.haskell.org/packages/archive/WebBits/2.0/doc/html/BrownPLT-JavaScript-Syntax.html
However, jmacro is a breeze for spitting out JS code. The little script
below will make a simple line plot with google charts.
I'll give flot a try latter. Zooming / panning sounds nice.
Cheers,
-Ryan
Aforementioned script:
---
{-# LANGUAGE QuasiQuotes #-}
import Language.Javascript.JMacro
hdr :: String
hdr = html head script type=\text/javascript\ src=\
https://www.google.com/jsapi\;/script script type=\text/javascript\
ftr :: String
ftr = /script /head body div id=\chart_div\ style=\width:
900px; height: 500px;\/div /body /html
testdata :: [(String, Int, Int)]
testdata = [
(2004, 100, 400),
(2005, 1170, 460),
(2006, 860, 580),
(2007, 1030, 540)
]
-- | This provides a set of basic functional programming primitives, a few
utility functions
-- and, more importantly, a decent sample of idiomatic jmacro code. View
the source for details.
-- body :: JStat
body :: (ToJExpr a3, ToJExpr a2, ToJExpr a1, ToJExpr a) = (a, a1, a2) -
a3 - JStat
body (title,line1,line2) testdata = [$jmacro|
google.load(visualization, 1, {packages:[corechart]});
fun drawChart {
var dat = new google.visualization.DataTable();
dat.addColumn('string', `(title)` );
dat.addColumn('number', `(line1)` );
dat.addColumn('number', `(line2)` );
// -- Here's our data... this can get BIG:
dat.addRows( `(testdata)` );
var options = { title: `(title)` };
var chart = new
google.visualization.LineChart(document.getElementById('chart_div'));
chart.draw(dat, options);
}
google.setOnLoadCallback(drawChart);
|]
main = do
putStrLn hdr
print$ renderJs$ body (blah,line1,line2) testdata
putStrLn ftr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Google Summer of Code - Lock-free data structures
Hi everyone, I would like to do the GSoC project outlined in http://hackage.haskell.org/trac/summer-of-code/ticket/1608 One of Haskell's great strengths is its support for all kinds of concurrent and parallel programmming, so I think that the Haskell ecosystem would benefit from having a wider range of efficient concurrent data structures. Also, more selfishly, I remember reading the article in CACM last summer and thinking that the whole idea of updating data structures directly using atomic compare-and-swap was really cool, so I would love to have an excuse to play around with it. Some (initial) ideas for lock-free data structures worth implementing: 1. A lock-free priority queue, e.g. using the approach based on skip-lists explained in [2] 2. Stacks, see [1] and [3] 3. Hash tables [4] but if anyone has other suggestions, I would obviously happy to hear them. GSoC stretches over 13 weeks. I would estimate that implementing a data structure, writing tests, benchmarks, documentation etc. should not take more than 3 weeks (it is supposed to be full-time work, after all), which means that I could implement 4 of them in the time available and still have some slack. About me: My name is Florian Hartwig, I'm a fifth year (Master's) student in Computing Science at the University of Glasgow. I've been using Haskell for a bit more than two years now (both for university courses and my recreational programming) and I'm currently using it for my Master's project, so I won't have to spend any time learning the Haskell basics. I don't have any other plans for the summer that might conflict with the project. I'd be thankful for any thoughts, questions and suggestions. Cheers, Florian [1] http://cacm.acm.org/magazines/2011/3/105308-data-structures-in-the-multicore-age/fulltext [2] http://www.sciencedirect.com/science/article/pii/S0743731504002333 [3] http://dl.acm.org/citation.cfm?id=1007944 [4] http://dl.acm.org/citation.cfm?id=564881 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
On Mar 18, 2012 6:39 PM, Florian Hartwig florian.j.hart...@gmail.com wrote: GSoC stretches over 13 weeks. I would estimate that implementing a data structure, writing tests, benchmarks, documentation etc. should not take more than 3 weeks (it is supposed to be full-time work, after all), which means that I could implement 4 of them in the time available and still have some slack. Don't underestimate the time required for performance tuning, and be careful to leave yourself learning time, unless you have already extensively used ThreadScope, read GHC Core, and worked with low-level strictness, unpacking, possibly even rewrite rules. I suspect that the measurable performance benefit from lockless data structures might be tricky to tease out of the noise created by unintentional strictness or unboxing issues. And we'd be much happier with one or two really production quality implementations than even six or seven at a student project level. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code idea of project application
On 19/03/2012, at 8:01 AM, Damien Desfontaines wrote: The project I suggest is mainly inspired by Ticket #1555 [1] : I think that would be a great idea to make it possible to call some Haskell code into OCamL. In particular, this would contribute to the spreading of Haskell in countries where OCamL is proeminent, mainly France and Italy. The idea would be the following : building a translator which would turn Haskell code into (purely functional) OCamL code, in order to enable the use of Haskell functions and libraries within OCamL programs, in a human-readable way (the OCamL source code generated would ideally be understandable enough to be manually modified). You might want to consider targeting F# as well as (or instead of) OCaml. I've had nothing but trouble with GODI, to the point where I gave up on OCaml entirely. On the other hand, F# came with Mono... F# has built-in support for lazy evaluation (although it is not the default), so this might simplify your task. Indeed, F# has comprehensions too, so the main impedance mismatch would be typeclasses. This would make an F# target a sensible half-way point for an OCaml target. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell Platform Versions Comparison Chart
On 3/18/12 5:08 AM, Simon Hengel wrote: Hi, I compiled a chart that gives a side-by-side comparison of package versions in various Haskell Platform releases. http://sol.github.com/haskell-platform-versions-comparison-chart/ This includes both, packages that come with ghc and platform packages. Source is on GitHub[1]. Nice. Any chance you could get the packages sorted alphabetically so that it's easier to look things up directly? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code - Lock-free data structures
On 19 March 2012 00:59, Chris Smith cdsm...@gmail.com wrote: On Mar 18, 2012 6:39 PM, Florian Hartwig florian.j.hart...@gmail.com wrote: GSoC stretches over 13 weeks. I would estimate that implementing a data structure, writing tests, benchmarks, documentation etc. should not take more than 3 weeks (it is supposed to be full-time work, after all), which means that I could implement 4 of them in the time available and still have some slack. Don't underestimate the time required for performance tuning, and be careful to leave yourself learning time, unless you have already extensively used ThreadScope, read GHC Core, and worked with low-level strictness, unpacking, possibly even rewrite rules. I suspect that the measurable performance benefit from lockless data structures might be tricky to tease out of the noise created by unintentional strictness or unboxing issues. And we'd be much happier with one or two really production quality implementations than even six or seven at a student project level. -- Chris Smith Thank you, Hofstadter's law definitely rears its head in many of my projects. I do have some experience with ThreadScope and strictness issues, but you I agree that I'm probably underestimating the time I need to learn. I also agree that my focus would be on quality rather than quantity. I quite like the modularity of this project, because it minimises the chance of having a lot of half-finished but useless code at the end of summer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
