New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Associate session with a lang config file #1957

Open
miguel-negrao opened this Issue Apr 7, 2016 · 18 comments

Comments

Projects
None yet
5 participants
@miguel-negrao
Member

miguel-negrao commented Apr 7, 2016

I would like to propose to associate each session with a lang config file, such that changing the session will/could change the config lang file also.

For those that always use the same config file this won't change anything, those that don't I think would profit from this since a different session tends to be associated with a different config file anyway. This would avoid having to do this manually, which is the way things currently work.

This is how Qt Creator works, there if I open the supercollider project it will not restore the previously opened windows, but If I open my last session it will open the previously opened windows and load the project I was working on.

This would also be useful for my proposed "projects" feature, where you are definitely working with a different config file (the project).

If there are situations where people think this is a bad idea, it could be configurable.

So, I'm asking for input on this.

@jamshark70

This comment has been minimized.

Show comment
Hide comment
@jamshark70

jamshark70 Apr 9, 2016

Contributor

If you switch to a session that uses a different config file, you'll have to recompile the class library. Should this be:

  • Automatic?
  • Prompted? ("This session uses a different language configuration file, so the class library must be recompiled. Do it now? [Yes] [I'll do it later] [Cancel session load]")
  • Totally manual (user's responsibility)?

If two sessions use the same config file, you might want to keep the language state (no recompile)... or it might be confusing that loading a session sometimes recompiles and sometimes doesn't.

Contributor

jamshark70 commented Apr 9, 2016

If you switch to a session that uses a different config file, you'll have to recompile the class library. Should this be:

  • Automatic?
  • Prompted? ("This session uses a different language configuration file, so the class library must be recompiled. Do it now? [Yes] [I'll do it later] [Cancel session load]")
  • Totally manual (user's responsibility)?

If two sessions use the same config file, you might want to keep the language state (no recompile)... or it might be confusing that loading a session sometimes recompiles and sometimes doesn't.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 9, 2016

Member

If you switch to a session that uses a different config file, you'll have to recompile the class library. Should this be:

Automatic?
Prompted? ("This session uses a different language configuration file, so the class library must be recompiled. Do it now? [Yes] [I'll do it later] [Cancel session load]")
Totally manual (user's responsibility)?

I think it should just warn, and leave it to the user to reboot the interpreter (It's not just recompiling library, the interpreter should be restarted for the new lang file to take effect, I think). Currently changing lang file gives no warning nor does it reboot the interpreter. Editing the lang file gives a warning ("The SuperCollider language configuration has been updated. Reboot the interpreter to apply the changes."). Opening a project will just warn that the interpreter should be restarted as well. I would say do the same thing when changing session.

Member

miguel-negrao commented Apr 9, 2016

If you switch to a session that uses a different config file, you'll have to recompile the class library. Should this be:

Automatic?
Prompted? ("This session uses a different language configuration file, so the class library must be recompiled. Do it now? [Yes] [I'll do it later] [Cancel session load]")
Totally manual (user's responsibility)?

I think it should just warn, and leave it to the user to reboot the interpreter (It's not just recompiling library, the interpreter should be restarted for the new lang file to take effect, I think). Currently changing lang file gives no warning nor does it reboot the interpreter. Editing the lang file gives a warning ("The SuperCollider language configuration has been updated. Reboot the interpreter to apply the changes."). Opening a project will just warn that the interpreter should be restarted as well. I would say do the same thing when changing session.

@nuss

This comment has been minimized.

Show comment
Hide comment
@nuss

nuss Apr 9, 2016

Contributor

I'm somewhat sceptical about this proposal: A session is basically an arrangement of open files, isn't it? So, one can easily open any file from within any session. But if each session can be associated with a different config file, i. e. especially different include and exclude paths, I dare to predict that will lead to confusion. Think of a situation where you created some file in some session which has been associated with some dedicated config. You forget about file, session etc.. You go on working with on other stuff in other sessions. You find that old session at some point and decide to delete it. Some time later you find that file again that you worked on in the meanwhile deleted session. Ok, you just open it in some other session. But surprise, surprise, it doesn't work any more as the config doesn't fit. Now, you reconfigure that session so the code in your file works again. However, the new config doesn't fit for the other files in the session any longer...

My suggestion: Leave the sessions implementation as it is. If one wants to think about real project management - good - but keep it separate from sessions. Sessions do make sense for their simplicity I think but I don't think they weren't meant for real project management.

Just my 2c

Contributor

nuss commented Apr 9, 2016

I'm somewhat sceptical about this proposal: A session is basically an arrangement of open files, isn't it? So, one can easily open any file from within any session. But if each session can be associated with a different config file, i. e. especially different include and exclude paths, I dare to predict that will lead to confusion. Think of a situation where you created some file in some session which has been associated with some dedicated config. You forget about file, session etc.. You go on working with on other stuff in other sessions. You find that old session at some point and decide to delete it. Some time later you find that file again that you worked on in the meanwhile deleted session. Ok, you just open it in some other session. But surprise, surprise, it doesn't work any more as the config doesn't fit. Now, you reconfigure that session so the code in your file works again. However, the new config doesn't fit for the other files in the session any longer...

My suggestion: Leave the sessions implementation as it is. If one wants to think about real project management - good - but keep it separate from sessions. Sessions do make sense for their simplicity I think but I don't think they weren't meant for real project management.

Just my 2c

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 9, 2016

Member

I'm somewhat sceptical about this proposal: A session is basically an arrangement of open files, isn't it?

Yup, together with window geometry info.

So, one can easily open any file from within any session. But if each session can be associated with a different config file, i. e. especially different include and exclude paths, I dare to predict that will lead to confusion. Think of a situation where you created some file in some session which has been associated with some dedicated config. You forget about file, session etc.. You go on working with on other stuff in other sessions. You find that old session at some point and decide to delete it. Some time later you find that file again that you worked on in the meanwhile deleted session. Ok, you just open it in some other session. But surprise, surprise, it doesn't work any more as the config doesn't fit. Now, you reconfigure that session so the code in your file works again. However, the new config doesn't fit for the other files in the session any longer...

But the problem that you describe can already happen. If you use different config files, and if the file you are editing depends on a specific config file, then when you change the config file in the preferences the scd file will not work when you go back to it. In that respect this is already something the user has to manage manually, if your scd file need a specific config file it's up to you to make sure that config file is selected and loaded by the interpreter. All this change would do is use a specifc config file when you open the session instead of whatever was currently selected, which might not work for the session you just opened either.

I see more of an issue for people who do not associate config files with sets of files, and more with different version of the same libraries, for instance switiching between stable and unstable version of libraries. In that case, once they select a different config file they probably want it to apply to all sessions. Don't know how common is either usage (lang files which are the same for all sessions or specific for different sessions), would be good to hear on that.

Also, like I said at the start, this could be configurable and disabled by default.

Member

miguel-negrao commented Apr 9, 2016

I'm somewhat sceptical about this proposal: A session is basically an arrangement of open files, isn't it?

Yup, together with window geometry info.

So, one can easily open any file from within any session. But if each session can be associated with a different config file, i. e. especially different include and exclude paths, I dare to predict that will lead to confusion. Think of a situation where you created some file in some session which has been associated with some dedicated config. You forget about file, session etc.. You go on working with on other stuff in other sessions. You find that old session at some point and decide to delete it. Some time later you find that file again that you worked on in the meanwhile deleted session. Ok, you just open it in some other session. But surprise, surprise, it doesn't work any more as the config doesn't fit. Now, you reconfigure that session so the code in your file works again. However, the new config doesn't fit for the other files in the session any longer...

But the problem that you describe can already happen. If you use different config files, and if the file you are editing depends on a specific config file, then when you change the config file in the preferences the scd file will not work when you go back to it. In that respect this is already something the user has to manage manually, if your scd file need a specific config file it's up to you to make sure that config file is selected and loaded by the interpreter. All this change would do is use a specifc config file when you open the session instead of whatever was currently selected, which might not work for the session you just opened either.

I see more of an issue for people who do not associate config files with sets of files, and more with different version of the same libraries, for instance switiching between stable and unstable version of libraries. In that case, once they select a different config file they probably want it to apply to all sessions. Don't know how common is either usage (lang files which are the same for all sessions or specific for different sessions), would be good to hear on that.

Also, like I said at the start, this could be configurable and disabled by default.

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 9, 2016

Contributor

I think it's a clever idea! It would allow for some seamlessness of the config switch. And people who use sessions (not many, maybe) would be aware of what is going on. And the others would never notice the option and thus never have a problem with it.
An attractive aspect of this is that it sounds like an isolatable feature. But one might also want to think about it in the context of other "use multiple configurations" initiatives/considerations like:

  • new quarks system
  • sc Atom support, which in my understanding builds on a model in which an entire isolated sc-install is run in a single "project folder"
  • an attempt to implement the possibility to define different appSupportDirs for sc

Even the question how to run SC in a build environment could be seen as related.

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

Contributor

bagong commented Apr 9, 2016

I think it's a clever idea! It would allow for some seamlessness of the config switch. And people who use sessions (not many, maybe) would be aware of what is going on. And the others would never notice the option and thus never have a problem with it.
An attractive aspect of this is that it sounds like an isolatable feature. But one might also want to think about it in the context of other "use multiple configurations" initiatives/considerations like:

  • new quarks system
  • sc Atom support, which in my understanding builds on a model in which an entire isolated sc-install is run in a single "project folder"
  • an attempt to implement the possibility to define different appSupportDirs for sc

Even the question how to run SC in a build environment could be seen as related.

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 11, 2016

Member

An attractive aspect of this is that it sounds like an isolatable feature. But one might also want to think about it in the context of other "use multiple configurations" initiatives/considerations like:

new quarks system
sc Atom support, which in my understanding builds on a model in which an entire isolated sc-install is run in a single "project folder"
an attempt to implement the possibility to define different appSupportDirs for sc

Even the question how to run SC in a build environment could be seen as related.

Actually, I'm considering this change as part of a bigger change related to sclang standalone mode and the "projects" feature (#311). Depending on the feedback I get here I would implement this change as part of that pull-request or I wouldn't implement it. Also, @scztt has ideas on how to make that work nicely on OSX too via sclang apps.

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

How is that a weakness ?

Member

miguel-negrao commented Apr 11, 2016

An attractive aspect of this is that it sounds like an isolatable feature. But one might also want to think about it in the context of other "use multiple configurations" initiatives/considerations like:

new quarks system
sc Atom support, which in my understanding builds on a model in which an entire isolated sc-install is run in a single "project folder"
an attempt to implement the possibility to define different appSupportDirs for sc

Even the question how to run SC in a build environment could be seen as related.

Actually, I'm considering this change as part of a bigger change related to sclang standalone mode and the "projects" feature (#311). Depending on the feedback I get here I would implement this change as part of that pull-request or I wouldn't implement it. Also, @scztt has ideas on how to make that work nicely on OSX too via sclang apps.

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

How is that a weakness ?

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 11, 2016

Contributor

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

How is that a weakness ?

Well, ideally each sclang instance would know by itself which configuration to use. A standalone that isn't built to support editing and just runs as an app wouldn't want to ship the IDE. Using Atom/vim etc also doesn't require the IDE. I like the IDE, but I'd hesitate to reinforce the dependency on it...

Contributor

bagong commented Apr 11, 2016

If I don't misunderstand, a weakness of the current sclang-config-switch system is that it's bound to the IDE, you depend on the IDE config to point to the sclang-config.

How is that a weakness ?

Well, ideally each sclang instance would know by itself which configuration to use. A standalone that isn't built to support editing and just runs as an app wouldn't want to ship the IDE. Using Atom/vim etc also doesn't require the IDE. I like the IDE, but I'd hesitate to reinforce the dependency on it...

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 11, 2016

Member

Well, ideally each sclang instance would know by itself which configuration to use. A standalone that isn't built to support editing and just runs as an app wouldn't want to ship the IDE. Using Atom/vim etc also doesn't require the IDE. I like the IDE, but I'd hesitate to reinforce the dependency on it...

Hum, I'm not sure I am getting the issue. The config file is an argument of the sclang binary. If you want to make an sclang standalone, In linux you can just make a script for launching sclang with the appropriate lang config file, on OSX you can have an app bundle which does the same, uses a script to launch sclang with the appropriate lang file. Other editors can also launch sclang with an appropriate config file.

Member

miguel-negrao commented Apr 11, 2016

Well, ideally each sclang instance would know by itself which configuration to use. A standalone that isn't built to support editing and just runs as an app wouldn't want to ship the IDE. Using Atom/vim etc also doesn't require the IDE. I like the IDE, but I'd hesitate to reinforce the dependency on it...

Hum, I'm not sure I am getting the issue. The config file is an argument of the sclang binary. If you want to make an sclang standalone, In linux you can just make a script for launching sclang with the appropriate lang config file, on OSX you can have an app bundle which does the same, uses a script to launch sclang with the appropriate lang file. Other editors can also launch sclang with an appropriate config file.

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 12, 2016

Contributor

Hum, I'm not sure I am getting the issue.

Nor am I ;)

So there is a mechanism in sclang to run it with a defined set of libraries, which is using sclang with -l langconfigfile and optionally -a to make it "standalone", i.e. not look into the default extensions folder. I guess that is what you're referring to? I am guessing now: additionally to making sure the libraries are only from explicitly specified locations, one would also need a ways to control where generated helpfiles, synthdefs etc are stored. I assume the scripts you are referring to have a way of handling that...

So my overall question would be: could the IDE make use of such a given set of rules that allows for an autonomous sclang? And apart from whether it's possible, would it have disadvantages, like maybe missing out on integration features between scide and sclang?

Contributor

bagong commented Apr 12, 2016

Hum, I'm not sure I am getting the issue.

Nor am I ;)

So there is a mechanism in sclang to run it with a defined set of libraries, which is using sclang with -l langconfigfile and optionally -a to make it "standalone", i.e. not look into the default extensions folder. I guess that is what you're referring to? I am guessing now: additionally to making sure the libraries are only from explicitly specified locations, one would also need a ways to control where generated helpfiles, synthdefs etc are stored. I assume the scripts you are referring to have a way of handling that...

So my overall question would be: could the IDE make use of such a given set of rules that allows for an autonomous sclang? And apart from whether it's possible, would it have disadvantages, like maybe missing out on integration features between scide and sclang?

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 12, 2016

Member

Hum, I'm not sure I am getting the issue.

Nor am I ;)

Not trying to be difficult here, but I'm really not getting it still. :-)

So there is a mechanism in sclang to run it with a defined set of libraries, which is using sclang with -l langconfigfile and optionally -a to make it "standalone", i.e. not look into the default extensions folder. I guess that is what you're referring to?

Yes, it is.

I am guessing now: additionally to making sure the libraries are only from explicitly specified locations, one would also need a ways to control where generated helpfiles, synthdefs etc are stored.

Do you mean, in order to have a standalone SCIDE ? But if so, then we are discussing a different thing now, I was talking about a standalone sclang. A standalone SCIDE would require not looking for the SCIDE config file (sc_ide_conf.yaml) in the user library location, and indeed managing helpfiles differently also. I hadn't thought about the synthdefs location, indeed currently on an (old type) OSX standalone it loads synthdefs from the bundle resource folder, otherwise it loads it from the user library directory, which is not good for standalone sclang use (or standalone SCIDE use). A cmd line option could be added to scsynth/supernova to specify the synthdefs location.

So my overall question would be: could the IDE make use of such a given set of rules that allows for an autonomous sclang? And apart from whether it's possible, would it have disadvantages, like maybe missing out on integration features between scide and sclang?

Did you mean to say "an autonomous SCIDE" instead of "autonomous sclang" ? Or are you maybe referring to editing files and running code via guis, but without using the IDE, so only using sclang, and opening up the guis from sclang code ? I didn't get this one... can you explain more ?

Member

miguel-negrao commented Apr 12, 2016

Hum, I'm not sure I am getting the issue.

Nor am I ;)

Not trying to be difficult here, but I'm really not getting it still. :-)

So there is a mechanism in sclang to run it with a defined set of libraries, which is using sclang with -l langconfigfile and optionally -a to make it "standalone", i.e. not look into the default extensions folder. I guess that is what you're referring to?

Yes, it is.

I am guessing now: additionally to making sure the libraries are only from explicitly specified locations, one would also need a ways to control where generated helpfiles, synthdefs etc are stored.

Do you mean, in order to have a standalone SCIDE ? But if so, then we are discussing a different thing now, I was talking about a standalone sclang. A standalone SCIDE would require not looking for the SCIDE config file (sc_ide_conf.yaml) in the user library location, and indeed managing helpfiles differently also. I hadn't thought about the synthdefs location, indeed currently on an (old type) OSX standalone it loads synthdefs from the bundle resource folder, otherwise it loads it from the user library directory, which is not good for standalone sclang use (or standalone SCIDE use). A cmd line option could be added to scsynth/supernova to specify the synthdefs location.

So my overall question would be: could the IDE make use of such a given set of rules that allows for an autonomous sclang? And apart from whether it's possible, would it have disadvantages, like maybe missing out on integration features between scide and sclang?

Did you mean to say "an autonomous SCIDE" instead of "autonomous sclang" ? Or are you maybe referring to editing files and running code via guis, but without using the IDE, so only using sclang, and opening up the guis from sclang code ? I didn't get this one... can you explain more ?

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 12, 2016

Contributor

I think I am thinking of SCIDE as a pure text editor, which might be missing out on essentials I haven't realized yet. If scide used a configuration stored entirely with sclang, you could in theory just swap different autonomous sclang (or supercollider?) instances.

Contributor

bagong commented Apr 12, 2016

I think I am thinking of SCIDE as a pure text editor, which might be missing out on essentials I haven't realized yet. If scide used a configuration stored entirely with sclang, you could in theory just swap different autonomous sclang (or supercollider?) instances.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 12, 2016

Member

The SCIDE calls specific sclang class library methods. If you use a newer SCIDE with an older sclang, the older sclang might be missing those methods, or have them implemented differently and you get into an inconsistent state. Given this, I'm not sure how useful it would be being able to switch sclang binary in the same SCIDE instance.

The feature that you are referring to could be more or less easily added to SCIDE projects (the feature I'm working on). It would just require adding a 'sclangPath' key to the lang/project config file, which would be relative to the project folder, so it could be 'sclangPath:sclang' or 'sclangPath:sclang.app/Contents/MacOS/sclang' (don't remember exactly the structure of an OSX bundle...), then the IDE when opening a project would store the path to sclang and use that instead of the default 'sclang'. Another possibility would be to have a default path in the project directory for sclang, for instance just in the root folder, and then have a key 'useLocalSCLang:true' which would look for an sclang at that location.

Member

miguel-negrao commented Apr 12, 2016

The SCIDE calls specific sclang class library methods. If you use a newer SCIDE with an older sclang, the older sclang might be missing those methods, or have them implemented differently and you get into an inconsistent state. Given this, I'm not sure how useful it would be being able to switch sclang binary in the same SCIDE instance.

The feature that you are referring to could be more or less easily added to SCIDE projects (the feature I'm working on). It would just require adding a 'sclangPath' key to the lang/project config file, which would be relative to the project folder, so it could be 'sclangPath:sclang' or 'sclangPath:sclang.app/Contents/MacOS/sclang' (don't remember exactly the structure of an OSX bundle...), then the IDE when opening a project would store the path to sclang and use that instead of the default 'sclang'. Another possibility would be to have a default path in the project directory for sclang, for instance just in the root folder, and then have a key 'useLocalSCLang:true' which would look for an sclang at that location.

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 12, 2016

Contributor

So just for a moment, let's think of sc-ide as "just another" editor, the one most tightly integrated with sclang (& scsynth), rather than it being SuperCollider per se. Benefits we derive after decoupling sc-ide from sclang&scsynth will be available to other editors as well. That could also include the development environments used for rather than as supercollider.

The tighter an "as"-IDE is integrated with sclang&scsynth, the more likely it will run into trouble when switching sclang versions, agreed. It would be interesting to try to quantify that trouble against the trouble resulting from trying to combine different library/classes-versions with a non-fitting sclang.

I think my vague grand scheme of multi configuration sclang(s) is quite similar to what you plan as "project", but I think I would prefer to see it sclang- rather than sc-ide-centered. The reasons to use different sclangs, or just different sclang-classes sets are far more rooted in sound-project oriented necessities, than using a different editor. And in most cases people would likely be happy to keep their normal environment, tweaked to personal taste, and switch engines, rather than reconfigure different (autonomous) sc-ide-supercolliders.

So if agreed that a "project"-project should be sclang centered, then adding project management functionality as bound to the sc-ide could be considered counter productive...

Contributor

bagong commented Apr 12, 2016

So just for a moment, let's think of sc-ide as "just another" editor, the one most tightly integrated with sclang (& scsynth), rather than it being SuperCollider per se. Benefits we derive after decoupling sc-ide from sclang&scsynth will be available to other editors as well. That could also include the development environments used for rather than as supercollider.

The tighter an "as"-IDE is integrated with sclang&scsynth, the more likely it will run into trouble when switching sclang versions, agreed. It would be interesting to try to quantify that trouble against the trouble resulting from trying to combine different library/classes-versions with a non-fitting sclang.

I think my vague grand scheme of multi configuration sclang(s) is quite similar to what you plan as "project", but I think I would prefer to see it sclang- rather than sc-ide-centered. The reasons to use different sclangs, or just different sclang-classes sets are far more rooted in sound-project oriented necessities, than using a different editor. And in most cases people would likely be happy to keep their normal environment, tweaked to personal taste, and switch engines, rather than reconfigure different (autonomous) sc-ide-supercolliders.

So if agreed that a "project"-project should be sclang centered, then adding project management functionality as bound to the sc-ide could be considered counter productive...

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 12, 2016

Member

I think my vague grand scheme of multi configuration sclang(s) is quite similar to what you plan as "project", but I think I would prefer to see it sclang- rather than sc-ide-centered.

Following the suggestion of @crucialfelix, my implementation of projects completely decouples the sclang part and the ide part. You can use the sclang part without the ide part, so you can use it from the terminal or from another editor. For sclang, a project is just a normal sclang config file which also has the key 'project:true'. Having that key enabled will cause all relative paths to be resolved to the directory of the conf file and all quarks to be downloaded to a "downloaded-quarks" folder in the project folder (the folder where is the config file), also adding a new quark in the Quarks gui automatically converts the path to a relative path (i.e. "downloaded-quarks/FilterTools"), as well as when adding any subdirectory of the project directory.

Member

miguel-negrao commented Apr 12, 2016

I think my vague grand scheme of multi configuration sclang(s) is quite similar to what you plan as "project", but I think I would prefer to see it sclang- rather than sc-ide-centered.

Following the suggestion of @crucialfelix, my implementation of projects completely decouples the sclang part and the ide part. You can use the sclang part without the ide part, so you can use it from the terminal or from another editor. For sclang, a project is just a normal sclang config file which also has the key 'project:true'. Having that key enabled will cause all relative paths to be resolved to the directory of the conf file and all quarks to be downloaded to a "downloaded-quarks" folder in the project folder (the folder where is the config file), also adding a new quark in the Quarks gui automatically converts the path to a relative path (i.e. "downloaded-quarks/FilterTools"), as well as when adding any subdirectory of the project directory.

@bagong

This comment has been minimized.

Show comment
Hide comment
@bagong

bagong Apr 12, 2016

Contributor

Sounds very nice! So how does that interact with scide? Is there a public prototype?

Contributor

bagong commented Apr 12, 2016

Sounds very nice! So how does that interact with scide? Is there a public prototype?

@muellmusik

This comment has been minimized.

Show comment
Hide comment
@muellmusik

muellmusik Aug 30, 2018

Contributor

@miguel-negrao is this issue still live and are you still pursuing it?

Contributor

muellmusik commented Aug 30, 2018

@miguel-negrao is this issue still live and are you still pursuing it?

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Sep 1, 2018

Member

@muellmusik Yes, I have implemented this in the projects pull-request #3278. I have been using that feature locally and find it very usefull. In case it would be beneficial to merge this without the projects part, I would have to separate the two features. Also, after #3733 is merged I have to refactor #3278 on top of #3733.

Member

miguel-negrao commented Sep 1, 2018

@muellmusik Yes, I have implemented this in the projects pull-request #3278. I have been using that feature locally and find it very usefull. In case it would be beneficial to merge this without the projects part, I would have to separate the two features. Also, after #3733 is merged I have to refactor #3278 on top of #3733.

@muellmusik

This comment has been minimized.

Show comment
Hide comment
@muellmusik

muellmusik Sep 1, 2018

Contributor

okay. leaving for now

Contributor

muellmusik commented Sep 1, 2018

okay. leaving for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment