[PlanetCCRMA] [sc-dev] Re: weird sclang problems with weird characters

Sun Jul 15 11:28:32 PDT 2012

On 07/15/2012 02:47 AM, Dan Stowell wrote:
> Hi Fernando,

Hi Dan,

> Unfortunately this happens from time to time, and I think we concluded
> that some Mac developers with German keyboards can occasionally press
> things like Alt+Space by accident, and put gremlin characters in code
> without noticing. It causes no problem for many devs, so it's hard to
> notice it happening.
>
> Here's a command-line way to strip a file (named "ggg.sc"):
>
>    tr -cd '\11\12\15\40-\176'<  ggg.sc>  tmp.txt&&  mv -f tmp.txt ggg.sc

Thanks!, I'll use it to make a new package (maybe something similar 
could be scripted into the release process of sc, sc3-plugins and the 
quarks?). How did you come up with that particular translation set for tr?

> I've just committed a fix to the MathLib quark fixing those files you
> identify. I've also committed a fix to the core code in both master
> and the 3.5 branch. Maybe you want to backport the patch? Here it is:
> <https://github.com/supercollider/supercollider/commit/aeab35e3103d35667eda069c64b699dc66d63bd8>

I wrote a tiny script that I will use to filter all sc files in my sc, 
sc3-plugins and quarks packages so that this will not happen again in 
the future (hopefully).

Thanks again!

(any linux'ers out there can explain why it only happens to, so far, one 
person only? Is this a locale thing? - for example I use the same files 
myself and sclang is happy about them)

-- Fernando

