Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonpj):
So HEAD (and 7.0.2) does a much better job here. It has a simple arity
analyser that (somewhat to my surprise) is clever enough to spot that
`test2` really has arity 3. Your earlier example was in fact nastier,
because `test4`'s arity depended on its parameter `k`, which isn't the
case with your new example.
Anyway try HEAD of 7.0.2.
{{{
T4978a.test2 [Occ=LoopBreaker]
:: [GHC.Word.Word8]
- (T4978a.Buffer - [Data.ByteString.Internal.ByteString])
- T4978a.Buffer
- [Data.ByteString.Internal.ByteString]
[GblId, Arity=3, Str=DmdType SC(S)L]
T4978a.test2 =
\ (ds_dQG :: [GHC.Word.Word8])
(eta_B1 :: T4978a.Buffer - [Data.ByteString.Internal.ByteString])
(eta1_X2 :: T4978a.Buffer) -
case ds_dQG of _ {
[] - eta_B1 eta1_X2;
: x1_ax6 xs1_ax7 -
case eta1_X2
of _ { T4978a.Buffer rb_dQL rb1_dQM rb2_dQN rb3_dQO rb4_dQP -
case GHC.Prim.=# 1 rb4_dQP of _ {
GHC.Bool.False -
lvl1_rYs
`cast` (CoUnsafe
T4978a.Builder [Data.ByteString.Internal.ByteString]
:: T4978a.Builder ~
[Data.ByteString.Internal.ByteString]);
GHC.Bool.True -
case x1_ax6 of _ { GHC.Word.W8# x2_aWt -
case GHC.Prim.writeWord8OffAddr#
@ GHC.Prim.RealWorld
(GHC.Prim.plusAddr# rb_dQL (GHC.Prim.+# rb2_dQN
rb3_dQO))
0
x2_aWt
GHC.Prim.realWorld#
of s2_aWv { __DEFAULT -
case GHC.Prim.touch#
@ GHC.ForeignPtr.ForeignPtrContents rb1_dQM s2_aWv
of _ { __DEFAULT -
T4978a.test2
xs1_ax7
eta_B1
(T4978a.Buffer
rb_dQL
rb1_dQM
rb2_dQN
(GHC.Prim.+# rb3_dQO 1)
(GHC.Prim.-# rb4_dQP 1))
}
}
}
}
}
}
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4905: New flag to disable warning on incomplete pattern matches in lambdas
#4905: New flag to disable warning on incomplete pattern matches in lambdas --+- Reporter: batterseapower | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by simonpj): * status: new = closed * resolution: = fixed Comment: No, it wasn't merged. It's a change in specification not a bug-fix, and we don't generally change that in patch releases. It's not a totally Unbreakable Law, but it's a good one. Moreover we plan 7.2 in a month or two. Is it a big deal for you? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4905#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4980: Warning about module abbreviation clashes
#4980: Warning about module abbreviation clashes -+-- Reporter: Lemming |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): Hmm. It's sometimes very useful to do just that! And indeed sometimes the two really ''do'' export `ident`, but in both cases it's the ''same'' `ident`, so it's fine. I'm a bit skeptical myself, but let's see if others like it. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4980#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4903: Inliner looping when specialising across modules (with GADTs and other extensions)
#4903: Inliner looping when specialising across modules (with GADTs and other extensions) -+-- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.1 Resolution: fixed | Keywords: Testcase: simplCore/should_compile/T4903 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Compile-time crash | -+-- Comment(by dreixel): If the INLINABLE pragma on line 37 of simplCore/should_compile/T4903a.hs is replaced by an INLINE pragma, the compiler loops. This should not happen, right?... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4903#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4980: Warning about module abbreviation clashes
#4980: Warning about module abbreviation clashes
-+--
Reporter: Lemming |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by Lemming):
Replying to [comment:1 simonpj]:
Hmm. It's sometimes very useful to do just that!
Because of that, I do not propose this option to be part of -Wall. But the
way I import modules it is almost sure, that renaming a module to the same
abbrevation was an accident (e.g. when merging two import lists).
And indeed sometimes the two really ''do'' export `ident`, but in both
cases it's the ''same'' `ident`, so it's fine.
But it would also be no problem to use two different renamings, say
{{{
import qualified Data.A as DA
import qualified Control.A as CA
}}}
and then being able to refer to ident by both DA.ident and CA.ident,
right? I mean, why do two modules export the same identifier? E.g. because
one module is meant as central module like Foreign that exports
identifiers of sub-modules like Foreign.Ptr. In this case I would decide
for one style, either importing all identifiers from the central module
Foreign or importing all of them from the specific sub-modules like
Foreign.Ptr, Foreign.Storable etc. Another reason might be that a module
was split and the identifiers are exported from the unsplit module for
compatibility reasons. In this case programmers are encouraged to use the
split modules exclusively.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4980#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4977: Warning about unqualified implicit imports
#4977: Warning about unqualified implicit imports
-+--
Reporter: Lemming |Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by Lemming):
Replying to [comment:4 simonpj]:
Hmm. So what triggers the warning? All your examples are for a module
`Top.A`; would the warning happen if I say `import M`?
The module name Top.A is irrelevant. 'import M' shall also trigger the
warning.
Maybe you meant to warn of any import that brings into scope a bunch of
unqualified names, unless they are explicitly enumerated. What about
{{{
import Top.A( T(..) )
}}}
Is that warned about too?
Ah, I missed that. Yes, importing constructors and class methods
unqualified and without explicit enumeration should also cause a warning.
What is the general rule?
My intention is to warn about all import statements, that can cause the
module to break, if there is something _added_ to the imported module.
Removals and modifications of the API of imported modules are out of scope
for any warning, since we cannot protect ourselves against such changes
via the choice of import statements.
I brought the PVP into the discussion, since if you import module M with
qualification or with explicit identifier list and M is part of the
package p and p follows the Package Versioning Policy, then you can
declare
{{{
Build-Depends: p == A.B.*
}}}
in your Cabal file. If you use imports that bring a bunch of identifiers
into scope without qualification and explicit enumeration, then you have
to restrict the version range to
{{{
Build-Depends: p == A.B.C.*
}}}
Thus this warning could promote the PVP and could encourage people to
import in a way that allows larger import version ranges and thus reduce
the number of updates to packages.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4977#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4903: Inliner looping when specialising across modules (with GADTs and other extensions)
#4903: Inliner looping when specialising across modules (with GADTs and other extensions) -+-- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler|Version: 7.1 Resolution: fixed | Keywords: Testcase: simplCore/should_compile/T4903 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Compile-time crash | -+-- Comment(by simonpj): It's a bug, thank you! My previous fix was inadequate I now see. Sigh. Will work on it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4903#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4905: New flag to disable warning on incomplete pattern matches in lambdas
#4905: New flag to disable warning on incomplete pattern matches in lambdas --+- Reporter: batterseapower | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Changes (by maeder): * status: closed = merge Comment: Since the new haskell platform will be based on 7.0.2 I think this ticket and http://hackage.haskell.org/trac/ghc/ticket/4842 are big deals. Generally a new release should not be announced with a promise for a further release (should I wait until then?). Make the current release as good as possible! (I've stupidly changed my code because of these warning.) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4905#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4905: New flag to disable warning on incomplete pattern matches in lambdas
#4905: New flag to disable warning on incomplete pattern matches in lambdas --+- Reporter: batterseapower | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by simonpj): The thing is that 7.0.2 isn't a new release. It's just a patch release of 7.0, which itself came out after ICFP last year. The HP, by design, lags compiler releases. I think we don't really mind either way at GHC HQ. If the HP folk want it in, we'd be happy to put it in. But what is good for you might be bad for someone else, which is why it might be worth asking them. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4905#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4905: New flag to disable warning on incomplete pattern matches in lambdas
#4905: New flag to disable warning on incomplete pattern matches in lambdas --+- Reporter: batterseapower | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler |Version: 7.0.1 Resolution: fixed| Keywords: Testcase: | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: None/Unknown | --+- Comment(by maeder): Only patch releases are sufficiently stable and will be used for a longer time. Therefore also some (unfortunate) features (aka specifications) may be worth changing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4905#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file
#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file --+- Reporter: igloo| Owner: Type: bug | Status: new Priority: high | Milestone: 7.0.3 Component: Compiler |Version: 6.13 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: | Os: MacOS X Blocking: | Architecture: x86 Failure: Building GHC failed | --+- Comment(by thorkilnaur): Hello, I am looking into possibly upgrading the tn23 Xcode. As I understand, also from a discussion on #ghc the other day, this may fix the problem. Best regards Thorkil -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4013#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1363: Sourcing multi-line scripts in GHCi: track line numbers, and bail out after first error
#1363: Sourcing multi-line scripts in GHCi: track line numbers, and bail out after first error -+-- Reporter: Frederik |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: _|_ Component: GHCi | Version: 6.6 Keywords: multiline script | Testcase: Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by igloo): Replying to [comment:18 vivian]: Okay. I'm not clear on the required refactoring (apart from the specific points mentioned). I didn't have anything particular in mind; it just felt like the existing code has grown rather than being designed. Don't worry about it. Are you interested in working more on this? I'm happy to make the fixes and improvements you've suggested. Great, thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1363#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop -+-- Reporter: tibbe |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by tibbe): That looks much better. I'll stil need to figure out if I can get `test2` to be strict in the buffer, as there's lots of reboxing going on. That's outside the scope of this ticket. Could we get this example turned into a test case? I'm not sure how to write one, otherwise I would do so myself. We'll likely depend on the arity analysis in the future, both in `binary` and `attoparsec`, and it would be nice to be confident that the performance of those libraries don't degrade dramatically in some future GHC version. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file
#4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while
relocating object file
--+-
Reporter: igloo| Owner:
Type: bug | Status: closed
Priority: high | Milestone: 7.0.3
Component: Compiler |Version: 6.13
Resolution: fixed| Keywords:
Testcase: | Blockedby:
Difficulty: | Os: MacOS X
Blocking: | Architecture: x86
Failure: Building GHC failed |
--+-
Changes (by igloo):
* status: new = closed
* resolution: = fixed
Comment:
Should be fixed for old versions of OS X by
{{{
Fri Feb 25 18:43:58 GMT 2011 Ian Lynagh ig...@earth.li
* Turn off split objects on Darwin if XCode 3.2 (#4013)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4013#comment:24
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter: pturnbull |Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.0.2
Component: GHCi| Version: 6.12.3
Keywords: MVar| Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
---+
Changes (by paterno):
* version: 7.0.1 = 6.12.3
* os: Unknown/Multiple = MacOS X
* architecture: x86 = x86_64 (amd64)
Comment:
I can verify this problem appears in the Mac OS X release as well.
My output is below.
{{{
bash-$ uname -a
Darwin thomas 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:11:58 PST
2010; root:xnu-1504.9.26~3/RELEASE_X86_64 x86_64
bash-$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude
[1]+ Stopped ghci
bash-$ fg
ghci
^C^C
Prelude
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.3 for i386-apple-darwin):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4245#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.0.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by tibbe):
Actually, I can unbox `Buffer` by redefining `empty` like so:
{{{
empty :: Builder
empty = Builder (\ k b - b `seq` k b)
{-# INLINE empty #-}
}}}
That gives me a perfect loop in the previous example. However,
redefining `empty` in the real `Data.Binary.Builder` module doesn't work.
The extra `seq` gets in the way of the arity analysis. I've attached
`Repro3.hs`, which is very similar to the code I posted previously except
that now includes code to allocate a new buffer when needed (that part was
stubbed out in the above example).
If I don't add the `seq` to `empty` the arity analysis works, but `Buffer`
gets passed around boxed. If I add the `seq` I get an unboxed `Buffer`,
but the arity analysis fails and I get a closure allocated on each
iteration of the loop.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop
#4978: Continuation passing style loop doesn't compile into a loop -+-- Reporter: tibbe |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by djahandarie): * cc: djahandarie@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4978#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1363: Sourcing multi-line scripts in GHCi: track line numbers, and bail out after first error
#1363: Sourcing multi-line scripts in GHCi: track line numbers, and bail out after first error -+-- Reporter: Frederik |Owner: vivian Type: feature request | Status: patch Priority: normal|Milestone: _|_ Component: GHCi | Version: 6.6 Keywords: multiline script | Testcase: Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by vivian): It would be good to have a test or two for `:script`, and also for the filenames and line numbers in errors. The test patch on this trac page has a test 'tests/ghc- regress.ghci/prog011' which (i) tests that the :script command works, (ii) generates an error in the script. The linenumber and filename of the location of the error are correctly reported. `sourceConfigFile` ought to set `progname` too. I can't seem to find `sourceConfigFile` (using find | grep) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1363#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
