RayDonnelly

13 ms·

61.
by RayDonnelly 9y ago
I don't think thats true. Our compilers are complete pseudo-cross compilers (i.e. with binutils, glibc, kernel headers and their own sysroot) that can be both hosted on and always target CentOS6. This means software built with them wil
62.
by RayDonnelly 9y ago
As is (actually working, usable) clang 4.0.1 on macOS 10.9
63.
by RayDonnelly 9y ago
Conda is a package manager for more than Python. It manages libraries that are shared between Python and R and other tools. This isn't possible with a purely Python-based solution. It also does envs better than most other solutions sin
64.
by RayDonnelly 9y ago
This is a terrible way to do IK. It is numerically unstable and will give vastly different solutions upon slight changes to the input. Coordinated Cyclic Descent using twist and swing quaternions give much better results: http://
65.
by RayDonnelly 10y ago
Further, linking PhysX to GPL3 is not possible.
66.
by RayDonnelly 10y ago
Most games developers won't touch GPL3, why not LGPL? Also should games engines really have *Player.cpp/.h files?
67.
by RayDonnelly 10y ago
A better name might be hoop-jumper. If you want a POSIX shell and real interoperability with Windows, I can recommend MSYS2 instead.
68.
by RayDonnelly 10y ago
Windows threw up CRC errors. I am not blaming Windows here, that would be unfair. Perhaps it was the only one that checked CRCs on read and one of the others didn't write CRCs on write. My use case was to store many large git repo clon
69.
by RayDonnelly 10y ago
I tried UDF for a few months on a macOS/Linux/Windows triple boot. It doesn't work reliably enough. I've switched to ext2 using e2fsd and Paragon (which I paid for) on Windows and macOS respectively. Fingers crossed. I w
70.
by RayDonnelly 11y ago
.. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows fo
71.
by RayDonnelly 11y ago
It's too much, honestly, but I'm biased.
72.
by RayDonnelly 11y ago
Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far. FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some
73.
by RayDonnelly 11y ago
Great. MSYS2 please though.
74.
by RayDonnelly 11y ago
I hope you misunderstand slightly still. So msys2 executables - those linked to msys-2.0.dll can be run from Windows executables (or double clicked to launch from Windows Explorer, or pinned to the Start Menu or the Task Bar), for example,
75.
by RayDonnelly 11y ago
Babun brings nothing to the table. I hate what they did to the apt-cyg copyright notices. Bad behaviour.
76.
by RayDonnelly 11y ago
We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.
77.
by RayDonnelly 11y ago
The documentation (once you've read about pacman, and makepkg on the wiki or on Arch Linux's wiki) is in the PKGBUILD files. Building all packages should be done with the exact same command, so there's not really any differen
78.
by RayDonnelly 11y ago
Yeah, but you need to be clear that it wasn't our cmake build of course. Generally get used using, asking for and contributing to MSYS2 packages if you can. That way everyone benefits. It's not the norm on Windows, but it very muc
79.
by RayDonnelly 11y ago
Well, we package our own software so we can work around any quirks that our system introduces, but actually generic cmake should work fairly well out of the box. The difference will the down to path translation. We don't stick to the o
80.
by RayDonnelly 11y ago
> As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows The M in MSYS2
81.
by RayDonnelly 11y ago
It seems we have a libvirt PKGBUILD but no released package. Here is the MSYS2 approach to software development, shamelessly taken from ArchLinux. Could you try this: pacman -Ss base-devel mingw-w64-x86_64-toolchain git clone http
82.
by RayDonnelly 11y ago
Git-4-Windows is a great project, just with a different focus. They contribute a lot to our packages (and Cygwin) too since git (and the shell) drags in quite a lot of stuff.
83.
by RayDonnelly 11y ago
I have literally no idea why you would even consider combining MSYS2 with TDM-x64 and Fedora precompiled. Just use MSYS2. It is all that you need. Can you explain why you would do this?
84.
by RayDonnelly 11y ago
I work on MSYS2, not Git-4-Windows. We come with Pacman included.
85.
by RayDonnelly 11y ago
pacman -S mingw-w64-{x86_64,i686}-cmake There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package which is used for building the packages in the msys repo (i.e. those linked
86.
by RayDonnelly 11y ago
This has been answered before. No, the msys2 repo doesn't follow the Cygwin packaging versions or schedules at all. They are built from the recipes at: https://github.com/Alexpux/MSYS2-packages .. they link to msy
87.
by RayDonnelly 11y ago
We need to merge our work carefully. Git-4-Windows with pacman and makepkg wouldn't work too well at present, as MSYS2 with a native git wouldn't work too well at present.
88.
by RayDonnelly 11y ago
Please read the links on the linked to page. MSYS2 is a rolling software distribution providing software built with the mingw-w64 compilers. Some of the software is Cygwin-like, but not much, only enough to distribute (and build) the native
89.
by RayDonnelly 11y ago
There was a time (around Blender 2.70) when we did provide Blender packages and it did compile (of course, since all our software is built from source) but then llvm dropped JIT around version 3.5 and it became incompatible with OpenShadin
90.
by RayDonnelly 11y ago
midipix is a very interesting project.

More ›