What does 'bottle :unneeded' do? - homebrew

I read Method: Formula.bottle but it's not very clear to me. When writing a home-brew formula, what does the following do?
bottle :unneeded

When a formula you submitted is accepted in one of the official taps, a bot grabs it; builds a pre-compiled version of the formula, and uploads it in some public location. This pre-compiled package is called a bottle and is used to speed-up installation of compiled things.
bottle :unneeded is an indication to the bot that this formula doesn’t need a bottle; e.g. because there’s nothing to compile.
Note that bottle :unneeded was deprecated by homebrew-core in June 2021, and no longer has any meaning to the bottler.

Related

How to fix the codes with the newest pydrake bindings?

I found a useful demo in github(https://github.com/maggiewu19/compass-gait-simulator). However, the codes didn't work with the newest pydrake. I ran the codes in google colab  and got errors.
Any reply will be appreciated.
I see. This is quite old -- it is using RigidBodyPlant which has been replaced by MultibodyPlant.
Drake has supported quite a long deprecation period on this. You can make most of it work by pulling the old RigidBodyPlant classes from attic, e.g. by changing this
from pydrake.all import (Box,
DiagramBuilder,
FindResourceOrThrow,
Isometry3,
SignalLogger,
Simulator)
from pydrake.attic.all import (FloatingBaseType, RigidBodyTree, RigidBodyPlant, VisualElement)
Unfortunately, I didn't leave as long of a deprecation period on PlanarRigidBodyVisualizer in the underactuated repo. You will have to pull an old version of underactuated to make that work.
FTR -- we are currently working on a way to make the colab setup's durable, by having a peg revision of drake (and underactuated) in the setup script. For now, you could download the old version of the underactuated repo, or just that specific file that was removed after it's deprecation period.
I can't guarantee you won't hit more errors after that. It would be much better to use the updated compass gait examples from class which are all using MultibodyPlant.

Dart pub.dev showing 'No Valid SDK'

I've just published an update to Dart a package that I'm working on.
https://pub.dev/packages/dshell
The latest updated doesn't seem to have any significant changes to the pubspec however pub.dev is reporting an error:
https://pub.dev/packages/dshell#flags
No valid SDK. (-20 points)
I've google this error and the associated description:
The analysis could not detect a valid SDK that can use this package.
I can't find any useful references to either message and I'm at a loss as to what might now be causing the problem.
The problem does appear to coincide with pub.dev moving to Dart 2.7 so maybe this is a bug in pana?
Any ideas on even where to look?
It looks like this is a known issue. Unfortunately, I think the only thing you can do at this point is wait until it gets fixed.

Using Eigen with EIGEN_USE_BLAS in iOS project

Out of educational purposes I'm trying to use Eigen in my pet project. In order to speed the math I included macro EIGEN_USE_BLAS which activates use of blas library.
But I encountered an issue when I tried to upload my project to Testflight. The Apple response to that was:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: _saxpy_, _sgemm_, _sgemv_, _strmm_,
_strmv_. If method names in your source code match the private Apple
APIs listed above, altering your method names will help prevent this
app from being flagged in future submissions. In addition, note that
one or more of the above APIs may be located in a static library that
was included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I know that Apple has blas library as a part of Accelerate.framework and it should be use strictly through Accelerate API. But the thing is that Eigen also has their own blas included in their source and the library actually has no intention of using Accelerate.framework private guts. So that is why Apple asks me to rename those functions or remove them completely in order to get rid of that inconvenience.
But I'm not even sure that it is possible to do - to tune Eigen and its blas to use alternative names.
Is there maybe a way to solve that issue in some efficient manner? Or maybe I don't know something about Eigen usage in iOS environment?
I was lucky to figure out the problem with few tips from my fellow colleagues and a strong will to get the job done, and now I want to share with you my conclusions.
The problem: Eigen doesn't have BLAS binary provided, it only has it's headers. And when one uses EIGEN_USE_BLAS macro and it actually works, that means that Apple is linking Eigen BLAS functions to their binary - BLAS binary which is a part of Accelerate.framework. The trickiest part is that your project doesn't necessarily should have Accelerate.framework inside. XCode will add necessary files automatically and of course it won't bother to tell you that.
What's weird for me the most here is that using "naked" BLAS provided by Apple's Accelerate.framework is a clear violation because it's private API. So... from my perspective it's kind of XCode violates this rule without my intention and tells me nothing about it. Strange...
So, in order to fix it, you need to build BLAS or OpenBLAS binary (I have built OpenBLAS), add it to the project and link through Other linker flags in Build settings. After that the error is gone and you're able to upload your build to Testflight.
In order to save you some time in building OpenBLAS for iOS, I will leave you few links. I think those would be enough:
http://www.programmersought.com/article/2638161057/ - very clear tutorial on how to build OpenBLAS
https://github.com/xianyi/OpenBLAS/tree/release-0.2.21 - source code of the library
https://github.com/xianyi/OpenBLAS/issues/1531 - discussion where you can find solutions to problems you might encounter
What I found the most confusing part of this whole story is the message from Apple. Here's another copy of that:
ITMS-90338: Non-public API usage - The app references non-public
symbols in My-Project: saxpy, sgemm, sgemv, strmm, strmv. If
method names in your source code match the private Apple APIs listed
above, altering your method names will help prevent this app from
being flagged in future submissions. In addition, note that one or
more of the above APIs may be located in a static library that was
included with your app. If so, they must be removed. For further
information, visit the Technical Support Information at
http://developer.apple.com/support/technical/
I'm not a native English speaker but I feel pretty confident to say that this text is a non-sense and has absolutely nothing to do with the solving of the actual problem.
It says absolutely nothing about the fact that private API was linked to my code and that is the problem. And that I need to provide my own backend for those functions in order to make error disappear. It says about names matching and that altering my names will help to solve the problem, when it clearly will not in my case.
I hope Apple will bring more clarity into this problem and that errors descriptions will have more sense in the future.

adding libz.1.2.3.dylib vs libz.1.1.3.dylib or libz.1.2.5.dylib

I am following this tutorial
The tutorial states to add libz.1.2.3.dylib. library, but because I have downloaded newer or older library (I don't know exactly if my library is newer or older that the library in the tutorial, but 99% it is newer). So, when I tried to add the libz.1.2.3.dylib. library, I didn't find it. However, when I typed libz I found these choices:
which one should I choose please?
In using dynamic libraries the one you normally use is libX.major_version.dylib in this case libz.1.2.dylib. This is a link to a library libX.major_version.minor_version.dylib which here is libz.1.2.5.dylib
The rationale for this is that the major version is changed only when the API is changed, the minor version is updated when any change is made. Thus your program should work when it uses any of the same major version and so you want the latest version.
In this case the tutorial had an older install and so its libz.1.2.dylib. should have pointed to libz.1.2.3.dylib.
For you you should use libz.1.2.5.dylib which should be like the tutorials version but with bug fixes and possibly extra functions that don't matter here as the tutorial won't call the new functions.
Normally libX.1.x.dylib would be older than libX.2.y.dylib but the writers might produce bug fixes to the old API whilst also working on the new API
Following on from the rational I gave libz.dylib should be a link to the highest number library but I would not use it as you are writing to a particular API so I would use a version specific (In this case if missing a link the I would not trust what libz.dylib points to)

RestKit 0.20.* tutorials that are actually up to date

Has anyone found tutorials for RestKits that are actually up to date? Not prerelease but something 0.20.* +. I was following along RestKits own tutorial that is suppose to be current and xcode is giving me a deprecated warning on one of their methods.
https://github.com/RestKit/RKGist/blob/master/TUTORIAL.md
Think I'm ready to jump oof the RestKit ship as if they aren't keeping their docs up to date that is a big warning sign for me. Also tried to build their latest examples from github and got a build error right away. Looks like a great project but someone who knows that library well needs to update the wiki and docs.

Resources