osx install fail

[erik flister]

>> The first time it runs Leksah indexes all your source so it can take some
>> time (even if it is only looking in .hi files).  It can take some time.
>
> i don't currently have the library source (my ghc install is from
> earlier, and was cleaned -- do you know of a way to 'unclean' to get
> the source back in the right place w/o rebuilding, which takes forever
> iirc?).

note that even without -k, macports leaves a lot of stuff around you
could make use of -

archived source (the manual says you are happy with archived source
from cabal, so...):
/opt/local/var/macports/distfiles/ghc/

libraries:
/opt/local/lib/ghc-6.10.3/

html docs:
/opt/local/share/ghc-6.10.3/doc/ghc/libraries/

huh, i do see a bunch of .pack files in ~/.leksah/ghc-6.10.3, tho i
never told leksah how to find them and don't recall it taking time to
build them.  these are not very human readable -- do they just contain
type signatures?  that's the only info leksah seems to have access to
regarding the libraries.

> Oh sorry, I forgot to say the script needs to be run from the root folder
> when launching from terminal.  Does it work ok from finder now too?

nope -- i didn't do anything that would fix that, right?

> but am I correct in thinking app itself is working ok now (not just
> launching and crashing or anything)?

the .app runs if i run /Applications/Leksah.app/Contents/MacOS/Leksah
from root dir.  cabal's leksah now runs from anywhere.

i just noticed that building all that stuff with +no_x11 means i can
no longer run gtk-chtheme:

erik-flisters-macbook-pro:~ eflister$ gtk-chtheme
dyld: Library not loaded: /opt/local/lib/libgtk-x11-2.0.0.dylib
  Referenced from: /opt/local/bin/gtk-chtheme
  Reason: image not found
Trace/BPT trap

all right, i fooled around with it all night and it turned into a
major QA session.  i don't have the energy to look through your trac
and enter all these, but here's a very long list of issues.

i was playing with candy, cool.  it works to set the candy file to
~/.cabal/share/leksah-0.6.1/data/Default.candy, but then the app
cannot relaunch after closing, claiming to to be able to see the file,
and had appended an extra '.candy' suffix -- but removing the extra
suffix from ~/.leksah/Default.prefs didn't fix it, i had to manually
delete the file.  often, entering the exact same thing in the candy
box that worked before crashes the whole app with:
leksah: user error (widgetGetDrawWindow: no DrawWindow available (the
widget is probably not realized))

clicking Configurat/To Candy (what is that supposed to do?) crashes
the whole app too.

i like this feature though :)  only about half of the symbols showed
up in any one font -- and it varied by font.  the ones that didn't
show up would often corrupt the following character, etc -- any way to
get this more robust?  maybe ship w/ a worst-case set of symbols to
show in case a given one isn't in the current font?  or a default font
that has all the symbols?  if you search for "definition" on this
page: http://en.wikipedia.org/wiki/Table_of_mathematical_symbols, see
if you agree with me that triple- vs. double-lined equals sign should
be flipped from your current usage.

btw, it would be nice to be able to filter the font list to show only
fixed width fonts, maybe include a preview to quickly asses if any of
the candy glyphs are missing.  and in general i'd like control over
syntax coloring, background color, opacity, etc.  why don't colors
distinguish, say, functions, class names, patterns/arguments,
keywords, syntactic elements/operators, etc?  i seem to only have
colors that distinguish types, comments, pragmas, escaped chars in
strings (a bit odd that it sees haddock-escaped items in comments?),
and literals (using oblivion).  the others seem to have an additional
category for keywords/syntactic elements (but misses ->, comma, round,
square, and curly braces).

relatively serious problems:
-leksah doesn't show up in my command-tab list (this is URGENT!)
-often when using expose (osx's feature that lets you see all open
windows and select one), it doesn't work the first time -- the first
click raises the window one below the current top window, and the
proces has to be repeated to actually raise leksah to the top.
-there are major window resizing problems -- it sometimes starts
changing the whole window when i'm just dragging a pane boundary, it
grows larger than the screen, etc.  after this happens one has to work
maximized or restart.
-sometimes when there are multiple files open, it gets stuck on one
and won't let me tab to the others.  resizing the window seems to fix
it.
-Package/Recent Packages never populated
-in Build Info, the wording "non-exposed or non-main modules" is
insanely confusing.  can't this be deduced from the exposure setting
in Library anyway?  i have a non-Main module (that DOES contain the
main function for one of my executable targets) that i don't want
exposed, but i do want it to show up in my module list so i can
navigate to it easily.  i can't figure out how to get that to happen.
(it contains quickcheck tests).  also, since it is a non-Main main, i
can't get it to run at all.  (prior to importing it into a cabal
package via leksah, i just had it be a Main main but with a
non-Main.hs file name, and ghc/ghci were happy with it.)
-why is the info pane editable?
-i can't get the option-command shortcut for toggling on/off a comment
to do anything.  when inserting a "--", remove 2 spaces so that the
code is still lined up nice.
-i can't get the command-option-r shortcut for running to do anything.
-need a keyboard shortcut to line up indentation of this line with
previous one -- better yet, an auto indent of selection feature that
does some best-practice indenting (preserve current layout semantics).
-cutting a whole line doesn't cut out its newline
-the type-ahead popup box can get in a state where it doesn't hilight
the current selection, which makes it very hard to tell what one is
choosing.
-having the type-ahead box occur while editing a comment is unhelpful.
-the formatting of the info pane/typeahead box can be very bad,
seemingly unrelated to the formatting in the source.

