tgamblin

12 ms·

61.
Libtree: why was that library loaded?(github.com)
2 points by tgamblin 5y ago|0 comments
62.
MinNPM: Lose all those dupes in your node_modules directory(youtube.com)
1 points by tgamblin 5y ago|0 comments
63.
Using Answer Set Programming for very general package solvers(youtube.com)
3 points by tgamblin 5y ago|0 comments
64.
DOE labs' default open source policy from 2004 [pdf](science.osti.gov)
2 points by tgamblin 5y ago|0 comments
65.
Gallery of physics problems on curved meshes in MFEM(mfem.org)
3 points by tgamblin 5y ago|0 comments
66.
Patents in Open Source: the important parts of real cases(google.github.io)
122 points by tgamblin 5y ago|43 comments
67.
by tgamblin 5y ago
Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to
68.
LLNL's Open Source Software(software.llnl.gov)
2 points by tgamblin 5y ago|0 comments
69.
by tgamblin 5y ago
Check out the tensorflow package in Spack. We patch Bazel slightly to allow external dependencies/library paths, and the dependencies are factored out into their own packages: https://spack.readthedocs.io/en/latest
70.
by tgamblin 5y ago
This is why Spack supports external packages. For any package, you can tell spack the prefix where it lives and build with that install prefix instead of a spack-built version: https://spack.readthedocs.io/en/latest&#x2
71.
by tgamblin 5y ago
And with dependency resolution (spack calls it “concretization”), which nix and guix do not have.
72.
by tgamblin 5y ago
See https://www.python.org/dev/peps/pep-0513/#key-causes-of-inte... . Software built with a newer glibc is not compatible with software built with an older glibc. You can't just build an EFL binary on an
73.
by tgamblin 5y ago
> I guess I just don’t see the use case where this is compelling. If I write a handy Unix utility in C, I’ll just keep the source code around, and compile it as needed. Isn't this exactly why you don't see the use case? You&#x
74.
Get the git log for a specific function(twitter.com)
6 points by tgamblin 6y ago|0 comments
75.
by tgamblin 6y ago
Yeah I guess I read that too quickly -- sorry. This: #!python3 Seems to work (i.e., search $PATH) on macos but AFAIK nowhere else. It fails on both ubuntu20 and centos8. Per this: https://www.in-ulm.de/~mascheck&#x2
76.
by tgamblin 6y ago
Yeah it would be nice if POSIX would move a little faster, but I guess the slowness is the point. This is probably obvious but bears repeating since we're on this tangent -- even -S and -P do not prevent the OS from truncating the she
77.
by tgamblin 6y ago
It's there because on some systems all the args are passed as one. -S splits them out. You can try this on Linux and env even warns you about it: # cat test.py #!/usr/bin/python3 import sys print(sys.
78.
by tgamblin 6y ago
I'm not sure how this solves the problem. The goal is to execute an interpreter in a long path via the shebang line , but this is a regular script that executes a program in a long path. You can't use this to make a file invoke
79.
by tgamblin 6y ago
True. The two disadvantages are: - you still get the python3 in PATH, not a specific one (sbang aims to use a specific interpreter) - The -S argument to env is not POSIX: https://pubs.opengroup.org/onlinepubs/9699919799
80.
by tgamblin 6y ago
In Spack https://github.com/spack/spack ), we encounter this when users install packages in deep paths within their home directories, or in deep paths within shared project directories (e.g., in NFS or Lustre on HPC mac
81.
Sbang lets you run scripts with long shebang lines(github.com)
30 points by tgamblin 6y ago|32 comments
82.
by tgamblin 6y ago
Some, but LLNL codes are mostly C++, especially now that they need to make effective use of GPUs. More on codes: - https://computing.llnl.gov/sierra-supercomputer-dedication Some repos of interest: - https://gith
83.
by tgamblin 6y ago
thanks!
84.
by tgamblin 6y ago
Yes but we still have many OP systems on the floor (see the link above).
85.
by tgamblin 6y ago
I work in Livermore Computing at LLNL. We manage upwards of 30 different compute clusters (many listed here: https://hpc.llnl.gov/hardware/platforms ). You can read about the machine slated to hit the floor in 2022&#x2
86.
Spack 0.14.0: parallel builds with locks or CI pipelines(github.com)
1 points by tgamblin 7y ago|0 comments
87.
by tgamblin 7y ago
On the NNSA side of DOE, the codes very intentionally do not depend on CUDA. They use RAJA ( https://github.com/llnl/raja ) or Kokkos ( https://github.com/kokkos/kokkos ) to ensure that they're
88.
by tgamblin 7y ago
At LLNL the story is similar, but the framework is RAJA: https://github.com/llnl/raja . RAJA is a bit simpler than Kokkos in that it does not require you to adopt its data structures. The Kokkos and RAJA teams are also
89.
by tgamblin 8y ago
Lawrence Livermore National Laboratory (LLNL) | Livermore, CA ONSITE | Spack Developer | ability to obtain a Q Clearance (US citizenship) required Want to work on open source for science? Come work on the Spack package manager ( https:&#x2
90.
by tgamblin 8y ago
How do you handle some of the more obscure cases? For example, citizens of some countries, including the US, can do a short, visa-free stay in China if they’re transiting through the major airports ( https://www.travelchinaguide.c

More ›