> 2012/7/14 Fernando Lopez-Lezcano<nando at ccrma.stanford.edu>:
>> Hi SuperColliders,
>>
>> One of the users of my Planet CCRMA SuperCollider packages is having a
>> strange problem. Starting sclang fails and I found some non-ascii characters
>> in the class that was reporting errors (see below). After editing them out
>> sclang got further but still failed to run. I imagine it has to be the
>> locale he is running under as he is the only person reporting problems (I
>> can't reproduce it). Any linux users have any ideas on why this is happening
>> and how it could be solved?
>>
>> Thanks...
>> -- Fernando
>>
>> On 07/13/2012 07:41 PM, Schindler, Allan wrote:
>>>
>>> Progress! I installed Fernando's edited version of
>>> /usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc
>>> The 2 lines in that Fernando edited to remove the possibly bogus character
>>> (which looks like a capital "E" with a circumflex on my display) no longer
>>> trigger parse errors from sced or sclang. The errors I now get are:
>>> ==========================================================
>>> init_OSC
>>> empty
>>> compiling class library...
>>> NumPrimitives = 665
>>> compiling dir: '/usr/share/SuperCollider/SCClassLibrary'
>>> compiling dir: '/usr/share/SuperCollider/Extensions'
>>> pass 1 done
>>>
>>> at '/JITLib/ProxySpace/wrapForNodeProxy.sc' line 68 char 5
>>> code -54
>>> in file '/JITLib/ProxySpace/wrapForNodeProxy.sc' line 68 char 5
>>> ERROR: Parse error
>>> in file '/JITLib/ProxySpace/wrapForNodeProxy.sc'
>>> line 68 char 5:
>>> ^
>>> }
>>> -----------------------------------
>>> ERROR: file '/JITLib/ProxySpace/wrapForNodeProxy.sc' parse failed
>>> error parsing
>>>
>>> at
>>>
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/LazyLindenmayer/extStringRewrite.sc'
>>> line 100 char 26
>>> code -54
>>> in file
>>>
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/LazyLindenmayer/extStringRewrite.sc'
>>> line 100 char 26
>>> ERROR: Parse error
>>> inval = current[0].yield;
>>> -----------------------------------
>>> ERROR: file
>>>
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/LazyLindenmayer/extStringRewrite.sc'
>>> parse failed
>>> error parsing
>>> ERROR: Class extension for nonexistent class 'StartRow'
>>> In
>>>
>>> file:'/usr/share/SuperCollider/Extensions/dewdrop_lib/ddwGUIEnhancements3.4/recursiveResize.sc'
>>> =======================================================
>>> The compile errors that I previously saw that have disappeared when using
>>> Fernando's edited file Solver.sc are:
>>>
>>> at
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 52 char 56
>>> code -54
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 52 char 56
>>> ERROR: Parse error
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 52 char 56:
>>> ^
>>> ++ [{ arg... args; af.(*args) }];
>>> -----------------------------------
>>> ERROR: file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> parse failed
>>> error parsing
>>> ERROR: Cannot find superclass 'Solver' for class 'Euler'
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 141 char 14:
>>> Euler : Solver {
>>> -----------------------------------
>>> ERROR: Cannot find superclass 'Solver' for class 'RK'
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 79 char 11:
>>> RK : Solver {
>>> -----------------------------------
>>> ERROR: Cannot find superclass 'RK' for class 'RK2'
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 126 char 8:
>>> RK2 : RK {
>>> -----------------------------------
>>> ERROR: Cannot find superclass 'RK' for class 'RK3'
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 112 char 8:
>>> RK3 : RK {
>>> -----------------------------------
>>> ERROR: Cannot find superclass 'RK' for class 'RK4'
>>> in file
>>> '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>> line 95 char 8:
>>> RK4 : RK {
>>> =============================================
>>> In looking at
>>>
>>> /usr/share/SuperCollider/SCClassLibrary/JITLib/ProxySpace/wrapForNodeProxy.sc
>>> and
>>>
>>> /usr/share/SuperCollider/Extensions/MathLib/classes/LazyLindenmayer/extStringRewrite.sc
>>> where the first errors now occur I was hoping to find something similar --
>>> a deviant-looking character -- but the characters where the compiler
>>> seems to
>>> die are circumflexes, and there are *lots* of circumflex characters in
>>> these files.
>>> I haven't had time to look into these errors more carefully.
>>> Thanks to Fernando for the custom cabintry onthe Solver.sc file. It really
>>> is good to see some prgoress on this knotty problem.
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Fernando Lopez-Lezcano [mailto:nando at ccrma.Stanford.EDU]
>>> Sent: Fri 7/13/2012 8:42 PM
>>> To: planetccrma at ccrma.Stanford.EDU; Schindler, Allan; Fernando
>>> Lopez-Lezcano
>>> Subject: Re: [PlanetCCRMA] sced missing from Gedit plugins
>>>
>>> On 07/13/2012 02:30 PM, Schindler, Allan wrote:
>>>>
>>>>   I am *still* trying to get supercollider functional with gedit/sced
>>>>   (gedit-3.2.6-1.fc16.i686) on F16 and am still getting compile errors.
>>>
>>>
>>> Argh, very sorry to hear that (I was hoping you were up and running
>>> already).
>>>
>>>>   The errors I get from sced are:
>>>>
>>>>   init_OSC
>>>>   empty
>>>>   compiling class library...
>>>>   NumPrimitives = 665
>>>>   compiling dir: '/usr/share/SuperCollider/SCClassLibrary'
>>>>   compiling dir: '/usr/share/SuperCollider/Extensions'
>>>>   pass 1 done
>>>>   at
>>>>   '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>>>   line 52 char 56
>>>>   code -54
>>>>   in file
>>>>   '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>>>   line 52 char 56
>>>>   ERROR: Parse error
>>>>   in file
>>>>   '/usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc'
>>>>   line 52 char 56:
>>>>   ^
>>>>   ++ [{ arg... args; af.(*args) }];
>>>
>>>
>>> Hmmm, I'm looking at the file with "more" and see a weird character in
>>> that line.
>>> This is what it looks like in an emacs buffer:
>>>
>>> ----
>>> order = (af.def.numArgs-1);
>>> f = ((order-1).collect{ |i| { arg... args; args[i+2]\312} })
>>> ++ [{ arg... args; af.(*args) }];
>>> f = f.as(NFunc);
>>> ----
>>>
>>> The "\312" is a character that probably should not be there. There is
>>> another line like that somewhere below:
>>>
>>> ----
>>> f = af.collect{ |func,k|
>>> //postln("function: "++ k);
>>> (((order-1).collect{ |i| { arg... args; args[i+2+(k*order)]\312} })
>>> ++ [{ arg... args; func.(*args) }])
>>> }.as(SystemNFunc);
>>> ----
>>>
>>> I'm trying to imagine _why_ this is triggering an error for you (I have
>>> those same files and they work). Maybe you are working with a different
>>> locale and in that one that character is recognized and acted upon??
>>>
>>> I tried to actually edit the file and emacs said:
>>>
>>> ----
>>> These default coding systems were tried to encode text
>>> in the buffer `Solver.sc':
>>> (emacs-mule-unix (15 . 4194187) (1516 . 4194250) (1880 . 4194250))
>>> (utf-8-unix (15 . 4194187) (1516 . 4194250) (1880 . 4194250))
>>> However, each of them encountered characters it couldn't encode:
>>> emacs-mule-unix cannot encode these:
>>> utf-8-unix cannot encode these:
>>>
>>> Click on a character (or switch to this window by `C-x o'
>>> and select the characters by RET) to jump to the place it appears,
>>> where `C-u C-x =' will give information about it.
>>> ----
>>>
>>> So there is something fishy going on with those characters (and there's
>>> one more I had not seen!)
>>>
>>> I'm attaching an edited version of that file, could you login as root
>>> and replace the one that is there with this one? Sorry, I'm running out
>>> of things to try :-(
>>>
>>> The full path of the file should be:
>>> /usr/share/SuperCollider/Extensions/MathLib/classes/Solver/Solver.sc
>>>
>>> Let us know how it goes...
>>> -- Fernando