Searchable "object list" for Quarks

Development
1

The idea is to be able to search for a particular class or method or keyword inside Quarks.

@Spacechild1 has pointed us at the deken package manager for PD which has the feature object lists .

deken uses help files to generate an object list automatically if one is not provided. This seems like a practical way to add this feature to legacy Quarks (of course many do not have adequate or any help files!)

If a Quark is installed and sclang is alive we can do

(
var file = "/tmp/ObjectList.txt";
Class.allClasses.select({|i| 
    i.filenameSymbol.asString.contains("MathLib")
}).do({|x| 
    var cmd = "echo" + x.asString + ">>" + file; cmd.unixCmd 
})
)

to make a list of the objects… Not sure how to do Class extension methods?

to get the summaries something like this:

(
var node = SCDoc.parseFileFull("/Applications/SuperCollider.app/Contents/Resources/HelpSource/Classes/SinOsc.schelp")  ;
SCDocEntry(node,"/Applications/SuperCollider.app/Contents/Resources/HelpSource/Classes/SinOsc.schelp").summary
)

(sorry I haven’t figured out how to get the .schelp file path just yet…)

@scztt has called for the creation of a new spec for “Quarks 2.0” - should an objects list be part of such a spec? should that list be part of a single YAML file or a seperate txt file as in deken?

4 Likes
4

Sorry for folderol! this one works:

(
~classes = { |quarkName| 
	Class.allClasses.select({ |x| 
		x.filenameSymbol.asString.contains(quarkName)
	}).reject{|x| x.asString.contains("Meta_")}
};

~schelpFiles = { |quarkName|
	Quark(quarkName).localPath.asPathName.deepFiles.flat.select{|i| 
	i.extension == "schelp"
	}	
};
~getSchelpFile = {|class quarkName|
	~schelpFiles.(quarkName).select{ |i| i.fileNameWithoutExtension == class.asString}.flat.unbubble
};

~summary = { |pathname|
		var node;
		pathname.notNil.if {
			node = SCDoc.parseFileFull(pathname.fullPath)  ;
			 SCDocEntry(node,pathname.fullPath).summary
	}{ "missing summary" }
};
~objectList = {|quarkName| 
	~classes.(quarkName).collect{|x|
		x->~summary.(~getSchelpFile.(x, quarkName))
	}.asDict
}
)
5

…and here a working method version

invoke like Quark("MathLib").objectList- again only works if a Quark is already loaded!

+Quark {
	classes {  
		^Class.allClasses.select({ |x| 
			x.filenameSymbol.asString.contains(this.name)
		}).reject{|x| x.asString.contains("Meta_")}
	}

	schelpFiles { 
		^localPath.asPathName.deepFiles.flat.select{|i| 
			i.extension == "schelp"
		}	
	}

	getSchelpFile {|class|
		^this.schelpFiles.select{ |i| i.fileNameWithoutExtension == class.asString}.flat.unbubble
	}

	objectList {
		var summary = { |pathname|
			var node;
			pathname.notNil.if {
				node = SCDoc.parseFileFull(pathname.fullPath)  ;
				SCDocEntry(node,pathname.fullPath).summary
			}{ "missing summary" }
		};
		^this.classes.collect{|x|
			x->summary.(this.getSchelpFile(x))
		}.asDict
	}
}
6

@jordan you mentioned that this could almost be done with grep

…and here’s an effort with grep sed and cut that seems to be working -

you invoke it with the local path of a Quark and it will spit out all the Class names

The thought is that it could be used to build up an object list for Quark’s that are not installed.

…of course with a Quark installed we could build not only an object list but a method list in a straightforward way

find "$1" -iname "*.sc" -exec grep -E\
	^[[:space:]]?\\b[[:upper:]][A-Za-z]*\ \(:[[:space:]]*[A-Za-z]*[[:space:]]\)\?{ {} \;\
	| sed 's/[[:space:]]*\(.*\){/\1/'\
	| cut -d" " -f1
7

But in order to grep, all quarks have to be downloaded, no? Or do you envision keeping a separate “database” that is (hopefully automatically) kept in sync with the quark list?

1 Like
8

It would be cool to have an API that allows you to search the quarks by either method name, Help files, or by some approximate search method. That would be a good project.

9

Method names is tricky - if a quark is loaded its straightforward:

Class.allClasses.collect( _.methods ).flat.reject( _.isNil )
.select({ |i| i.filenameSymbol.contains("MathLib")} ).do(_.postln)

will display all the methods defined in MathLib…

sc files could be parsed for methods but that would be a little bit of a pain…

re database.I think its best if we expect each Quark to contain an objectList file - we could provide for legacy Quarks and generate on the fly for dlownloaded quarks that don’t have. Unless there’s a simpler approach?

10

@semiquaver , You may want to have a look at packages.sc, which already has existing implementations of some of the methods you are describing. For example, we can already do:

UGen.findMethod(\thresh2).package;
Euler.package;
Quark("MathLib").definesClasses;
Quark("MathLib").definesExtensionMethods.do{|m| [m.ownerClass.name, m.name].postln};
Quark("MathLib").definesClasses.do{|c| c.name.postln; c.methods.do{|m| "\t".post; m.name.postln}};

Those are for already downloaded quarks, but I agree that it would be amazing if there were a way to query quarks that have not been downloaded!

1 Like
11

Yea, I was thinking about all quarks out there, not the ones in the downloaded folder.

12

oof… reinventing the wheel… I overlooked that file somehow… thx…

I guess I could see this being rejiggered as part of a more coherent modular approach if everything goes well

13

Ok… but one still needs to download the quark to get the object list file, no? Or is there a central repository of nothing but objectlist files somewhere?

1 Like
14

OK I’m thinking I should fork the downloaded-quarks repo and write a script to add an ObjectList file to each Quark folder - dumb? (there is already an update script which doesn’t seem to have been run in 6 or 7 years,…)

15

Not as far as I can tell :slight_smile:

I think most quarks remain fairly stable once they’ve past their initial few releases, but ideally such ObjectList should be regenerated once in a while. Or maybe it’s the quark’s author’s responsibility to ask for a regeneration if new classes were added? (I guess I need to do some digging to understand how all this works in systems which offer search already - I think many package management systems explicitly require developers to announce that new version of their software is available, which is different from the downloaded-quarks repo)