Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthew R. Becker
    @beckermr
    that should work
    if you are using any cdts, make sure they have cos7 in the name
    Matti Picus
    @mattip
    thanks, that worked. I am not sure conda install sysroot-cos7-x86_64 was the best way to do the update, but it worked
    Matthew R. Becker
    @beckermr
    awesome
    Sean M. Law
    @seanlaw
    Hello! I maintain the conda-forge STUMPY package and have a label from 2020. Is there a way to remove all labels from being displayed alongside main? https://anaconda.org/conda-forge/stumpy
    Matthew R. Becker
    @beckermr
    Thoee labels cannot br removed. Also please dieect this kind of wuestion to thr main conda firge room
    Matti Picus
    @mattip
    Over at conda-forge/triqs-feedstock#18, the admin would like to disable pypy until they are convinced it is properly supported upstream. How could they best do that?
    Matthew R. Becker
    @beckermr
    thanks for the request - let's move it to the main conda-forhe room
    Ray Donnelly
    @mingwandroid
    Has anyone had a look at zig cc? https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
    Itamar Turner-Trauring
    @itamarst
    hello
    I am comparing performance of conda-forge python and python from distros, and conda's is 20% faster
    which is pretty nice
    I assume it's due to using different compiler options (I know there's e.g. -mtune=haswell in there somewhere)
    but, I don't know where to find the differences in how things are compiled
    could anyone give me a pointer?
    thanks!
    Uwe L. Korn
    @xhochy
    @itamarst Have a look at https://github.com/conda-forge/python-feedstock/blob/master/recipe/build_base.sh and the rest of the repo
    Itamar Turner-Trauring
    @itamarst
    that doesn't specify things like -mtune=haswell though?
    Chris Burr
    @chrisburr
    That's just the conda-forge default from the compiler activation scripts, you can see them in the build logs (linked from the README) https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=269326&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Hello there. Sorry it's been a while, but I have now had the bandwidth to work on the DPC++ compiler conda packages and their respective activation recipes. I have them working and was able to successfully build our dpctl package with it, but I have a question I think you guys can help me with.

    With compiler packages, I assume in every case that users will want to add something like {{ compiler('dpcpp') }} in the build area of a meta.yaml, correct? If that is the case, does this mean that I would have to change dpctl to look at BUILD_PREFIX instead of PREFIX?

    I got it to work because I added {{ compiler('dpcpp') }} in the host area, and so the module was able to find the include files, and load the libraries (host -> PREFIX while build -> BUILD_PREFIX).

    Isuru Fernando
    @isuruf
    which include files and libraries?
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Everything shipped with the DPC++ compiler. In this case, moving it from host to build means that the SYCL header files are not found because I had set CPATH=$PREFIX/include
    Isuru Fernando
    @isuruf
    sycl header files should go in lib/clang/<ver>/include
    BTW, since DPC++ is open source and will conflict with clang, we'll be building it from source
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    @isuruf thank you! worked like a charm :D and thanks for the update. Good to know before we release anything :)
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    @isuruf just to make sure what I'm doing for the DPC++ compiler conda packages will not clash with other compiler packages, I want to run by you what I'm doing to create the impl packages. So the Intel DPC++ compiler has the following directories in the install root: compiler, bin, lib, include. All I have done is copy everything from bin and lib and put it in <PREFIX>/bin and <PREFIX>\Library\bin. I copied the content in include and put it in /lib/clang/<ver>/include as you had suggested, and I copied compiler to <PREFIX>/compiler. I did not want to copy the content of compiler/<lib/include> to <PREFIX>/<lib/include> since I assumed everything was in that compiler directory for a reason.
    Isuru Fernando
    @isuruf
    @AndresGuzman-Ballen, can you send a list of files in the conda package?
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Sure! I can do that :) probably makes it easier haha
    I just copy and paste the info/files file here?
    or via email
    Isuru Fernando
    @isuruf
    make a gist?
    https://gist.github.com/
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Good thinking ;) I imagine you can see this? https://gist.github.com/AndresGuzman-Ballen/9ce1fbafc431190d97bd35b6448decbc
    Isuru Fernando
    @isuruf
    yes, I can see it now
    there's a lot of overlap between that and the clang packages
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Ah, in the bin directory
    Andres Guzman-Ballen
    @AndresGuzman-Ballen
    Is the concern that a user will have two clang compilers in their meta.yaml and that you have an unstable build environment or in best case scenario, a bunch of clobber warnings?
    Matthew R. Becker
    @beckermr
    exactly
    Andres Guzman-Ballen
    @AndresGuzman-Ballen

    I see. One trivial solution to this is just slapping an 'intel' string to the names. I don't know to what extent we want to do this, but it is certainly a possibility if there's no other choice.

    Another trivial solution is to just install everything onto <PREFIX>/dpcpp, although this now means there isn't a guarantee that people will get a DPC++ compiler working out of the box since Python has been designed to always have all the libraries in <PREFIX>/lib or <PREFIX/bin> and although the activation scripts can certainly add a path like <PREFIX>/dpcpp/bin to PATH, there is that rare possibility a Python module will not be able to find a certain library simply because it was expected to be in the <PREFIX>/lib or <PREFIX>\Library\lib directory.

    The last solution that may exist is something that can be added to meta.yaml that prevents two packages from being in the same environment. Is this a possibility? Or is there a 4th solution I have not mentioned?

    Matthew R. Becker
    @beckermr
    @isuruf should suggest things
    I am not 100% what the downsides are of each of these options
    Isuru Fernando
    @isuruf
    1. This means we'll have to build all the other components of LLVM that intel is not doing. libcxx, compiler-rt, openmp, mlir, etc
    2) If the DPC++ compiler is used for compiling openmp code, then it'll need an openmp runtime from clang and we'll have two runtimes, which becomes messy
    Isuru Fernando
    @isuruf
    Best solution is to replay the intel patches on top of llvm 12.0.0
    Matthew R. Becker
    @beckermr
    more compilers coming in!
    https://github.com/conda-forge/conda-forge.github.io/issues/1390#issuecomment-821581452
    Wolf Vollprecht
    @wolfv
    @isuruf I openend an issue on conda-forge.github.io to track wasm: conda-forge/conda-forge.github.io#1401
    written down all I understand so far... feel free to let me know if something is wrong :)
    jakirkham
    @jakirkham

    Do we have thoughts on what 11 version of LLVM works well? The Numba dev team asked this previously

    https://github.com/numba/llvmlite/issues/639#issuecomment-818703892

    Edit: Relevant PR ( numba/llvmlite#715 )