Quarks

Discussion:

Quarks

Scott Wilson

2014-10-17 19:31:47 UTC

I just spent upwards of half an hour with a postgrad student trying to get Quarks to work on his machine.

Problem 1: svn doesnt come standard with OSX anymore.
- let me pre-empt Tim, and say, yes, thats Apples fault, but my point is its not the users fault

Problem 2: theres no place where you can just grab OSX svn binaries anymore
- this is baffling to me, but you must either install it bundled with some client, install a whole package manager (which most non-dev people wont want), or register for some service (we tried the latter with a mailinator address, but the installer was non-functional!)

Problem 3: The easiest way to do it from a normal user perspective is to install Xcode, but that doesnt put svn in one of the hardcoded places quarks expects, and again provides non-devs with a massive and otherwise unnecessary application.

This is really, really awful. I can honestly say that manually downloading and installing extensions would be far easier, and I think we can do a lot better than that. The two of us, with experience and non-SC-specific knowledge, persisted and got it to work, but I cant imagine that the typical SC user would do anything but just give up. Especially new users...

As it is Quarks is basically broken, and I think has been for some time. Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever working? I added the Download class some time ago, so it seems to me that the main piece required for a dependency-less, actually easy to use Quarks is in place. As long as there was a predictable URL that would be fine, e.g. Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip, Platform.userExtensionDir +/+ quarks/ixiQuarks);

S.

Dan Stowell

2014-10-17 19:43:51 UTC

Permalink

Hi Scott,

I guess at this point, Quarks2 could simply be put into core. It's
been tested. It even has plain curl as an available method. But I'm
not using SC much at the moment so I'm not willing to be the one to
push on this I'm afraid.
https://github.com/danstowell/Quarks2

Dan

2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
> I just spent upwards of half an hour with a postgrad student trying to get
> Quarks to work on his machine.
>
> Problem 1: svn doesn’t come standard with OSX anymore.
> - let me pre-empt Tim, and say, yes, that’s Apple’s fault, but my point is
> it’s not the user’s fault
>
> Problem 2: there’s no place where you can just grab OSX svn binaries anymore
> - this is baffling to me, but you must either install it bundled with some
> client, install a whole package manager (which most non-dev people won’t
> want), or register for some service (we tried the latter with a mailinator
> address, but the installer was non-functional!)
>
> Problem 3: The ‘easiest’ way to do it from a normal user perspective is to
> install Xcode, but that doesn’t put svn in one of the hardcoded places
> quarks expects, and again provides non-devs with a massive and otherwise
> unnecessary application.
>
>
> This is really, really awful. I can honestly say that manually downloading
> and installing extensions would be far easier, and I think we can do a lot
> better than that. The two of us, with experience and non-SC-specific
> knowledge, persisted and got it to work, but I can’t imagine that the
> typical SC user would do anything but just give up. Especially new users...
>
> As it is Quarks is basically broken, and I think has been for some time.
> Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever working?
> I added the Download class some time ago, so it seems to me that the main
> piece required for a dependency-less, actually easy to use Quarks is in
> place. As long as there was a predictable URL that would be fine, e.g.
> Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip”,
> Platform.userExtensionDir +/+ “quarks/ixiQuarks”);
>
> S.

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Carver

2014-10-17 21:07:53 UTC

Permalink

Quarks is a nightmare, yes.

I would love to see Quarks2 built into the core. I've also got a
Quarks2-like toolchain that I wouldn't mind merging with the Quarks2 as it
is now - though I think it broadens the scope in a way that would certainly
require some more discussion.

Is this something worth talking about further for 3.7?
(Also, what is 3.7 at this point, other that head of
supercollider/supercollider? Sort of hard to talk w/o at least some idea
for what the release should be....)

- Scott C

On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:

> Hi Scott,
>
> I guess at this point, Quarks2 could simply be put into core. It's
> been tested. It even has plain curl as an available method. But I'm
> not using SC much at the moment so I'm not willing to be the one to
> push on this I'm afraid.
> https://github.com/danstowell/Quarks2
>
> Dan
>
> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
> > I just spent upwards of half an hour with a postgrad student trying to
> get
> > Quarks to work on his machine.
> >
> > Problem 1: svn doesnât come standard with OSX anymore.
> > - let me pre-empt Tim, and say, yes, thatâs Appleâs fault, but my point
> is
> > itâs not the userâs fault
> >
> > Problem 2: thereâs no place where you can just grab OSX svn binaries
> anymore
> > - this is baffling to me, but you must either install it bundled with
> some
> > client, install a whole package manager (which most non-dev people wonât
> > want), or register for some service (we tried the latter with a
> mailinator
> > address, but the installer was non-functional!)
> >
> > Problem 3: The âeasiestâ way to do it from a normal user perspective is
> to
> > install Xcode, but that doesnât put svn in one of the hardcoded places
> > quarks expects, and again provides non-devs with a massive and otherwise
> > unnecessary application.
> >
> >
> > This is really, really awful. I can honestly say that manually
> downloading
> > and installing extensions would be far easier, and I think we can do a
> lot
> > better than that. The two of us, with experience and non-SC-specific
> > knowledge, persisted and got it to work, but I canât imagine that the
> > typical SC user would do anything but just give up. Especially new
> users...
> >
> > As it is Quarks is basically broken, and I think has been for some time.
> > Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever
> working?
> > I added the Download class some time ago, so it seems to me that the main
> > piece required for a dependency-less, actually easy to use Quarks is in
> > place. As long as there was a predictable URL that would be fine, e.g.
> > Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip
> â,
> > Platform.userExtensionDir +/+ âquarks/ixiQuarksâ);
> >
> > S.
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>

Dan Stowell

2014-10-17 21:34:09 UTC

Permalink

"3.7" is just the master branch, that's all.

Dan