here's my source:
data Note = Note {
      pitchClass :: PitchClass
    , oct        :: Octave
    } deriving(Eq, Show)

and here's what shows up in the type-ahead box for "No...." (huh!??!
why do we need two statements of the signature?  why is there a big
newline and awkward tabbing in the middle of the definition of Note?
why are field names separated from their types?  why not use ! in
place for strict?  this is also what info looks like, except it
doesn't show the first two lines.)  this is a big problem in the
type-ahead-box where bad formatting makes it hard to scan/understand a
long list of possible matches.

-- | hTheory-0.1:Theory
PitchClass -> Octave -> Note
-- | hTheory-0.1:Theory
data Note
            = Note :: PitchClass -> Octave -> Note
          Stricts: _ _
          Fields: pitchClass oct

this should instead be a one liner like (with !'s in place on any stricts):
data Note {pitchClass :: PitchClass, oct :: Octave} instance of Eq,
Show, <others...> (from: hTheory-0.1:Theory.hs)

even better would be to separate the kind, type signature, instance
listing, and source separated into grid columns.

in the info pane i think you should use the formatting supplied by the
source.  even better would be haddock html, including the instance
listing.

-i have some problem in my code that may be an infinite loop -- it
causes a print out like:
executable name:<<loop>>
but it is printed out first in the output, rather than at the expected
sequential location, so easily missed.  btw, how is this detected?
it's unexpected to have it detected and killed for me -- i would
rather it just obviously hung at the corresponding spot in the output
(with ctrl-c to kill it).  trying to replicate this with something
like print [1..] just results in a hang that one can't do anything
about, but eventually it recovers on its own...  one wants ghci
behavior here -- spew out text, ctrl-c for killing, etc.
-having to click on configure and then build is annoying -- build
should just configure if it needs to.  because the build button is
active even during configuration, building can then interrupt the
configuration.
-run button is confusing -- it's active even after a clean, but does
nothing and does not trigger a build.  also, if there has been a
successful build, it runs that version even if there is currently an
error preventing a new build, making this condition hard to notice and
understand.
-currently highlighted item in context menu completely disappears
rather than being highlighted (turns to white text on very light
background, at least under oblivion/my clearlooks theme (can't
remember what i picked and i can't run chtheme anymore).
-can't list all references to ==, for instance.  if there's going to
be a reference pane, i think you should be able to do this rather than
expecting user to use search.  a list of matches w/contexts to scan
through is often nicer than stepping through one match at a time.
-candy doesn't work in the info or interface panes.
-why no typeahead in import statements?

minor items:
-things that should use the command ("apple") key are mapped to ctrl by default
-the manual says to use the .gtkrc-2.0 file, but it isn't in the
leksah-0.6.1/data/ downloaded from hackage, or
http://code.haskell.org/leksah/data/, or in
~/.cabal/share/leksah-0.6.1/data/
-i haven't set up XDG_DATA_DIRS -- what symptoms should this cause?
-welcome.txt isn't showing up
-i strongly prefer that the save icon be disabled when the file is not dirty
-in the open package dialog, grey out non- .cabal files
-why not include the base dependency by default?
-allow file/page/line/word cursor key commands
(ctrl-a,ctrl-e,meta-f,meta-b, etc)
-the "Update meta info for active package" message in the log is
confusing -- is it an instruction to the user?  clicking the green
button doesn't seem to do anything.  it's unclear when meta data
should be updated -- disable the green button if meta data is up to
date, and auto-update the meta data if possible.
-the X toolbar button next to 'save' has no tooltip, and feels like
it's going to delete something rather than close it.  it's unnecessary
cuz each file has its own close button in the tab.
-when two files with same name (but from different directories) are
open, just having (n) appended to one of them isn't good (what if file
were really named that?  and closing one and reopening it increments
its n!) -- show its path on rollover instead or something.
-building should not boot the user out of their current editing tab to
an Errors tab -- what is the point of an errors tab instead of the Log
anyway?
-when a pane is empty, hide it rather than leaving a big blank space
for the user to drag away.  dockable/rearrangable panes would be nice.
 i thought that was one of the features you were touting?

feature requests:
-easy links to documentation describing LANGUAGE pragmas would be
great! (ie, in the compiler error that suggests it, right click
options to see documentation on them, add them to the package, or add
them to the file's header, etc.  if it's already in the file header,
right click it to get docs, etc.  same idea for compiler options.
-alphabetical order of editor tabs may not be what the user wants --
allow drag rearrangement.
-clicking on a red underlined error in the editor should set the log
focus to that error.
-allow log-clickable links to haddock errors.  include haddock doc gen
in the normal build, and once doc is generated, have some easy way to
link/view it (cross referenced with each module/function/class, etc).
use this instead of the info pane.  for doc building, include
hscolourized src with anchors (see haddock flags at
http://www.cs.york.ac.uk/fp/darcs/hscolour/).
-right click function usage in editor or mention in info pane to go to
info pane for its definition/doc/type sig, etc.  (type, kind, and info
are always disabled in my editor context menu)
-double clicking on a reference just does a text search (ie, includes
comments, non-case/fullword matches, etc) -- should just go to actual
usages.  also, it doesn't start searching from current cursor
location, sometimes jumps to a whole different file!
-allow sorting the interface pane by type
-background building is cool, but every keystroke seems excessive --
how about waiting for braces to be balanced, notice that the user is
working on non-commented text, typing to stop for a second or so, etc.
 the aggressive autosaving this does is also worrying, seems easy for
stray accidents to get saved and hard to notice/recover from.  i know
one can turn off autobuilding, but it's cool, so finding a way to make
it safe and unobtrusive (flickering messages scrolling by in the log
as you type is disconcerting).
-special coloring for haddock formatted comments would be great.  also
special coloring for identifiers from outside the current package.
-undo/redo buttons should be disabled when there's nothing to
undo/redo, and a dropdown list specifying exactly the actions that
will be un/redone would be good.

serious problems:
-i had multiple crashes that reported a bus error.  my sense is that
it's either building or leksah figuring out how many build infos to
make that caused this, but it only happens rarely -- there are lots of
non-crashing occurances of 'extracted infos', so i'm not sure what's
the cause.

-the display (for one file only) frequently gets in a mode where it
would fail to update when i moved the cursor, or selected some text --
nothing happens (screen looks frozen).  but the update would show up
when i resized, clicked on a module name, etc.  i think typing was
only showing up due to the incremental building that every keystroke
triggers.  have to close and reopen entire app (not just that file) to
get out of this mode.  it happens a lot and is very annoying!  may be
related to this (i get lots of these, but they don't all seem to cause
it):
(leksah:62534): Gdk-CRITICAL **: gdk_cursor_unref: assertion `cursor
!= NULL' failed

or i get lots of these too -- maybe it's them:
leksah: waitForProcess: does not exist (No child processes)

(leksah:63495): Gtk-WARNING **: Invalid text buffer iterator: either
the iterator is uninitialized, or the characters/pixbufs/widgets in
the buffer have been modified since the iterator was created.
You must use marks, character numbers, or line numbers to preserve a
position across buffer modifications.
You can apply tags and insert marks without invalidating your iterators,
but any mutation that affects 'indexable' buffer contents (contents
that can be referred to by character offset)
will invalidate all outstanding iterators

(leksah:63495): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion
`gtk_text_iter_get_buffer (iter) == buffer' failed


-i can't get the debugger to work.  i followed the manual instructions
for hello world to the letter, but 'evaluate' (and the other
debug-related options in the Debug/context menus) is always greyed
out.  this is with or without the button pressed for "use GHCI
debugger to build and run" (which is not specified in the hello world
part of the manual).  i think a better design than a button would just
be menu items for "run" vs. "debug".  visual debugging was my whole
reason for interest in leksah!  :)

-one needs easy access to a ghci session with the current package
modules (and their imports?) in scope for interactive
development/testing.  is this the idea behind the large editable area
at the top of the debugging panel -- a scratchpad for executable lines
to evaluate in ghci?  cuz that would be exactly what i want, but right
now it doesn't do anything.

-there's occasionally a serious space leak somewhere -- memory usage
skyrockets and my system starts thrashing badly if i don't close the
app.  might have to do with getting into loops, but the memory isn't
freed.

anyway, lots of niggles, but all-in-all it's looking pretty sweet.

-e