- ghc-devs - Haskell.org

RE: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located
by Simon Peyton Jones 23 Nov '15

23 Nov '15

Alan | ApiAnnotations: Make all RdrName occurences Located There is a principle here: that every RdrName occurrence is located. Is this principle articulated in a Note anywhere? I wish it was! (Including an explanation of why.) Otherwise you risk someone removing the change in a few years time. When I built HsSyn originally I reasoned that data HsExpr = ...| HsVar RdrName was better than data HsExpr = ... | HsVar (Located RdrName0 because the location on the RdrName is identical to that on the LHsExpr, so it's redundant. But you think it is non-redundant. I'm sure you are right (although I don't know why), but it would be a real help to document the invariant and the reasoning in the code somewhere. Are there any other principles that the code embodies? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 22 November 2015 23:11 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #11019: ApiAnnotations: Make all RdrName occurences | Located | | #11019: ApiAnnotations: Make all RdrName occurences Located | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: alanz | Owner: alanz | Type: bug | Status: new | Priority: normal | Milestone: 8.0.1 | Component: Compiler | Version: 7.10.2 | Resolution: | Keywords: | | ApiAnnotations | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Phab:1512 | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari <ben@…>): | | In [changeset:"3df9563e590bbfbfe1bc9171a0e8fc93ceef690d/ghc" | 3df9563e/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="3df9563e590bbfbfe1bc9171a0e8fc93ceef690d" | ApiAnnotations: Make all RdrName occurences Located | | At the moment the API Annotations can only be used on the | ParsedSource, as there are changes made to the RenamedSource that | prevent it from being used to round trip source code. | | It is possible to build a map from every Located Name in the | RenamedSource from its location to the Name, which can then be used | when resolved names are required when changing the ParsedSource. | | However, there are instances where the identifier is not located, | specifically | | (GHC.VarPat name) | (GHC.HsVar name) | (GHC.UserTyVar name) | (GHC.HsTyVar name) | | Replace each of the name types above with (Located name) | | Updates the haddock submodule. | | Test Plan: ./validate | | Reviewers: austin, goldfire, bgamari | | Reviewed By: bgamari | | Subscribers: goldfire, thomie, mpickering | | Differential Revision: https://phabricator.haskell.org/D1512 | | GHC Trac Issues: #11019 | }}} | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.h | askell.org%2ftrac%2fghc%2fticket%2f11019%23comment%3a5&data=01%7c01%7c | simonpj%40064d.mgd.microsoft.com%7cd486e47f742f47e34e7308d2f39230b0%7c | 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AmQZ%2boKbdHXQ4cuPjYOVePqF7 | ivXocZyqHXbcyBj3GY%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.h | askell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c | d486e47f742f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c | 1&sdata=Ca9k88QpvsPGDgrkQCANdKLAPCnAKwoZdHzbIhBgnIU%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd486e47f7 | 42f47e34e7308d2f39230b0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q | aS%2fcmZrioGbpGHXUFNcdCmhyFt6mnV4DH4ucOsO7eo%3d

1 0

On parsing Haskell and CPP
by Gershom B 22 Nov '15

22 Nov '15

We've had quite a bit of discussion lately on the difficulty in performing automated processing of Haskell files in the presence of CPP. It turns out that folks have tackled this sort of problem in the world of C, and done some interesting work. I recently ran across SuperC [1], part of the xtc [2] project. In the setting of C they have achieved some impressive results, including as I understand it, the ability to handle the entire Linux kernel across all CPP-recognized configurations. They note that this is a rather tedious to implement task, even once one has recognized the specification of how to do so. However, the paper is good at reviewing related work and simpler techniques as well, and perhaps among them there is a "good enough" set for the CPP used in common Haskell libraries? Cheers, Gershom [1] https://cs.nyu.edu/rgrimm/papers/pldi12.pdf [2] http://cs.nyu.edu/xtc/

1 0

Re: mac platform problem with configure in 7.10.3 release candidate 3
by George Colpitts 22 Nov '15

22 Nov '15

On MacOS if your path is such that gcc is the gnu gcc rather than Apple's gcc then ./configure gives checking whether we are cross compiling... configure: error: in `/Users/gcolpitts/downloads/ghc-7.10.2.20151114': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details I worked around this by doing export PATH=/usr/bin:$PATH before doing ./configure After that the install worked fine. Thanks On Wed, Nov 18, 2015 at 10:48 AM, Ben Gamari <ben(a)well-typed.com> wrote: > > Hello everyone, > > We are pleased to announce the third release candidate of GHC 7.10.3: > > https://downloads.haskell.org/~ghc/7.10.3-rc3/ > > There have been a few changes since -rc2, > > * The newly-introduced readelf configure check has been disabled on > non-ELF platforms > > * Some tracing output from the typechecker that was causing > some testsuites to fail was removed > > * A latent bug in call arity analysis (#11064) is fixed > > * A code generation bug (#10870) in the PowerPC NCG is fixed > > * A bug in the treatment of foreign calls during demand analysis > (#11076) which had affected GHCJS is fixed > > * A bug in the x86 NCG causing invalid assembly to be produced > when compiling with `-g` is fixed. > > At this moment you will find the source tarball, as well as, 64-bit > Windows, Mac OS X, 32- and 64-bit modern Linux (built on Debian 8) > binary distributions available at the above URL. As usual, you may need > to work around our content delivery network's update latency by adding > redundant forward-slashes to the URL. > > It has come to our attention that there still may be some issues with > long command lines on Windows with this release: While the toolchain > upgrade included in this release has the response file support necessary > to work around this limitation, the version of the Cabal library > shipped with this release does not. Unfortunately, the fix [1], which > affects Cabal's haddock integration, has not yet shipped in a Cabal > release. If you encounter this issue you might consider installing Cabal > and cabal-install from git. > > Lastly, I'd like to take a moment to acknowledge Futureice [2], who have > donated a brand new Mac Mini for use by GHC developers to help support > this platform. Their generosity is the reason we are able to offer OS X > builds to you today. > > Many thanks to Futureice for this donation! > > Happy testing! > > Cheers, > > - Ben > > > [1] > https://github.com/haskell/cabal/commit/1c1228a808b55331ac1db6d71fd2f8533f5… > [2] http://futurice.com/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

3 8

new Typeable story
by Richard Eisenberg 21 Nov '15

21 Nov '15

Hi Simon, I'm a bit confused by the new handling of Typeable. * You say (in Note [Grand plan for Typeable]) that there is trouble making the TyCon/Module information for the types in GHC.Types. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? * Even more bizarre would be putting TyCon/Module info for GHC.Prim stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that GHC.Types itself doesn't try to solve a Typeable constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in Data.Typeable.Internal. There's also not very many lifted tycons in GHC.Prim. I count TYPE and RealWorld, and that's it. For what it's worth, a weird dependency from GHC.Prim to GHC.Types actually works in practice. I put Levity in GHC.Types but (TYPE :: Levity -> TYPE 'Lifted) in GHC.Prim. No one complained. * Let's assume that we really can't clean up this mess. It still seems that several TyCons are missing from Data.Typeable.Internal. Like promoted nil and cons, and Nat, and Symbol. At the least, we should put a loud comment in the export list of GHC.Types saying that everything defined there must be accompanied by a definition in Data.Typeable.Internal. What do you think? Richard

1 1

Re: Proposal: accept pull requests on GitHub
by Thomas Miedema 20 Nov '15

20 Nov '15

> > The real hint is that "the number of contributions will go up". That's > a noble goal and I think it's at the heart of this proposal. > It's not. What's at the heart of my proposal is that `arc` sucks. Most of those quotes I posted are from regular contributors (here's another one: "arcanist kinda makes stuff even more confusing than Git by itself"). Newcomers will give it their best shot, thinking it's just another thing they need to learn, thinking it's their fault for running into problems, thinking they'll get the hang of it eventually. Except they won't, or at least I haven't, after using it for over a year. Maybe the fundamental problem with Phabricator is that it doesn't understand Git well, and the problems I posted on https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator are just symptoms of it. I'm having trouble putting this into words though (something about branches and submodules). Perhaps someone else can? In my opinion it's is a waste of our time trying to improve `arc` (it is 34000 lines of PHP btw + another 70000 LOC for libphutil), when `pull requests` are an obvious alternative that most of the Haskell community already uses. When you're going to require contributors to use a non-standard tool to get patches to your code review system, it better just work. `arc` is clearly failing us here, and I'm saying enough is enough. I need to think about your other points. Thank you for the thorough reply. > Here's the meat of it question: what is the cost of achieving this > goal? That is, what amount of work is sufficient to make this goal > realizable, and finally - why is GitHub *the best use of our time for > achieving this?* That's one aspect of the cost - that it's the best > use of the time. I feel like this is fundamentally why I always seem > to never 'get' this argument, and I'm sure it's very frustrating on > behalf of the people who have talked to me about it and like GitHub. > But I feel like I've never gotten a straight answer for GHC. > > If the goal is actually "make more people contribute", that's pretty > broad. I can make that very easy: give everyone who ever submits a > patch push access. This is a legitimate way to run large projects that > has worked. People will almost certainly be more willing to commit, > especially when overhead on patch submission is reduced so much. Why > not just do that instead? It's not like we even mandate code review, > although we could. You could reasonably trust CI to catch and revert > things a lot of the time for people who commit directly to master. We > all do it sometimes. > > I'm being serious about this. I can start doing that tomorrow because > the *cost is low*, both now and reasonably speaking into some > foreseeable future. It is one of many solutions to raw heart of the > proposal. GitHub is not a low cost move, but also, it is a *long term > cost* because of the technical deficiencies it won't aim to address > (merge commits are ugly, branch reviews are weak, ticket/PR namespace > overlaps with Trac, etc etc) or that we'll have to work around. > > That means that if we want GitHub to fix the "give us more > contributors" problem, and it has a high cost, it not only has _to fix > the problem_, it also has to do that well enough to offset its cost. I > don't think it's clear that is the case right now, among a lot of > other solutions. > > I don't think the root issue is "We _need_ GitHub to get more > contributors". It sounds like the complaint is more "I don't like how > Phabricator works right now". That's an important distinction, because > the latter is not only more specific, it's more actionable: > > - Things like Arcanist can be tracked as a Git submodule. There is > little to no pain in this, it's low cost, and it can always be > synchronized with Phabricator. This eliminates the "Must clone > arcanist" and "need to upgrade arcanist" points. > > - Similarly when Phabricator sometimes kills a lot of builds, it's > because I do an upgrade. That's mostly an error on my part and I can > simply schedule upgrades regularly, barring hotfixes or somesuch. That > should basically eliminate these. The other build issues are from > picking the wrong base commit from the revision, I think, which I > believe should be fixable upstream (I need to get a solid example of > one that isn't a mega ultra patch.) > > - If Harbormaster is not building dependent patches as mentioned in > WhyNotPhabricator, that is a bug, and I have not been aware of it. > Please make me aware of it so I can file bugs! I seriously don't look > at _every_ patch, I need to know this. That could have probably been > fixed ASAP otherwise. > > - We can get rid of the awkwardness of squashes etc by using > Phabricator's "immutable" history, although it introduces merge > commits. Whether this is acceptable is up to debate (I dislike merge > commits, but could live with it). > > - I do not understand point #3, about answering questions. Here's > the reality: every single one of those cases is *almost always an > error*. That's not a joke. Forgetting to commit a file, amending > changes in the working tree, and specifying a reviewer are all total > errors as it stands today. Why is this a minus? It catches a useful > class of 'interaction bugs'. If it's because sometimes Phabricator > yells about build arifacts in the tree, those should be .gitignore'd. > If it's because you have to 'git stash' sometimes, this is fairly > trivial IMO. Finally, specifying reviewers IS inconvenient, but > currently needed. We could easily assign a '#reviewers' tag that would > add default reviewers. > - In the future, Phabricator will hopefully be able to > automatically assign the right reviewers to every single incoming > patch, based on the source file paths in the tree, using the Owners > tool. Technically, we could do that today if we wanted, it's just a > little more effort to add more Herald rules. This will be far, far > more robust than anything GitHub can offer, and eliminates point #3. > > - Styling, linting etc errors being included, because reviews are > hard to create: This is tangential IMO. We need to just bite the > bullet on this and settle on some lint and coding styles, and apply > them to the tree uniformly. The reality is *nobody ever does style > changes on their own*, and they are always accompanied by a diff, and > they always have to redo the work of pulling them out, Phab or not. > Literally 99% of the time we ask for this, it happens this way. > Perhaps instead we should just eliminate this class of work by just > running linters over all of the source code at once, and being happy > with it. > > Doing this in fact has other benefits: like `arc lint` will always > _correctly_ report when linting errors are violated. And we can reject > patches that violate them, because they will always be accurate. > > - As for some of the quotes, some of them are funny, but the real > message lies in the context. :) In particular, there have been several > cases (such as the DWARF work) where the idea was "write 30 commits > and put them on Phabricator". News flash: *this is bad*, no matter > whether you're using Phabricator or not, because it makes reviewing > the whole thing immensely difficult from a reviewer perspective. The > point here is that we can clear this up by being more communicative > about what we expect of authors of large patches, and communicating > your intent ASAP so we can get patches in as fast as possible. Writing > a patch is the easiest part of the work. > > And more: > > - Clean up the documentation, it's a mess. It feels nice that > everything has clear, lucid explanations on the wiki, but the wiki is > ridiculously massive and we have a tendancy for 'link creep' where we > spread things out. The contributors docs could probably stand to be > streamlined. We would have to do this anyway, moving to GitHub or not. > > - Improve the homepage, directly linking to this aforementioned page. > > - Make it clear what we expect of contributors. I feel like a lot of > this could be explained by having a 5 minute drive-by guide for > patches, and then a longer 10-minute guide about A) How to style > things, B) How to format your patches if you're going to contribute > regularly, C) Why it is this way, and D) finally links to all the > other things you need to know. People going into Phabricator expecting > it to behave like GitHub is a problem (more a cultural problem IMO but > that's another story), and if this can't be directly fixed, the best > thing to do is make it clear why it isn't. > > Those are just some of the things OTTOMH, but this email is already > way too long. This is what I mean though: fixing most of these is > going to have *seriously smaller cost* than moving to GitHub. It does > not account for "The GitHub factor" of people contributing "just > because it's on GitHub", but again, that value has to outweigh the > other costs. I'm not seriously convinced it does. > > I know it's work to fix these things. But GitHub doesn't really > magically make a lot of our needs go away, and it's not going to > magically fix things like style or lint errors, the fact Travis-CI is > still pretty insufficient for us in the long term (and Harbormaster is > faster, on our own hardware, too), or that it will cause needlessly > higher amounts of spam through Trac and GitHub itself. I don't think > settling on it as - what seems to be - a first resort, is a really > good idea. > > > On Wed, Sep 2, 2015 at 4:09 PM, Niklas Hambüchen <mail(a)nh2.me> wrote: > > On 02/09/15 22:42, Kosyrev Serge wrote: > >> As a wild idea -- did anyone look at /Gitlab/ instead? > > > > Hi, yes. It does not currently have a sufficient review functionality > > (cannot handle multiple revisions easily). > > > > On 02/09/15 20:51, Simon Marlow wrote: > >> It might feel better > >> for the author, but discovering what changed between two branches of > >> multiple commits on github is almost impossible. > > > > I disagree with the first part of this: When the UI of the review tool > > is good, it is easy to follow. But there's no open-source implementation > > of that around. > > > > I agree that it is not easy to follow on Github. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

4 4

spj-wildcard-refactor
by Simon Peyton Jones 20 Nov '15

20 Nov '15

Status on my spj-wildcard-refactor patch · I’m down to one test failure a modest perf regression on T3064. This is really a test of type family reduction which is nothing to do with my changes, so I have no idea what’s happening there. I’m waiting till I can build a profiled compiler to test. What’s the best workflow for to take my branch with tons of wibble-ish patches, and commit to HEAD with a small number of sensible patches. I was thinking: · Git checkout wip/spj-wildcard-refactor · Git merge master · Git reset master (leaves working files alone) · Now commit patches Is that right? Simon

3 2

Profiled build
by Simon Peyton Jones 20 Nov '15

20 Nov '15

I can’t build a profiled HEAD compiler. In validate.mk I put GhcProfiled = YES GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -fprof-auto GhcLibHcOpts += -Wwarn GhcLibWays += p But then ‘sh validate –fast’ gives rts/RtsFlags.c: In function ‘read_heap_profiling_flag’: rts/RtsFlags.c:1562:26: error: error: assignment discards ‘const’ qualifier from pointer target type [-Werror] rts/RtsFlags.c:1565:27: error: error: assignment discards ‘const’ qualifier from pointer target type [-Werror] cc1: all warnings being treated as errors `gcc' failed in phase `C Compiler'. (Exit code: 1) Does anyone have ideas for how to fix this? Simon

2 2

Feature status for GHC 8.0
by Ben Gamari 19 Nov '15

19 Nov '15

tldr. Please let us know the status of your patches for GHC 8.0. Hello everyone! You are receiving this message because you responsible for one of the in-flight items on the GHC 8.0 roadmap [1]. As you may know, the release is quickly approaching and we'd like to have final patches up for review in the next week or so. Until then we'd like to get an idea of how your various projects are progressing. Below is a list of the projects which we believe are still in progress along with my understanding of the state of your work. If you see your name in this list please let us know how things are going. * OverloadedRecordFields Adam Gundry Documentation needed Full ORF not happening? * Kind equality Richard Eisenberg Patches coming soon? * GADT pattern matching rework George Karachalias How is this coming along? * LLVM backend Austin Seipp Patches coming * Pattern synonyms Matthew Pickering Documentation needed (ongoing work in D1325) * Backpack work Edward Z. Yang How is this coming along? * Compact regions Giovanni Campagna Patches need revision Edward Z. Yang * Type signature sections Herbert Valerio Riedel Not pushing for 8.0? * DWARF-based stack traces and Ben Gamari statistical profiling Patches slowly being merged Documentation needed Thanks for all of your hard work! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

4 4

RE: About Feature status for GHC 8.0
by Simon Peyton Jones 19 Nov '15

19 Nov '15

1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. Yes: provided it all validates, just commit it. It’s already a substantial improvement over what we have right now. I’d still like to understand why putting literals in guards rather than in patterns makes performance worse. But that should not stand in the way of getting it in. Still I hope you won’t drop the investigation altogether. I suspect that making literals-in-guards work acceptably well will improve performance all round. 1. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? Yes I think so. Simon From: George Karachalias [mailto:george.karachalias@gmail.com] Sent: 18 November 2015 19:49 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Tom Schrijvers <tom.schrijvers(a)cs.kuleuven.be>; Dimitrios Vytiniotis <dimitris(a)microsoft.com> Subject: About Feature status for GHC 8.0 Hello Simon, I got the mail from Ben Gamari about the state of our patch (since GHC 8.0 release is approaching) and I would like to respond to Ben tomorrow about it. Current State As you have probably noticed, I reverted back to the last commit (just revert, I did not rewrite history) that was able to bootstrap the compiler. This means that literals are currently in the pattern syntax. I could not find why moving literals to the solver generated so many problems. The only thing that I didn't have the time to address yet is warnings for data families but the deadline is close so I will look into that. Performance of current implementation When I started the implementation, I branched on this commit (it was the HEAD at the time): https://git.haskell.org/ghc.git/commit/b14dae3cc43572a9dd5ca11241981105e428…<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.haskel…> For some time now I was under the impression that our checker consumes a lot of memory because we had many perf-failures from the test suit. Yet, I ran the test suite with the above version of GHC. The performance tests from the test suite that fail for our implementation fail for that as well. Hence, I do not think that it is our problem exactly, I expect GHC's current HEAD to perform OK, and when merging I do not expect any performance problems from our checker (the only performance test we fail is testsuite/tests/perf/compiler/T5642.hs which has pattern matching on ~100 constructors and also nested pattern matching so I think that it makes a lot of sense to consume more memory on this one). More importantly, what should my response to Ben be? Many users are expecting the new checker so I would like to merge what we have when I finish the data families handling. I would like to drop the literals from patterns but for now I think that having the improved checker in GHC 8.0 is more important. We can always make it more generic in the future. To wrap things up: 1. Shall I assume that we will be part of GHC 8.0? Dropping the literals from the pattern syntax is not an option at the moment since I am as swamped as ever. Nevertheless I can sprint for about a week and wrap what we have up which works OK. 2. Ben asked the developers to put the patches on the phabricator but you have told me that there is no need since you have reviewed the code yourself. Shall I assume this still holds? George -- things you own end up owning you

1 0

RE: Window build broken
by Tamar Christina 19 Nov '15

19 Nov '15

Hmm, Presumably Simon didn't change this. Maybe the msys2 install is broken? TamarFrom: David Macek Sent: ‎18/‎11/‎2015 09:35 To: Simon Peyton Jones; lonetiger(a)gmail.com; ghc-devs(a)haskell.org Subject: Re: Window build broken On 18. 11. 2015 9:29, Simon Peyton Jones wrote: > It’s msys2. I don’t have Cygwin on this machine. I have no idea where that prompt comes from, but I agree it’s suspicious. Looks like your /etc/fstab is wrong. There should be a line like this one, that removes the `cygdrive` prefix from Windows drive/letter mounts: none / cygdrive binary,posix=0,noacl,user 0 0 -- David Macek

3 3