2014-10-17 22:07 GMT+01:00 Scott Carver <scott-y6qSm6YX8/***@public.gmane.org>:
> Quarks is a nightmare, yes.
>
> I would love to see Quarks2 built into the core. I've also got a
> Quarks2-like toolchain that I wouldn't mind merging with the Quarks2 as it
> is now - though I think it broadens the scope in a way that would certainly
> require some more discussion.
>
> Is this something worth talking about further for 3.7?
> (Also, what is 3.7 at this point, other that head of
> supercollider/supercollider? Sort of hard to talk w/o at least some idea for
> what the release should be....)
>
> - Scott C
>
> On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:
>>
>> Hi Scott,
>>
>> I guess at this point, Quarks2 could simply be put into core. It's
>> been tested. It even has plain curl as an available method. But I'm
>> not using SC much at the moment so I'm not willing to be the one to
>> push on this I'm afraid.
>> https://github.com/danstowell/Quarks2
>>
>> Dan
>>
>> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>> > I just spent upwards of half an hour with a postgrad student trying to
>> > get
>> > Quarks to work on his machine.
>> >
>> > Problem 1: svn doesn’t come standard with OSX anymore.
>> > - let me pre-empt Tim, and say, yes, that’s Apple’s fault, but my point
>> > is
>> > it’s not the user’s fault
>> >
>> > Problem 2: there’s no place where you can just grab OSX svn binaries
>> > anymore
>> > - this is baffling to me, but you must either install it bundled with
>> > some
>> > client, install a whole package manager (which most non-dev people won’t
>> > want), or register for some service (we tried the latter with a
>> > mailinator
>> > address, but the installer was non-functional!)
>> >
>> > Problem 3: The ‘easiest’ way to do it from a normal user perspective is
>> > to
>> > install Xcode, but that doesn’t put svn in one of the hardcoded places
>> > quarks expects, and again provides non-devs with a massive and otherwise
>> > unnecessary application.
>> >
>> >
>> > This is really, really awful. I can honestly say that manually
>> > downloading
>> > and installing extensions would be far easier, and I think we can do a
>> > lot
>> > better than that. The two of us, with experience and non-SC-specific
>> > knowledge, persisted and got it to work, but I can’t imagine that the
>> > typical SC user would do anything but just give up. Especially new
>> > users...
>> >
>> > As it is Quarks is basically broken, and I think has been for some time.
>> > Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever
>> > working?
>> > I added the Download class some time ago, so it seems to me that the
>> > main
>> > piece required for a dependency-less, actually easy to use Quarks is in
>> > place. As long as there was a predictable URL that would be fine, e.g.
>> >
>> > Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip”,
>> > Platform.userExtensionDir +/+ “quarks/ixiQuarks”);
>> >
>> > S.
>>
>>
>>
>> --
>> http://www.mcld.co.uk
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 07:23:03 UTC

Permalink

On 17 Oct 2014, at 22:07, Scott Carver <scott-y6qSm6YX8/***@public.gmane.org> wrote:

> Quarks is a nightmare, yes.
>
> I would love to see Quarks2 built into the core. I've also got a Quarks2-like toolchain that I wouldn't mind merging with the Quarks2 as it is now - though I think it broadens the scope in a way that would certainly require some more discussion.

How so?
>
> Is this something worth talking about further for 3.7?

Yes.

Dan, in Quarks 2, I gather the idea is things can be completely decentralised. So how does one get a master list of whats available? Or at least how does one discover Quarks?

S.

> (Also, what is 3.7 at this point, other that head of supercollider/supercollider? Sort of hard to talk w/o at least some idea for what the release should be....)
>
> - Scott C
>
> On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:
> Hi Scott,
>
> I guess at this point, Quarks2 could simply be put into core. It's
> been tested. It even has plain curl as an available method. But I'm
> not using SC much at the moment so I'm not willing to be the one to
> push on this I'm afraid.
> https://github.com/danstowell/Quarks2
>
> Dan
>
> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
> > I just spent upwards of half an hour with a postgrad student trying to get
> > Quarks to work on his machine.
> >
> > Problem 1: svn doesnt come standard with OSX anymore.
> > - let me pre-empt Tim, and say, yes, thats Apples fault, but my point is
> > its not the users fault
> >
> > Problem 2: theres no place where you can just grab OSX svn binaries anymore
> > - this is baffling to me, but you must either install it bundled with some
> > client, install a whole package manager (which most non-dev people wont
> > want), or register for some service (we tried the latter with a mailinator
> > address, but the installer was non-functional!)
> >
> > Problem 3: The easiest way to do it from a normal user perspective is to
> > install Xcode, but that doesnt put svn in one of the hardcoded places
> > quarks expects, and again provides non-devs with a massive and otherwise
> > unnecessary application.
> >
> >
> > This is really, really awful. I can honestly say that manually downloading
> > and installing extensions would be far easier, and I think we can do a lot
> > better than that. The two of us, with experience and non-SC-specific
> > knowledge, persisted and got it to work, but I cant imagine that the
> > typical SC user would do anything but just give up. Especially new users...
> >
> > As it is Quarks is basically broken, and I think has been for some time.
> > Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever working?
> > I added the Download class some time ago, so it seems to me that the main
> > piece required for a dependency-less, actually easy to use Quarks is in
> > place. As long as there was a predictable URL that would be fine, e.g.
> > Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip,
> > Platform.userExtensionDir +/+ quarks/ixiQuarks);
> >
> > S.
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>

Dan Stowell

2014-10-20 07:54:11 UTC

Permalink

2014-10-20 8:23 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>
> On 17 Oct 2014, at 22:07, Scott Carver <scott-y6qSm6YX8/***@public.gmane.org> wrote:
>
> Quarks is a nightmare, yes.
>
> I would love to see Quarks2 built into the core. I've also got a
> Quarks2-like toolchain that I wouldn't mind merging with the Quarks2 as it
> is now - though I think it broadens the scope in a way that would certainly
> require some more discussion.
>
>
> How so?
>
>
> Is this something worth talking about further for 3.7?
>
>
> Yes.
>
> Dan, in Quarks 2, I gather the idea is things can be completely
> decentralised. So how does one get a master list of what’s available? Or at
> least how does one discover Quarks?

There is no master list. You have a simple text file listing the
sources from which you want to HEAR about quarks, in
Platform.userAppSupportDir +/+ "quarks_sources.txt". By default it
looks like this:

# sources list - one URL per line. Lines beginning with # are ignored.
https://raw.github.com/supercollider/quarks2seed/master/default_quarks_sources.yaml

If you go and look at that file you'll see a dictionary of URLs. Each
of those URLs leads to a "directory" of quarks. So new quarks can be
added to an existing "directory", or to a brand new one maintained by
someone else. In the latter case, they would announce the directory
URL through normal human methods and you would add it to your
quarks_sources.txt.

Dan

> (Also, what is 3.7 at this point, other that head of
> supercollider/supercollider? Sort of hard to talk w/o at least some idea for
> what the release should be....)
>
> - Scott C
>
> On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:
>>
>> Hi Scott,
>>
>> I guess at this point, Quarks2 could simply be put into core. It's
>> been tested. It even has plain curl as an available method. But I'm
>> not using SC much at the moment so I'm not willing to be the one to
>> push on this I'm afraid.
>> https://github.com/danstowell/Quarks2
>>
>> Dan
>>
>> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>> > I just spent upwards of half an hour with a postgrad student trying to
>> > get
>> > Quarks to work on his machine.
>> >
>> > Problem 1: svn doesn’t come standard with OSX anymore.
>> > - let me pre-empt Tim, and say, yes, that’s Apple’s fault, but my point
>> > is
>> > it’s not the user’s fault
>> >
>> > Problem 2: there’s no place where you can just grab OSX svn binaries
>> > anymore
>> > - this is baffling to me, but you must either install it bundled with
>> > some
>> > client, install a whole package manager (which most non-dev people won’t
>> > want), or register for some service (we tried the latter with a
>> > mailinator
>> > address, but the installer was non-functional!)
>> >
>> > Problem 3: The ‘easiest’ way to do it from a normal user perspective is
>> > to
>> > install Xcode, but that doesn’t put svn in one of the hardcoded places
>> > quarks expects, and again provides non-devs with a massive and otherwise
>> > unnecessary application.
>> >
>> >
>> > This is really, really awful. I can honestly say that manually
>> > downloading
>> > and installing extensions would be far easier, and I think we can do a
>> > lot
>> > better than that. The two of us, with experience and non-SC-specific
>> > knowledge, persisted and got it to work, but I can’t imagine that the
>> > typical SC user would do anything but just give up. Especially new
>> > users...
>> >
>> > As it is Quarks is basically broken, and I think has been for some time.
>> > Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever
>> > working?
>> > I added the Download class some time ago, so it seems to me that the
>> > main
>> > piece required for a dependency-less, actually easy to use Quarks is in
>> > place. As long as there was a predictable URL that would be fine, e.g.
>> >
>> > Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip”,
>> > Platform.userExtensionDir +/+ “quarks/ixiQuarks”);
>> >
>> > S.
>>
>>
>>
>> --
>> http://www.mcld.co.uk
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 08:23:18 UTC

Permalink

On 20 Oct 2014, at 08:54, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>
>
> There is no master list. You have a simple text file listing the
> sources from which you want to HEAR about quarks, in
> Platform.userAppSupportDir +/+ "quarks_sources.txt". By default it
> looks like this:
>
> # sources list - one URL per line. Lines beginning with # are ignored.
> https://raw.github.com/supercollider/quarks2seed/master/default_quarks_sources.yaml

Okay, but presumably we have that one as an informal standard?
>
> If you go and look at that file you'll see a dictionary of URLs. Each
> of those URLs leads to a "directory" of quarks. So new quarks can be
> added to an existing "directory", or to a brand new one maintained by
> someone else. In the latter case, they would announce the directory
> URL through normal human methods and you would add it to your
> quarks_sources.txt.

How are those yaml files generated? This is not really my area of expertise, but one problem is that http requests cant just grab everything in a directory, so we would need a list of files to use the Download class. (Same problem with curl I think.)

Those yaml files seem to specify a method, usually git. That sort of dependency is exactly what I think we should avoid. I think for all Quarks there should be a way to use them out of the box and git, etc. should just be for devs and power users. If Quarks 2 means that you need svn *and* git *and* curl that would just make things worse, or?

(Sorry if Im misunderstanding!)

S.

>
> Dan
>
>
>> (Also, what is 3.7 at this point, other that head of
>> supercollider/supercollider? Sort of hard to talk w/o at least some idea for
>> what the release should be....)
>>
>> - Scott C
>>
>> On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:
>>>
>>> Hi Scott,
>>>
>>> I guess at this point, Quarks2 could simply be put into core. It's
>>> been tested. It even has plain curl as an available method. But I'm
>>> not using SC much at the moment so I'm not willing to be the one to
>>> push on this I'm afraid.
>>> https://github.com/danstowell/Quarks2
>>>
>>> Dan
>>>
>>> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>>>> I just spent upwards of half an hour with a postgrad student trying to
>>>> get
>>>> Quarks to work on his machine.
>>>>
>>>> Problem 1: svn doesnt come standard with OSX anymore.
>>>> - let me pre-empt Tim, and say, yes, thats Apples fault, but my point
>>>> is
>>>> its not the users fault
>>>>
>>>> Problem 2: theres no place where you can just grab OSX svn binaries
>>>> anymore
>>>> - this is baffling to me, but you must either install it bundled with
>>>> some
>>>> client, install a whole package manager (which most non-dev people wont
>>>> want), or register for some service (we tried the latter with a
>>>> mailinator
>>>> address, but the installer was non-functional!)
>>>>
>>>> Problem 3: The easiest way to do it from a normal user perspective is
>>>> to
>>>> install Xcode, but that doesnt put svn in one of the hardcoded places
>>>> quarks expects, and again provides non-devs with a massive and otherwise
>>>> unnecessary application.
>>>>
>>>>
>>>> This is really, really awful. I can honestly say that manually
>>>> downloading
>>>> and installing extensions would be far easier, and I think we can do a
>>>> lot
>>>> better than that. The two of us, with experience and non-SC-specific
>>>> knowledge, persisted and got it to work, but I cant imagine that the
>>>> typical SC user would do anything but just give up. Especially new
>>>> users...
>>>>
>>>> As it is Quarks is basically broken, and I think has been for some time.
>>>> Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever
>>>> working?
>>>> I added the Download class some time ago, so it seems to me that the
>>>> main
>>>> piece required for a dependency-less, actually easy to use Quarks is in
>>>> place. As long as there was a predictable URL that would be fine, e.g.
>>>>
>>>> Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip,
>>>> Platform.userExtensionDir +/+ quarks/ixiQuarks);
>>>>
>>>> S.
>>>
>>>
>>>
>>> --
>>> http://www.mcld.co.uk
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>
>>
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Dan Stowell

2014-10-20 08:38:30 UTC

Permalink

2014-10-20 9:23 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>
> On 20 Oct 2014, at 08:54, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>
>
>
> There is no master list. You have a simple text file listing the
> sources from which you want to HEAR about quarks, in
> Platform.userAppSupportDir +/+ "quarks_sources.txt". By default it
> looks like this:
>
> # sources list - one URL per line. Lines beginning with # are ignored.
> https://raw.github.com/supercollider/quarks2seed/master/default_quarks_sources.yaml
>
>
> Okay, but presumably we have that one as an informal standard?

Yes

> If you go and look at that file you'll see a dictionary of URLs. Each
> of those URLs leads to a "directory" of quarks. So new quarks can be
> added to an existing "directory", or to a brand new one maintained by
> someone else. In the latter case, they would announce the directory
> URL through normal human methods and you would add it to your
> quarks_sources.txt.
>
>
> How are those yaml files generated?

So far they're generated by typing in a text editor. There's no big
pile of code around this yet.

> This is not really my area of expertise,
> but one problem is that http requests can’t just grab everything in a
> directory, so we would need a list of files to use the Download class. (Same
> problem with curl I think.)

I don't remember if we thought that through

> Those yaml files seem to specify a ‘method’, usually git. That sort of
> dependency is exactly what I think we should avoid.

Each quark entry specifies a method. Well, at least you are free to
create one "git" entry and one "http" entry in different directory
files...

I'm sorry but this is frustrating trying to dredge this stuff out of
memories of the discussions which are just as old to me as they are to
you. If you want to alter the approach so that each quark entry can be
multi-protocol, I have no objections because I have no strong
memory/intention for all of this. So please fork that repository and
implement it, I can imagine it working.

> I think for all Quarks
> there should be a way to use them out of the box and git, etc. should just
> be for devs and power users. If Quarks 2 means that you need svn *and* git
> *and* curl that would just make things worse, or?

This doesn't make sense to me. Are you suggesting that each quark
should be available by *any* of those methods, whichever the user is
set up to use? That sounds like massive barrier for quark makers.

Dan

> (Sorry if I’m misunderstanding!)
>
> S.
>
>
> Dan
>
>
> (Also, what is 3.7 at this point, other that head of
> supercollider/supercollider? Sort of hard to talk w/o at least some idea for
> what the release should be....)
>
> - Scott C
>
> On Fri, Oct 17, 2014 at 12:43 PM, Dan Stowell <danstowell-***@public.gmane.org> wrote:
>
>
> Hi Scott,
>
> I guess at this point, Quarks2 could simply be put into core. It's
> been tested. It even has plain curl as an available method. But I'm
> not using SC much at the moment so I'm not willing to be the one to
> push on this I'm afraid.
> https://github.com/danstowell/Quarks2
>
> Dan
>
> 2014-10-17 20:31 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>
> I just spent upwards of half an hour with a postgrad student trying to
> get
> Quarks to work on his machine.
>
> Problem 1: svn doesn’t come standard with OSX anymore.
> - let me pre-empt Tim, and say, yes, that’s Apple’s fault, but my point
> is
> it’s not the user’s fault
>
> Problem 2: there’s no place where you can just grab OSX svn binaries
> anymore
> - this is baffling to me, but you must either install it bundled with
> some
> client, install a whole package manager (which most non-dev people won’t
> want), or register for some service (we tried the latter with a
> mailinator
> address, but the installer was non-functional!)
>
> Problem 3: The ‘easiest’ way to do it from a normal user perspective is
> to
> install Xcode, but that doesn’t put svn in one of the hardcoded places
> quarks expects, and again provides non-devs with a massive and otherwise
> unnecessary application.
>
>
> This is really, really awful. I can honestly say that manually
> downloading
> and installing extensions would be far easier, and I think we can do a
> lot
> better than that. The two of us, with experience and non-SC-specific
> knowledge, persisted and got it to work, but I can’t imagine that the
> typical SC user would do anything but just give up. Especially new
> users...
>
> As it is Quarks is basically broken, and I think has been for some time.
> Please, can we fix this for 3.7, and get Quarks 2, or 3 or whatever
> working?
> I added the Download class some time ago, so it seems to me that the
> main
> piece required for a dependency-less, actually easy to use Quarks is in
> place. As long as there was a predictable URL that would be fine, e.g.
>
> Download("https://github.com/thormagnusson/ixiQuarks/archive/master.zip”,
> Platform.userExtensionDir +/+ “quarks/ixiQuarks”);
>
> S.
>
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
>
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 09:22:10 UTC

Permalink

On 20 Oct 2014, at 09:38, Dan Stowell <danstowell-***@public.gmane.org> wrote:

> 2014-10-20 9:23 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>>
>> On 20 Oct 2014, at 08:54, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>
>>
>>
>> There is no master list. You have a simple text file listing the
>> sources from which you want to HEAR about quarks, in
>> Platform.userAppSupportDir +/+ "quarks_sources.txt". By default it
>> looks like this:
>>
>> # sources list - one URL per line. Lines beginning with # are ignored.
>> https://raw.github.com/supercollider/quarks2seed/master/default_quarks_sources.yaml
>>
>>
>> Okay, but presumably we have that one as an informal standard?
>
> Yes
>
>> If you go and look at that file you'll see a dictionary of URLs. Each
>> of those URLs leads to a "directory" of quarks. So new quarks can be
>> added to an existing "directory", or to a brand new one maintained by
>> someone else. In the latter case, they would announce the directory
>> URL through normal human methods and you would add it to your
>> quarks_sources.txt.
>>
>>
>> How are those yaml files generated?
>
> So far they're generated by typing in a text editor. There's no big
> pile of code around this yet.
>
>> This is not really my area of expertise,
>> but one problem is that http requests cant just grab everything in a
>> directory, so we would need a list of files to use the Download class. (Same
>> problem with curl I think.)
>
> I don't remember if we thought that through
>
>> Those yaml files seem to specify a method, usually git. That sort of
>> dependency is exactly what I think we should avoid.
>
> Each quark entry specifies a method. Well, at least you are free to
> create one "git" entry and one "http" entry in different directory
> files...
>
> I'm sorry but this is frustrating trying to dredge this stuff out of
> memories of the discussions which are just as old to me as they are to
> you. If you want to alter the approach so that each quark entry can be
> multi-protocol, I have no objections because I have no strong
> memory/intention for all of this. So please fork that repository and
> implement it, I can imagine it working.
>
>> I think for all Quarks
>> there should be a way to use them out of the box and git, etc. should just
>> be for devs and power users. If Quarks 2 means that you need svn *and* git
>> *and* curl that would just make things worse, or?
>
> This doesn't make sense to me. Are you suggesting that each quark
> should be available by *any* of those methods, whichever the user is
> set up to use? That sounds like massive barrier for quark makers.

No, I am asking if Quarks2 as it exists requires users to have svn, git, and curl installed in order to get all available Quarks.

What I want is for users to be able to get any Quark without having *any* of those installed, with just vanilla SC out of the box, i.e. remove the current massive barrier for non-expert users. We can make that simple for quark makers, i.e. a script which just generates a file manifest so the Download class can grab them all.

S.

Dan Stowell

2014-10-20 09:39:35 UTC

Permalink

2014-10-20 10:22 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>
> On 20 Oct 2014, at 09:38, Dan Stowell <danstowell-***@public.gmane.org> wrote:
>
> 2014-10-20 9:23 GMT+01:00 Scott Wilson <***@scottwilson.ca>:
>
>
> On 20 Oct 2014, at 08:54, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>
>
>
> There is no master list. You have a simple text file listing the
> sources from which you want to HEAR about quarks, in
> Platform.userAppSupportDir +/+ "quarks_sources.txt". By default it
> looks like this:
>
> # sources list - one URL per line. Lines beginning with # are ignored.
> https://raw.github.com/supercollider/quarks2seed/master/default_quarks_sources.yaml
>
>
> Okay, but presumably we have that one as an informal standard?
>
>
> Yes
>
> If you go and look at that file you'll see a dictionary of URLs. Each
> of those URLs leads to a "directory" of quarks. So new quarks can be
> added to an existing "directory", or to a brand new one maintained by
> someone else. In the latter case, they would announce the directory
> URL through normal human methods and you would add it to your
> quarks_sources.txt.
>
>
> How are those yaml files generated?
>
>
> So far they're generated by typing in a text editor. There's no big
> pile of code around this yet.
>
> This is not really my area of expertise,
> but one problem is that http requests can’t just grab everything in a
> directory, so we would need a list of files to use the Download class. (Same
> problem with curl I think.)
>
>
> I don't remember if we thought that through
>
> Those yaml files seem to specify a ‘method’, usually git. That sort of
> dependency is exactly what I think we should avoid.
>
>
> Each quark entry specifies a method. Well, at least you are free to
> create one "git" entry and one "http" entry in different directory
> files...
>
> I'm sorry but this is frustrating trying to dredge this stuff out of
> memories of the discussions which are just as old to me as they are to
> you. If you want to alter the approach so that each quark entry can be
> multi-protocol, I have no objections because I have no strong
> memory/intention for all of this. So please fork that repository and
> implement it, I can imagine it working.
>
> I think for all Quarks
> there should be a way to use them out of the box and git, etc. should just
> be for devs and power users. If Quarks 2 means that you need svn *and* git
> *and* curl that would just make things worse, or?
>
>
> This doesn't make sense to me. Are you suggesting that each quark
> should be available by *any* of those methods, whichever the user is
> set up to use? That sounds like massive barrier for quark makers.
>
>
> No, I am asking if Quarks2 as it exists requires users to have svn, git, and
> curl installed in order to get all available Quarks.

To get all of them, yes.

> What I want is for users to be able to get any Quark without having *any* of
> those installed, with just vanilla SC out of the box, i.e. remove the
> current massive barrier for non-expert users.

I understand that apple is messing us all around. It's now hard for
mac users to run svn; is it the same for git?

> We can make that simple for
> quark makers, i.e. a script which just generates a file manifest so the
> Download class can grab them all.

This makes me uncomfortable because it seems it'll often be unclear
how a user got the quark or what version they're *really* running. I'd
recommend that when you implement the Download version you include
something to help with that, e.g. logging the date of install and the
download checksum - something, anything. I'm not against you making
something which can Download anything, but please do beware of the
potential problems. With git/svn it's so easy to work out which
branch/commit someone has...

Dan
--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 11:02:57 UTC

Permalink

On 20 Oct 2014, at 10:39, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>
>> No, I am asking if Quarks2 as it exists requires users to have svn, git, and
>> curl installed in order to get all available Quarks.
>
> To get all of them, yes.

Then Im afraid I think that does make the situation worse. Now a user can get svn working, only to find that some Quarks require git or curl. I understand that back in the mists of time people may have been thinking about flexibility rather than users, but i think its pretty evident we cant keep going like that.
>
>> What I want is for users to be able to get any Quark without having *any* of
>> those installed, with just vanilla SC out of the box, i.e. remove the
>> current massive barrier for non-expert users.
>
> I understand that apple is messing us all around. It's now hard for
> mac users to run svn; is it the same for git?

It is not Apples fault that we decided to implement a bodgey package manager that broke when they stopped shipping the OS with a piece of software that 99.999% of their users do not need. It is not Apples fault that our bodgey package manger broke when other people decided for whatever reasons to stop producing the svn binary packages they used to.

Basically, its all our fault.

You can get git binaries for Mac fairly easily at the moment, but thats really not the point. AFAIK, none of git, svn, or curl is included in all of OSX, Linux and Windows, and even if they were the same sort of breakage could easily occur in the future. We can do better.
>
>> We can make that simple for
>> quark makers, i.e. a script which just generates a file manifest so the
>> Download class can grab them all.
>
> This makes me uncomfortable because it seems it'll often be unclear
> how a user got the quark or what version they're *really* running. I'd
> recommend that when you implement the Download version you include
> something to help with that, e.g. logging the date of install and the
> download checksum - something, anything. I'm not against you making
> something which can Download anything, but please do beware of the
> potential problems. With git/svn it's so easy to work out which
> branch/commit someone has

Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Ive suggested that in the past people objected that that was too much trouble for devs, despite the fact that thats the way its done with the vast majority of software, including SC. For super users I dont mind if Quarks supports distribution by git, curl, or punchcards. Im just making a plea for the regular humans.

But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.

S.

0001

2014-10-20 11:54:52 UTC

Permalink

Hi, sorry for hijacking, but I guess this would require some support for http as a language primitive (Im not very up to date though so sorry if Im missing something).
I have been dreaming about this for some time so maybe I would be able to help but starting in one month from now.

gerard

El 20/10/2014, a les 13.02, Scott Wilson <***@scottwilson.ca> va escriure:

>
> On 20 Oct 2014, at 10:39, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>>
>>> No, I am asking if Quarks2 as it exists requires users to have svn, git, and
>>> curl installed in order to get all available Quarks.
>>
>> To get all of them, yes.
>
> Then Im afraid I think that does make the situation worse. Now a user can get svn working, only to find that some Quarks require git or curl. I understand that back in the mists of time people may have been thinking about flexibility rather than users, but i think its pretty evident we cant keep going like that.
>>
>>> What I want is for users to be able to get any Quark without having *any* of
>>> those installed, with just vanilla SC out of the box, i.e. remove the
>>> current massive barrier for non-expert users.
>>
>> I understand that apple is messing us all around. It's now hard for
>> mac users to run svn; is it the same for git?
>
> It is not Apples fault that we decided to implement a bodgey package manager that broke when they stopped shipping the OS with a piece of software that 99.999% of their users do not need. It is not Apples fault that our bodgey package manger broke when other people decided for whatever reasons to stop producing the svn binary packages they used to.
>
> Basically, its all our fault.
>
> You can get git binaries for Mac fairly easily at the moment, but thats really not the point. AFAIK, none of git, svn, or curl is included in all of OSX, Linux and Windows, and even if they were the same sort of breakage could easily occur in the future. We can do better.
>>
>>> We can make that simple for
>>> quark makers, i.e. a script which just generates a file manifest so the
>>> Download class can grab them all.
>>
>> This makes me uncomfortable because it seems it'll often be unclear
>> how a user got the quark or what version they're *really* running. I'd
>> recommend that when you implement the Download version you include
>> something to help with that, e.g. logging the date of install and the
>> download checksum - something, anything. I'm not against you making
>> something which can Download anything, but please do beware of the
>> potential problems. With git/svn it's so easy to work out which
>> branch/commit someone has
>
> Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Ive suggested that in the past people objected that that was too much trouble for devs, despite the fact that thats the way its done with the vast majority of software, including SC. For super users I dont mind if Quarks supports distribution by git, curl, or punchcards. Im just making a plea for the regular humans.
>
> But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.
>
> S.

Scott Wilson

2014-10-20 11:57:00 UTC

Permalink

There's already the Download class. Did you want something more?

> On 20 Oct 2014, at 12:54, 0001 <0001-0S03WspcetzrZ44/***@public.gmane.org> wrote:
>
> Hi, sorry for hijacking, but I guess this would require some support for http as a language primitive (Iâm not very up to date though so sorry if Iâm missing something).
> I have been dreaming about this for some time so maybe I would be able to help but starting in one month from now.
>
> âŠ
>
> gerard
>
>
>
>
> El 20/10/2014, a les 13.02, Scott Wilson <***@scottwilson.ca> va escriure:
>
>>
>> On 20 Oct 2014, at 10:39, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>>>
>>>> No, I am asking if Quarks2 as it exists requires users to have svn, git, and
>>>> curl installed in order to get all available Quarks.
>>>
>>> To get all of them, yes.
>>
>> Then Iâm afraid I think that does make the situation worse. Now a user can get svn working, only to find that some Quarks require git or curl. I understand that back in the mists of time people may have been thinking about flexibility rather than users, but i think itâs pretty evident we canât keep going like that.
>>>
>>>> What I want is for users to be able to get any Quark without having *any* of
>>>> those installed, with just vanilla SC out of the box, i.e. remove the
>>>> current massive barrier for non-expert users.
>>>
>>> I understand that apple is messing us all around. It's now hard for
>>> mac users to run svn; is it the same for git?
>>
>> It is not Appleâs fault that we decided to implement a bodgey package manager that broke when they stopped shipping the OS with a piece of software that 99.999% of their users do not need. It is not Appleâs fault that our bodgey package manger broke when other people decided for whatever reasons to stop producing the svn binary packages they used to.
>>
>> Basically, itâs all our fault.
>>
>> You can get git binaries for Mac fairly easily at the moment, but thatâs really not the point. AFAIK, none of git, svn, or curl is included in all of OSX, Linux and Windows, and even if they were the same sort of breakage could easily occur in the future. We can do better.
>>>
>>>> We can make that simple for
>>>> quark makers, i.e. a script which just generates a file manifest so the
>>>> Download class can grab them all.
>>>
>>> This makes me uncomfortable because it seems it'll often be unclear
>>> how a user got the quark or what version they're *really* running. I'd
>>> recommend that when you implement the Download version you include
>>> something to help with that, e.g. logging the date of install and the
>>> download checksum - something, anything. I'm not against you making
>>> something which can Download anything, but please do beware of the
>>> potential problems. With git/svn it's so easy to work out which
>>> branch/commit someone hasâŠ
>>
>> Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Iâve suggested that in the past people objected that that was too much trouble for devs, despite the fact that thatâs the way itâs done with the vast majority of software, including SC. For super users I donât mind if Quarks supports distribution by git, curl, or punchcards. Iâm just making a plea for the regular humans.
>>
>> But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.
>>
>> S.
>

0001

2014-10-20 12:05:02 UTC

Permalink

Sounds great, I was guessing that but Im still on 3.6.6 right now. Another thing would be support for ogg/flac in OSX libsndfile ( I posted a patch a very long time ago). But that surely does not belong to this thread.

gerard

El 20/10/2014, a les 13.57, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org> va escriure:

> There's already the Download class. Did you want something more?
>
>
> On 20 Oct 2014, at 12:54, 0001 <0001-0S03WspcetzrZ44/***@public.gmane.org> wrote:
>
>> Hi, sorry for hijacking, but I guess this would require some support for http as a language primitive (Im not very up to date though so sorry if Im missing something).
>> I have been dreaming about this for some time so maybe I would be able to help but starting in one month from now.
>>
>>
>>
>> gerard
>>
>>
>>
>>
>> El 20/10/2014, a les 13.02, Scott Wilson <***@scottwilson.ca> va escriure:
>>
>>>
>>> On 20 Oct 2014, at 10:39, Dan Stowell <danstowell+sc3-***@public.gmane.org> wrote:
>>>>>
>>>>> No, I am asking if Quarks2 as it exists requires users to have svn, git, and
>>>>> curl installed in order to get all available Quarks.
>>>>
>>>> To get all of them, yes.
>>>
>>> Then Im afraid I think that does make the situation worse. Now a user can get svn working, only to find that some Quarks require git or curl. I understand that back in the mists of time people may have been thinking about flexibility rather than users, but i think its pretty evident we cant keep going like that.
>>>>
>>>>> What I want is for users to be able to get any Quark without having *any* of
>>>>> those installed, with just vanilla SC out of the box, i.e. remove the
>>>>> current massive barrier for non-expert users.
>>>>
>>>> I understand that apple is messing us all around. It's now hard for
>>>> mac users to run svn; is it the same for git?
>>>
>>> It is not Apples fault that we decided to implement a bodgey package manager that broke when they stopped shipping the OS with a piece of software that 99.999% of their users do not need. It is not Apples fault that our bodgey package manger broke when other people decided for whatever reasons to stop producing the svn binary packages they used to.
>>>
>>> Basically, its all our fault.
>>>
>>> You can get git binaries for Mac fairly easily at the moment, but thats really not the point. AFAIK, none of git, svn, or curl is included in all of OSX, Linux and Windows, and even if they were the same sort of breakage could easily occur in the future. We can do better.
>>>>
>>>>> We can make that simple for
>>>>> quark makers, i.e. a script which just generates a file manifest so the
>>>>> Download class can grab them all.
>>>>
>>>> This makes me uncomfortable because it seems it'll often be unclear
>>>> how a user got the quark or what version they're *really* running. I'd
>>>> recommend that when you implement the Download version you include
>>>> something to help with that, e.g. logging the date of install and the
>>>> download checksum - something, anything. I'm not against you making
>>>> something which can Download anything, but please do beware of the
>>>> potential problems. With git/svn it's so easy to work out which
>>>> branch/commit someone has
>>>
>>> Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Ive suggested that in the past people objected that that was too much trouble for devs, despite the fact that thats the way its done with the vast majority of software, including SC. For super users I dont mind if Quarks supports distribution by git, curl, or punchcards. Im just making a plea for the regular humans.
>>>
>>> But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.
>>>
>>> S.
>>

0001

2014-10-20 12:06:10 UTC

Permalink

nescivi

2014-10-20 19:29:49 UTC

Permalink

On 20-10-14 14:06, 0001 wrote:
> Sounds great, I was guessing that but I’m still on 3.6.6 right now.
> Another thing would be support for ogg/flac in OSX libsndfile ( I posted
> a patch a very long time ago). But that surely does not belong to this
> thread.

Did you submit the patch as a pull request, or as an issue on github, or
just on the list?

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

0001

2014-10-20 11:55:26 UTC

Permalink

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Andrea Valle

2014-10-20 12:02:28 UTC

Permalink

> Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Ive suggested that in the past people objected that that was too much trouble for devs, despite the fact that thats the way its done with the vast majority of software, including SC. For super users I dont mind if Quarks supports distribution by git, curl, or punchcards. Im just making a plea for the regular humans.

I totally agree with Scott, and I said it many times from a users pov. Which -let me state it unpleasantly- is the only relevant here, because devs know how to use a versioning system, and they just manage their working activity the way they prefer.

I think its pretty obvious.

Users just need:
1. a place on the web where to download stuff
2. a clear indication where to place stuff on their machine
3. to keep the recompile mantra in their minds.

Oh, but maybe I have an older version? Ok, I delete it and download it again. Whats the issue here? There are no hidden files in installing quarks.
Its the force of SC, theyre just txt files.

We dont need either a download manager. Everybody can download the way s/he prefers from the quark webpage.
BTW, its the way I do very happily, as my svn is broken since years. I go to quarks dir, download and go.

Best

-a-

PS: of course, maximum respect and gratitude to all who have profused their efforts into quark development!

>
> But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.
>
> S.

--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - StudiUm
Università degli Studi di Torino
--> http://www.cirma.unito.it/andrea/
--> http://www.fonurgia.unito.it/andrea/
--> http://www.flickr.com/photos/vanderaalle/sets/
--> http://vimeo.com/vanderaalle
--> andrea.valle-Ob+***@public.gmane.org
--------------------------------------------------

"This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous."
(Jeffrey 'The Dude' Lebowski)

Scott Wilson

2014-10-20 13:12:26 UTC

Permalink

> On 20 Oct 2014, at 13:02, Andrea Valle <valle-***@public.gmane.org> wrote:
>
>> Well, to be honest, if I had my way, we would clearly separate releases and dev tree. When Iâve suggested that in the past people objected that that was too much trouble for devs, despite the fact that thatâs the way itâs done with the vast majority of software, including SC. For super users I donât mind if Quarks supports distribution by git, curl, or punchcards. Iâm just making a plea for the regular humans.
>
> I totally agree with Scott, and I said it many times from a userâs pov. Which -let me state it unpleasantly- is the only relevant here, because devs know how to use a versioning system, and they just manage their working activity the way they prefer.
>
> I think itâs pretty obvious.
>
> Users just need:
> 1. a place on the web where to download stuff
> 2. a clear indication where to place stuff on their machine
> 3. to keep the ârecompileâ mantra in their minds.
>
> âOh, but maybe I have an older version? Ok, I delete it and download it againâ. Whatâs the issue here? There are no hidden files in installing quarks.
> Itâs the force of SC, theyâre just txt files.
>
> We donât need either a download manager. Everybody can download the way s/he prefers from the quark webpage.
> BTW, itâs the way I do very happily, as my svn is broken since years. I go to quarks dir, download and go.

I was actually looking to see if there was a url where you could just download the latest everything from sf. Couldn't find it.

If that's possible we could make that the default behaviour and document it. (Just check for an svn install and then use download if not found.) Not ideal IMO but would be a vast improvement on the current brokenness.

Personally I think it would be best to fix in-SC downloading rather than remove it. An all in one download would be better than nothing.

S.
>
>
> Best
>
> -a-
>
> PS: of course, maximum respect and gratitude to all who have profused their efforts into quark development!
>
>
>>
>> But in any case, the script which generates the manifest could tag it with a version. That could be derived from scm info if desired.
>>
>> S.
>
> --------------------------------------------------
> Andrea Valle
> --------------------------------------------------
> CIRMA - StudiUm
> UniversitÃ degli Studi di Torino
> --> http://www.cirma.unito.it/andrea/
> --> http://www.fonurgia.unito.it/andrea/
> --> http://www.flickr.com/photos/vanderaalle/sets/
> --> http://vimeo.com/vanderaalle
> --> andrea.valle-Ob+***@public.gmane.org
> --------------------------------------------------
>
> "This is a very complicated case, Maude. You know, a lotta ins, a lotta outs, a lotta what-have-yous."
> (Jeffrey 'The Dude' Lebowski)
>

felix

2014-10-20 13:24:43 UTC

Permalink

http://sourceforge.net/p/quarks/code/HEAD/tree/

"download snapshot"

But it could be hosted elsewhere like
https://github.com/supercollider/quarks
and then people can download snapshots for specific versions.

On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org> wrote:

> I was actually looking to see if there was a url where you could just
> download the latest everything from sf. Couldn't find it.
>

--
..
http://soundcloud.com/crucialfelix
http://github.com/crucialfelix
.

Scott Wilson

2014-10-20 14:22:37 UTC

Permalink

On 20 Oct 2014, at 14:24, felix <felix-***@public.gmane.org> wrote:

>
> http://sourceforge.net/p/quarks/code/HEAD/tree/
>
> "download snapshot

Thanks. I saw that, but I need something that can be put into Download(http:///quarks-latest.zipOrSomethingLikeThat, Platform.userExtensionDirectory +/+ quarks/);

S.

>
> But it could be hosted elsewhere like https://github.com/supercollider/quarks
> and then people can download snapshots for specific versions.
>
>
>
> On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org> wrote:
> I was actually looking to see if there was a url where you could just download the latest everything from sf. Couldn't find it.
>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .

felix

2014-10-20 14:42:24 UTC

Permalink

I'll volunteer to get github.com/supercollider/quarks set up and synced to
the current state.

or maybe just update this:
https://github.com/supercollider-quarks/super-repository

We can tag releases and then there is a fixed tarball URL

On Mon, Oct 20, 2014 at 4:22 PM, Scott Wilson <***@scottwilson.ca> wrote:

>
> On 20 Oct 2014, at 14:24, felix <felix-***@public.gmane.org> wrote:
>
>
> http://sourceforge.net/p/quarks/code/HEAD/tree/
>
> "download snapshotâ
>
>
> Thanks. I saw that, but I need something that can be put into Download(â
> http://âŠ/quarks-latest.zipOrSomethingLikeThatâ,
> Platform.userExtensionDirectory +/+ âquarks/â);
>
> S.
>
>
> But it could be hosted elsewhere like
> https://github.com/supercollider/quarks
> and then people can download snapshots for specific versions.
>
>
>
> On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org>
> wrote:
>
>> I was actually looking to see if there was a url where you could just
>> download the latest everything from sf. Couldn't find it.
>>
>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .
>
>
>

--
..
http://soundcloud.com/crucialfelix
http://github.com/crucialfelix
.

Scott Wilson

2014-10-20 15:13:40 UTC

Permalink

That would be fantastic thank you! If we could have both latest or specific tags that would work very well.

S.

On 20 Oct 2014, at 15:42, felix <felix-***@public.gmane.org> wrote:

>
> I'll volunteer to get github.com/supercollider/quarks set up and synced to the current state.
>
> or maybe just update this:
> https://github.com/supercollider-quarks/super-repository
>
> We can tag releases and then there is a fixed tarball URL
>
>
>
> On Mon, Oct 20, 2014 at 4:22 PM, Scott Wilson <***@scottwilson.ca> wrote:
>
> On 20 Oct 2014, at 14:24, felix <felix-***@public.gmane.org> wrote:
>
>>
>> http://sourceforge.net/p/quarks/code/HEAD/tree/
>>
>> "download snapshot
>
> Thanks. I saw that, but I need something that can be put into Download(http:///quarks-latest.zipOrSomethingLikeThat, Platform.userExtensionDirectory +/+ quarks/);
>
> S.
>
>>
>> But it could be hosted elsewhere like https://github.com/supercollider/quarks
>> and then people can download snapshots for specific versions.
>>
>>
>>
>> On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org> wrote:
>> I was actually looking to see if there was a url where you could just download the latest everything from sf. Couldn't find it.
>>
>>
>>
>> --
>> ..
>> http://soundcloud.com/crucialfelix
>> http://github.com/crucialfelix
>> .
>
>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .

felix

2014-10-20 15:23:45 UTC

Permalink

I'll tag them by SC release.

probably git subtree is better than git submodule:

http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

so that it appears to be one large repo and you can download it

On Mon, Oct 20, 2014 at 5:13 PM, Scott Wilson <***@scottwilson.ca> wrote:

> That would be fantastic thank you! If we could have both latest or
> specific tags that would work very well.
>
> S.
>
> On 20 Oct 2014, at 15:42, felix <felix-***@public.gmane.org> wrote:
>
>
> I'll volunteer to get github.com/supercollider/quarks set up and synced
> to the current state.
>
> or maybe just update this:
> https://github.com/supercollider-quarks/super-repository
>
> We can tag releases and then there is a fixed tarball URL
>
>
>
> On Mon, Oct 20, 2014 at 4:22 PM, Scott Wilson <***@scottwilson.ca> wrote:
>
>>
>> On 20 Oct 2014, at 14:24, felix <felix-***@public.gmane.org> wrote:
>>
>>
>> http://sourceforge.net/p/quarks/code/HEAD/tree/
>>
>> "download snapshotâ
>>
>>
>> Thanks. I saw that, but I need something that can be put into Download(â
>> http://âŠ/quarks-latest.zipOrSomethingLikeThatâ
>> <http://.../quarks-latest.zipOrSomethingLikeThat%E2%80%9D>,
>> Platform.userExtensionDirectory +/+ âquarks/â);
>>
>> S.
>>
>>
>> But it could be hosted elsewhere like
>> https://github.com/supercollider/quarks
>> and then people can download snapshots for specific versions.
>>
>>
>>
>> On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org>
>> wrote:
>>
>>> I was actually looking to see if there was a url where you could just
>>> download the latest everything from sf. Couldn't find it.
>>>
>>
>>
>>
>> --
>> ..
>> http://soundcloud.com/crucialfelix
>> http://github.com/crucialfelix
>> .
>>
>>
>>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .
>
>
>

--
..
http://soundcloud.com/crucialfelix
http://github.com/crucialfelix
.

Scott Carver

2014-10-20 17:09:09 UTC

Permalink

I appreciate the usefulness of being able to browser-download and
drag-install it, but I'd emphasize that this is one very small use-case,
and encourages novice users to get themselves into potentially confusing /
broken situations. After all, now it's on the user to manually figure out
dependencies of the quark when they can't recompile, and manually download
and install those dependencies (including potentially dependencies on the
specific version of SuperCollider itself....). Their code will likely not
run on another machine, nor will it run when they email it to a friend, nor
will it run when they email it to the violinist who is performing their
piece in Munich or whatever - that is, unless they wrote down the version
numbers and urls of every quark they downloaded (which they probably
didn't). Those are all things that it should not be on the user to manage.

If there's a concern about adding extra installations or steps for users,
why not package SuperCollider with a copy of git (most git clients and some
ide's do), npm (atom does this), python (google drive - which is a python
app - does this, as does sublime text), or whatever else we decide is
required to support proper package management?

And, re. listings - the simplicity of a single quarks listing that points
to git repositories is appealing, as Quarks2 is doing now. But, I'm not
sure this is scalable - there are currently... ~158 quarks? Which means 158
file downloads just to list available quarks, and 158 each time you want to
update that listing. And arguably that list should be much larger than it
is, because many of those quarks are actually an aggregate of unrelated
things that really should be published separately - and were probably not
because it's a pain. This also entails 158 separate people maintaining a
list to all their quark versions, which is minor but still massively
duplicated effort.

(I'm glad that felix mentioned npm because I feel like that is a model that
would fit SC well. Npm has solved a lot of very difficult package
management problems in a way that no other package manager (apart from
possibly Ruby gems) has come close to. I investigated using npm for
handling quarks last year, but it wasn't a good match for several reasons I
won't go into. Nonetheless, it's definitely the high water mark in terms of
functionality and usability.)

- S

On Mon, Oct 20, 2014 at 8:23 AM, felix <felix-***@public.gmane.org> wrote:

>
> I'll tag them by SC release.
>
>
> probably git subtree is better than git submodule:
>
>
> http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
>
> so that it appears to be one large repo and you can download it
>
>
>
>
>
>
> On Mon, Oct 20, 2014 at 5:13 PM, Scott Wilson <***@scottwilson.ca> wrote:
>
>> That would be fantastic thank you! If we could have both latest or
>> specific tags that would work very well.
>>
>> S.
>>
>> On 20 Oct 2014, at 15:42, felix <felix-***@public.gmane.org> wrote:
>>
>>
>> I'll volunteer to get github.com/supercollider/quarks set up and synced
>> to the current state.
>>
>> or maybe just update this:
>> https://github.com/supercollider-quarks/super-repository
>>
>> We can tag releases and then there is a fixed tarball URL
>>
>>
>>
>> On Mon, Oct 20, 2014 at 4:22 PM, Scott Wilson <***@scottwilson.ca> wrote:
>>
>>>
>>> On 20 Oct 2014, at 14:24, felix <felix-***@public.gmane.org> wrote:
>>>
>>>
>>> http://sourceforge.net/p/quarks/code/HEAD/tree/
>>>
>>> "download snapshotâ
>>>
>>>
>>> Thanks. I saw that, but I need something that can be put into Download(â
>>> http://âŠ/quarks-latest.zipOrSomethingLikeThatâ
>>> <http://.../quarks-latest.zipOrSomethingLikeThat%E2%80%9D>,
>>> Platform.userExtensionDirectory +/+ âquarks/â);
>>>
>>> S.
>>>
>>>
>>> But it could be hosted elsewhere like
>>> https://github.com/supercollider/quarks
>>> and then people can download snapshots for specific versions.
>>>
>>>
>>>
>>> On Mon, Oct 20, 2014 at 3:12 PM, Scott Wilson <s.d.wilson-mHdZ94l+***@public.gmane.org>
>>> wrote:
>>>
>>>> I was actually looking to see if there was a url where you could just
>>>> download the latest everything from sf. Couldn't find it.
>>>>
>>>
>>>
>>>
>>> --
>>> ..
>>> http://soundcloud.com/crucialfelix
>>> http://github.com/crucialfelix
>>> .
>>>
>>>
>>>
>>
>>
>> --
>> ..
>> http://soundcloud.com/crucialfelix
>> http://github.com/crucialfelix
>> .
>>
>>
>>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .
>

felix

2014-10-20 17:42:10 UTC

Permalink

Conversely, 158 is a pitifully small number for us to waste our time
maintaining code for.

I've looked into the possibility of reusing npm (just as atom did with
apm). its a bit more work than I had hoped.

but just throwing those 158 quarks in on npm is fine. nobody cares, they
welcome it. there's 101k packages on there,
not all of the are js.

the explosive growth of nodejs was very much due to how well npm was put
together. it made sharing part of the culture and it made it very easy to
play with.

Ruby Gems has another lesson: they blew it on security and had several very
high profile vulnerabilities including an attack.
you don't want to roll your own.

the problem with Quarks2 is that it still has too many moving parts. and
that means technical debt and maintenance costs.

On Mon, Oct 20, 2014 at 7:09 PM, Scott Carver <scott-y6qSm6YX8/***@public.gmane.org> wrote:

> And, re. listings - the simplicity of a single quarks listing that points
> to git repositories is appealing, as Quarks2 is doing now. But, I'm not
> sure this is scalable - there are currently... ~158 quarks? Which means 158
> file downloads just to list available quarks, and 158 each time you want to
> update that listing. And arguably that list should be much larger than it
> is, because many of those quarks are actually an aggregate of unrelated
> things that really should be published separately - and were probably not
> because it's a pain. This also entails 158 separate people maintaining a
> list to all their quark versions, which is minor but still massively
> duplicated effort.
>
> (I'm glad that felix mentioned npm because I feel like that is a model
> that would fit SC well. Npm has solved a lot of very difficult package
> management problems in a way that no other package manager (apart from
> possibly Ruby gems) has come close to. I investigated using npm for
> handling quarks last year, but it wasn't a good match for several reasons I
> won't go into. Nonetheless, it's definitely the high water mark in terms of
> functionality and usability.)
>

--
..
http://soundcloud.com/crucialfelix
http://github.com/crucialfelix
.

Scott Wilson

2014-10-20 18:11:24 UTC

Permalink

Felix has a point about maintenance: whether we can do it is moot, as we seemingly dont. Quarks2 has been in the works for a couple of years now. I dont doubt anyones good intentions, but we need to practical.

For myself, at this point Id be happy with anything reasonably stable that actually works. That includes bundling (although people rejected that in the past), or a pre-rolled pm. But I think what felix is doing is the path of least resistance at the moment, will get it working again, and doesnt preclude a better solution in the future.

A single download package that the SC classes can get restores the status quo, and allows updates. Its not the most elegant or efficient, but at least new users wont have to run away screaming.

Felix, if you get the links working I can tweak the classes to use Download.

S.

On 20 Oct 2014, at 18:42, felix <felix-***@public.gmane.org> wrote:

>
> Conversely, 158 is a pitifully small number for us to waste our time maintaining code for.
>
> I've looked into the possibility of reusing npm (just as atom did with apm). its a bit more work than I had hoped.
>
> but just throwing those 158 quarks in on npm is fine. nobody cares, they welcome it. there's 101k packages on there,
> not all of the are js.
>
> the explosive growth of nodejs was very much due to how well npm was put together. it made sharing part of the culture and it made it very easy to play with.
>
> Ruby Gems has another lesson: they blew it on security and had several very high profile vulnerabilities including an attack.
> you don't want to roll your own.
>
> the problem with Quarks2 is that it still has too many moving parts. and that means technical debt and maintenance costs.
>
>
>
> On Mon, Oct 20, 2014 at 7:09 PM, Scott Carver <scott-y6qSm6YX8/***@public.gmane.org> wrote:
> And, re. listings - the simplicity of a single quarks listing that points to git repositories is appealing, as Quarks2 is doing now. But, I'm not sure this is scalable - there are currently... ~158 quarks? Which means 158 file downloads just to list available quarks, and 158 each time you want to update that listing. And arguably that list should be much larger than it is, because many of those quarks are actually an aggregate of unrelated things that really should be published separately - and were probably not because it's a pain. This also entails 158 separate people maintaining a list to all their quark versions, which is minor but still massively duplicated effort.
>
> (I'm glad that felix mentioned npm because I feel like that is a model that would fit SC well. Npm has solved a lot of very difficult package management problems in a way that no other package manager (apart from possibly Ruby gems) has come close to. I investigated using npm for handling quarks last year, but it wasn't a good match for several reasons I won't go into. Nonetheless, it's definitely the high water mark in terms of functionality and usability.)
>
>
>
>
> --
> ..
> http://soundcloud.com/crucialfelix
> http://github.com/crucialfelix
> .

felix

2014-10-20 13:21:16 UTC

Permalink

I think this is pragmatic.

The quarks can be made into a single download and just link people to this.

Make that the first recommendation for users: *download them from {here}
and put them {here}*

If you like some other quark, then just git clone it or download it.

---

For programmers and more advanced users, I recommend using npm.

Just publish your quarks. It works right now, and it works great.
You can search the directory online.
Anybody can publish and there's lots of support.
Anybody can install it on any OS with a simple download.

A community the size of supercollider cannot maintain its own packaging
system,
and it doesn't need to anymore.

Atom didn't bother to build their own, they just used npm

It should not be trying to do downloads, security, dependency management,
searchable indices.
Security is a very serious concert

On Mon, Oct 20, 2014 at 2:02 PM, Andrea Valle <valle-***@public.gmane.org> wrote:

> Well, to be honest, if I had my way, we would clearly separate releases
> and dev tree. When Iâve suggested that in the past people objected that
> that was too much trouble for devs, despite the fact that thatâs the way
> itâs done with the vast majority of software, including SC. For super users
> I donât mind if Quarks supports distribution by git, curl, or punchcards.
> Iâm just making a plea for the regular humans.
>
>
> I totally agree with Scott, and I said it many times from a userâs pov.
> Which -let me state it unpleasantly- is the only relevant here, because
> devs know how to use a versioning system, and they just manage their
> working activity the way they prefer.
>
> I think itâs pretty obvious.
>
> Users just need:
> 1. a place on the web where to download stuff
> 2. a clear indication where to place stuff on their machine
> 3. to keep the ârecompileâ mantra in their minds.
>
> âOh, but maybe I have an older version? Ok, I delete it and download it
> againâ. Whatâs the issue here? There are no hidden files in installing
> quarks.
> Itâs the force of SC, theyâre just txt files.
>
> We donât need either a download manager. Everybody can download the way
> s/he prefers from the quark webpage.
> BTW, itâs the way I do very happily, as my svn is broken since years. I go
> to quarks dir, download and go.
>
>
> Best
>
> -a-
>
> PS: of course, maximum respect and gratitude to all who have profused
> their efforts into quark development!
>
>
>
> But in any case, the script which generates the manifest could tag it with
> a version. That could be derived from scm info if desired.
>
> S.
>
>
> --------------------------------------------------
> Andrea Valle
> --------------------------------------------------
> CIRMA - StudiUm
> UniversitÃ degli Studi di Torino
> --> http://www.cirma.unito.it/andrea/
> --> http://www.fonurgia.unito.it/andrea/
> --> http://www.flickr.com/photos/vanderaalle/sets/
> --> http://vimeo.com/vanderaalle
> --> andrea.valle-Ob+***@public.gmane.org
> --------------------------------------------------
>
> "This is a very complicated case, Maude. You know, a lotta ins, a lotta
> outs, a lotta what-have-yous."
> (Jeffrey 'The Dude' Lebowski)
>
>

--
..
http://soundcloud.com/crucialfelix
http://github.com/crucialfelix
.

nescivi

2014-10-20 19:32:56 UTC

Permalink

On 20-10-14 14:02, Andrea Valle wrote:
>> Well, to be honest, if I had my way, we would clearly separate
>> releases and dev tree. When I’ve suggested that in the past people
>> objected that that was too much trouble for devs, despite the fact
>> that that’s the way it’s done with the vast majority of software,
>> including SC. For super users I don’t mind if Quarks supports
>> distribution by git, curl, or punchcards. I’m just making a plea for
>> the regular humans.
>
> I totally agree with Scott, and I said it many times from a user’s pov.
> Which -let me state it unpleasantly- is the only relevant here, because
> devs know how to use a versioning system, and they just manage their
> working activity the way they prefer.
>
> I think it’s pretty obvious.
>
> Users just need:
> 1. a place on the web where to download stuff
> 2. a clear indication where to place stuff on their machine
> 3. to keep the “recompile” mantra in their minds.
>
> “Oh, but maybe I have an older version? Ok, I delete it and download it
> again”. What’s the issue here? There are no hidden files in installing
> quarks.
> It’s the force of SC, they’re just txt files.
>

Apart from the directory where to put the files, nothing is hidden ;)

But this is solved by the shortcut in the file menu of the IDE, and the
SC line of code:

Platform.userAppSupportDir.openOS;

What should be added is to automatically add a folder named Extensions,
as I have seen some cases in a workshop where people had problems with
creating the directory, by either misspelling, or having the case (the
capital E) wrong. Would have saved about half an hour of workshop time,
if it had been created automatically in my last workshop.

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Miguel Negrão

2014-10-20 14:08:46 UTC

Permalink

On 20-10-2014 12:02, Scott Wilson wrote:

> Well, to be honest, if I had my way, we would clearly separate releases
> and dev tree. When Ive suggested that in the past people objected that
> that was too much trouble for devs, despite the fact that thats the way
> its done with the vast majority of software, including SC. For super
> users I dont mind if Quarks supports distribution by git, curl, or
> punchcards. Im just making a plea for the regular humans.

Hi,

I think Scott has a valid point here.

It's not much work to create a link to a zip file in github from a git
tag using github releases. Devs could work in git and create a quarks2
release by creating a tag, creating a release in github and editing the
quarks2 yamls file, adding the new version and link. I'm sure the
process could be automated and done in the background by some server, if
someone wanted to spend the time coding that.

best,
Miguel

nescivi

2014-10-20 19:28:53 UTC

Permalink

Hiho,

On 20-10-14 13:02, Scott Wilson wrote:
>
> On 20 Oct 2014, at 10:39, Dan Stowell <danstowell+sc3-***@public.gmane.org
> <mailto:danstowell+sc3-***@public.gmane.org>> wrote:
>>>
>>> No, I am asking if Quarks2 as it exists requires users to have svn,
>>> git, and
>>> curl installed in order to get all available Quarks.
>>
>> To get all of them, yes.
>
> Then I’m afraid I think that does make the situation worse. Now a user
> can get svn working, only to find that some Quarks require git or curl.
> I understand that back in the mists of time people may have been
> thinking about flexibility rather than users, but i think it’s pretty
> evident we can’t keep going like that.

As long as we keep our *standard* list of quarks available as simple
downloads, with just dependencies to each other and not to external
sources, it will be sufficient to *just* use the standard Download class
(is this one still fictional, or already there?).

Any further user/developer created quarks can use whichever system the
developer finds useful for as wide as she wants to spread the use of her
quark.

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 19:40:33 UTC

Permalink

On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org> wrote:

> As long as we keep our *standard* list of quarks available as simple
> downloads, with just dependencies to each other and not to external
> sources, it will be sufficient to *just* use the standard Download class
> (is this one still fictional, or already there?).

Its there: https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1

But truth is stranger than fiction

S.

nescivi

2014-10-20 19:47:19 UTC

Permalink

On 20-10-14 21:40, Scott Wilson wrote:
>
> On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org
> <mailto:nescivi-***@public.gmane.org>> wrote:
>
>> As long as we keep our *standard* list of quarks available as simple
>> downloads, with just dependencies to each other and not to external
>> sources, it will be sufficient to *just* use the standard Download class
>> (is this one still fictional, or already there?).
>
> It’s
> there: https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1
>
> But truth is stranger than fiction…

Indeed...

So this only works within the IDE? Given the Qt dependency for doing this?

That means it will not work on headless systems like BeagleBones...

I am not sure we want to make Quarks support only available for systems
running a graphical user interface.

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 20:15:48 UTC

Permalink

On 20 Oct 2014, at 20:47, nescivi <nescivi-***@public.gmane.org> wrote:

> On 20-10-14 21:40, Scott Wilson wrote:
>>
>> On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org
>> <mailto:nescivi-***@public.gmane.org>> wrote:
>>
>>> As long as we keep our *standard* list of quarks available as simple
>>> downloads, with just dependencies to each other and not to external
>>> sources, it will be sufficient to *just* use the standard Download class
>>> (is this one still fictional, or already there?).
>>
>> It’s
>> there: https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1
>>
>> But truth is stranger than fiction…
>
> Indeed...
>
> So this only works within the IDE? Given the Qt dependency for doing this?
>
> That means it will not work on headless systems like BeagleBones...
>
> I am not sure we want to make Quarks support only available for systems
> running a graphical user interface.

Then by all means change the implementation. Tim had a suggestion and said he’d look into it, but never did.

As it is, it would not break anything. The existing svn approach would still work. It would just mean most people could do it without additional dependancies. So I don’t see how it’s not a net win.

S.
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

nescivi

2014-10-20 20:38:15 UTC

Permalink

On 20-10-14 22:15, Scott Wilson wrote:
>
> On 20 Oct 2014, at 20:47, nescivi <nescivi-***@public.gmane.org> wrote:
>
>> On 20-10-14 21:40, Scott Wilson wrote:
>>>
>>> On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org
>>> <mailto:nescivi-***@public.gmane.org>> wrote:
>>>
>>>> As long as we keep our *standard* list of quarks available as simple
>>>> downloads, with just dependencies to each other and not to external
>>>> sources, it will be sufficient to *just* use the standard Download class
>>>> (is this one still fictional, or already there?).
>>>
>>> It’s
>>> there: https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1
>>>
>>> But truth is stranger than fiction…
>>
>> Indeed...
>>
>> So this only works within the IDE? Given the Qt dependency for doing this?
>>
>> That means it will not work on headless systems like BeagleBones...
>>
>> I am not sure we want to make Quarks support only available for systems
>> running a graphical user interface.
>
> Then by all means change the implementation. Tim had a suggestion and said he’d look into it, but never did.
>
> As it is, it would not break anything. The existing svn approach would still work. It would just mean most people could do it without additional dependancies. So I don’t see how it’s not a net win.

>From a design point of view it is mixing sclang functionality with
editor functionality, or at least that is what I see from quickly
looking at the commits.
I am just a bit concerned about it.

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Scott Wilson

2014-10-20 21:24:10 UTC

Permalink

On 20 Oct 2014, at 21:38, nescivi <nescivi-***@public.gmane.org> wrote:

> On 20-10-14 22:15, Scott Wilson wrote:
>>
>> On 20 Oct 2014, at 20:47, nescivi <nescivi-***@public.gmane.org> wrote:
>>
>>> On 20-10-14 21:40, Scott Wilson wrote:
>>>>
>>>> On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org
>>>> <mailto:nescivi-***@public.gmane.org>> wrote:
>>>>
>>>>> As long as we keep our *standard* list of quarks available as simple
>>>>> downloads, with just dependencies to each other and not to external
>>>>> sources, it will be sufficient to *just* use the standard Download class
>>>>> (is this one still fictional, or already there?).
>>>>
>>>> Its
>>>> there: https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1
>>>>
>>>> But truth is stranger than fiction
>>>
>>> Indeed...
>>>
>>> So this only works within the IDE? Given the Qt dependency for doing this?
>>>
>>> That means it will not work on headless systems like BeagleBones...
>>>
>>> I am not sure we want to make Quarks support only available for systems
>>> running a graphical user interface.
>>
>> Then by all means change the implementation. Tim had a suggestion and said hed look into it, but never did.
>>
>> As it is, it would not break anything. The existing svn approach would still work. It would just mean most people could do it without additional dependancies. So I dont see how its not a net win.
>
>
> From a design point of view it is mixing sclang functionality with
> editor functionality, or at least that is what I see from quickly
> looking at the commits.
> I am just a bit concerned about it.

I understand the concern. At the time I used Qt because it avoided an additional dependency, which people usually object to on principle.

But right now the Quarks situation is a much bigger deal. The back end of Download could always be changed. This is the lib Tim suggested:

http://cpp-netlib.org

Its not a massive job (IIRC the biggest problem with it was SCs incomplete boost), and I may get to it one day, but to be blunt my SC list is pretty long at the moment, and somebody might want to do Quarks without svn on a headless SC, and cant manually download is pretty low on my priorities to solve.

S.

Scott Carver

2014-10-20 22:08:40 UTC

Permalink

It should be possible, with Qt5 at least, to winnow down the dependencies
of QtDownload to just the QtNetwork and QtCore libraries..... I think. That
would avoid ui dependencies and allow running in a headless environment,
though it doesn't remove the Qt dependencies entirely (which can be a
problem in itself).

- S

On Mon, Oct 20, 2014 at 2:24 PM, Scott Wilson <***@scottwilson.ca> wrote:

>
> On 20 Oct 2014, at 21:38, nescivi <nescivi-***@public.gmane.org> wrote:
>
> On 20-10-14 22:15, Scott Wilson wrote:
>
>
> On 20 Oct 2014, at 20:47, nescivi <nescivi-***@public.gmane.org> wrote:
>
> On 20-10-14 21:40, Scott Wilson wrote:
>
>
> On 20 Oct 2014, at 20:28, nescivi <nescivi-***@public.gmane.org
> <mailto:nescivi-***@public.gmane.org <nescivi-***@public.gmane.org>>> wrote:
>
> As long as we keep our *standard* list of quarks available as simple
> downloads, with just dependencies to each other and not to external
> sources, it will be sufficient to *just* use the standard Download class
> (is this one still fictional, or already there?).
>
>
> Itâs
> there:
> https://github.com/supercollider/supercollider/commit/4d352de268f6d346397c767537fb8e785d5602b1
>
> But truth is stranger than fictionâŠ
>
>
> Indeed...
>
> So this only works within the IDE? Given the Qt dependency for doing this?
>
> That means it will not work on headless systems like BeagleBones...
>
> I am not sure we want to make Quarks support only available for systems
> running a graphical user interface.
>
>
> Then by all means change the implementation. Tim had a suggestion and said
> heâd look into it, but never did.
>
> As it is, it would not break anything. The existing svn approach would
> still work. It would just mean most people could do it without additional
> dependancies. So I donât see how itâs not a net win.
>
>
>
> From a design point of view it is mixing sclang functionality with
> editor functionality, or at least that is what I see from quickly
> looking at the commits.
> I am just a bit concerned about it.
>
>
> I understand the concern. At the time I used Qt because it avoided an
> additional dependency, which people usually object to on principle.
>
> But right now the Quarks situation is a much bigger deal. The back end of
> Download could always be changed. This is the lib Tim suggested:
>
> http://cpp-netlib.org
>
> Itâs not a massive job (IIRC the biggest problem with it was SCâs
> incomplete boost), and I may get to it one day, but to be blunt my SC list
> is pretty long at the moment, and somebody might want to do Quarks without
> svn on a headless SC, and canât manually download is pretty low on my
> priorities to solve.
>
> S.
>

Jakob Leben

2014-10-21 01:52:20 UTC

Permalink

Hi devs,

1. I think adding a dependency on another small library for HTTP (perhaps
including the lib in our sources) is far less evil (and it's the long-run
solution anyway) than using Qt for this purpose.

2. Mind that these are two different things: 1. the quarks system, 2. a
particular "official" storage location (and access method) for quarks. As
far as I understand the Quarks 2 system adds flexibility to choose any
location and method desirable (including existing svn), and therefore I
don't see anything else but a win in adopting it as soon as possible.
Discussion about what should be the official or default quarks storage /
method is orthogonal.

Jakob

Scott Wilson

2014-10-21 06:57:16 UTC

Permalink

Hi Jakob,

On 21 Oct 2014, at 02:52, Jakob Leben <jakob.leben-***@public.gmane.org> wrote:

> Hi devs,
>
> 1. I think adding a dependency on another small library for HTTP (perhaps including the lib in our sources) is far less evil (and it's the long-run solution anyway) than using Qt for this purpose.

Yeah, that’s not really the issue. In itself it's small. The problem was it required a larger subset of boost than we currently use. Looking back, I’d even started switching to it, but the boost thing was beyond my ken and I guess Tim just never had time.

I think somebody suggested including all of boost at some point. That would have the advantage of being simple, and less likely to cause problems.
>
> 2. Mind that these are two different things: 1. the quarks system, 2. a particular "official" storage location (and access method) for quarks. As far as I understand the Quarks 2 system adds flexibility to choose any location and method desirable (including existing svn), and therefore I don't see anything else but a win in adopting it as soon as possible. Discussion about what should be the official or default quarks storage / method is orthogonal.

If you look back at the start of this thread, you’ll see that the actual point was 3. Quarks has become almost unusable for a large number of non-expert users – and let’s face it, it was never really very good for them – and that has to be fixed. Any changes to 1 or 2 that don’t sort 3 are just rearranging the deck chairs on the Titanic.

S.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/