From: JP M. <jp...@mo...> - 2009-09-28 06:58:49
|
Hello all, I have got the oultine view and code folding functions working again. I have extended Scion with an outline command, which returns the information needed to display the outline tree, with each top level declaration and its enclosing block, used for folding. For the moment, data declarations with constructors and fields, class declarations with methods, instances, functions and other type declarations (type, newtype) are handled. It doesn't show the module, fixity or import statements as the old eclipsefp did, but I don't think that's critical. You can choose location based or name based sorting in the outline view. As usual, to get all of this, you need to get both the eclipse fp code and the Scion code from my githubs repositories: git://github.com/JPMoresmau/scion.git git://github.com/JPMoresmau/eclipsefp.git Good luck! JP -- JP Moresmau http://jpmoresmau.blogspot.com/ |
From: Thomas t. C. <tte...@gm...> - 2009-09-28 07:14:01
|
Great job! Maybe I'll grab a copy tonight and start playing with it. Any plans on what your next work will be? Thomas On Mon, Sep 28, 2009 at 08:58, JP Moresmau <jp...@mo...> wrote: > Hello all, > > I have got the oultine view and code folding functions working again. > I have extended Scion with an outline command, which returns the > information needed to display the outline tree, with each top level > declaration and its enclosing block, used for folding. For the moment, > data declarations with constructors and fields, class declarations > with methods, instances, functions and other type declarations (type, > newtype) are handled. It doesn't show the module, fixity or import > statements as the old eclipsefp did, but I don't think that's > critical. > You can choose location based or name based sorting in the outline view. > > As usual, to get all of this, you need to get both the eclipse fp code > and the Scion code from my githubs repositories: > git://github.com/JPMoresmau/scion.git > git://github.com/JPMoresmau/eclipsefp.git > > Good luck! > > JP > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
From: JP M. <jp...@mo...> - 2009-09-28 07:39:49
|
Mmhhh, I think maybe things to do with source folders and module handling. For the moment you can configure one source folder for a project, but when you create a new module in it or in a subfolder, scion doesn't pick it up and the background type check operation fails. The thing is that you can have several source folders for one given project (Scion is a perfect example of that: one folder for the library, one folder for the server), and that you need to referenced new modules in the Cabal file as well. So I think we need to change this. We need to keep the Cabal file in sync when adding remove modules (via other-modules, exposed-modules...) and we need to handle multiple source folders as indicated by hs-source-dirs. This is pure Java/Eclipse dev. Then I suppose a good feature to add would be to be able to type check, outline, fold etc. without saving the file, which would involve work on the Scion side. JP On Mon, Sep 28, 2009 at 9:13 AM, Thomas ten Cate <tte...@gm...> wrote: > Great job! Maybe I'll grab a copy tonight and start playing with it. > > Any plans on what your next work will be? > > Thomas > > On Mon, Sep 28, 2009 at 08:58, JP Moresmau <jp...@mo...> wrote: >> Hello all, >> >> I have got the oultine view and code folding functions working again. >> I have extended Scion with an outline command, which returns the >> information needed to display the outline tree, with each top level >> declaration and its enclosing block, used for folding. For the moment, >> data declarations with constructors and fields, class declarations >> with methods, instances, functions and other type declarations (type, >> newtype) are handled. It doesn't show the module, fixity or import >> statements as the old eclipsefp did, but I don't think that's >> critical. >> You can choose location based or name based sorting in the outline view. >> >> As usual, to get all of this, you need to get both the eclipse fp code >> and the Scion code from my githubs repositories: >> git://github.com/JPMoresmau/scion.git >> git://github.com/JPMoresmau/eclipsefp.git >> >> Good luck! >> >> JP >> >> -- >> JP Moresmau >> http://jpmoresmau.blogspot.com/ >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> eclipsefp-develop mailing list >> ecl...@li... >> https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > -- JP Moresmau http://jpmoresmau.blogspot.com/ |
From: Thomas t. C. <tte...@gm...> - 2009-09-28 09:55:58
|
On Mon, Sep 28, 2009 at 09:39, JP Moresmau <jp...@mo...> wrote: > Mmhhh, I think maybe things to do with source folders and module > handling. For the moment you can configure one source folder for a > project, but when you create a new module in it or in a subfolder, > scion doesn't pick it up and the background type check operation > fails. The thing is that you can have several source folders for one > given project (Scion is a perfect example of that: one folder for the > library, one folder for the server), Distribution.PackageDescription.BuildInfo supports multiple source folders, yes. But Scion is a bad example, because that's two separate Cabal packages, and hence it would be two separate projects. That is, assuming you'll want to keep the 1:1 relation between EclipseFP projects and Cabal packages... but I see no reason to change this. But there can be multiple executables/libraries produced from a single Cabal project, which is what I was trying to capture in my buildtargets branch. > and that you need to referenced > new modules in the Cabal file as well. So I think we need to change > this. We need to keep the Cabal file in sync when adding remove > modules (via other-modules, exposed-modules...) and we need to handle > multiple source folders as indicated by hs-source-dirs. Yah. Would be cool if you could just right-click a module and click "Expose" or something? If there are multiple libraries defined in the Cabal file, this would need to fold out to a submenu, allowing you to choose. And have the icon change to show which modules are exposed? By the way, I can make icons, if you don't feel like doing them. Just tell me what you need. > This is pure Java/Eclipse dev. Then I suppose a good feature to add > would be to be able to type check, outline, fold etc. without saving > the file, which would involve work on the Scion side. Yes, that'd be of great value. Thomas |
From: JP M. <jp...@mo...> - 2009-09-29 07:51:38
|
I don't think I understand what you're saying about Scion and multiple Cabal packages. I would have thought the 1:1 relationship was between a cabal file and an Eclipse project. I'm not sure it'd be great to have to have two different projects in Eclipse to develop the Scion library and the Scion server, since both are using the same lib folder, you'll be able to open the same file in the two different projects. Of course if you keep a 1:1 relationship between the cabal file and the eclipse project you may have different flags and options for the same source file, depending on the target, I suppose that's what you addressed in your branch. But scion is actually managing that, I suppose: when we typecheck a file, scion figures out the flags to use. I see that the IHaskellProject interface supports already multiple source locations, so it probably shouldn't be a bug job to make sure that list is actually linked to the Cabal info, and displayed in the new module dialog box. JP On Mon, Sep 28, 2009 at 11:55 AM, Thomas ten Cate <tte...@gm...> wrote: > On Mon, Sep 28, 2009 at 09:39, JP Moresmau <jp...@mo...> wrote: >> Mmhhh, I think maybe things to do with source folders and module >> handling. For the moment you can configure one source folder for a >> project, but when you create a new module in it or in a subfolder, >> scion doesn't pick it up and the background type check operation >> fails. The thing is that you can have several source folders for one >> given project (Scion is a perfect example of that: one folder for the >> library, one folder for the server), > > Distribution.PackageDescription.BuildInfo supports multiple source > folders, yes. But Scion is a bad example, because that's two separate > Cabal packages, and hence it would be two separate projects. That is, > assuming you'll want to keep the 1:1 relation between EclipseFP > projects and Cabal packages... but I see no reason to change this. > > But there can be multiple executables/libraries produced from a single > Cabal project, which is what I was trying to capture in my > buildtargets branch. > >> and that you need to referenced >> new modules in the Cabal file as well. So I think we need to change >> this. We need to keep the Cabal file in sync when adding remove >> modules (via other-modules, exposed-modules...) and we need to handle >> multiple source folders as indicated by hs-source-dirs. > > Yah. Would be cool if you could just right-click a module and click > "Expose" or something? If there are multiple libraries defined in the > Cabal file, this would need to fold out to a submenu, allowing you to > choose. And have the icon change to show which modules are exposed? > > By the way, I can make icons, if you don't feel like doing them. Just > tell me what you need. > >> This is pure Java/Eclipse dev. Then I suppose a good feature to add >> would be to be able to type check, outline, fold etc. without saving >> the file, which would involve work on the Scion side. > > Yes, that'd be of great value. > > Thomas > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > -- JP Moresmau http://jpmoresmau.blogspot.com/ |
From: Thomas t. C. <tte...@gm...> - 2009-09-29 14:12:11
|
On Tue, Sep 29, 2009 at 09:51, JP Moresmau <jp...@mo...> wrote: > I don't think I understand what you're saying about Scion and multiple > Cabal packages. I would have thought the 1:1 relationship was between > a cabal file and an Eclipse project. Yes, this is what I meant. > I'm not sure it'd be great to > have to have two different projects in Eclipse to develop the Scion > library and the Scion server, since both are using the same lib > folder, you'll be able to open the same file in the two different > projects. Ah, I understand the confusion. Up until right before I stopped working on EclipseFP, Scion consisted of two separate Cabal packages: one for the library, one for the standalone server program. This was inconvenient, because it required you to "cabal install" the library before you could even build the server. These packages were merged around the time I stopped pulling nominolo's changes, but I forgot about that. > Of course if you keep a 1:1 relationship between the cabal > file and the eclipse project you may have different flags and options > for the same source file, depending on the target, I suppose that's > what you addressed in your branch. But scion is actually managing > that, I suppose: when we typecheck a file, scion figures out the flags > to use. What I addressed in my branch was to support multiple targets in the first place, and the UI to add/delete/modify targets. And yes, the same source file could be used for multiple targets. I'm not sure how Scion handles this. Actually, it doesn't really make sense to ask it to typecheck a file, without specifying the parameters or the target whose parameters should be used... > I see that the IHaskellProject interface supports already multiple > source locations, so it probably shouldn't be a bug job to make sure > that list is actually linked to the Cabal info, and displayed in the > new module dialog box. Yep, that sounds sensible. If "New module" was invoked through the context menu of the Project Explorer, this should be filled out with the directory (or parent) of the thing that was right-clicked. For example, if I have source directories src1, src2, and I right-click on src2/some/dir and choose "New module", then the module should by default be created in src2. In other cases (e.g. invoked through the main menu), you could just remember the previous value. Thomas |