Dude, you rock. Totally.
On Tue, Sep 8, 2009 at 08:47, JP Moresmau<jp@...> wrote:
> - add a "output" parameter to the loadComponent method in scion. This
> turns on generation option for Ghc
> - also in scion, specify the output name of the final file inside the
> dist directory (otherwise it would generate an exe in the middle of
> source folders)
You should discuss your changes to Scion with nominolo, so he can pull
them and roll them into the next release.
> - so in eclipsefp the background type checking doesnt change and still
> uses load (on the file) and background type check
> - but the build process configures the cabal project, lists all
> components and loads them with the output parameter sets to true. We
> then let ghc figure out what needs to be recompiled. This means we
> don't compile and output individual files but rather the components
> (exe, librairies)
> This means the compilation is based on the Cabal file settings rather
> than the preferences GHC settings, which is in my opinion a good
> thing: I want to configure my project's options only once, and that's
> in the Cabal file that I'll need anyway for Hackage upload and such.
True. There is one concern I had about *requiring* the use of Cabal,
which is that it could overwhelm beginning Haskell programmers. But if
no editing of the Cabal file is needed to compiler basic programs, and
the UI is friendly enough to do basic editing, then it will just be
two more "magic" files in the project tree, and this might not be much
of an issue.
> I ran into issues with job scheduling that required little changes in
> the ScionCommand class, and more serious issues with the scion server
> output handling (if the output was too big as in the result of
> Configure, the thread just hung). I've added a thread to read the
> output and print it in the Scion Server console (since the GHC
> compilation console is of no use anymore).
> The default dist folder in eclipse fp is dist-scion (without the
> leading dot) so that you can see it in the Project explorer in eclipse
> (it's automatically refreshed after the build).
> So now I basically need to remove all obsolete preferences page (for
> GHC options, etc) and put the same type of GUI in the Cabal editor so
> that we can specify all options easily in there (we could of course
> keep the GHC preferences page as some kind of defaults for all
> projects).
Or provide that page in the Project Properties window instead, and
have it modify the Cabal file directly? I think it is more Eclipse-y
to put these things into Project Properties, than to have a separate
editor for them. (For advanced stuff, the text editor with Cabal
highlighting should stay, of course.)
> For the moment the form part of the Cabal editor doesn't
> work for me (it doesn't show anything, not even the name), don't know
> if that's normal.
Normal, in the sense of "known bug":
http://sourceforge.net/tracker/?func=detail&aid=2849407&group_id=108233&atid=1000719
As to this, and later posts in this thread (refactoring support),
there seems to be a common pattern: we want to make some modification
to one or more source files, and want to let Scion decide what the
exact modification will be. We have two options:
1. Let Scion modify the file(s) directly. This means (to prevent
losing unsaved changes) that the IDE has to save the file before
sending any "modify" command to Scion. That might be an issue in some
cases.
2. Let Scion decide what needs to be changed, but let the IDE perform
the actual changes. This means that Scion would send some kind of diff
over the wire. However, this diff would be based upon the on-disk
version of the file, so would also require saving. Unless we send the
entire unsaved file over the wire, have Scion modify it, and send the
entire modified file back. Or the diff format could be made flexible
enough to work around modifications that have been made in the
meantime.
Note that the IDE does not always know in advance which files would
need changing! For example, if a function is renamed, it also needs to
be renamed in all files where it occurs, but the IDE might not know
which files these are. (A "findAllReferences" function in Scion,
returning the text span of every occurrence in every file, would be
almost as good as a "rename" command but not have this problem, but
you get the point.)
These are just some things to think about; I'm not sure myself which
option is best.
> I haven't looked at the outline view, but I see that dumpDefinedNames
> seems to have all the info I need, so I'll probably just need to add
> another command based on that in the scion interface.
I'm not sure if that command also lists definitions that are not in
the global scope, e.g. in "where" clauses. If not, a new command could
be added to Scion for this.
> Any feedback welcome... I'm not too familiar with github, but I
> suppose I can push all of that to my fork and let Thomas see if he
> likes it...
I like it already!
Leif, if you're reading this, is it okay if I add JP to the SF.net
project so he can update the website and push out new versions and
such?
Thomas
|