UGen lookup seems to be case-sensitive

[tildebyte]

As it stands, chuck_doc_search.py points to: http://chuck.cs.princeton.edu/doc/program/ugen_full.html#SndBuf which (at least on Win 7 FF 25) is the top of the page. Lower-casing the UGen name: http://chuck.cs.princeton.edu/doc/program/ugen_full.html#sndbuf navigates to the specific entry.

[zeffii]

yeah, that's by design - they end up in the same place? i'll make it case agnostic. sure!

[tildebyte]

I don't think I was clear... The mixed-case URL goes to the top of the page; the lowercase URL goes directly to the anchor link for the specific UGen...

[zeffii]

OK, that behaves differently on chrome, it was always jumping directly to ugen in question

[tildebyte]

Gosh I love standards :smile:

[zeffii]

This way is fine for me too. mark it as fixed for now?

[tildebyte]

Sounds good.

[tildebyte]

Apologies. In true ChucK fashion, "it depends", i.e. 'ADSR' is U/C, 'gain' is L/C - there's no rhyme or reason. http://www.htmlhelp.com/reference/html40/special/a.html - "When linking to a named anchor, the name is treated as case sensitive." So, they really need to decide on one style for the HTML. Seems like the actual language case should apply, i.e. the 'dac' anchor link should be 'dac', the 'Gain' anchor link should be 'Gain', etc. The problem is that the language itself seems to ignore case...

[zeffii]

it's not clear to me, using chrome, what to fix.

[tildebyte]

Yeah, the only thing which comes to mind ATM is to scrape the doc page(s) and see what the anchor link name attribute is, and then hard-code that (hooray). So, Chrome is working regardless of case? That breaks the standard... interesting.

[zeffii]

perhaps you can show me an example of where this is failing for you.

I'm spending some time this evening trying to get chuck shell to work, i've not given up on something so trivial.

[tildebyte]

Here's the complete list, grep'd from the HTML. Note that e.g. "gain" should be "Gain", and "sinosc" should be "SinOsc". I don't yet see anything U/C which shouldn't be: "dac" "adc" "blackhole" "gain" "noise" "impulse" "step" "halfrect" "fullrect" "zerox" "BiQuad" "Filter" "OnePole" "TwoPole" "OneZero" "TwoZero" "PoleZero" "LPF" "HPF" "BPF" "BRF" "ResonZ" "FilterBasic" "Dyno" "delayp" "sndbuf" "phasor" "sinosc" "pulseosc" "sqrosc" "triosc" "sawosc" "GenX" "Gen5" "Gen7" "Gen9" "Gen10" "Gen17" "CurveTable" "LiSa" "netout" "netin" "pan2" "mix2" "StkInstrument "BandedWG" "BlowBotl" "BlowHole" "Bowed" "Brass" "Clarinet" "Flute" "Mandolin" "ModalBar" "Moog" "Saxofony" "Shakers" "Sitar" "StifKarp" "VoicForm" "FM" "BeeThree" "FMVoices" "HevyMetl" "PercFlut" "Rhodey" "TubeBell" "Wurley" "Delay" "DelayA" "DelayL" "Echo" "Envelope" "ADSR" "JCRev" "NRev" "PRCRev" "Chorus" "Modulate" "PitShift" "SubNoise" "Blit" "BlitSaw" "BlitSquare" "WvIn" "WaveLoop" "WvOut"

[zeffii]

i'm not sure how to resolve the difference between how Firefox and Chrome handle the fragment identifier

It's only lowercase because you noticed this wasn't working for firefox, for the Ugen names. It isn't designed to look for a destinction between the gain method and the Gain object. Please give some (or two) examples of what you are selecting and what you expect doc_search to do.

If there is slight inconsistency in how the chuck doc / manual uses the identifier, then it might be worth converting the docs (maybe ask permission of Ge.. it's in ChucK's best interest anyway) to the doc structure of read the docs

[tildebyte]

LOL @ the fragment identifier wiki entry; the ChucK docs are even more wrong than I had thought. The anchor attribute shouldn't even be 'name', it should be 'id'.

I realize you changed the code to fix my issue. The underlying problem is in the HTML docs themselves.

If I select SqrOsc and CTRL+SHIFT+], I get the online doc, scrolled to the SqrOsc entry, because the 'name' attribute for that entry is lowercase (<a name="sqrosc" class="heading">[ugen]</a>), as is the URI you're using. If, however, I select Envelope and CTRL+SHIFT+], I get the top of the online doc, because its 'name' attribute is uppercase (<a name="Envelope" class="heading">[ugen]</a>). The bottom line is that the case presented to us as canonical in the course (i.e. 'SinOsc') does not in all cases match what's in the raw HTML code of the docs.

Read The Docs is nice, but I'm not a fan of reStructuredText.

[zeffii]

I see, well http://chuck.cs.princeton.edu/doc/program/ugen_full.html#Envelope http://chuck.cs.princeton.edu/doc/program/ugen_full.html#envelope jump to the same location in Chrome.

Not sure if I feel like sticking time into this complexity headache. If you write out a rule when to lowercase and when not to for firefox, it would be easy enough to have an environmental variable that users can set to Firefox or webkit (chrome). Other than that...

[tildebyte]

Figures. Safari on OSX acts like Chrome... If you wouldn't mind, could you revert back to preserving case in the URLs? Apparently Chrome and Safari don't care, and at least some of the anchor links will work in FF. Next time, I'll research more thoroughly before I ask for code changes :D

[zeffii]

sure thing! soon, as i'm not in favour of changing case for searches -- it might make more sense to expand the list of valid 'hits' or use a different hit list if "firefox" is specified in the chuck addon settings file.

[tildebyte]

Derp. I dunno why I didn't think of using the settings file...

[zeffii]

I've been thinking about this sporadically (as i get closer to nailing the chuck --shell interactivity) , I think indeed a simple switch will suffice...but it'll look ugly. If it goes pear-shape at least it can be reverted

[zeffii]

thinking about the issue gives me a headache man.