Thanks for the response Miller,
I was trying to make my project smaller to see how small I can get with the
error. Doing this I erased [else/keyboard] and the problem stopped, I later
created it again and no problem. so I really dont know if that was the
cause or not but now this error message
Interesting - that's a bit of code nobody's touched for at least 15 years.
The next thing I'd do would be to try to run the project under a memory-
integrity-checking system (I use valgrind in linux to do this).
If you'd be willing to send me the project (or even better if you can reduce
the
>
>
> > I'd argue that more time has been spent writing emails on this issue
> than it would take for each person to take one external, make a fat build,
> and upload to deken.
>
I'll still take quite some time to get ready to compile for M1 by updating
my OS and XCode, and I don't have an apple
On 3/30/22 17:30, Dan Wilcox wrote:
How many externals are there, really?
there's a total of 146 externals that have macOS binaries (of any form).
of these, there are 10 externals that provide M1 binaries.
I'd argue that more time has been spent writing emails on this issue than it
would
On 30.03.2022 17:43, Dan Wilcox wrote:
I would add instructions on running the app under Rosetta for older
externals. I would *not* start providing separate builds.
Agreed.
Forcing Rosetta is also something extensively documented online and on
Apple's own website:
I would add instructions on running the app under Rosetta for older externals.
I would *not* start providing separate builds.
Forcing Rosetta is also something extensively documented online and on Apple's
own website:
https://support.apple.com/en-us/HT211861
Personally, I can't build fat macOS externals because I don't have a
(recent enough) Mac...
But generally you're right: it's not like we're talking about thousands
of packages. Deken currently lists 204 Darwin amd64 binaries, some of
which are actually multiple versions of the same library.
> On Mar 30, 2022, at 4:54 PM, Alexandre Torres Porres wrote:
>
> Guess what? A few minutes later I wrote this, I got this email message "I'm
> writing because I'm using a new computer with an M1 processor and I don't
> seem to be able to open your library anymore with Pd 0.52.2 "
>
> So,
This will not be solved by providing two separate binaries because people with
an ARM processor will download the ARM version nevertheless.
I would say compiling the libraries for ARM is the way to go ;-)
Best!
Edwin
On 30 Mar 2022, at 16:55, Alexandre Torres Porres wrote:
Em qua., 30 de
Hello List
I just downloaded and installed the latest Pd 0.52-2. But if I open a
project of mine and close it I get the message (messages come up when I
cles the patch)
"consistency check failed: drawline"
the patch opened and closed with no problem in previous versions of Pd, I
had no error
How many externals are there, really? For those that use pd-lib-builder, it's a
simple recompile.
I'd argue that more time has been spent writing emails on this issue than it
would take for each person to take one external, make a fat build, and upload
to deken.
We went through this already
I guess you've proven your point :-)
On 30.03.2022 16:54, Alexandre Torres Porres wrote:
Em qua., 30 de mar. de 2022 às 10:12, Alexandre Torres Porres
escreveu:
Not long ago, we had separate Vanilla binaries for i386 / x86_64
mac builds in Miller's site. There was a consideration
Em qua., 30 de mar. de 2022 às 10:12, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> Not long ago, we had separate Vanilla binaries for i386 / x86_64 mac
> builds in Miller's site. There was a consideration that the 'i386' was
> there to run 'old i386 externals'. I think something like
Em qua., 30 de mar. de 2022 às 06:17, Dan Wilcox
escreveu:
> I don't understand your reasoning why "separate binaries make more sense."
> I don't recall the previous Pd & Pd-extended ppc / i386 / x86_64 mac builds
> being a major issue.
>
Not long ago, we had separate Vanilla binaries for i386
Now *I* am utterly confused.
now people seem to all agree that it was much better way back then.
I think everybody agrees that there should be an ARM64 binary for macOS.
The question is just whether it should be the default on M1 machines
when there are so few ARM64 externals for macOS
I don't understand your reasoning why "separate binaries make more sense." I
don't recall the previous Pd & Pd-extended ppc / i386 / x86_64 mac builds being
a major issue. Same for externals which were also built "fat." Most mac apps
are built as "universal" to cover the various transitions:
On 3/29/22 16:10, Christof Ressi wrote:
If you have an apple silicon, it'll run under the hood the arm code
and then it will only find and load 'arm64' externals?
From my understanding, yes. For that reason, I guess it's not a good
idea to provide universal binaries at this point and we
17 matches
Mail list logo
