Is it time for an official fork?

This project has been very successful. It has garnered a lot of interest and helped me and many others. However, it is falling behind.  I don't bother to create pull requests because it is unlikely they will get merged.
This project was the boilerplate for an application of mine in production. It is not a big deal for me if this project dies. I'll update my application and move on. But we still get a lot new interest. Without too much work we could keep things current.
@erikras do you anticipate further work on this? If not, there are at least several people with write access but they haven't been very active recently. Should a few more be added? I'd be happy to help.
If we don't get any response, is there any interest in an official fork with at least several active committers?
Edit: Thanks @erikras I appreciate your work!

I'm in the same boat; This boilerplate was vital in helping me get my app going but in the past month or so I've been checking in less and less as it gets further behind and I've been keeping things up to date on my own (and not merging back because the pull requests already exist). I'm not sure I can commit development resources towards an updated fork, but I'd be more than willing to help answer question tickets as they come in.

I'm anxious enough to get my pull request in that I'm also willing to help review/etc...I'm anticipating starting a fresh project from this, and I'd rather update all the packages here, rather than locally.

I'm about to start a really large project using this as my boilerplate, but I'm hesitating because some of the version numbers are pretty old. I'm pretty interested in starting from a clean slate.

@jaraquistain & @roof12
Im exactly in that same situation. Our project was based off this repo. We would have huge amounts to contribute back as lessons learnt from deploying to production.

Refactored server render
Refactored auth approach (JWT)
Refactored redux async action creators (sagas)
Containerized docker architecture
New testing stack (enzyme + ava)
Functional approach (more readable & testable)
Reduced dependancies
Updated dependancies (node 5.x.x, react 15.x.x, webpack 2.x.x etc...)

I have merge / write access to this repo BTW

Appreciate all of you willing to help contribute to update the library.
I feel like I can also contribute the lessons I have learnt from creating a fairly extensive app, starting off from this boilerplate and in general, contribute back in any way I can.
@andersryanc I'd love to see some of those points that you've mentioned in the lessons learnt especially auth, refactored server render, docker, etc.
Also, to your point of closing the issues to just developers, I don't think we'll need to go that far if we can (starting now) point them towards SO and Gitter/Discord at the beginning of the README fairly clearly Currently, the FAQ sort of encourages folks to create issues for any questions. I like the approach that some other libraries take wherein you can have a clear instruction on the README and then close any issue that might come up (which doesn't happen that often). Closing 'issues' to vetted developers makes it harder for new enthusiasts, like I once was, to feel included.
And finally for, How-To's, I envision linking to or maintaining community contributed recipes could help to deal with specific sort of use-cases without overloading the boilerplate itself (react-virtualized is a good example).

Sure, there is allot. The server refactor is the simplest and as I was just in that headspace here is a gist taken straight from what we have:
https://gist.github.com/andrewmclagan/c4e84b0dd76e721cf75db1c06439a19b

@andrewmclagan Thanks for that gist, My next app steps are to really clean up both the dev-flow logic and server-side stuff so it'll be a useful reference for me.
If you find some spare time the points I'd be interested in some elaboration on are:

"Functional approach (more readable & testable)" Just like a general summary of what points were improved with functional approaches
"Reduced dependancies (76 rather then 98)" Which ones did you drop?

Sure, more then happy to elaborate. Will jot it here when i have time.

I'm still hoping to hear from @erikras. I emailed him directly in case he has notifications turned off for this project.
If does not respond or is not interested in maintaining the project, I suggest that we proceed conservatively. There are a lot of good ideas for changing things, but the first goal ought to be updating module versions and replacing obsolete modules. After that, well, everyone has ideas but the direction is determined by the people willing to do the work.

Hi guys. I'm afraid I don't really have time to help maintain this repo. My OSS resources are already swamped with redux-form, which is a library that hundreds of people are actually using in production (currently at 124k downloads/month), so this boilerplate learner repo has fallen to the side.
I said as much when I anointed @andrewmclagan as a Contributor. In my opinion, the goal for this repo, going forward, should be as a solid, but minimal, collection of the best bleeding edge technologies, but not a whole kitchen sink smorgasbord of every silly little npm package that someone writes. A good example of "every silly little npm package someone writes" is multireducer, which I mostly wrote as an exercise in understanding Redux and does not belong in this repo.
This repo benefited from being one of the first to catch the Redux / Hot Reloading wave, but now there are myriad others out there. It was always meant to be a technology learning platform, and was never a versioned library to be required() into a project. I have personally cloned this repo several times to build web apps, so it is still useful for that, but yes, it needs to be modernized with its dependencies, which means fixing breaking changes of, say, react-router, as they appear.
From his comments on this issue, I'm confident that @andrewmclagan is the right person to move this repo forward...assuming he has the time. If someone would like to volunteer to help him, I think that maintaining this repo, rather than "an official fork", would be a better option.

There's at least one 'enthusiast' who forked this for a startup & has enjoyed its stack the last 3 months. So, I'm invested in fostering this repo's continued maintenance and open source fertility.
I'll start being more active with the issues and/or discord/stackoverflow.
Saying that, the discord channel invite page says it's expired: https://discordapp.com/invite/0ZcbPKXt5bZZb1Ko
Channel missing from my reactiflux dashboard also.

@erikras I would have answered that question for you had you not already done so haha:

I'm afraid I don't really have time to help maintain this repo. My OSS resources are already swamped with redux-form

You are doing so much good work there my friend! Keep it up.
I agree with you, I feel any focus that I put here, into a boiler plate is somewhat futile. In a sense its a great learning resource and will further the community. Although I cant stress enough that people should go off and learn react step by step. Do not jump into a boiler plate without knowing what the dependancies, methodologies and patterns are. You are just creating a nightmare for yourself.

@andrewmclagan how can we help?

I don't understand how to reconcile "technology learning platform" (@erikras) with @andrewmclagan's interest in discouraging beginners. But, we'll see how it unfolds. I mostly want to see the dependencies caught up.
I'm available to help with code. I'm also willing to answer questions and close tickets.

I'd be glad to help too, I've been using this boilerplate for several projects and have updated its dependencies for them

I don't understand how to reconcile "technology learning platform" (@erikras) with @andrewmclagan's interest in discouraging beginners.

Different people learn differently. This repo is not a good place to start for a total React n00b, but if you've got a general grip on what React is, what Redux is, and a vague understanding of what Webpack does, but are wondering, "Okay, but what does a fully built website look like?", then this is the perfect repo to answer that question.
I, personally, discover a lot of new tech by reading through other people's source code and thinking, "What is this library being imported here?", and then investigating to understand what it does and how the pieces fit together.
When I first published it, there were very few repos that truly combined the best of the tech on offer. What I think this repo should be is a simple, fully functioning webapp, demonstration of the current best tech.

@andrewmclagan It sounds like you've done a lot of refactoring already for your own projects.  Even if you don't immediately have the time to merge your changes back into this repo yourself it might be something others could work on if you set up another repo with the changes you've made.  It would help a lot just to see how you cleaned things up and removed unnecessary dependencies.

^ seconded. The thing that I generally find most useful is just pouring over someone else's implementations and using that to inform my own development choices

Yeah, I apologias if people have taken my comments the wrong way. The most important thing is to foster the react community, if we truly want this stack to be long lived. As @erikras mentioned, everybody learns differently. Certainly you need a level of ability in react, webpack and node in general to decipher or gain any insights from a repo such as this. A basic understanding, certainly not expert level.
Still, I strongly believe novice devs are making their life tough by building projects on a codebase they don't understand. One strength of the react community is the vast amount of learning resources around React, Redux, Webpack, ES6+.... What is a novice dev? If your unable to trace how something was implemented in this repo through the stack, then you are probably missing some core concepts.
I will start with a few small PR's over the next week or so, leave them up for review as I have merge access I wont assume they are best practice. For sure Im not going to say what we have come up with is the best way forward, although know that our stack is currently being used in production distributed across 4 machines in a docker container architecture. Handling in excess of 70,000 unique visits a day.

@erikras @andrewmclagan Thanks for this project.  As an (intermediate) noob who stepped into this project, I now understand your thoughts about using this project as a base for a full system, not as a learning tool.
One (quick) concrete thing you could do is to review the README.md to help set people's expectations about the project. I've summarized (correctly, I hope) these points from the discussion above:
About the project:

The project is a suitable as a base for production systems. Many (dozens? hundreds?) developers have used it to build production systems that survive real Internet traffic.
Toward that end, the pace of adding new functionality has slowed from its initial commit a year ago. Its focus is stable technologies that are reliable.
We intend that this be a relatively minimal system. We will add important new packages that add significant benefits, but don't plan to track every little new repo that comes along.
We will continue updating dependencies, so that cloning the project will give current, stable packages

Who should use this?

Designed for experienced developers
It will be a lot of work to understand the stack if you're new to React, Redux, universal apps. There are better avenues for learning these technologies.
Please only file an Issue if you think you have found an actual bug.
Questions ("How does this work?", "Where can I get help with ...?") etc should be asked on StackOverflow or gitter

Thanks again for all the work you've put into it.

Spot on, perhaps write up a PR. Very well worded.

One area we do need to document is the async side effect architecture. It's basically a modified thunk middleware model. It's not noted anywhere as I'm aware

On that note we should discuss this moving forward. Promises are great, although as applications scale redux-saga like patterns really make a difference. At the cost of understanding generator functions

To continue has anyone taken a look at react-boilerplate? It's by far the most concise foundation I have come accross. We could learn some lessons from them. Especially in testing and docs.

Thanks for the compliments @andrewmclagan, ping me if you need pointers for specific things.
I personally really love redux-saga and think it's going to be the future, but the generator functions tend to scare off people. Imo they'll have to learn them anyway sooner or later, so that's a tradeoff that's worth having.

@andrewmclagan Thanks for the kind words about my summary. I must apologize that I won't have time to create a PR for edits to the README.md but please do carry on.

I could also help answering questions and closing issues. I started using this boilerplate 6 months ago for a project that's now in production, would like to see this updated and advanced further

@andrewmclagan what about all the work that @bdefore have done on this project?

@andrewmclagan I will say that for seasoned developers who have learned countless frameworks in a myriad of languages, boilerplates are often the best way to glean the "best practices" as learning from the bottom up can be frustrating when we are used to being able to see the bigger picture. Given a well-made boiler plate I can generally see what's going on and begin to dissect why rather quickly, and I find it a more enjoyable way to learn than reading docs and creating Hello Worlds at this stage. Just one perspective /shrug

I believe that Github should have a new "issues" section which is specifically for "HOW" questions, haha.
I strongly think that there should be two "issues" sections, one for the developing / improving issues ( the present one ), and the other one for "HOW" questions, we can call it "questions".
Asking in another website for a specific project is too inefficient.

Here's my summary of the conversation so far:
@erikras: This project is intended to be a minimal learning platform. I don't have time to work on it. @andrewmclagan supports this vision and is in charge.
@andrewmclagan: I agree. It is not meant for beginners. I'd like to add much more, like JWT and Docker. I'll try to make some commits, but any work I do is probably wasted.
Multiple people: Great, how can we help?
[No response]
I feel bad for new people starting with this project and those submitting pull requests. I feel they would be better served if we pointed them to an actively maintained project.
If there was interest in continuing the original vision of @erikras, I could contribute meaningful work but not lead it. That path seems unlikely. Another option would be to admit that we are not a good starting point for new projects and pivot to a shared application core for those who already have applications in production. I would be in favor of that, but it would be challenging due to how much we have all diverged from master.
None of this is meant as a complaint. I have no expectations, only appreciation for all who have contributed. I just don't like the uncertainty of the status of the project.

checkout this project https://github.com/choonkending/react-webpack-node
looks very clean and up to date.

@roof12 It appears this project has been abandoned as the issues and PRs keep piling up... not that it is a bad thing as @erikras is doing some great work on redux-form! It seems @andrewmclagan has perhaps abandoned this project as well since he was not in favor due to the number of newbies asking questions and I am sure if real busy too, so I am not sure he would want to be the lead on this repo. It is too bad as this project had some really great features in its time but has simply fallen behind and out of date. I would also like to say I appreciate everyone who has contributed to this project, thank you.

Then wouldn't this be a great time to fork? It seems that question was taken off the table, but is the cause for the whole discussion. I see that @bertho-zero made a PR with package updates and a few others have mentioned that they have kept their projects up to date. I could imagine many would like to see this project continue, as would I.

@andrewmclagan: I will start with a few small PR's over the next week or so, leave them up for review as I have merge access I wont assume they are best practice.

Before we adopt the fork, maybe@andrewmclagan can chime in? @andrewmclagan, are you still planning to start updating this repo as per your above comment?

Hey @andrewmclagan can you share your work on migrating to redux-saga?

so, nobody's up to the task?

checkout racket it's really nice refactor of react-redux-universal-hot-example with saga and yo built in

you could check react-universal-saga, it's based on this repo for a real project that I did for my company. It has all the updated dependencies and redux-saga of course.
There are still some TODOs that I plan to implement as well that represent a more 'real-world' codebase, but at its state right now, it should be good enough to kick-off any production-ready project. The good thing about react-universal-saga is that, you have the flexibility and control over the codebase in however ways you want to modify it to meet your requirement.

Find this, https://github.com/bertho-zero/react-redux-universal-hot-example
Seems @bertho-zero would keep to lead this.

@SunHuawei Not sure about that. That fork is much more opinionated than the original project, and not in a good way (imo). Databasing should be left up to the end user.

@isaachinman, yes, agree. So, I am going to fork this and fix the out of date dependencies by myself. After that, maybe I can improve it continuously regarding the original idea - keep focus on front-end.

@SunHuawei That would be awesome. It is sad that this boilerplate has been abandoned. Please let me know when you fork it, perhaps with time available, I could help out in some way.

Since this boilerplate has been abandoned - is there alternatives anyone can suggest? This repo was beyond just getting started up and running fast but was a great place for people to share the latest trends, libraries, etc. and see it in action!

If people are interested, I can clean up my fork a bit and share it. I believe the only breaking change if you use ncu and bring all dependencies to their most current versions has to do with syncHistoryWithStore.
What I liked the most about this boilerplate was the carefully thought out architecture, but also that it remained pretty unopinionated outside of that.

@mmahalwy, cannot agree more. Since that, it is absolutely necessary to keep the libraries right at the bleeding edge. I am willing to take this. As I said above, I will fix the out of date dependencies issue first. After that I will let you guys know. And @tzarger , sure, believe you guys would be helpful.

@isaachinman @SunHuawei  Btw, @bertho-zero's repo also has a basic-api branch which is without the new opinionated stuff. Do take a look at that, and the updates there.

@oyeanuj , yes, there is a basic-api. I checked it just seconds ago, but it just has one change(https://github.com/bertho-zero/react-redux-universal-hot-example/commit/fc3b3ff3f692a99146b8eb0925cc1d073aeb241e) actually.  Seems he reverted all changes merged from master before that commit.

You can also see all the changes between the original repo and my basic-api branch here: .../compare/master...bertho-zero:basic-api
and you can retrieve a .diff or .patch by adding the extension to the url above:

.diff
.patch

Feathersjs, for short, this is an extension of use for express services, hooks, events ... and a client to connect easily. Each parts of feathers is optional, that is why it is so light.
If you do not know feathers, I can only advise you to throw them a look.
Its purpose and application that I'm going in the direction of universal API, connectable to any database system with the management of real-time (or not), and all the aspects feathers brings. It is very intuitive, easy to understand and the documentation is pretty cool.
For those wishing to start a project from scratch with an api in node so it will be very fast to create a restful API connected to their favorite database and the client, with a very flexible authentication system (which manages eg roles), all this in the form of reusable services easily called in front.
All previous functionality are also still there, for those who want only the SSR, or only client I created the branch basic-api.


fix(scroll): render styles elem in editor template.

Summary of Changes

fix scrolling bug in Editor via sketchy techniques

Demo

Fixed this for realzisies in #61 . I basically did this same thing of adding css, but placed it in its own file and imported it with other scss files.
Thanks for all your work figuring this out!


Queue trigger condition is simple textbox

Describe the Bug with repro steps

Create a new workflow
Add a new trigger - Azure Queue - On a new message
Go to Settings -> General -> Trigger conditions
Observe the trigger input is a simple text textbox, doesn't allow inserting Expression or Data from previous steps

What type of Logic App Is this happening in?
Standard (Portal)
Are you using Preview Designer or GA Designer
Preview
Workflow JSON
No response
Screenshots or Videos
Trigger conditions:

Other textboxes:

Browser
Edge version 113.0.1774.35
Additional context
No response

@abatishchev - this is not a supported scenario, we do not allow entering expressions in trigger condition since trigger is the entry point of workflow. Also this was not present in our GA designer as well, so closing this as a non bug.

@preetriti1 can you please explain (or point to the right doc) what should go into the texbox?
Its description says:

Specify one of more expressions ...

And you're saying:

we do not allow entering expressions

I'm puzzled by the contradiction. Can you please explain?


219735 Fix docker image and docker commands for bash, app, tests, for…

I would prefer to have an entrypoint.sh script and have bash or swext as part of the command.
Imagine you want to enter the bash (without using a docker compose)
The most natural command line is:
$ docker run -it <image-name> bash

Instead of:
$ docker run -it  --entrypoint bash <image-name>

Thanks, my friend! Done


Weird positioning when adjacent overlapping div contains float

Demo: http://codepen.io/anon/pen/ogrYOr
I expected the flex container div to be sized and positioned according to its parent (just like block) div but it's not.

ie/chrome: instead of top of parent div, it's positioned right below float of adjacent parent div (sorry I don't know how to properly say it)
firefox: just weird

Am I missing something?

I noticed setting overflow: hidden on .parent makes the flex container behave as I'd expect.

According to the spec:

floats do not intrude into the flex container

This would explain why the flex container is being rendered directly below the floated items (in Chrome).
As for which behavior is correct (Chrome/IE vs. FF), I'm not sure, but I don't think it has anything to do with Flexbox. If you remove the .child element (the only thing with display: flex), there is still a rendering difference, and I think that's the heart of the problem.


Not working with new version of Vite, dependency issue

npm install --save-dev vite-plugin-rewrite-all
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/vite
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/vite-plugin-rewrite-all
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/learningx/.npm/eresolve-report.txt for a full report.
npm ERR!      /Users/learningx/.npm/_logs/2022-07-28T13_19_47_167Z-debug-0.log

Is there anyone who can reply please?

Did you look at the contents of  /Users/learningx/.npm/_logs/2022-07-28T13_19_47_167Z-debug-0.log?

I understand this part, but this current plugin is not update to date with the new vite version.

Which version of Vue are you using? 2 or 3?

I'm using React - ^18.2.0

I release a new version<EMAIL_ADDRESS>to support Vite 2 & 3, Please update it @Learning-X

Thank you very much, very appreciated @alphatr !!


Improved err handling in ApiController.GetResponse

-The GetResponse method swallowed any exceptions and returned an empty
string if anything else than the WebException was thrown, causing
valuable information to get lost.
-In case an WebException was thrown, more specific exceptions are
thrown, but those exceptions did not wrap the original exception causing
valuable information about the error to get lost.

Nice improvement, thanks!


Failure to solve conda requirements with custom conda repository

Checks

[x] I have checked that this issue has not already been reported.

[x] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
Using this minimal pixi.toml file with pixi v0.34.0
[project]
name = "pixi-tests"
version = "1.0.0"
description = "A pixi project for testing"
channels = ["https://software.repos.intel.com/python/conda", "conda-forge"]
platforms = ["win-64"]

[dependencies]
ifx_win-64 = "*"

[tasks]
info = {cmd=[ "where", "ifx"]}

I also made a test repo: https://github.com/Krande/pixi_testing
Issue description
Fails to find the package "ifx_win-64".
(base) C:\Work\code\code-aster-src>pixi run info
  × failed to solve the conda requirements of 'default' 'win-64'
  ╰─▶ Cannot solve the request because of: No candidates were found for ifx_win-64 *.

Expected behavior
When I try using mamba it finds the package.
(base) C:\Work\code\code-aster-src>mamba create -n mambatest -c https://software.repos.intel.com/python/conda -c conda-forge ifx_win-64

Looking for: ['ifx_win-64']

https://software.repos.intel.com/python/conda/no..            No change
https://software.repos.intel.com/python/conda/wi..            No change
conda-forge/noarch                                  17.0MB @  29.5MB/s  0.6s
conda-forge/win-64                                  25.2MB @  32.3MB/s  0.8s
Transaction
  Prefix: C:\Work\miniforge3\envs\mambatest

  Updating specs:

   - ifx_win-64

  Package                    Version  Build           Channel                                     Size
--------------------------------------------------------------------------------------------------------
  Install:
--------------------------------------------------------------------------------------------------------

  + compiler_shared         2025.0.0  intel_1162      software.repos.intel.com/python/conda      195MB
  + intel-cmplr-lib-rt      2025.0.0  intel_1162      software.repos.intel.com/python/conda       16MB
  + intel-cmplr-lic-rt      2025.0.0  intel_1162      software.repos.intel.com/python/conda       47kB
  + tcm                        1.2.0  intel_583       software.repos.intel.com/python/conda      332kB
  + umf                        0.9.0  intel_584       software.repos.intel.com/python/conda       63kB
  + intel-cmplr-lib-ur      2025.0.0  intel_1162      software.repos.intel.com/python/conda        1MB
  + intel-openmp            2025.0.0  intel_1162      software.repos.intel.com/python/conda        4MB
  + intel-fortran-rt        2025.0.0  intel_1162      software.repos.intel.com/python/conda        3MB
  + vswhere                    3.1.7  h57928b3_0      conda-forge                                219kB
  + ucrt                10.0.22621.0  h57928b3_1      conda-forge                               Cached
  + vs2022_win-64        19.41.34120  h72b6792_22     conda-forge                                 20kB
  + vc14_runtime         14.40.33810  hcc2c482_22     conda-forge                               Cached
  + vs_win-64                2022.11  h72b6792_22     conda-forge                                 18kB
  + vc                          14.3  h8a93ad2_22     conda-forge                               Cached
  + tbb                     2022.0.0  vc14_intel_396  software.repos.intel.com/python/conda      233kB
  + intel-opencl-rt         2025.0.0  intel_1162      software.repos.intel.com/python/conda      100MB
  + ifx_impl_win-64         2025.0.0  intel_1162      software.repos.intel.com/python/conda       29MB
  + ifx_win-64              2025.0.0  intel_1162      software.repos.intel.com/python/conda       18kB

  Summary:

  Install: 18 packages

  Total download: 348MB

--------------------------------------------------------------------------------------------------------

Confirm changes: [Y/n]

Is this is a bug in pixi, or am I doing something wrong (which is completely plausible)?
Best Regards
Kristoffer

I can't find a way to install these as well, I do find that I can install A version of intel-opencl-rt but not in the same version as mamba. Asked @wolfv to take a look as he probally understands the channel better.

Hi @Krande - I think this might be related to weird unicode characters in the repodata. I see a bunch of "common_cmplr_lib_rt \u003E=2024.2.0", in the repodata when visiting https://software.repos.intel.com/python/conda/win-64/repodata.json
I don't really think that rattler deals well with that. I am wondering why / how conda mamba work (do they decode this data or ignore it? ...

Hmm, although on closer inspection, things seem well decoded when running pixi search on that channel / subdir. E.g. pixi search intelpython3_full -c https://software.repos.intel.com/python/conda --platform=win-64 shows good results.
I'll have to dig deeper - later today!

Thanks @wolfv! I can confirm that your suggested workaround works for me :)


(mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')) on M2

Prerequisites
Please answer the following questions for yourself before submitting an issue.

[X ] I am running the latest code. Development is very rapid so there are no tagged versions as of now.
[X ] I carefully followed the README.md.
[ X] I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
[ X] I reviewed the Discussions, and have a new bug or useful enhancement to share.

Expected Behavior
I'm trying to launch the Llama API following the guide in https://github.com/abetlen/llama-cpp-python#:~:text=docs/install/macos.md, on my Macbook M2.
Current Behavior
Unfortunately, after running the last command, which is
python3 -m llama_cpp.server --model $MODEL  --n_gpu_layers 1
I get
RuntimeError: Failed to load shared library '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib': dlopen(/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib, 0x0006): tried: '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (no such file), '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
Any help would be much appreciated!

Prerequisites
Please answer the following questions for yourself before submitting an issue.

[X ] I am running the latest code. Development is very rapid so there are no tagged versions as of now.
[X ] I carefully followed the README.md.
[ X] I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
[ X] I reviewed the Discussions, and have a new bug or useful enhancement to share.

Expected Behavior
I'm trying to launch the Llama API following the guide in https://github.com/abetlen/llama-cpp-python#:~:text=docs/install/macos.md, on my Macbook M2.
Current Behavior
Unfortunately, after running the last command, which is
python3 -m llama_cpp.server --model $MODEL --n_gpu_layers 1
I get
RuntimeError: Failed to load shared library '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib': dlopen(/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib, 0x0006): tried: '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (no such file), '/Users/alessandropaticchio/miniforge3/envs/llama/lib/python3.9/site-packages/llama_cpp/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
Any help would be much appreciated!

Add-DCMAKE_OSX_ARCHITECTURES=arm64 to CMake build, follow this up:
CMAKE_ARGS="-DLLAMA_METAL=on -DCMAKE_OSX_ARCHITECTURES=arm64"

The parent Python process runs as x86_64, but the loaded shared object is in arm64e or arm64.
When I initially encountered this problem, I was using this Python interpreter on my m2:
$ file $(which python3)
/usr/local/bin/python3: Mach-O 64-bit executable x86_64

There was also the default MacOS version:
$ file /usr/bin/python3
/usr/bin/python3: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/python3 (for architecture x86_64):     Mach-O 64-bit executable x86_64
/usr/bin/python3 (for architecture arm64e):     Mach-O 64-bit executable arm64e

When a binary is compiled with two architectures, you must select the architecture to execute using the "arch" command.
arch -arm64e /usr/bin/python3

If you run into this problem, first check which architecture your parent Python interpreter is compiled for:
file $(which python3)

Then, install a Python interpreter into your environment that matches the shared object (.so) architecture that ctypes attempts to import.

@steveoOn  last version this worked on was 2.0.13, 2.0.14 fails to compile.
@kugg in my case I have only arm64 binary and still face same error. When llama_cpp is being built, CMAKE decides to use x86
@alessandropaticchio why is this issue closed?
The issue is still actual and moreover, the workaround @steveoOn suggested stopped working.

Current state with 0.2.15:
(.venv) potapov-m1:ai muzhig$ CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python
Using pip 23.3.1 from /Users/muzhig/PycharmProjects/ai/.venv/lib/python3.10/site-packages/pip (python 3.10)
Collecting llama-cpp-python
  Downloading llama_cpp_python-0.2.15.tar.gz (7.7 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7.7/7.7 MB 11.1 MB/s eta 0:00:00
  Running command pip subprocess to install build dependencies
  Collecting scikit-build-core>=0.5.1 (from scikit-build-core[pyproject]>=0.5.1)
    Using cached scikit_build_core-0.6.1-py3-none-any.whl.metadata (17 kB)
  Collecting exceptiongroup (from scikit-build-core>=0.5.1->scikit-build-core[pyproject]>=0.5.1)
    Using cached exceptiongroup-1.1.3-py3-none-any.whl.metadata (6.1 kB)
  Collecting packaging>=20.9 (from scikit-build-core>=0.5.1->scikit-build-core[pyproject]>=0.5.1)
    Using cached packaging-23.2-py3-none-any.whl.metadata (3.2 kB)
  Collecting tomli>=1.1 (from scikit-build-core>=0.5.1->scikit-build-core[pyproject]>=0.5.1)
    Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
  Collecting pathspec>=0.10.1 (from scikit-build-core[pyproject]>=0.5.1)
    Using cached pathspec-0.11.2-py3-none-any.whl.metadata (19 kB)
  Collecting pyproject-metadata>=0.5 (from scikit-build-core[pyproject]>=0.5.1)
    Using cached pyproject_metadata-0.7.1-py3-none-any.whl (7.4 kB)
  Using cached scikit_build_core-0.6.1-py3-none-any.whl (134 kB)
  Using cached packaging-23.2-py3-none-any.whl (53 kB)
  Using cached pathspec-0.11.2-py3-none-any.whl (29 kB)
  Using cached exceptiongroup-1.1.3-py3-none-any.whl (14 kB)
  Installing collected packages: tomli, pathspec, packaging, exceptiongroup, scikit-build-core, pyproject-metadata
  Successfully installed exceptiongroup-1.1.3 packaging-23.2 pathspec-0.11.2 pyproject-metadata-0.7.1 scikit-build-core-0.6.1 tomli-2.0.1
  Installing build dependencies ... done
  Running command Getting requirements to build wheel
  Getting requirements to build wheel ... done
  Running command pip subprocess to install backend dependencies
  Collecting ninja>=1.5
    Using cached ninja-<IP_ADDRESS>-py2.py3-none-macosx_10_9_universal2.macosx_10_9_x86_64.macosx_11_0_arm64.macosx_11_0_universal2.whl.metadata (5.3 kB)
  Using cached ninja-<IP_ADDRESS>-py2.py3-none-macosx_10_9_universal2.macosx_10_9_x86_64.macosx_11_0_arm64.macosx_11_0_universal2.whl (270 kB)
  Installing collected packages: ninja
  Successfully installed ninja-<IP_ADDRESS>
  Installing backend dependencies ... done
  Running command Preparing metadata (pyproject.toml)
  *** scikit-build-core 0.6.1 using CMake 3.26.2 (metadata_wheel)
  Preparing metadata (pyproject.toml) ... done
Collecting typing-extensions>=4.5.0 (from llama-cpp-python)
  Obtaining dependency information for typing-extensions>=4.5.0 from https://files.pythonhosted.org/packages/24/21/7d397a4b7934ff4028987914ac1044d3b7d52712f30e2ac7a2ae5bc86dd0/typing_extensions-4.8.0-py3-none-any.whl.metadata
  Downloading typing_extensions-4.8.0-py3-none-any.whl.metadata (3.0 kB)
Collecting numpy>=1.20.0 (from llama-cpp-python)
  Obtaining dependency information for numpy>=1.20.0 from https://files.pythonhosted.org/packages/e3/63/fd76159cb76c682171e3bf50ed0ee8704103035a9347684a2ec0914b84a1/numpy-1.26.1-cp310-cp310-macosx_11_0_arm64.whl.metadata
  Downloading numpy-1.26.1-cp310-cp310-macosx_11_0_arm64.whl.metadata (61 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.2/61.2 kB 275.4 MB/s eta 0:00:00
Collecting diskcache>=5.6.1 (from llama-cpp-python)
  Obtaining dependency information for diskcache>=5.6.1 from https://files.pythonhosted.org/packages/3f/27/4570e78fc0bf5ea0ca45eb1de3818a23787af9b390c0b0a0033a1b8236f9/diskcache-5.6.3-py3-none-any.whl.metadata
  Downloading diskcache-5.6.3-py3-none-any.whl.metadata (20 kB)
Downloading diskcache-5.6.3-py3-none-any.whl (45 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 45.5/45.5 kB 214.2 MB/s eta 0:00:00
Downloading numpy-1.26.1-cp310-cp310-macosx_11_0_arm64.whl (14.0 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 14.0/14.0 MB 18.9 MB/s eta 0:00:00
Downloading typing_extensions-4.8.0-py3-none-any.whl (31 kB)
Building wheels for collected packages: llama-cpp-python
  Running command Building wheel for llama-cpp-python (pyproject.toml)
  *** scikit-build-core 0.6.1 using CMake 3.26.2 (wheel)
  *** Configuring CMake...
  loading initial cache file /var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/tmpp3_873f3/build/CMakeInit.txt
  -- The C compiler identification is AppleClang <IP_ADDRESS>30022
  -- The CXX compiler identification is AppleClang <IP_ADDRESS>30022
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
  -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
  -- Found Threads: TRUE
  -- Accelerate framework found
  -- Metal framework found
  -- CMAKE_SYSTEM_PROCESSOR: x86_64
  -- x86 detected
  CMake Warning (dev) at vendor/llama.cpp/CMakeLists.txt:731 (install):
    Target llama has RESOURCE files but no RESOURCE DESTINATION.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Warning (dev) at CMakeLists.txt:18 (install):
    Target llama has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Warning (dev) at CMakeLists.txt:27 (install):
    Target llama has PUBLIC_HEADER files but no PUBLIC_HEADER DESTINATION.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  -- Configuring done (4.1s)
  -- Generating done (0.0s)
  -- Build files have been written to: /var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/tmpp3_873f3/build
  *** Building project with Ninja...
  [1/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -DLLAMA_BUILD -DLLAMA_SHARED -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -Dllama_EXPORTS -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wmissing-declarations -Wmissing-noreturn -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -Wmissing-prototypes -Wextra-semi -march=native -MD -MT vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o -MF vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o.d -o vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/llama.cpp
  FAILED: vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -DLLAMA_BUILD -DLLAMA_SHARED -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -Dllama_EXPORTS -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wmissing-declarations -Wmissing-noreturn -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -Wmissing-prototypes -Wextra-semi -march=native -MD -MT vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o -MF vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o.d -o vendor/llama.cpp/CMakeFiles/llama.dir/llama.cpp.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/llama.cpp
  clang: error: the clang compiler does not support '-march=native'
  [2/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-metal.m
  FAILED: vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-metal.m.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-metal.m
  clang: error: the clang compiler does not support '-march=native'
  [3/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml.c
  FAILED: vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml.c
  clang: error: the clang compiler does not support '-march=native'
  [4/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-quants.c
  FAILED: vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-quants.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-quants.c
  clang: error: the clang compiler does not support '-march=native'
  [5/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-alloc.c
  FAILED: vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-alloc.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-alloc.c
  clang: error: the clang compiler does not support '-march=native'
  [6/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-backend.c
  FAILED: vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_USE_ACCELERATE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wdouble-promotion -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -march=native -MD -MT vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o -MF vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o.d -o vendor/llama.cpp/CMakeFiles/ggml.dir/ggml-backend.c.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/ggml-backend.c
  clang: error: the clang compiler does not support '-march=native'
  [7/23] cd /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp && /usr/local/Cellar/cmake/3.26.2/bin/cmake -DMSVC= -DCMAKE_C_COMPILER_VERSION=<IP_ADDRESS>30022 -DCMAKE_C_COMPILER_ID=AppleClang -DCMAKE_VS_PLATFORM_NAME= -DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -P /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/common/../scripts/build-info.cmake
  -- Found Git: /usr/bin/git (found version "2.39.2 (Apple Git-143)")
  [8/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DLLAMA_BUILD -DLLAMA_SHARED -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/. -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/../.. -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/../../common -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wno-cast-qual -MD -MT vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/llava.cpp.o -MF vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/llava.cpp.o.d -o vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/llava.cpp.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/llava.cpp
  [9/23] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DLLAMA_BUILD -DLLAMA_SHARED -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/. -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/../.. -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/../../common -I/private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -fPIC -Wno-cast-qual -MD -MT vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/clip.cpp.o -MF vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/clip.cpp.o.d -o vendor/llama.cpp/examples/llava/CMakeFiles/llava.dir/clip.cpp.o -c /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534/vendor/llama.cpp/examples/llava/clip.cpp
  ninja: build stopped: subcommand failed.

  *** CMake build failed
  error: subprocess-exited-with-error

  × Building wheel for llama-cpp-python (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /Users/muzhig/PycharmProjects/ai/.venv/bin/python /Users/muzhig/PycharmProjects/ai/.venv/lib/python3.10/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/tmponng6h66
  cwd: /private/var/folders/x2/ss9myv0d7wjdp8z7c69xpyq40000gn/T/pip-install-6hf62331/llama-cpp-python_e29ecd08248b4cd0a1cea8e98565d534
  Building wheel for llama-cpp-python (pyproject.toml) ... error
  ERROR: Failed building wheel for llama-cpp-python
Failed to build llama-cpp-python
ERROR: Could not build wheels for llama-cpp-python, which is required to install pyproject.toml-based projects

@muzhig sorry to hear this stopped working.
Just speculating on what could have caused this to regress, can you try compiling with -DLLAMA_NATIVE=ON flag?

checking arch```muzhig$ arch
arm64```

checking arch
(0.2.17) latest version with previously working hotfix
-DLLAMA_NATIVE=ON
No luck :( I think the key is CMake config saying it detected x86:
  -- CMAKE_SYSTEM_PROCESSOR: x86_64
  -- x86 detected

Probably has something to do with llava being added after 0.2.13 - since a second lib has to be built (libllava.dylib) - maybe this is why @steveoOn 's fix no longer works...?

Work around for now:
(I believe the issue maybe with virtual environments - I was using conda).
Working installation for bakllava:
python3 -m venv source venv/bin/activate
pip install py-llm-core

Then download your models -
grab both
ggml-model-q5_k.gguf
mmproj-model-f16.gguf
Place these where ever (you'll reference the path in your .py)
There is a bug in the llama_cpp module: llama_chat_format.py
change line 966 from
llama.eval(llama.tokenize(system_prompt.encode("utf8"), add_bos=True))
to
 llama.eval(llama.tokenize((' '.join([e['text'] for e in system_prompt])).encode('UTF-8'), add_bos=True))

@YAY-3M-TA3 comment + using a previous version (0.2.11) worked for me.
!CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python==0.2.11

I try on use the old version , It  works . But it runs too slow, Maybe Can not use the arm arch
CMAKE_ARGS="-DLLAMA_METAL=on -DCMAKE_OSX_ARCHITECTURES=arm64" pip install --upgrade --force-reinstall llama-cpp-python==v0.1.85 --no-cache-dir

This worked fine for me -- afaik it's the latest version pulled straight from the git repository:
CMAKE_ARGS="-DLLAMA_METAL=on" FORCE_CMAKE=1 pip install -U git+https://github.com/abetlen/llama-cpp-python.git --no-cache-dir

I too am having problems with this using Apple M2 and OSX version 14.1.2 (23B92).  Some details if it helps others:

Arch
(llama) ~ ➤ arch
arm64

Conda
(llama) ~ ➤ conda info

     active environment : llama
    active env location : /Users/fozziethebeat/anaconda3/envs/llama
            shell level : 1
       user config file : /Users/fozziethebeat/.condarc
 populated config files : /Users/fozziethebeat/.condarc
          conda version : 23.7.4
    conda-build version : 3.26.1
         python version : 3.11.5.final.0
       virtual packages : __archspec=1=arm64
                          __osx=14.1.2=0
                          __unix=0=0
       base environment : /Users/fozziethebeat/anaconda3  (writable)
      conda av data dir : /Users/fozziethebeat/anaconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/osx-arm64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-arm64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /Users/fozziethebeat/anaconda3/pkgs
                          /Users/fozziethebeat/.conda/pkgs
       envs directories : /Users/fozziethebeat/anaconda3/envs
                          /Users/fozziethebeat/.conda/envs
               platform : osx-arm64
             user-agent : conda/23.7.4 requests/2.31.0 CPython/3.11.5 Darwin/23.1.0 OSX/14.1.2 aau/0.4.2 c/04QvfUPEw4ylU87j3NEdGw s/z6SZBnNd3JF988yxq7fzoQ e/8NeTeH7rTaxso2UfOVXsxw
                UID:GID : 501:20
             netrc file : None
           offline mode : False

Which Python
(llama) ~ ➤ file $(which python3)
/Users/fozziethebeat/anaconda3/envs/llama/bin/python3: Mach-O 64-bit executable arm64
(llama) ~ ➤ file /usr/bin/python3
/usr/bin/python3: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/python3 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/python3 (for architecture arm64e):	Mach-O 64-bit executable arm64e

Working install
CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python==0.2.13

This got me to a final run of the server with
ggml_metal_init: GPU name:   Apple M2
ggml_metal_init: GPU family: MTLGPUFamilyApple8 (1008)

Failed Install
CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python==0.2.14

This led to eventually
clang: error: unsupported argument 'native' to option '-march='
  [7/17] cd /private/var/folders/h1/v4wn7py50kj2ntk27xvc0vjm0000gn/T/pip-install-3qkvzxq1/llama-cpp-python_8fd30f7c2244404b8a8225a8a98d18c1/vendor/llama.cpp && /usr/local/Cellar/cmake/3.27.1/bin/cmake -DMSVC= -DCMAKE_C_COMPILER_VERSION=<IP_ADDRESS>00040 -DCMAKE_C_COMPILER_ID=AppleClang -DCMAKE_VS_PLATFORM_NAME= -DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -P /private/var/folders/h1/v4wn7py50kj2ntk27xvc0vjm0000gn/T/pip-install-3qkvzxq1/llama-cpp-python_8fd30f7c2244404b8a8225a8a98d18c1/vendor/llama.cpp/common/../scripts/build-info.cmake

I managed to install llama.cpp manually with no problem using make (no special changes).  So I'm guessing this is something weird about cmake that I am not familiar with.
i've tried later versions and at HEAD but nothing past 0.2.13 was able to compile.

Okay, I did some hacking to the CMakeLists.txt file and found that by adding
    set(LLAMA_NATIVE "Off" CACHE BOOL "llama: disable march native" FORCE)

somewhere in it, I got everything to install properly.  I did some investigating and discovered that for some reason my xcode toolchain doesn't support the --march option.  Version 0.2.13 doesn't trigger anything since it never tries to add that option when calling clang.  I still want to investigate why my xcode clang doesn't have this option.  (note, my locally installed clang does have this flag).

@fozziethebeat around line 18 I guess, does setting it before pip installing work as well ie CMAKE_ARGS="-DLLAMA_NATIVE=OFF"

That looks like it did it.  In a new environment I ran
CMAKE_ARGS="-DLLAMA_NATIVE=OFF" pip install llama-cpp-python

And everything worked with great success

@YAY-3M-TA3 comment + using a previous version (0.2.11) worked for me.
!CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python==0.2.11

It worked for me, thanks a lot!

Here is what worked for me after all (with latest version):
CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_APPLE_SILICON_PROCESSOR=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python
I started digging from the logline:
  -- CMAKE_SYSTEM_PROCESSOR: x86_64
  -- x86 detected

and stumbled upon this thread https://discourse.cmake.org/t/macos-cmake-detect-system-processor-incorrectly-on-apple-silicon/5129/5
@abetlen probably makes sense to add this in the troubleshooting / README?

Here is what worked for me after all (with latest version):
CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_APPLE_SILICON_PROCESSOR=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python
I started digging from the logline:
  -- CMAKE_SYSTEM_PROCESSOR: x86_64
  -- x86 detected

and stumbled upon this thread https://discourse.cmake.org/t/macos-cmake-detect-system-processor-incorrectly-on-apple-silicon/5129/5
@abetlen probably makes sense to add this in the troubleshooting / README?

in which path you write it ?

CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python==0.2.11

this fixed it for me - epic, thank you

CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_APPLE_SILICON_PROCESSOR=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python

for me it doesn't work :(
$ CMAKE_ARGS="-DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_APPLE_SILICON_PROCESSOR=arm64 -DLLAMA_METAL=on" pip install --upgrade --verbose --force-reinstall --no-cache-dir llama-cpp-python
.........
  [13/37] /Library/Developer/CommandLineTools/usr/bin/clang -DACCELERATE_LAPACK_ILP64 -DACCELERATE_NEW_LAPACK -DGGML_BUILD -DGGML_METAL_EMBED_LIBRARY -DGGML_SCHED_MAX_COPIES=4 -DGGML_SHARED -DGGML_USE_ACCELERATE -DGGML_USE_BLAS -DGGML_USE_LLAMAFILE -DGGML_USE_METAL -D_DARWIN_C_SOURCE -D_XOPEN_SOURCE=600 -Dggml_EXPORTS -I/private/var/folders/6q/dn566lyd20z9x1phnzlwgmlc0000gn/T/pip-install-0ywptpy8/llama-cpp-python_b5d4267932764b429df8cc13ef85ee80/vendor/llama.cpp/ggml/src/../include -I/private/var/folders/6q/dn566lyd20z9x1phnzlwgmlc0000gn/T/pip-install-0ywptpy8/llama-cpp-python_b5d4267932764b429df8cc13ef85ee80/vendor/llama.cpp/ggml/src/. -F/Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/System/Library/Frameworks -O3 -DNDEBUG -std=gnu11 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk -fPIC -Wshadow -Wstrict-prototypes -Wpointer-arith -Wmissing-prototypes -Werror=implicit-int -Werror=implicit-function-declaration -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -Wdouble-promotion -MD -MT vendor/llama.cpp/ggml/src/CMakeFiles/ggml.dir/ggml.c.o -MF vendor/llama.cpp/ggml/src/CMakeFiles/ggml.dir/ggml.c.o.d -o vendor/llama.cpp/ggml/src/CMakeFiles/ggml.dir/ggml.c.o -c /private/var/folders/6q/dn566lyd20z9x1phnzlwgmlc0000gn/T/pip-install-0ywptpy8/llama-cpp-python_b5d4267932764b429df8cc13ef85ee80/vendor/llama.cpp/ggml/src/ggml.c
  ninja: build stopped: subcommand failed.

  *** CMake build failed
  error: subprocess-exited-with-error

  × Building wheel for llama-cpp-python (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /Users/seba/Projects/python/learn-ai/venv/bin/python3.12 /Users/seba/Projects/python/learn-ai/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /var/folders/6q/dn566lyd20z9x1phnzlwgmlc0000gn/T/tmpg0x2ib1v
  cwd: /private/var/folders/6q/dn566lyd20z9x1phnzlwgmlc0000gn/T/pip-install-0ywptpy8/llama-cpp-python_b5d4267932764b429df8cc13ef85ee80
  Building wheel for llama-cpp-python (pyproject.toml) ... error
  ERROR: Failed building wheel for llama-cpp-python
Failed to build llama-cpp-python
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (llama-cpp-python)


Documentation details update

PR related to https://github.com/AY2122S2-CS2103T-W14-2/tp/issues/70
Added relevant user stories in DG
Added add-t, del-t, edit-t and export features and use cases into UG and DG
No changes made to the storage component so far.

There are still merge conflicts in this PR. Let me know once you have resolved it! Also, for the sequence diagram, you might want to try creating the image from the PUML file that you have created again. I tried your code and the output sequence diagram does not have that yellow box on the right

Thanks @simjunheng! Should be good now I think


standalone compiler

Hi, CoffeeScript provides its core compiler as a standalone script so it can be used in any javascript engine. Is it possible to run the LiveScript compiler outside node.js as well? I tried the compiled livescript.js (which I guess is only intended for browsers) but couldn't make it work (I use the duktape engine).

this is exactly equivalent to the CoffeeScript version.

Thanks for your answer.
With the CoffeeScript version I can simply do something like:
var coffee = require('lib/coffee-script').CoffeeScript;
var script = readfile('js/test.coffee');
eval(coffee.compile(script))

But doesn't work with the LiveScript version. I must be missing something.

Here's such an example in one of my projects: https://github.com/vendethiel/wowboardhelpers/blob/master/Slakefile (see ls-parse, src is the source code).
Maybe you have an error, what "does not work"?

Thank you for the info. If I try the following I get a TypeError: not callable error because the compile method is undefined.
var LiveScript = require('livescript.js');
LiveScript.compile(src)

It seems that require('livescript.js') returns an "empty object" (no properties/methods).
Duktape has its own module loading system based on CommonJS and with support for module.exports. Although it works for CoffeeScript, Duktape module loading may not work  with LiveScript somehow.

You're not supposed to load "livescript.js". But anyway, I think this is an issue with how duktape does its stuff. It definitely works in nodejs, so this is not a bug of ours.


Scarf Proposal

A proposal to use Scarf as a gateway for binary and container image downloads.

👍 LGTM

After reading the document, my takeways are:

The vendor neutrality required by the CNCF (link?) requires the cert-manager project to "mask" any vendor mentions such as Jetstack or Venafi in things like image names and Helm chart repo URLs.
The official cert-manager images contain the word "jetstack", such as quay.io/jetstack/cert-manager-controller.
Scarf wouldn't host or deal with the high network traffic due to the image pulls since the images would stay in quay.io.
The canonical image would still be quay.io/jetstack/cert-manager-controller.
On top of fixing this vendor-neutrality problem, the cert-manager project would also be able to communicate on how many image pulls are done every month. We haven't been able to do that with Quay since pulling the download logs crashes their servers, and we have been stuck with "approximately 1 million pulls per day" in all of our project updates...

I have a few questions:

An easy solution to the original problem could be to relocate (or rather duplicate) images to quay.io/cert-manager-org/cert-manager (the cert-manager is apparently taken). Has this been explored? Is there any other alternative to Scarf?
Who will pay for this, is the CNCF going to pay?
Has any other CNCF project adopted this tool, what do they think about adopting this tool?
If Scarf is free, what's their business model, are they somehow reselling some acquired data to third parties?
What about Helm charts? The name "jetstack" appears too when adding the repo:helm repo add jetstack https://charts.jetstack.io

How exactly does the "path" problem affect us? Would it prevent us from removing the /jetstack path from the image names?
I think everyone would like to know what the new image names would look like. Would it be something like:img.cert-manager.io/cert-manager-controller

Extra improvement: Additional to removing the jetstack name, we will also remove the quay.io name and switch to a more neutral domain (eg. cert-manager.io).

Addressed in e7f3ff6

An easy solution to the original problem could be to relocate (or rather duplicate) images to quay.io/cert-manager-org/cert-manager (the cert-manager is apparently taken). Has this been explored? Is there any other alternative to Scarf?

This does not fully solve the problem as it leaves a dependency upon the quay.io service
Further detail added in ad2e24d

Who will pay for this, is the CNCF going to pay?

A free tier account for OSS projects will be created (clarified in e7f3ff6). The free tier will address the goals listed in the proposal (further discussion to be had around the "path" problem).
Higher tiered (basic/premium) accounts are available at cost, pricing based on the number of monthly tracked companies and the number of seats for access. For transparency, Venafi may contribute towards this cost later but has yet to commit to doing so at the moment of writing.

Has any other CNCF project adopted this tool, what do they think about adopting this tool?

Apache Superset
Apache SkyWalking
Apache DevLake
Apache DolphinScheduler
Rocket.Chat
Buoyant (Linkerd)

If Scarf is free, what's their business model, are they somehow reselling some acquired data to third parties?

"Basic" & "Premium" tiers are available at cost, providing more significant insights, support and SLAs. See Scarf's pricing model. Scarf will generate revenue from these account types.

What about Helm charts?

These should also be addressed, and Scarf may be an appropriate solution; however, Helm chart hosting is currently out of the scope of this proposal.
Default container image locations should be updated within existing Helm charts to reflect the newly chosen location.

How exactly does the "path" problem affect us? Would it prevent us from removing the /jetstack path from the image names?

The cert-manager images are currently located at quay.io/jetstack/cert-manager-controller. Current Scarf functionality allows for domain changes to a custom domain such as img.cert-manager.io (using @maelvls example). This would result in the new location being img.cert-manager.io/jetstack/cert-manager-controller, which continues to use "jetstack" in the path.
As described in the proposal, a workaround is being investigated by Scarf to allow for a custom path. There is also an alternative approach with the use of an additional hosting location such as ghcr.io/cert-manager/cert-manager-controller

I'd like to know what the new image names would look like

The chosen custom domain and image hosting location are topics to be discussed by the maintainers, and discussion from the community would also be welcome.

Hi, just wanted to leave a quick note here as well are just pointing out a couple of other CNCF projects that are utilizing Scarf:

https://github.com/dapr/docs/pull/3025
https://github.com/litmuschaos/litmus/pull/4298, https://github.com/litmuschaos/litmus/pull/4298

Also, that Scarf is building a formal partnership with the Linux Foundation (and all of its subsidiary organizations, like the CNCF), and is now listed on this list of partners here: https://www.linuxfoundation.org/projects/partnerships

We discussed this proposal during the bi-weekly development meeting: https://docs.google.com/document/d/1Tc5t6ylY9dhXAan1OjOoldeaoys1Yh4Ir710ATfBa5U/edit#bookmark=id.cn5lnyf8y3oh
I think that the PR can be merged based on that conversation.
/approve
/lgtm


Merge kitchen.yml into kitchen.dokken.yml

Description
Run tests on all platforms
Issues Resolved
N/A
Check List

[ ] All tests pass. See TESTING.md for details.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable.

#5 resolves ci/delivery

Fmm... I'll check it. It should not be so tough to fix gentoo tests

Investigated that but couldn't find the cause, and a retry resolved... :)


Plumb header validator into HTTP/1 server codec

Additional Description:
This PR plumbs header validator into HTTP/1 codec. The code is disabled in normal builds and is behind the ENVOY_ENABLE_UHV flag, which is tested during compile_time_options build only.
H/1 client and H/2 codecs are to be done in a follow up PR.
Risk Level: Low, no changes for normal Envoy builds.
Testing: Unit Tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Yan Avlasov<EMAIL_ADDRESS>

/retest

Changed the return type of header validator to be a tuple of action and details string and enforced non empty string at construction.


[booksonic-air][Add] Add booksonic-air

Signed-off-by: TJ Wesolowski<EMAIL_ADDRESS>Special notes for your reviewer:
Adds a chart for Booksonic-air leveraging the common chart and the Linuxserver.io image.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [radarr])

👏 thanks for the new chart


Better definitions for issuance and supply

The difference between issuance and supply is becoming more apparent as the numbers come in and discussions continue. We need to truly understand the difference between these two methods or properties of the Ethereum network. I think we are pretty well agreed on issuance. We have followed the yellow paper combined with multiple client implementations. We have three independent scripts coming to consensus on what the issuance has been.
The supply seems to be a different story. Though a certain number of ETH has been issued, that does not mean that it still exists.  But apparently there are ways to actually destroy ETH. I think a first good step is to enumerate ways that ETH can be destroyed. And we should also come to agreement on what destroying ETH means. For example, if ETH is stuck at an address, does that count as being destroyed (I think not)?
The only way I have heard of ETH being truly destroyed is through contract self-destructs.

Contract self-destructs that name themselves as the recipient of the funds.


model contract enforce is not done at compile time

When trying to enforce contracts on a model schema, the dbt run command is supposed to throw a Compilation Error before dbt has materialised the table when the contract does not match - instead the run continues to happen and a Compilation error is thrown after the run is executed.
If the table already exists, it gets dropped, making the situation worse for downstream systems.
tested with dbt-athena 1.5.2 and 1.6.4 versions.
test_contract.sql
-------------------
{{
  config(
    materialized = 'table',
    )
}}

select
  'abc123' as customer_id,
  'My Best Customer' as customer_namex

schema.yml
version: 2

models:
    - name: test_contract
      config:
        materialized: table
        contract:
          enforced: true
      columns:
        - name: customer_id
          data_type: string
        - name: customer_name
          data_type: string

Result:
04:12:02  Running with dbt=1.6.8
04:12:02  Registered adapter: athena=1.6.4
04:12:02  Found 19 models, 4 tests, 0 sources, 0 exposures, 0 metrics, 380 macros, 0 groups, 0 semantic models
04:12:02
04:12:08  Concurrency: 1 threads (target='prod')
04:12:08
04:12:08  1 of 1 START sql table model z_xxxxxx.test_contract ................... [RUN]
04:12:11  1 of 1 ERROR creating sql table model z_xxxxxx.test_contract .......... [ERROR in 3.57s]
04:12:11
04:12:11  Finished running 1 table model in 0 hours 0 minutes and 9.35 seconds (9.35s).
04:12:11
04:12:11  Completed with 1 error and 0 warnings:
04:12:11
04:12:11    Compilation Error in model test_contract (models/presentation/test_contract.sql)
  This model has an enforced contract that failed.
  Please ensure the name, data_type, and number of columns in your contract match the columns in your model's definition.

  | column_name    | definition_type | contract_type | mismatch_reason       |
  | -------------- | --------------- | ------------- | --------------------- |
  | customer_name  |                 | VARCHAR       | missing in definition |
  | customer_namex | VARCHAR         |               | missing in contract   |

  > in macro assert_columns_equivalent (macros/materializations/models/table/columns_spec_ddl.sql)
  > called by macro default__get_assert_columns_equivalent (macros/materializations/models/table/columns_spec_ddl.sql)
  > called by macro get_assert_columns_equivalent (macros/materializations/models/table/columns_spec_ddl.sql)
  > called by macro athena__create_table_as (macros/materializations/models/table/create_table_as.sql)
  > called by macro create_table_as (macros/materializations/models/table/create_table_as.sql)
  > called by macro safe_create_table_as (macros/materializations/models/table/create_table_as.sql)
  > called by macro materialization_table_athena (macros/materializations/models/table/table.sql)
  > called by model test_contract (models/presentation/test_contract.sql)
04:12:11
04:12:11  Done. PASS=0 WARN=0 ERROR=1 SKIP=0 TOTAL=1

Expected:
contract is checked at Compile time before dbt run runs the materialisation on the table.

@faizhasan did you check if this is related to dbt-core and not to dbt-athena? in my understanding this is the expected behvior. Maybe @Jrmyy can also help out here.

Unsure what you mean by testing with dbt-core, do you mean with a different adapter like dbt-spark?
In general a Compilation error is thrown before runtime execution, not after.  At the moment the behavior of contract enforcement in dbt-athena is destructive - the model table gets removed if contract does not match.
The dbt documentation refers to contract enforcement in 2 places both clearly saying this should happen before model is executed.
reference/resource-configs/contract
When you dbt run your model, before dbt has materialized it as a table in the database, you will see this error:

govern/model-contracts
When building a model with a defined contract, dbt will do two things differently:

`1. dbt will run a "preflight" check to ensure that the model's query will return a set of columns with names and data types matching the ones you have defined. This check is agnostic to the order of columns specified in your model (SQL) or YAML spec.
2. dbt will include the column names, data types, and constraints in the DDL statements it submits to the data platform, which will be enforced while building or updating the model's table.

The destructive behaviour is indeed far from ideal.
I looked how the table materialization looks like in dbt-athena, and I didn't see any reference to contracts, that's why I suspect that this behavior gets inherited by dbt-core.
Could you tell me in version of dbt-core and dbt-athena you saw this behavior?

Our implementation is slightly different from dbt-core because we are limited by what can be done in Trino. dbt-core handles it directly during the table creation (with a create or replace) but we can't do that, so we do it before creating the table.
This means that indeed, in the case the materialization is table and is_ha=False, the table is:

deleted
then the contract is checked -> if there is an error indeed the table will be deleted
then we create the table

We can try to make the contract check before dropping the table

@Jrmyy i missed that contract check was inside the cta, we should definitely try to move it out and put in the materialization

This could be tricky because we want to do it also for all tables we create along the way (to stay consistent with dbt-core implementation), which means temp tables, ha tables, etc

We can but the long term solution should be to have a non-destructive behavior for contract enforcement or not, independent from the high availability feature.


SimpleSettings

Description
ALERT:T his gd(Gdevelop) extension is in the development phase so problems may occur and have things missing :(
Simple Setting adds "simple settings". One of them would be the button that can earn money and also change the scene, it is also possible to make 1 character from top-down in just a few seconds!for help contact: DevPato#0547 on discord
How to use the extension
To know about the extension contact me on discord: DevPato#0547 I will accept all requests and meet you by teaching you how to use the extension!
Checklist

[X] I've followed all of the best practices.
[X] I confirm that this extension can be integrated to this GitHub repository, distributed and MIT licensed.
[X] I am aware that the extension may be updated by anyone, and do not need my explicit consent to do so.

What tier of review do you aim for your extension?
Community (Unreviewed)
Example file
none
Extension file
Simple_Settings.zip

@DvPato You never addressed the issue raised by the bot. Are you still willing to submit your extension? If we do not hear from you, we'll assume you have abandoned the extension and close the submission. Please follow the bots instructions or create a new submission with the issue fixed.


The use of findDOMNode is deprecated in React Strict Mode

Hey! First thanks for this great library I've been using for so long.
It is used also inside of react-datetime and I got an issue from a user complaining about using reactDom.findDOMNode. Looks that it's going to be deprecated and we should move away from it.
Any alternative for removing it?
Cheers

Does the warning tell you what should be used instead, by any chance?

The docs suggest using refs:
https://reactjs.org/docs/strict-mode.html#warning-about-deprecated-finddomnode-usage

given how this HOC works, refs are a problem until it's uplifted to use forwardRefs, so it might keep throwing warnings until we can get to updating it with those =(
(but if you want to take a stab at it, that'd be aweseme!)

The main issue as I posted above, is that warnings now will become errors when this is used with upcoming react features.

But React follows proper semver, and do not release minor versions that are backward incompatible. Those warnings will not turn into errors until React 17, at which point v6 of this library will become incompatible (just like how v5 is incompatible with versions before v15).
I'm not saying this shouldn't get fixed, but I am saying that warnings are not errors, and this library will keep working with the main React component pattern just fine until that next major release comes out. So until then: if you want to take a stab at it, that's great, but I probably won't get to addressing this myself until I can find some time from my other engagements (or someone pays me to make time and do this sooner).

v6.9.0 published

Hello, I see that the issue is closed, but I still notice it with me even though I up react-onclickoutsideit to version 6.10.0
"Warning: findDOMNode is deprecated in StrictMode...."

was that a typo, or are you actually using something called react-onclickoutsideit? (because that would be a different project, then)

Typo, sorry, what I'm using is "react-onclickoutside": "^6.10.0" exactly.

Then you'll want to file a new issue, since this one got closed, with a minimum reproducible example so the problem's essentially reproducible with a copy paste. Thanks!

I see no newer issue. Was this resolved?

I didn't see a new issue filed, so not yet


[Improvement][Task] Mask configYaml in task log for non-admin users

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Kubernetes cluster's configYaml should better not visible in log.

Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

https://github.com/apache/dolphinscheduler/blob/6af361a7d6ae604cf0df0b8e10b63b76c752ce31/dolphinscheduler-worker/src/main/java/org/apache/dolphinscheduler/server/worker/runner/WorkerTaskExecuteRunnable.java#L199
To control log printing, I think use Jackson Filter to control the serialization process is OK. I will have a try.
ref: https://www.baeldung.com/jackson-serialize-field-custom-criteria


Fix type for Shop#google_apps_login_enabled

Description
Fixes #1334
Fixes incorrect type of Shop#google_apps_login_enabled attribute in REST API.
How has this been tested?
This code can be used to reproduce the issue and test the fix:
shop = Shop.last
shopify_shop = shop.with_shopify_session do
  ShopifyAPI::Shop.all.first
end
shop_data = shopify_shop.to_hash
shop_data["google_apps_login_enabled"] = true
loaded_shop = shop.with_shopify_session do
  ShopifyAPI::Shop.new(from_hash: shop_data)
end
loaded_shop.google_apps_login_enabled

Checklist:

[x] My commit message follow the pattern described in here
[x] I have performed a self-review of my own code.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have updated the project documentation.
[x] I have added a changelog line.

cc @paulomarg


manifest: Update hostap to fix build error

Fix build error of undefined reference to 'inet_aton' in hostap/src/utils/ip_addr.c

Hi @jukkar @krish2718  please review


Cleanup branches

There are a handful of branches that are 'stale' or haven't been updated in a couple months.
With anything that was last updated more than 2 months ago should we should check what the changes were and incorporate them are discard them as it makes sense.
Branches
thanos-export
The only change for thanos-export is the addition of the Product--CREATE-OR-UPDATE-flat-item-sku.md file. This seems like general documentation that can be cleaned up and added to the general documentation (or perhaps products) section.
SupplierOrderIntegration
The only change for this branch is the addition of the Order--SupplierOrders.md file. Let's make sure that the endpoint is documented and up to date, then delete this branch.
add_phone_retailer
Seems to be (as described by the name) the addition of phone to the create_order_retailer.md, get_order_detail.md calls.
Also includes the addition of the _ordering/get_order_list.md (/api/orders/) call.

[ ] thanos-export
[ ] gollum-docs (Jason)
[ ] file-specs (Konan)
[ ] 125-order-docs


add thread-hierarchy and bitset-word8

Thanks. I manually applied the patch due to some merge conflict.


Corrected the starting version for the Processor renaming to 1.3.0

Description
Preppers were renamed to processor starting in version 1.3.0. I have updated the documentation to correctly note this.
Issues Resolved
Check List

[x] New functionality includes testing.
[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #668 (5040847) into main (fd09fb5) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #668   +/-   ##
=========================================
  Coverage     91.65%   91.65%
  Complexity      606      606
=========================================
  Files            75       75
  Lines          1834     1834
  Branches        152      152
=========================================
  Hits           1681     1681
  Misses          117      117
  Partials         36       36

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd09fb5...5040847. Read the comment docs.


Fix/ros2 body heaviour

Proposed changes
Ros2 for the body beahviour
Related issues

#254
Necessary checks

[ ] Update package version
[ ] Run catkin build
[ ] Write documentation
[ ] Create issues for future work
[ ] Test on your machine
[ ] Test on the robot
[ ] Put the PR on our Project board

Problem: all the fixes marc did in the head behaviour are also in there, because I checked out his branch. How can I change that?

You could point the pr at his pr, but I would just wait until they are merged in the master as this also results in them disappearing from the diff.


Firebase Notification  initialization from setting page

Related Issues

Short Description and Why It's Useful
Firebase Notification  initialization from setting page
Screenshots of Visual Changes before/after (If There Are Any)

Contribution and Currently Important Rules Acceptance

[ ] I read and followed contribution rules

Verified the changes in release v2.24.1 and found that they are working fine.


logos not fitting on Members page

Hey @direnakkoc
I spotted an issue with the Members page today ... some of the logos no longer fit properly on the background 'boxes'. They are either not centred properly or they are too big for their box
Can you take a look, please?
Thanks!

Hey @CiaraFlanagan ,
the issue is resolved with his PR: https://github.com/CURIOSSorg/curioss.org/pull/8


Fix module name

@stetsyk2 What is going on here? Do you have some weird plugin that keeps raising bogus PRs?

@rittneje no, sorry, I just wanted to merge this to my fork and misclicked


fix: language file configuration for language with country codes

See #5

Codecov Report

Merging #6 into master will decrease coverage by -0.18%.
The diff coverage is 90%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
- Coverage   94.21%   94.03%   -0.18%
==========================================
  Files          14       14
  Lines         294      302       +8
==========================================
+ Hits          277      284       +7
- Misses         17       18       +1

Impacted Files
Coverage Δ

tinymce/widgets.py
92.85% <90%> (-0.48%)
:x:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 413d3f5...797c75b. Read the comment docs.

Thanks. It looks good. However, please re-submit it against develop branch. I plan to release a new version soon (with updated TinyMCE and some minor changes) and I will include your PR in it.

Sure, opened #7


DocumentProvider does not auto refresh on load

Muzei document provider exposes the daily wallpaper. However, when using Files app to look at Muzei document provider, it shows yesterday's and today's wallpaper. Pull down to refresh does remove yesterday's wallpaper.
However, it would be nice if this is updated automatically when document provider is queried when Files app is started with Muzei as the active provider.

This is working as intended - the Featured Art source does not automatically move forward to the next artwork (it is the regular Auto Advance that moves you to today's wallpaper), so during that time between loading today's wallpaper and actually seeing it as your wallpaper in Muzei, both wallpapers are correctly visible.
The reason why refreshing clears the old artwork is that it triggers the same onLoadRequested() that indicates that we're on the latest image.

The only side effect i noticed was without auto refresh when using Files app, user could try to share yesterday's wallpaper to other apps and path obtained from fileUri was invalid and file operation fails in the other app.


ML4H example notebooks

The notebooks are examples pulled from the ml4h repo.  I added some VWB-related info but did not change the notebook content otherwise.  (IMO there are some places in these notebooks that could be improved for a better UX; however, I'm not changing them as part of this PR, just basically importing them).
So no need to comment in this PR on anything but the VWB-related content.

thanks, @johntbates !