These are chat archives for supercollider/supercollider

11th
May 2017
Patrick Dupuis
@patrickdupuis
May 11 2017 05:30
I'm trying to test the JPverb fixes again. i'm not sure how to have git pull the recent changes into my local branch of this PR.
Patrick Dupuis
@patrickdupuis
May 11 2017 05:37
I guess I can just create a new local branch git fetch origin pull/143/head:myBranch
Rainer Schütz
@bagong
May 11 2017 06:59
@patrickdupuis you mean how to update the PR you already checked out as a branch with new commits that were added? I think what you suggest works with the branch you already have. So instead of :myBranch, try :theBranchIalready have...
Just check with git log that you really got everything after that...
Rainer Schütz
@bagong
May 11 2017 10:00
Hmm, now I get:
fatal: Refusing to fetch into current branch refs/heads/jpverb of non-bare repository
I swear I did something similar in the past that would work...
In general I'd love to know how to checkout a PR as branch that tracks the PR, so that's I'd only have to do: git pull...
Ah, my mistake was: you cannot have that branch checked out while you are fetchin into it. After I checked out master, git fetch scorg pull/143/head:jpverb would bring the latest and greatest...
Rainer Schütz
@bagong
May 11 2017 10:05
scorg is what I call the sc3-plugins repo in my local repo, and jpverb is the name I gave to the branch containing the PR
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 10:23
i am taking as a project
to translate the whole supercollider documentation
to portuguese
does that sound like a good thing to do?
since it was added to long term projects
?
and is something i am currently capable to do at the current tense
?
:)
Rainer Schütz
@bagong
May 11 2017 10:28
Take your time, it's a biiiig and difficult job. The help system language is really verry specific code. I sometimes think it's unnecessary because only people understand it, who already know what it's describing. Kind of: if you're ready to understand SC documentation you can just read the class files instead ;)
Note also that there is no way in place atm that allows to switch languages in the help system...
There is in the menu system...
Actually somebody contacted me the other day proposing to translate the menus to Korean... That would be a nice challenge...
An interesting side effect: the sc core maintainers would not be able to understand/judge the translations ;)
Will be an interesting experiment into decentralized ownership ;)
@tiagmoraismorgado , that person proposing korean menus is currently working on a korean tutorial...
there is a Japanese one already
And SC might be able to handle internationality better in the closer future...
Maybe a tutorial is a good way to pave the way for the English documentation. And it's not as daunting a task...
LFSaw
@LFSaw
May 11 2017 14:30
hey there :)
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:45
i think the issue is actually providing a single package
featuring all the languages support
like sam aaron did with sonic pi
i think i will have the translation done maybe until end of summer
anyways one thing that i notice
is that you have to restrict what will be translated
otherwise you get to a point under which it's difficult to share code
Rainer Schütz
@bagong
May 11 2017 14:49
Honestly @tiagmoraismorgado , even if somebody translated the documentation to German, I would prefer to read the English one (If I read it at all).
I know Sonic Pi quite well... Sam has different priorities and more helpers...
Documentation in Sonic Pi and SC are completely different.
The SC documentation in it's origins are a definition of what the language should do.
Sam's documentation is help for a user to learn Sonic Pi...
That difference in approach is very difficult to bridge...
Tutorials and Guides try to help in that respect...
You never understood that side of the SC documentation, that's why you produced help files that weren't really welcome...
It's not about originality and creativity there, not even about good didactics, but a bout a clear definition of the language
mind you, the documentation has developed into a state over the years, where one might ask how true that still is...
And yet it is important to understand those two completely different types of "documentation"
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:54
well maybe you are right
but it would be fine to have supercollider translated into other languages
and since i pointed that out and someone included it in long term projects
i think i will grab the original docs
and just translate it to other languages
first portuguese of course
and i will try not mess around with code examples
maybe i will do my own version of the supercollider docs
that has been an ongoing project
like adding my own exemples and stuff
but that will be for a personal distribution
and will be more like a punk kind of thing
Rainer Schütz
@bagong
May 11 2017 14:56
sure. A lovely side of that gitteria as that everybody can make her own versions and try to bring it under the people...
*is not as
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:57
but indeed make overall translations to other languages
Rainer Schütz
@bagong
May 11 2017 14:57
Punk is cool, it just doesn't have a space yet in SC core
And it probably never will...
But SC is not only the core distribution...
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:58
i know you have scjs
Rainer Schütz
@bagong
May 11 2017 14:58
SC lives in 100 places, and that is one of the things that's cool about it
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:58
which is crucialfelix
Rainer Schütz
@bagong
May 11 2017 14:58
about free software in general
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 14:58
and you have bindings to other languages as well
like what svn sourceforge and that kind of stuff
?
i know pure data has diferente distributions
within supercollider i only know about language bindings
Rainer Schütz
@bagong
May 11 2017 14:59
Sorry @tiagmoraismorgado , I have to leave... Chat some other time, okay...
tiagomoraismorgado
@tiagomoraismorgado88
May 11 2017 15:00
there was also used to be like alternate versions but that was more in the past
ok
Patrick Dupuis
@patrickdupuis
May 11 2017 18:24
thanks for the git help @bagong
I'm seeing much better performance with JPverb now that I built SC and plugs with CMAKE_BUILD_TYPE=Release
What is the default build type for SC? I thought it was RelWithDebInfo, but maybe it's None?
this is my CMakeCache.txt, maybe it is of help to your quesion, @patrickdupuis :)
Brian Heim
@brianlheim
May 11 2017 18:59
default build type is Debug
there is no "None" build config
we have Debug/RelWithDebInfo/RelMinSize (not 100% on the name)/Release
Patrick Dupuis
@patrickdupuis
May 11 2017 19:17
Ok, so if you don't specify a build type (CMAKE_BUILD_TYPE:STRING= ), then it chooses Debug?
Rainer Schütz
@bagong
May 11 2017 19:17
Well, @brianlheim and @patrickdupuis , with Visual Studio/msvc/msbuild and with Xcode it is Debug, that's true, but with make on Linux it used to RelWithDebinfo...
I am not aware that anything changed. It's defined in the top-level CMakeLists.txt, have a look
Patrick Dupuis
@patrickdupuis
May 11 2017 19:18
What happens when you leave it blank, like in LFSaw's CMakeCache.txt example above?
Rainer Schütz
@bagong
May 11 2017 19:18
Ah, then it's undefined
I think...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:18
ok :)
Rainer Schütz
@bagong
May 11 2017 19:19
And in that case the definition in CMakeLists is overridden
I am not sure what happens then, but your experience would indicate that it build debug then...
Could you verify...
But it's certainly not good practice to leave CMAKE_BUILD_TYPE undefined... ;)
Probably this will happen:
Patrick Dupuis
@patrickdupuis
May 11 2017 19:20
certainly not if it has an performance impact
Rainer Schütz
@bagong
May 11 2017 19:20
it's about compile optimizations
there are generic compile optimizations which are done independently of build configuration
those would probably even be made if build type was undefined...
But I think there are none ;)
the optimizations like O2 O3 and the like are done depending on how build type is defined...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:22
ok, so there are two things...
Rainer Schütz
@bagong
May 11 2017 19:22
so if it is not defined none of the optimizations will occur
but that doesn't mean that you have a debug build
which requires ndebug, if I remember correctly
it just means that you get a non-optimized non-debug build
Patrick Dupuis
@patrickdupuis
May 11 2017 19:23
oddly, i'm seeing worse performance in the case of jpverb when SC is built with NATIVE=ON
Rainer Schütz
@bagong
May 11 2017 19:23
That's what I would expect, but I might be wrong
What happens with NATIVE is pretty misterious...
We haven't been checking NATIVE anymore for years...
It might have changed what happened...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:24
the default is OFF
I
Rainer Schütz
@bagong
May 11 2017 19:24
In that JPverb/deind thread we haven't discussed how FAUST compiler flags interact with sc3-plugins ones
I am actually interested to understand if they do...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:25
i'll try and rebuild everything with the default configs and see if SC with NATIVE is the real problem
Rainer Schütz
@bagong
May 11 2017 19:25
In theory faust compiler flags could influence the code generated. I just wonder if that happens...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:25
go for it!
:)
Rainer Schütz
@bagong
May 11 2017 19:25
I am not saying I am going for anything...
Just interested :D
Longing to know :D
Patrick Dupuis
@patrickdupuis
May 11 2017 19:25
Check it out! :thumbsup:
Rainer Schütz
@bagong
May 11 2017 19:25
As to native: it's off by default because NATIVE=ON builds are not portable to other processor types
The default is generic, so a build can be used on many machines...
But in fact in theory this NATIVE option is one of the reasons why it could be advantagous to build yourself...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:26
I always assumed it would give slightly better performance, but i guess not always
Rainer Schütz
@bagong
May 11 2017 19:27
Only it's not maintained, and current maintainers don't really understand what it does...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:27
so devs should stick with the defaults
Rainer Schütz
@bagong
May 11 2017 19:27
Yes, I think what native does is defined by gcc
but it interferes with setting done in the build system...
as a dev you should definitely do a generic build if you build for others
because you don't know what kind of machine they have...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:29
i meant, as a tester of things, should i stick with the defaults? :)
Rainer Schütz
@bagong
May 11 2017 19:29
If you build for yourself with dev-intent it might be useful to build native too to inspect if something bad happens :D
I think there is no straightforward answer
Patrick Dupuis
@patrickdupuis
May 11 2017 19:29
like in this case
Rainer Schütz
@bagong
May 11 2017 19:29
but different tests should be comparable...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:29
ok
Rainer Schütz
@bagong
May 11 2017 19:30
So if we benchmark both should either use generic settings or native... Or actually...
Native always makes the comparison problemati...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:30
and my tests are definitely not the same in this case
Rainer Schütz
@bagong
May 11 2017 19:30
because the optimizations are likely different on different systems...
Yep...
So if we compare processor use we should make a log explicit, among others build configuration and special optimizations like NATIVE...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:31
Do you specify a build type for your dev/testing?
Brian Heim
@brianlheim
May 11 2017 19:32
the default optimization level for clang and gcc is -O3
Rainer Schütz
@bagong
May 11 2017 19:32
I always use Release mode without native if there is no special reason to do something...
Patrick Dupuis
@patrickdupuis
May 11 2017 19:33
so no RelWithDebInfo by default for dev work?
or Debug?
Rainer Schütz
@bagong
May 11 2017 19:33
in Release mode, right Brian... But what -O3 means in detail is another story...
Brian Heim
@brianlheim
May 11 2017 19:33
it means all optimizations are turned on
Rainer Schütz
@bagong
May 11 2017 19:33
Debug if you debug, not if you compare performance
Brian Heim
@brianlheim
May 11 2017 19:34
and fwiw when i build on mac i see the flag -march=native being passed to clang
Patrick Dupuis
@patrickdupuis
May 11 2017 19:34
@LFSaw I am happy to say that JPverb is now only consuming ~10% of the server with your changes
Rainer Schütz
@bagong
May 11 2017 19:34
Well, there are something like two or three dozens and I believe they also depend on processor type etc...
So I think it's hard to make very sharply clear what you compare...
But the O's are nice as a general "leveling" sort of
The influence is generally not that big...
As to that DebWithRelInfluence
It uses the same optimization level as Release, @patrickdupuis , so in theory it should be as fast as Release mode
That is the general understanding in this community
I think you problem was that you totally disabled optimizations by undefining build type...
But as we said, that doesn't mean you build a debug version
@patrickdupuis , if you have 10% our results are the same now...
Brian Heim
@brianlheim
May 11 2017 19:38
well considering we're all probably building for x86, it's not as unpredictable as you make it sound
Patrick Dupuis
@patrickdupuis
May 11 2017 19:39
So we still aren't quite sure what happens when the build type is undefined?
Brian Heim
@brianlheim
May 11 2017 19:40
otoh you have a point, some of them might change based on what number of vector extensions your processor has
just looked at the cmake file again
@bagong you were right, the default is RelWithDebInfo if you're not using Xcode or VS
but if you use either of those it's out of cmake's control and the default will be Debug
unless you specify with --config during the build step
Patrick Dupuis
@patrickdupuis
May 11 2017 19:45
so for linux, it's still default RelWithDebInfo
Rainer Schütz
@bagong
May 11 2017 19:45
yes
Brian Heim
@brianlheim
May 11 2017 19:45
yep, basically for any non-IDE environment
i wonder actually what CLion would do
Rainer Schütz
@bagong
May 11 2017 19:46
@brianlheim , the better way of saying it is: is the build system multi-configuration or not
although I think the default RelWithDebInfo is only in SC because it's explicitly set in the build system...
to be overridden on the command line if so wished...
So even make would build Debug by default if it weren't set othewise in our build system...
That decision was made a few years back because people were build without realizing that they were creating a debug build...
and had performance problems
so that "compromise" was made specificly for Linux
in multi-configuration build system CMAKE_BUILD_TYPE is ignored...
the build configuration is not defined with CMAKE_BUILD_TYPE... the respective generators create files for both release and debug mode, and you can build both without having to reconfigure the build
that's why you specify the configuration in the build step
the output folders distinguish release and debug binaries...
that's not the case by default in single configuration build systems...
Rainer Schütz
@bagong
May 11 2017 19:51
in the SC build system for Windows the distinction into build folders distinguishing build configuration is emulated
Brian Heim
@brianlheim
May 11 2017 19:51
learning all kinds of things today
Rainer Schütz
@bagong
May 11 2017 19:51
in order to make the build folder structure the same for msys and VS builds
Brian Heim
@brianlheim
May 11 2017 19:55
ohh clion passes Debug by default
@bagong have you ever looked into clion? i think they're quickly trying to make it easier to install on linux
and, it's got a vim bindings plugin
Rainer Schütz
@bagong
May 11 2017 20:02
no, never heard of it. Will have a look when I have time ;) Thanks for the hint...
Another trend is using Ninja as build system. It's a lot faster than make.
But the SC scripts need some corrections for that, I am not sure what. But we get errors...
ccache is a big time saver on linux, btw...
Brian Heim
@brianlheim
May 11 2017 20:17
it's made by Jetbrains, their IDEs are generally amazing. they have an extension for VS too called resharper++
i'm not sure of your situation but you can get an education version for free
otherwise it is a little expensive
Rainer Schütz
@bagong
May 11 2017 20:18
Ah, I'll have a look...
Although I kind of like the idea of working with free stuff...
But yea, I've heard that that Jetbrains stuff is supposed to be extra-good
Brian Heim
@brianlheim
May 11 2017 20:19
i started with their java IDE, which does actually have a community version
Rainer Schütz
@bagong
May 11 2017 20:21
Create a SC plugin for Jetbrains ;)
Brian Heim
@brianlheim
May 11 2017 20:22
haha
it's really the incredibly simple things that better IDEs have save me the most time, especially as projects scale upward.. good static analysis, refactor-rename, jump to definition, automated simple fixes. I have some of that in vim, but not quite all of it. i think atom or sublime may offer that too, but i haven't had good experiences with either, surprisingly on the level of text editing functions. probably just edge cases on my part
Rainer Schütz
@bagong
May 11 2017 21:43
Yea... For everybody what makes her happy ;)
So should I commit that PR quickly? cmake-build-debug sounds like there might also be cmake-build-release etc... Maybe a cmake-build-* would make sense?
Brian Heim
@brianlheim
May 11 2017 21:59
ah that's an idea. I haven't seen that in anyone else's gitignore files, but i just checked and switching the configure via the GUI does change the output folder. you can set it manually anyway, but it's nice to make the common case easy
@bagong Thanks for the tip! Just updated the PR. I would like it to be merged quickly, it's fairly innocuous and makes it unproblematic to develop with CLion.
Rainer Schütz
@bagong
May 11 2017 22:04
okay...
I'll wait for that build to complete, although it's worthless... ;)
I thought it was a file... In other cases folders use a prepended /, but I guess that's not really needed...
Rainer Schütz
@bagong
May 11 2017 23:40
@brianlheim , try echo | clang -E - -march=native -### on OSX. I wonder if march native means the same in an clang/LLVM context as with gcc... I think handling of native (default off) is restricted to GCC in our build definition (that includes mingw but excludes msvc). If it's set by default on OSX that might actually be a mistake for our travis builds. Although nobody has reported misterious problem of the type you'd expect with native on incompatible processor types. Maybe Xcode has a smart way of handling native if CMAKE_OSX_DEPLOYMENT_TARGET is set to 10.7 although the build machine is 10.10? After all the OSX hardware variation is fairly small...