Fred's edit pass on content collections guide

What kind of changes does this PR include?

updated content

Description
As a part of my v2.0 readiness docs pass, I took a look at the content collections guide and had some suggestions for how to improve the guide. My edits focused on three main areas:

Improve readability and ordering: Since this is meant to be a guide, I took a serious look at how the information is presented and in what order. Instead of jumping the user immediately into TypeScript configuration, the guide now introduces the concepts more slowly, building as it goes. The goal is to define terms early, introduce new concepts one at a time, and not overwhelm.
Collect concepts into a single place: I took a look at places where concepts were explained across multiple sections, and did my best to bring them into a single section. This is feedback we've gotten before so I'm extra sensitive to it!
Remove reference material: Remove anything that is really reference. This was mainly directed at detailed type definitions, which belong in reference and not guides. Adding to reference is left as TODO.

TODO

Add back Content Entry type definition somewhere within reference.
Resolve getEntry() SSR issue

Just a reminder that we need to incorporate https://github.com/withastro/astro/pull/5893 here, because getEntry() has now been renamed to getEntryBySlug()

Note: I added a necessary corresponding change to a link reference from api-reference here.
I know this PR might not be in its final form, but at least now the other page that will need changes is here, and visible for editing. (We are also going to have to update this page by renaming getEntry() for example.)

Current status:

[ ]  all links fixed (in both content-collections and api-reference) to correspond to edits to headings
[ ] getEntry renamed to getEntryBySlug including any corresponding definitions (id -> slug) and code samples (post-1.md -> post-1)
[ ] obvious typos etc. fixed
[ ] Conflicts resolved
[ ] Editing for content, style etc.

@sarah11918 second pass complete!

@sarah11918 thanks for the amazing review! Made some great improvements based on your feedback. It sounds like you're either "LGTM" or close to it, so I'll leave this open until Monday or until I see your approval come through.
I'm feeling pretty good about where this is now, but don't hesitate to give this another review if you have the time and feel the need.

Just a quick reminder that merging this will remove the experimental note, so we might want to wait until Tuesday anyway! We have a "merge.on.release" label we can add for extra safety against forgetting.
I'm sure it will be great, and I'll just find time to scan for typos etc. just to be safe.

I'm going to merge this sooner actually, because I realized that the current docs have gotten out of date with the API. There will likely be one more PR to this page before release, so that will give us a chance for any final review before Tuesday's launch.


add suppliedtype to suppliers

Q
A

🐛 Bug fix?
no

🚀 New feature?
no

⚠ Deprecations?
no

❌ BC Break
no

🔗 Related issues
#160

❓ Documentation
no

Description
add suppliedtype to suppliers

Switching this one to draft since we are reworking supplied for the deep mode in #619


Advice on Subcategories

I'm just getting into this piece of code (Great Work!) and I'm wanting to add subcategories. Any suggestions on how to go about this? I'd be looking to have Brand as the main category, then Specific Phones (We're a cellphone shop). Also looking to add Variants. I just need an overall idea of how to go about this.
Thanks.

Hi!
Thanks for your feedback, interest on the project and looking forward to seeing your store powered by it!
The concept of Category/Collection is something up to the storefront, as you might have already noticed. On the API/Atlas (https://github.com/yoonic/atlas) side of things, there's only the concept of "Collections" which can be used to group Products (and also Contents, Customer, etc if you wish).
In order to achieve sub-categories, you just need to set a parentId to the sub-category (collection) --> https://github.com/yoonic/atlas/blob/master/src/resources/collections/models.js#L87-L89

I'm building 2 sites - one backend for corporate customers for the Boss and a simple Disaster Preparedness Kits ecommerce site ( I can show you the latter one once it is up!).

Nice! Did my answer help?

Yes, I believe it will work. I've been working on creating Variants first. Also, wiped my HD accidentally so I'm starting over a bit. I'll let you know on the subcategories!

Question on variants: I'm getting the options to appear on the CartItems. Where will I be storing the Product Variant Data, or is there nothing to hold the Data at the moment and i must create my own StoreHandler?

The Products entity has the concept of "metadata" that is an object in which you can store whatever sorts of information you want. You can use that for variant logic.

@stevecawdery Share that backend with the opensource! Would love to integrate it


Struggling to map Page thumbnail and include asset transfer

Category

[X] Bug
[ ] Enhancement
[X] User Error

Problem Area

[ ] Page Transformation: Error during the setup/use of the Page Transformation UI solution (did you check our troubleshooting guide?)
[ ] Page Transformation: Error during the use of page transformation from PnP PowerShell
[X] Page Transformation: Error during the use of page transformation from .Net
[ ] Page Transformation: Page is not looking correct after transformation
[ ] Modernization Scanner: something went wrong...

Expected or Desired Behavior
Trying to transform a PublishingPageImage field to the BannerImageUrl field for the page thumbnail field.
Observed Behavior
Transform does not transfer the asset or update the URL and still references the source.
Have I got the mapping wrong? My understanding in some parts of the mapping is still limited.
Steps to Reproduce

Create a page with an image or two, an image that uses page controls and referenced in metadata such as PublishingPageImage.
Add mapping

<MetaData>
<!-- default fields omitted for brevity -->
<Field Name="PublishingPageImage" TargetFieldName="BannerImageUrl" Functions="ReturnCrossSiteRelativePath(ToImageUrl({PublishingPageImage}))" />
</MetaData>

also tried
<MetaData>
<!-- default fields omitted for brevity -->
<Field Name="PublishingPageImage" TargetFieldName="BannerImageUrl" Functions="ToImageUrl({PublishingPageImage})" />
</MetaData>

still references source location. Any ideas?

Hey @pkbullock ,
The ways to configure the preview image of a page are documented here: https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-userinterface-site-pages-model-publishing#can-i-control-the-page-preview-image
So in your case I think you should be using this:
<MetaData>
<!-- default fields omitted for brevity -->
<Field Name="PublishingPageImage" TargetFieldName="BannerImageUrl" Functions="ToPreviewImageUrl({PublishingPageImage})" />
</MetaData>

If you have multiple fields containing images and you want a "fall back" mechanism in case your PublishingPageImage field is null then do something like this:
<MetaData>
<!-- default fields omitted for brevity -->
<Field Name="PublishingPageImage;Image2;Image3" TargetFieldName="BannerImageUrl" Functions="ToPreviewImageUrl({@Name})" />
</MetaData>

🤦♂ Facepalm moment - read the docs. That worked, thanks for the pointer Bert.


ATA Update

In this page the link  last version of ATA (1.9.7576.49398) isn't available (error 404 not found)

Hi @nicogis, thanks for writing into docs about this! Please report a support ticket about this issue as it's not related to our docs on learn.microsoft.com.
Note that the mainstream support of Microsoft Advanced Threat Analytics (ATA) ended on January 12, 2021. Only extended support will be continued until January 13, 2026.
I'm going to close this issue for now, but feel free to open further issues if you have comments on the docs content.
#please-close


import default operator

It may be beyond the current proposal, but I've just received some feedback. (BG: dynamic-import is now implemented in WebKit nightly).
In the static import syntax. we have 3 forms: import * as namespace, import { named }, and import deafult.
On the other hand, the current dynamic-import proposal always resolves the result promise with the namespace object.
By using this object and existing ES syntax, we can write the code that is similar to the second named form.
const { named } = await import("...");

However, for the third case, we need to write a bit storage code like this.
const { default:map } = await import("../map.js");

or
const map = (await import("../map.js")).default;

In the static import syntax, we have the import default syntax separately while we can write the named import syntax like the following.
import {default as map} from "../map.js"

This default export/import mechanism encouraged modules to export the one representative default export and helped the developer to just use the default exported one instead of specifying the exported binding names.
So here, I would like to discuss about introducing the similar thing to the dynamic import. Like,
import default ("../map.js")

This was briefly discussed in committee and the feeling was that the additional complexity of having these compound contextual keywords was not worth the few characters saved.

@domenic
Personally I do not want to introduce it immediately in this proposal. (It means that I would like to introduce another draft for that if we think we should introduce it) So it is not in a hurry. :)
However, the above reason is not convicing to me. I do not think that the purpose of this import default is just saving the few characters,
It is essentially the same problem to import {default as map} from "../map.js". And is it introduced to just save the few characters?

In my opinion, yes, both are about saving characters. The difference is in the complexity. When you already have forms of the form import _____ from "specifier", adding a new value for ___ (i.e. default) is not a big deal. But there is no empty ____ in the import() form which we can fill in with various things, default being only one of them. Furthermore, there is no precedent for a function or function-like form that has a space in its name (like import default(x)).
My thinking is that import() is a low-level function for exposing the low-level primitive, the module namespace object. It isn't meant to be super-ergonomic; for that you want to just use normal import statements, which are designed for ergonomics.

Thanks so much!!

In my opinion, yes, both are about saving characters. The difference is in the complexity. When you already have forms of the form import _____ from "specifier", adding a new value for ___ (i.e. default) is not a big deal. But there is no empty ____ in the import() form which we can fill in with various things, default being only one of them.

Personally, I do not agree with this. ES provides the one special representative binding named default.
Right, it saves the few characters. But rather than that, it provides the "standard" way to expose the module: like, typically, we expose the XXX class with the default for the XXX.js file.
It sounds to me like the difference between constructor and function. We can write the function
that returns an object instead of using ES constructor form. But ES provides the one representative way to do that, constructors and new XXX form.
This "standard" way introduces a convention to the libraries. And we can construct an object in the library by using this standard way instead of bothering how to create the object in this library: some library may provide XXX.create method, and some library may provide XXX.new method.

Furthermore, there is no precedent for a function or function-like form that has a space in its name (like import default(x)).

Right. But fortunately, the both import and default are keywords. So I think it is much easier than the spaced contextual keywords.

My thinking is that import() is a low-level function for exposing the low-level primitive, the module namespace object. It isn't meant to be super-ergonomic; for that you want to just use normal import statements, which are designed for ergonomics.

But it is reasonable to me. If we think import() is a low-level function (like fetch in whatwg), I think the current one is reasonable. It exposes the namespace object, which contains all the bindings.
However it also raises the different question. Can we use this import()as a building block?
It is context sensitive operator. Thus we cannot wrap this import with the function. For example, we cannot create the function importDefault based on the current import() operator due to the referencingScriptOrModule.
Do we have a plan extending this import to take some referencingScriptOrModule information? (maybe, as a second argument)
And do we have a plan to expose the current running referencingScriptOrModule information to the JS? And even in that case, still we need to write the code like the following since referencingScriptOrModule is context sensitive.
await importDefault("../map.js", referencingScriptOrModule())

Plz do not laugh. There is a keyword which already semantically assume we are creating the object: "new"
In the context of synchronous call and parsing it should be about similar to "await"
const { default:map } = new import("../map.js");
To make it even more attractive, it is shimmable in case of the need to have runtime distinction between new import()' and import()`

However it also raises the different question. Can we use this import()as a building block?
It is context sensitive operator. Thus we cannot wrap this import with the function. For example, we cannot create the function importDefault based on the current import() operator due to the referencingScriptOrModule.

That's a great question. Note that you can still wrap it if you want, but not in a shared library. So e.g. at the top of your module you could do
function importDefault(x) {
  return import(x).then(ns => ns.default);
}

Do we have a plan extending this import to take some referencingScriptOrModule information? (maybe, as a second argument)

That would be an interesting idea worth exploring, IMO. Fortunately we've reserved the second argument so we can do that.

And do we have a plan to expose the current running referencingScriptOrModule information to the JS?

Yes, that's largely tracked as https://github.com/whatwg/html/issues/1013.
@sashafirsov I can't tell how what you're proposing is related to this thread.

That's a great question. Note that you can still wrap it if you want, but not in a shared library. So e.g. at the top of your module you could do

Yeah, but it's a bit unfortunate... but,

That would be an interesting idea worth exploring, IMO. Fortunately we've reserved the second argument so we can do that.

If we can do that thing, we can alleviate the situation. Like,
function importDefault(x) {
  return import(modifyBasedOnSomeScript(x), someScript).then(ns => ns.default);
}

Yes, that's largely tracked as whatwg/html#1013.

Great! I've just commented on that issue about the script in worker module script :)

Another issue is with tree shaking: contrary to import {onlyThis} from 'module, import(module) provides no information to optimizers about what part of the namespace is used.
Would it not be possible to add a second argument, like import(module, ['onlyThis']) -> {onlyThis: fn...} and maybe even import(module, 'onlyThis') -> fn...?

@wmertens no. See #19.
I'll close this issue as we don't plan on modifying this proposal in this way.


bin/mocha and bin/_mocha have no exe permission in 6.1.x

Prerequisites

[x] Checked that your issue hasn't already been filed by cross-referencing issues with the faq label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with: node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend that you not install Mocha globally.

Description

It seems the the files bin/mocha and bin/_mocha have no exe permissions in 6.1.0 and 6.1.1. If I do an npm install --no-bin-links and try ./node_modules/mocha/bin/_mocha (or mocha) I get Permission denied in linux.
At least in 6.0.2 these files had rwx permissions.
Steps to Reproduce

Linux environment needed
npm install --no-bin-links
./node_modules/mocha/bin/_mocha or
./node_modules/mocha/bin/mocha
Expected behavior: [What you expect to happen]
file is executable and actually node ./node_modules/mocha/bin/_mocha get's executed.
Actual behavior: [What actually happens]

File is not executable and therefore Permission denied happens.
Reproduces how often: [What percentage of the time does it reproduce?] 100%
Versions

The output of mocha --version and node node_modules/.bin/mocha --version: 6.1.1
The output of node --version: 10.15.3
Your operating system

name and version: Linux Ubuntu 18.04
architecture (32 or 64-bit): 64

Your shell (e.g., bash, zsh, PowerShell, cmd): bash
Your browser and version (if running browser tests): -
Any third-party Mocha-related modules (and their versions): -
Any code transpiler (e.g., TypeScript, CoffeeScript, Babel) being used (and its version): -

Additional Information

@juergba I think you might need to fix this on your side if you're going to be publishing.  I've re-published to work around the issue, but we need to ensure that the file modes are set properly when publishing from windows.
This is a Git issue.  When you cloned, it's likely the permissions for bin/mocha, bin/_mocha and lib/cli/cli.js were lost.  These URLs might help...

http://blog.lesc.se/2011/11/how-to-change-file-premissions-in-git.html
https://stackoverflow.com/questions/6476513/git-file-permissions-on-windows

Also, WSL or Git-for-Windows' cygwin thing might help?  not sure.

@Flarna This has been (temporarily) fixed in v6.1.2:

whoa 1985? wtf

whoa 1985? wtf

What are you talking about?

$ touch<PHONE_NUMBER>01 bin/mocha
$ touch<PHONE_NUMBER>55 bin/_mocha bin/options.js

The "npm" registry needs work...
We need to unpublish both mocha-6.1.0 and 6.1.1; don't need users downloading either of these.
Unpublishing must occur within 72 hours!
Further, mocha@next is somehow set to "6.0.2"

If using Windows, use this to prevent file permission changes to UN*X scripts:
C:> git config --local core.fileMode false

Thanks!

@juergba, note the npm issues!

Related:
https://github.com/npm/npm/issues/16645
IMO this is an npm issue that's never been fixed.

see also https://github.com/npm/node-tar/issues/210 which may be where the fix needs to live


Title for root hooks

Is your feature request related to a problem or a nice-to-have?? Please describe.
This feature request is opened to solve the reporter issue: https://github.com/travisjeffery/mocha-teamcity-reporter/issues/56
Describe the solution you'd like
I would like to have an optional ability to set a title for any root hook, like it can be done with normal hook:
export const mochaHooks = async () => {
  return {
    beforeEach('Before each root hook', () => {
      console.log(`Before each`);
    }),
    afterEach('After each root hook', () => {
      console.log(`After each`);
    }),
  };
};

Additional context
I'm trying to implement the ability to mute failed tests and hooks via TeamCity. TeamCity allows to mute tests to make build green. It works fine but only if we disable the following condition: one of build steps exited with an error (e.g non-zero exit code in command line runner):

If we do not disable it, build will be always treated as failed because mocha returns exit code > 0 if any test or hook was failed.
So we decided to switch it off. But we faced another issue - we will not be able to realize that any hook failed because it does not look as a test for TeamCity and exit code is ignored. The only way to see it is to check count of executed test. Not the best way actually. The main issue here is tests that are skipped by mocha because of hook failure. You can check mochajs/mocha#4392 issue for details
So we enabled recordHookFailures flag and faced issue https://github.com/travisjeffery/mocha-teamcity-reporter/issues/56 - a lot of tests appeared in each build.
My suggestion how to solve reporter issue - is to check root hooks title. But it required some additional development in mocha, because in current implementation there is no way to define root hooks titles.

If a hook is given a named function, that name will be used if no description is supplied.

Above suggestion doesn't work?

@juergba that's a great thing I missed! It works! Thank you so much.
export const mochaHooks = async () => {
  return {
    beforeEach: [
      function myRootBeforeEach() {
        console.log(`Before each global func`);
      }
    ],
    afterEach: [
      function myRootAfterEach() {
        console.log(`After each global hook`);
      },
    ]
  };
};

Log:
##teamcity[testSuiteStarted name='Login - Login page tests.' flowId='29560']
##teamcity[testStarted name='Test 1' captureStandardOutput='true' flowId='29560']
##teamcity[testStarted name='"before each" hook: myRootBeforeEach for "Test 1"' captureStandardOutput='true' flowId='29560']
Before each global func
Test 1 OK
##teamcity[testFinished name='Test 1' duration='0' flowId='29560']
##teamcity[testStarted name='"after each" hook: myRootAfterEach for "Test 1"' captureStandardOutput='true' flowId='29560']
After each global hook
##teamcity[testSuiteFinished name='Login - Login page tests.' duration='2' flowId='29560']

So suggestion above fixes my issue. But probably feature reqeust is still a good idea for the future.
No sure if I should close it or leave for the future.

Ok, we leave this issue open for some time.
Btw your solution should work without using arrays as well.

It's been some time, over 3.5 years. Closing. 🙂


Searching by User not working

Try searching by a known user in our system, and it won't come back on the search page.  I think it's related to the / appended to the search URL from the UI:

@codyseibert  I've fixed this, I will give a PR.

@mani-barathi i assigned you

#360


URLize does not remove "+", but returns "+".

(´・ω・｀) < tested with v0.16 and 0.17-DEV on Debian jessie

I think this is related to #2395

Thanks @thiagomgd, but it seems rather to be related to #1290 and this topic.
I'm just wondering why @spf13, who knows about Go templates' characteristic that converts "+" to "+" in the URLs context, has only merged #1966 …
Thank you anyway. <3

This issue has been automatically marked as stale because it has not been commented on for at least four months.
The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.
This issue will automatically be closed in four months if no further activity occurs. Thank you for all your contributions.

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.
If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.


chore: Update build system

Description of your changes

Update github workflows
Bump build submodule
Use Go 1.18

Fixes issues with failed pipelines.
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
CI

LGTM, thanks for tackling this


Replace ttf fonts with web fonts

https://github.com/src-d/sourced-ui/pull/106 introduced new fonts but they aren't optimized for web. We will need to improve it by using some more suitable format. For example woff2.

@smacker @ricardobaeta indeed, we have the web fonts available for our typefaces at our root > Product > Design > Brand Guidelines > Typefaces drive folders

@smacker @marnovo This commit on the source{d} branded superset UI PR solves this issue.


Issue saving mistral-7b-instruct-v0.3-bnb-4bit to GGUF

Issue during saving unsloth/mistral-7b-instruct-v0.3-bnb-4bit after training/saving, both in Kaggle and gguf-my-repo
I have tried converting uploaded LoRA and the merged version with gguf-my-repo and the push_to_hub_gguf built-in method.
# Saves successfully
tokenizer.push_to_hub(LORA_ONLY, private=True)
peft_model.push_to_hub(
    LORA_ONLY,
    tokenizer,
    save_method='lora',
)

# Saves successfully
tokenizer.push_to_hub(MERGED_MODEL, private=True)
peft_model.push_to_hub_merged(
    MERGED_MODEL,
    tokenizer,
)

%cd /tmp
tokenizer.push_to_hub(GGUF_MODEL, private=True)
# Error, Space issue, but there is also mention of vocab errors
# that I think is similar to errors encountered in gguf-my-repo
peft_model.push_to_hub_gguf(
        GGUF_MODEL, tokenizer,
        quantization_method = [
            'q4_k_m',
            'q5_k_m',
            'q6_k',
        ])

push_to_hub_gguf
/tmp

No files have been modified since last commit. Skipping to prevent empty commit.

Unsloth: Merging 4bit and LoRA weights to 16bit...
Unsloth: Will use up to 16.08 out of 31.36 RAM for saving.

100%|██████████| 32/32 [00:19<00:00,  1.62it/s]

Unsloth: Saving tokenizer... Done.
Unsloth: Saving model... This might take 5 minutes for Llama-7b...
Unsloth: Saving My_HF_Username/MistralInstruct-v0.3-FT-GGUF/pytorch_model-00001-of-00003.bin...
Unsloth: Saving My_HF_Username/MistralInstruct-v0.3-FT-GGUF/pytorch_model-00002-of-00003.bin...
Unsloth: Saving My_HF_Username/MistralInstruct-v0.3-FT-GGUF/pytorch_model-00003-of-00003.bin...
Done.
==((====))==  Unsloth: Conversion from QLoRA to GGUF information
   \\   /|    [0] Installing llama.cpp will take 3 minutes.
O^O/ \_/ \    [1] Converting HF to GGUF 16bits will take 3 minutes.
\        /    [2] Converting GGUF 16bits to ['q4_k_m', 'q6_k'] will take 10 minutes each.
 "-____-"     In total, you will have to wait at least 16 minutes.

Unsloth: [0] Installing llama.cpp. This will take 3 minutes...
Unsloth: [1] Converting model at My_HF_Username/MistralInstruct-v0.3-FT-GGUF into f16 GGUF format.
The output location will be /tmp/My_HF_Username/MistralInstruct-v0.3-FT-GGUF/unsloth.F16.gguf
This will take 3 minutes...
Traceback (most recent call last):
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 1524, in set_vocab
    self._set_vocab_sentencepiece()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 747, in _set_vocab_sentencepiece
    tokens, scores, toktypes = self._create_vocab_sentencepiece()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 764, in _create_vocab_sentencepiece
    raise FileNotFoundError(f"File not found: {tokenizer_path}")
FileNotFoundError: File not found: My_HF_Username/MistralInstruct-v0.3-FT-GGUF/tokenizer.model

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 1527, in set_vocab
    self._set_vocab_llama_hf()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 839, in _set_vocab_llama_hf
    vocab = gguf.LlamaHfVocab(self.dir_model)
  File "/tmp/llama.cpp/gguf-py/gguf/vocab.py", line 402, in __init__
    self.tokenizer = AutoTokenizer.from_pretrained(
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/auto/tokenization_auto.py", line 920, in from_pretrained
    return tokenizer_class.from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2213, in from_pretrained
    return cls._from_pretrained(
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2447, in _from_pretrained
    tokenizer = cls(*init_inputs, **init_kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama_fast.py", line 157, in __init__
    super().__init__(
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_fast.py", line 132, in __init__
    slow_tokenizer = self.slow_tokenizer_class(*args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 169, in __init__
    self.sp_model = self.get_spm_processor(kwargs.pop("from_slow", False))
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 199, in get_spm_processor
    with open(self.vocab_file, "rb") as f:
TypeError: expected str, bytes or os.PathLike object, not NoneType

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 4436, in <module>
    main()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 4430, in main
    model_instance.write()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 434, in write
    self.prepare_metadata(vocab_only=False)
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 427, in prepare_metadata
    self.set_vocab()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 1530, in set_vocab
    self._set_vocab_gpt2()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 683, in _set_vocab_gpt2
    tokens, toktypes, tokpre = self.get_vocab_base()
  File "/tmp/llama.cpp/convert_hf_to_gguf.py", line 511, in get_vocab_base
    tokenizer = AutoTokenizer.from_pretrained(self.dir_model)
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/auto/tokenization_auto.py", line 920, in from_pretrained
    return tokenizer_class.from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2213, in from_pretrained
    return cls._from_pretrained(
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2447, in _from_pretrained
    tokenizer = cls(*init_inputs, **init_kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama_fast.py", line 157, in __init__
    super().__init__(
  File "/opt/conda/lib/python3.10/site-packages/transformers/tokenization_utils_fast.py", line 132, in __init__
    slow_tokenizer = self.slow_tokenizer_class(*args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 169, in __init__
    self.sp_model = self.get_spm_processor(kwargs.pop("from_slow", False))
  File "/opt/conda/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 199, in get_spm_processor
    with open(self.vocab_file, "rb") as f:
TypeError: expected str, bytes or os.PathLike object, not NoneType
Something went wrong saving to GGUF…
Unsloth: Quantization failed for /tmp/My_HF_Username/MistralInstruct-v0.3-FT-GGUF/unsloth.F16.gguf
You are in a Kaggle environment, which might be the reason this is failing.
Kaggle only provides 20GB of disk space. Merging to 16bit for 7b models use 16GB of space.
This means using `model.{save_pretrained/push_to_hub}_merged` works, but
`model.{save_pretrained/push_to_hub}_gguf will use too much disk space.
I suggest you to save the 16bit model first, then use manual llama.cpp conversion.

With manually duplicated `config.json` from `adapter-config.json` based on this issue #421
GGUF-my-repo for LoRA
Error: Error converting to fp16: b'INFO:hf-to-gguf:Loading model: MistralInstruct-v0.3-FT\nTraceback (most recent call last):\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 4433, in \n main()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 4405, in main\n model_architecture = hparams["architectures"][0]\nKeyError: 'architectures'\n'

GGUF-my-repo for Merged
Error: Error converting to fp16: b'INFO:hf-to-gguf:Loading model: MistralInstruct-v0.3-FT-Merged\nINFO:gguf.gguf_writer:gguf: This GGUF file is for Little Endian only\nINFO:hf-to-gguf:Exporting model...\nINFO:hf-to-gguf:gguf: loading model weight map from 'pytorch_model.bin.index.json'\nINFO:hf-to-gguf:gguf: loading model part 'pytorch_model-00001-of-00003.bin'\nINFO:hf-to-gguf:token_embd.weight, torch.float16 --> F16, shape = {4096, 32768}\nINFO:hf-to-gguf:blk.0.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.0.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.0.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.0.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.0.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.0.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.0.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.0.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.0.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.1.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.1.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.1.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.1.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.1.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.1.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.1.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.1.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.1.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.2.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.2.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.2.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.2.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.2.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.2.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.2.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.2.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.2.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.3.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.3.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.3.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.3.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.3.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.3.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.3.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.3.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.3.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.4.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.4.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.4.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.4.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.4.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.4.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.4.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.4.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.4.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.5.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.5.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.5.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.5.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.5.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.5.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.5.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.5.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.5.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.6.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.6.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.6.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.6.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.6.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.6.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.6.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.6.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.6.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.7.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.7.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.7.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.7.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.7.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.7.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.7.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.7.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.7.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.8.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.8.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.8.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.8.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.8.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.8.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.8.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.8.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.8.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.9.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.9.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.9.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.9.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.9.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.9.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.9.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.9.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.9.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.10.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.10.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.10.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.10.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.10.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.10.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:gguf: loading model part 'pytorch_model-00002-of-00003.bin'\nINFO:hf-to-gguf:blk.10.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.10.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.10.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.11.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.11.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.11.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.11.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.11.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.11.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.11.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.11.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.11.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.12.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.12.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.12.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.12.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.12.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.12.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.12.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.12.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.12.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.13.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.13.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.13.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.13.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.13.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.13.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.13.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.13.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.13.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.14.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.14.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.14.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.14.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.14.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.14.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.14.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.14.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.14.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.15.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.15.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.15.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.15.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.15.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.15.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.15.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.15.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.15.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.16.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.16.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.16.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.16.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.16.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.16.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.16.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.16.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.16.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.17.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.17.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.17.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.17.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.17.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.17.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.17.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.17.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.17.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.18.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.18.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.18.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.18.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.18.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.18.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.18.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.18.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.18.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.19.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.19.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.19.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.19.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.19.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.19.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.19.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.19.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.19.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.20.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.20.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.20.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.20.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.20.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.20.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.20.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.20.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.20.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.21.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.21.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.21.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.21.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.21.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.21.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.21.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.21.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.21.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.22.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.22.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.22.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.22.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:gguf: loading model part 'pytorch_model-00003-of-00003.bin'\nINFO:hf-to-gguf:blk.22.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.22.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.22.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.22.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.22.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.23.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.23.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.23.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.23.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.23.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.23.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.23.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.23.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.23.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.24.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.24.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.24.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.24.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.24.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.24.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.24.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.24.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.24.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.25.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.25.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.25.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.25.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.25.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.25.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.25.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.25.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.25.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.26.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.26.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.26.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.26.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.26.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.26.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.26.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.26.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.26.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.27.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.27.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.27.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.27.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.27.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.27.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.27.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.27.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.27.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.28.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.28.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.28.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.28.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.28.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.28.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.28.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.28.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.28.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.29.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.29.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.29.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.29.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.29.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.29.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.29.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.29.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.29.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.30.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.30.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.30.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.30.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.30.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.30.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.30.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.30.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.30.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.31.attn_q.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.31.attn_k.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.31.attn_v.weight, torch.float16 --> F16, shape = {4096, 1024}\nINFO:hf-to-gguf:blk.31.attn_output.weight, torch.float16 --> F16, shape = {4096, 4096}\nINFO:hf-to-gguf:blk.31.ffn_gate.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.31.ffn_up.weight, torch.float16 --> F16, shape = {4096, 14336}\nINFO:hf-to-gguf:blk.31.ffn_down.weight, torch.float16 --> F16, shape = {14336, 4096}\nINFO:hf-to-gguf:blk.31.attn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:blk.31.ffn_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:output_norm.weight, torch.float16 --> F32, shape = {4096}\nINFO:hf-to-gguf:output.weight, torch.float16 --> F16, shape = {4096, 32768}\nINFO:hf-to-gguf:Set meta model\nINFO:hf-to-gguf:Set model parameters\nINFO:hf-to-gguf:gguf: context length = 32768\nINFO:hf-to-gguf:gguf: embedding length = 4096\nINFO:hf-to-gguf:gguf: feed forward length = 14336\nINFO:hf-to-gguf:gguf: head count = 32\nINFO:hf-to-gguf:gguf: key-value head count = 8\nINFO:hf-to-gguf:gguf: rope theta = 1000000.0\nINFO:hf-to-gguf:gguf: rms norm epsilon = 1e-05\nINFO:hf-to-gguf:gguf: file type = 1\nINFO:hf-to-gguf:Set model tokenizer\nTraceback (most recent call last):\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 1521, in set_vocab\n self._set_vocab_sentencepiece()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 744, in _set_vocab_sentencepiece\n tokens, scores, toktypes = self._create_vocab_sentencepiece()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 761, in _create_vocab_sentencepiece\n raise FileNotFoundError(f"File not found: {tokenizer_path}")\nFileNotFoundError: File not found: MistralInstruct-v0.3-FT-Merged/tokenizer.model\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 1524, in set_vocab\n self._set_vocab_llama_hf()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 836, in _set_vocab_llama_hf\n vocab = gguf.LlamaHfVocab(self.dir_model)\n File "/home/user/app/llama.cpp/gguf-py/gguf/vocab.py", line 402, in init\n self.tokenizer = AutoTokenizer.from_pretrained(\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/auto/tokenization_auto.py", line 907, in from_pretrained\n return tokenizer_class.from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2208, in from_pretrained\n return cls._from_pretrained(\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2442, in _from_pretrained\n tokenizer = cls(*init_inputs, **init_kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama_fast.py", line 157, in init\n super().init(\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_fast.py", line 132, in init\n slow_tokenizer = self.slow_tokenizer_class(*args, **kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 171, in init\n self.sp_model = self.get_spm_processor(kwargs.pop("from_slow", False))\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 201, in get_spm_processor\n with open(self.vocab_file, "rb") as f:\nTypeError: expected str, bytes or os.PathLike object, not NoneType\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 4433, in \n main()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 4427, in main\n model_instance.write()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 434, in write\n self.prepare_metadata(vocab_only=False)\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 427, in prepare_metadata\n self.set_vocab()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 1527, in set_vocab\n self._set_vocab_gpt2()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 680, in _set_vocab_gpt2\n tokens, toktypes, tokpre = self.get_vocab_base()\n File "/home/user/app/llama.cpp/convert_hf_to_gguf.py", line 511, in get_vocab_base\n tokenizer = AutoTokenizer.from_pretrained(self.dir_model)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/auto/tokenization_auto.py", line 907, in from_pretrained\n return tokenizer_class.from_pretrained(pretrained_model_name_or_path, *inputs, **kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2208, in from_pretrained\n return cls._from_pretrained(\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_base.py", line 2442, in _from_pretrained\n tokenizer = cls(*init_inputs, **init_kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama_fast.py", line 157, in init\n super().init(\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/tokenization_utils_fast.py", line 132, in init\n slow_tokenizer = self.slow_tokenizer_class(*args, **kwargs)\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 171, in init\n self.sp_model = self.get_spm_processor(kwargs.pop("from_slow", False))\n File "/home/user/.pyenv/versions/3.10.13/lib/python3.10/site-packages/transformers/models/llama/tokenization_llama.py", line 201, in get_spm_processor\n with open(self.vocab_file, "rb") as f:\nTypeError: expected str, bytes or os.PathLike object, not NoneType\n'

This is the same method I've been using for mistral-7b-instruct-v0.2-bnb-4bit, although I will try again to see if the issue is specifically in v0.3.

Do you get this error at all?
Unsloth: Merging 4bit and LoRA weights to 16bit...
Unsloth: Will use up to 23.73 out of 50.99 RAM for saving.
100%|██████████| 32/32 [00:19<00:00,  1.67it/s]
Unsloth: Saving tokenizer... Done.
Unsloth: Saving model... This might take 5 minutes for Llama-7b...
Done.
==((====))==  Unsloth: Conversion from QLoRA to GGUF information
\   /|    [0] Installing llama.cpp will take 3 minutes.
O^O/ _/ \    [1] Converting HF to GGUF 16bits will take 3 minutes.
\        /    [2] Converting GGUF 16bits to ['q8_0'] will take 10 minutes each.
"-____-"     In total, you will have to wait at least 16 minutes.
Unsloth: [0] Installing llama.cpp. This will take 3 minutes...
Unsloth: [1] Converting model at User/Model into q8_0 GGUF format.
The output location will be /content/unsloth.Q8_0.gguf
This will take 3 minutes...
TypeError                                 Traceback (most recent call last)
 in <cell line: 4>()
2 # Save to 8bit Q8_0
3 #if True: model.save_pretrained_gguf("UserAI.gguf", tokenizer,)
----> 4 if True: model.push_to_hub_gguf("Me", tokenizer, quantization_method="q8_0", token="Mine")
5
6 # Save to 16bit GGUF
4 frames
/usr/local/lib/python3.10/dist-packages/google/protobuf/descriptor.py in new(cls, name, package, options, serialized_options, serialized_pb, dependencies, public_dependencies, syntax, pool, create_key)
1022         name=None,
1023         full_name=None,
-> 1024         index=None,
1025         methods=None,
1026         options=None,
TypeError: Couldn't build proto file into descriptor pool!
Invalid proto descriptor for file "sentencepiece_model.proto":
sentencepiece_model.proto: A file with this name is already in the pool.

@Linguiniotta Kaggle sadly has limited disk space - the trick is to save LoRAs, then load it in Colab, then merge.
@CurtiusSimplus Oh yep I saw you opened a new issue

It merges successfully, but I cannot convert it to GGUF now, both v0.2 & v0.3  - with the builtin push_to_hub_gguf, though it used to work before. My last export to GGUF (q4_k_m, q5_k_m, q6_k) worked successfully with the builtin push_to_hub_gguf on October 12, 2024 ~12:16pm. My original environment in Kaggle is set to (2024-10-04). So probably a recent update messed with the push_to_hub_gguf function? Saving method is the same across different runs as shown in my original post.
With gguf-my-repo, I can successfully convert v0.2, but fails with v0.3, with the same error output as my main post.
Also is it possible to change the location of huggingface_tokenizers_cache/models--unsloth--mistral-7b-instruct-v0.3-bnb-4bit? I think this directory gets autogenerated during saving, by default in /kaggle/working. Is it possible to change it to /tmp as it has around 80~90GB disk space.

@Linguiniotta Wait is /tmp actually allowed to be used - if yes - I will gladly edit all notebooks to use it!!! (Maybe try doing cat and ls on a file inside of /tmp)

Yes, it is available to use for around ~90GB, that's where I had been storing it for saving XD. My session metrics previously showed 81.6GiB/57.6GiB.
I have not done it in this newer update of unsloth yet, but in my previous notebooks here is the result of the saved GGUF. To save space/time, and since the merged model gets saved locally anyway, I just move it to the destination expected by the GGUF conversion.
peft_model.push_to_hub_merged(
    MERGED_MODEL, # The temp path for the merged model
    tokenizer,
)

 Output
/tmp

Unsloth: You are pushing to hub, but you passed your HF username = My_HF_Username.
We shall truncate My_HF_Username/MistralInstruct-v0.2-FT-Merged to MistralInstruct-v0.2-FT-Merged
Unsloth: You have 2 CPUs. Using `safe_serialization` is 10x slower.
We shall switch to Pytorch saving, which will take 3 minutes and not 30 minutes.
To force `safe_serialization`, set it to `None` instead.
Unsloth: Kaggle/Colab has limited disk space. We need to delete the downloaded
model which will save 4-16GB of disk space, allowing you to save on Kaggle/Colab.
Unsloth: Will remove a cached repo with size 4.1G

Unsloth: Merging 4bit and LoRA weights to 16bit...
Unsloth: Will use up to 19.59 out of 31.36 RAM for saving.

  3%|▎         | 1/32 [00:00<00:03,  8.61it/s]We will save to Disk and not RAM now.
100%|██████████| 32/32 [00:45<00:00,  1.41s/it]

Unsloth: Saving tokenizer... Done.
Unsloth: Saving model... This might take 5 minutes for Llama-7b...
Unsloth: Saving MistralInstruct-v0.2-FT-Merged/pytorch_model-00001-of-00003.bin...
Unsloth: Saving MistralInstruct-v0.2-FT-Merged/pytorch_model-00002-of-00003.bin...
Unsloth: Saving MistralInstruct-v0.2-FT-Merged/pytorch_model-00003-of-00003.bin...

!mkdir -p /tmp/{GGUF_MODEL} && mv /tmp/{MERGED_MODEL}/* /tmp/{GGUF_MODEL}

Result after push_to_hub_gguf, older version

 du -ha /tmp/{GGUF_MODEL} | sort -h
4.0K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/config.json
4.0K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/generation_config.json
4.0K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/special_tokens_map.json
4.0K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/tokenizer_config.json
8.0K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/README.md
24K	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/pytorch_model.bin.index.json
3.4M	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/tokenizer.json
4.1G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/unsloth.Q4_K_M.gguf
4.3G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/pytorch_model-00003-of-00003.bin
4.7G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/pytorch_model-00001-of-00003.bin
4.7G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/pytorch_model-00002-of-00003.bin
4.8G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/unsloth.Q5_K_M.gguf
5.6G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/unsloth.Q6_K.gguf
14G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF/unsloth.F16.gguf
42G	/tmp/My_HF_Username/MistralInstruct-v0.2-FT-GGUF

Following the error in the latter parts, I think this check could be the culprit. #1201
Although, upon checking, there has been no changes for this line in around October it is possible the issue is not here?
https://github.com/unslothai/unsloth/blob/49ae6194122b594a7054da0bfd6f387cf720f40f/unsloth/save.py#L1110-L1118
https://github.com/unslothai/unsloth/blob/49ae6194122b594a7054da0bfd6f387cf720f40f/unsloth/save.py#L1158-L1166


Upgrade GitHub actions

Closes #373

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

CLA signed !

Any chance this can get approved and merged? GitHub has now started warning that the codeql action will be deprecated in December 2024
CodeQL Action v2 will be deprecated on December 5th, 2024


Better handling of exceptions

Make it so the try-catch over the calculator function prints different things depending on the type of error
for example showing a divide by 0 error if a division by 0 occurs.
do this by making different exception classes instead of just the general one and catching the new error classes in calculator.

Added with:
d958d713ae04bdf4c66e5a49056a652584414580 (Descriptions of each error)
d958d713ae04bdf4c66e5a49056a652584414580 (Fixed the invalid test which caused the above commit to fail)


add LNURL Auth to bitkit

Also need to make sure it generates a widget

LNURL Auth added as of this commit.


Integration Test - Release - 2022/01/07 07:03:43

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign PRMergerTest2

#reassign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#please-close

GitHub user PRMergerTest2 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign NonAllowedUser

#unassign PRMergerTest1


Import Error most likely due to a circular import

Installing worked fine using pip, but when importing mouette in a script, i do get the following error.
Exception has occurred: ImportError
cannot import name 'utils' from partially initialized module 'mouette' (most likely due to a circular import) (c:\Users\User\Documents\Mouette\.venv\lib\site-packages\mouette\__init__.py)

I do get the same error outside of a virtual enviroment both on windows and on ubuntu in a virtual machine

Hi,
Thanks for pointing this out ! It turns out I messed up the setup of subpackages. I uploaded a new version on Pypi and I am now able to run the library inside a virtual environment.
Guillaume

Hey,
thanks for the quick fix, now everything works as it should. Also thanks for your work with the project!


Missing ignore in bower.json

bower angular-inview#~1.5.6      invalid-meta angular-inview is missing "ignore" entry in bower.json

bower ppl should have fixed that


add  unit test

What type of PR is this?
/kind feature

What this PR does / why we need it:
Improve unit test coverage
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/assign @erikjiang

/lgtm

/lgtm

/approve


⚠ Bofrost.at has degraded performance

In 5be9062, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 957 ms

Resolved: Bofrost.at performance has improved in bf7c17c after 7 minutes.


$exists queries

MongoDB support query where we ask for presence of a field in a document. I think this would be good as a function, similar to inline javascript. The null value and existence of a field are two separate issues, so is_nil, won't be a good solution.
I'm thinking of something like this:
from u in User,
     where: exists(u.name)

I think this one could be supported by the fragment syntax for now. So I would close this in favor of #5. In the future, we can start adding those directly to Ecto, if more and more adapters need them.

As suggested closing in favour of #5 and fragments.


Increase gas to 30

Updating the gas from 1 gwei to 30 gwei in all the transactions
Update the hash and signed-raw-tx for those transactions

How is this tested to make sure it passes all the tests?

I had commented out this https://github.com/rlan35/harmony/blob/aaad61f6145f8985e0b5d111d439d03ed34f4e6f/node/node.go#L1033 , and created a custom image with the update harmony repo and tests in this PR.
The old transactions (without 30gwei) will result in failure -underpriced

Hey @harjas27 let's continue our discussion in public when possible. And I'll reply to your question here. let's enabled the the staking transaction test as well and make sure they can run successfully.

for the staking transactions, I am unable to send the signed tx.
This is my code snippet for generating one of the CreateValidator transaction:
stx = {
    "validatorAddress": "one109r0tns7av5sjew7a7fkekg4fs3pw0h76pp45e",
    "name": "test",
    "identity": "test0",
    "website": "test",
    "security-contact": "test",
    "details": "test",
    "rate": "0.1",
    "max-rate": "0.9",
    "max-change-rate": "0.05",
    "min-self-delegation":<PHONE_NUMBER>0000000000000,
    "max-total-delegation":<PHONE_NUMBER>0000000000000000,
    "bls-public-keys": ['0x4f41a37a3a8d0695dd6edcc58142c6b7d98e74da5c90e79b587b3b960b6a4f5e048e6d8b8a000d77a478d44cd640270c'],
    "nonce": "0x0",
    'directive': staking_structures.Directive.CreateValidator,
    "chainId": 2,
    "gasLimit": 21000,
    "gasPrice":<PHONE_NUMBER>0,
    "amount":<PHONE_NUMBER>0000000000000,
}
signed_raw_tx = staking_signing.sign_staking_transaction(stx, private_key = private_key)
print(tx_use, signed_raw_tx)

But when I send this using hmyv2_sendRawStakingTransaction, it returns :
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"rlp: expected input list for []bls.SerializedSignature, decoding into (types.CreateValidator).SlotKeySigs"}}

did you wait for epoch 2 when the staking epoch start ?
based on the error message, I wondered if the bls key was actually correctly being added into the signed tx.
When using the CLI, I need to specify the folder location of the bls key, ie if I am in the root folder of that github repo, I would create the validator with the below cli snippet
hmy --node="http://localhost:9598" staking create-validator --validator-addr one109r0tns7av5sjew7a7fkekg4fs3pw0h76pp45e --name "Harmony External Validator node" --identity Harmony  --website harmony.one --security-contact Harmony --details "Harmony External Validator node" --rate 0.1 --max-rate 1 --max-change-rate 0.05 --min-self-delegation 10000 --max-total-delegation<PHONE_NUMBER>0 --amount 10000 --bls-pubkeys  4f41a37a3a8d0695dd6edcc58142c6b7d98e74da5c90e79b587b3b960b6a4f5e048e6d8b8a000d77a478d44cd640270c  --bls-pubkeys-dir localnet/configs/

@harjas27 if that helped, last week I was helping with PR4100 and needed a stable external validator on localnet. We managed to have a stable elected validator by updating the block per epoch to 60 (now 10)

@sophoah the transactions have been updated with the new gas, but the test test_get_median_raw_stake_snapshot is still failing, working on that

@sophoah the gas fees is updated now. However the test test_get_median_raw_stake_snapshot is still failing.
The validator gets elected, in response of hmy_getSuperCommittees, I get :
{"bls-public-key":"4f41a37a3a8d0695dd6edcc58142c6b7d98e74da5c90e79b587b3b960b6a4f5e048e6d8b8a000d77a478d44cd640270c","earning-account":"one109r0tns7av5sjew7a7fkekg4fs3pw0h76pp45e","effective-stake":"10000000000000000000000.000000000000000000","is-harmony-slot":false,"raw-stake":"10000000000000000000000.000000000000000000","voting-power-%":"0.320000000000000002","voting-power-unnormalized":"1.000000000000000000"}

But for hmyv2_getMedianRawStakeSnapshot, it is:
{"jsonrpc":"2.0","id":1,"result":{"epos-median-stake":"0.000000000000000000","epos-slot-candidates":[],"epos-slot-winners":[],"max-external-slots":6}}

if the validator is seen elected in hmy_getSuperCommittees but hmyv2_getMedianRawStakeSnapshot doesn't return the correct data that might be a bug in the codebase used for the test, did you you pull the latest commit for that ? there was some test done on the localnet https://github.com/harmony-one/harmony/pull/4100 (done manually) not sure if new updates broke it or not.

I have tried with both - code before that PR was merged and latest, the test of failing in both cases

Hey, if that is the case, then it should be all good, the localnet validator election instability is a known issue. We need to increase the block per epoch from 10 to 60 to have it work stable. Can you do so and post here the end result? I'll work out separately the localnet number of blocks

for the staking transactions, I am unable to send the signed tx. This is my code snippet for generating one of the CreateValidator transaction:
stx = {
    "validatorAddress": "one109r0tns7av5sjew7a7fkekg4fs3pw0h76pp45e",
    "name": "test",
    "identity": "test0",
    "website": "test",
    "security-contact": "test",
    "details": "test",
    "rate": "0.1",
    "max-rate": "0.9",
    "max-change-rate": "0.05",
    "min-self-delegation":<PHONE_NUMBER>0000000000000,
    "max-total-delegation":<PHONE_NUMBER>0000000000000000,
    "bls-public-keys": ['0x4f41a37a3a8d0695dd6edcc58142c6b7d98e74da5c90e79b587b3b960b6a4f5e048e6d8b8a000d77a478d44cd640270c'],
    "nonce": "0x0",
    'directive': staking_structures.Directive.CreateValidator,
    "chainId": 2,
    "gasLimit": 21000,
    "gasPrice":<PHONE_NUMBER>0,
    "amount":<PHONE_NUMBER>0000000000000,
}
signed_raw_tx = staking_signing.sign_staking_transaction(stx, private_key = private_key)
print(tx_use, signed_raw_tx)

But when I send this using hmyv2_sendRawStakingTransaction, it returns :
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"rlp: expected input list for []bls.SerializedSignature, decoding into (types.CreateValidator).SlotKeySigs"}}

I think you've fixed this, but the branch validator-sigs on my pyhmy fork has this commit https://github.com/MaxMustermann2/pyhmy/commit/4f266619faa4924f64d4de4e48b919ee00e5f905 which should help you correct that, if still needed.

for the staking transactions, I am unable to send the signed tx. This is my code snippet for generating one of the CreateValidator transaction:
stx = {
    "validatorAddress": "one109r0tns7av5sjew7a7fkekg4fs3pw0h76pp45e",
    "name": "test",
    "identity": "test0",
    "website": "test",
    "security-contact": "test",
    "details": "test",
    "rate": "0.1",
    "max-rate": "0.9",
    "max-change-rate": "0.05",
    "min-self-delegation":<PHONE_NUMBER>0000000000000,
    "max-total-delegation":<PHONE_NUMBER>0000000000000000,
    "bls-public-keys": ['0x4f41a37a3a8d0695dd6edcc58142c6b7d98e74da5c90e79b587b3b960b6a4f5e048e6d8b8a000d77a478d44cd640270c'],
    "nonce": "0x0",
    'directive': staking_structures.Directive.CreateValidator,
    "chainId": 2,
    "gasLimit": 21000,
    "gasPrice":<PHONE_NUMBER>0,
    "amount":<PHONE_NUMBER>0000000000000,
}
signed_raw_tx = staking_signing.sign_staking_transaction(stx, private_key = private_key)
print(tx_use, signed_raw_tx)

But when I send this using hmyv2_sendRawStakingTransaction, it returns :
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"rlp: expected input list for []bls.SerializedSignature, decoding into (types.CreateValidator).SlotKeySigs"}}

I think you've fixed this, but the branch validator-sigs on my pyhmy fork has this commit MaxMustermann2/pyhmy@4f26661 which should help you correct that, if still needed.

yes I used the go-sdk to sign the validator txs

@sophoah Verified that all tests pass after updating the block per epoch to 60 in localnet config

@harjas27 can you paste the test logs here, then we should be able to merge that PR

hey @harjas27 thanks for your help


Unused type parameter should be indefered as {}

TypeScript Version:  2.2.2
Code
class Task<x, a> {
  execute:(succeed: (value: a) => void, fail: (error: x) => void) => number | void

  static fail <x, a> (error: x): Task<x, a> {
      return new Fail(error)
  }

  fork(succeed: (value: a) => void, fail: (error: x) => void) {
    this.execute(succeed, fail)
  }
}

class Fail<x, a> extends Task<x, a> {
  error:x
  constructor(error: x) {
    super()
    this.error = error
  }
  fork(succeed: (value: a) => void, fail: (error: x) => void) {
    fail(this.error)
  }
}

const task:Task<number, void> = Task.fail(4) // <- Type 'Task<number, {}>' is not assignable to type 'Task<number, void>'.

Expected behavior:
I would expect Task.fail(4) to be inferred as Task<number, *> where * type is open for further inference. In other words it should be able to satisfy Task<number, void> or Task<number, number> or whatever else maybe thrown at it.
It is also worth mentioning that same code type checks in flow as expected.
Actual behavior:
Unused type parameter is inferred as {} making causing a type checker to fail on commented line with a following error:

Type Task<number, {}> is not assignable to type Task<number, void>.
Type {} is not assignable to type void.

It also seems that problem persists even class does not use type parameter here is a refactored example:
// @flow

class Future<x, a> {
  constructor(private execute: (succeed: (value: a) => void, fail: (error: x) => void) => number | void) {

  }

  fork(succeed: (value: a) => void, fail: (error: x) => void) {
    this.execute(succeed, fail)
  }
}

class Fail<x>  {
  error:x
  constructor(error: x) {
    this.error = error
  }
  fork <a> (succeed: (value: a) => void, fail: (error: x) => void) {
    fail(this.error)
  }
}

const fail = <x, a> (error: x):Task<x, a> =>
  new Fail(error)

type Task<x, a> =
    | Fail<x>
    | Future<x, a>

const task:Task<number, void> = fail(4) // <- Type 'Task<number, {}>' is not assignable to type 'Task<number, void>'.

Which still has same error:

Type 'Task<number, {}>' is not assignable to type 'Task<number, void>'.
Type 'Future<number, {}>' is not assignable to type 'Task<number, void>'.
Type 'Future<number, {}>' is not assignable to type 'Future<number, void>'.
Type '{}' is not assignable to type 'void'.

But it type checks fine if following code if Fail is instantiated directly:
const task:Task<number, void> = new Fail(4)

Presumably that's due to a type parameter in the succeed function itself.

If a type parameter has no inference location (and no default), then inference gives it the upper bound which is {}. the type parameter is not open for further inference at that point.
if you would want that type parameter to match anything if not specified, consider adding a default to it as  fail <x, a = any> (error: x): Task<x, a>.
The problem here seems to be the same as https://github.com/Microsoft/TypeScript/issues/11152. the generic type is only referenced in return type position, which is currently not an inference position, https://github.com/Microsoft/TypeScript/issues/11152 tracks addressing that.

@mhegazy Thanks for the clarification.

if you would want that type parameter to match anything if not specified, consider adding a default to it as fail <x, a = any> (error: x): Task<x, a>.

It's more like I presume that if a has no effect on result it should be able to match anything rather than {} (any object ? or does it has some other meaning) in TS ?

The problem here seems to be the same as #11152. the generic type is only referenced in return type position, which is currently not an inference position, #11152 tracks addressing that.

Does that mean that once #11152 is fixed both examples would work as expected ? Or would using any still be required ?

It's more like I presume that if a has no effect on result it should be able to match anything rather than {} (any object ? or does it has some other meaning) in TS ?

The rational for this is that a type parameter with no inference location is suspect. setting it to any allows it to slip through unnoticed, where as the {} makes it fail on usage, forcing users to specify that explicitly or fix the declaration. you can specify any manually as a default if this is the intent. i think in your case it does make sense to set it to any.

Does that mean that once #11152 is fixed both examples would work as expected ? Or would using any still be required ?

#11152 does not change the general case, unmatched type parameters will still be {}; it should address some of the common cases where you have a contextual type that is today ignored, but with #11152 would be used and would contribute to inference.

Also is a = any a new feature not available in 2.2.2 ? I get a error TS1005: ',' expected., but it seems to work on the playground 😕

Also is a = any a new feature not available in 2.2.2 ? I get a error TS1005: ',' expected., but it seems to work on the playground 😕

Never mind I found answer to my question https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#generic-parameter-defaults


[MicroProfile Reactive Messaging 1.0 is now available] Blog Announcement

@cescoffier & @kenfinnigan,
MP reactive messaging 1.o available
MP forum thread is not enough, that added to the git issue here works great.
B/c of previews git issue by Ken this fun follow up exists.  This is your very first blog post, so can you prioritize your on-boarding?
Ken, you as the blog reviewer & editor need to ensure in future content publishing that the 2 items: author's pic and header  are in the post before publishing goes live.
Also Clement, your blog misses the step of git submission via this repo,  where you and Ken nicely owned it. :)
Sweet announcement, congratulations to everyone involved. !

@aeiras,
First, I've filled the bio and linked the gravatar account.
Also, I'm discovering the process. I'm surprised that @cealsair didn't mention having to post on this Git repo first (as Cesar asked me to write this post). Also, two days before, another MP release has been announced and I followed the same process.
BTW, @kenfinnigan was not the reviewer, @cealsair was.

Hey beautiful #usualsuspects @cescoffier,
All good, now you know the process and when in doubt, just do and on each iteration you and us will get better!
The coolest thing you did is finding someone who knew the topic to review it first. :) Kudos! you always rock on collaborating and limiting later debt-- that impresses me the most of awesome YOU!
Abrazos and see you soon- OC1, right? :) close ticket.

We had to fast track the posts :-)
Thank you for your support on this Clement.
On Fri, Jul 12, 2019 at 3:01 AM Clement Escoffier<EMAIL_ADDRESS>wrote:

@aeiras https://github.com/aeiras,
First, I've filled the bio and linked the gravatar account.
Also, I'm discovering the process. I'm surprised that @cealsair
https://github.com/cealsair didn't mention having to post on this Git
repo first (as Cesar asked me to write this post). Also, two days before,
another MP release has been announced and I followed the same process.
BTW, @kenfinnigan https://github.com/kenfinnigan was not the reviewer,
@cealsair https://github.com/cealsair was.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/microprofile-marketing/issues/137?email_source=notifications&email_token=AGB2SAV5M3ZOYIAR6DRIQA3P7AT3ZA5CNFSM4IBVYRM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZY4HCA#issuecomment-510772104,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGB2SAV5WPIDSHIHQCA2FPLP7AT3ZANCNFSM4IBVYRMQ
.

--
Cesar Saavedra
Senior Principal Technical Product Marketing Manager
<EMAIL_ADDRESS>(407) 492-9801

yes, i figured that was the case based on the form of the post MicroProfiler @cealsair!
Thats the reason I followed up via a new issue to make sure next iteration is easier for everyone involved :) cheers


Remove doc hidden from GenericColumnReader

Currently the lack of docs makes it hard to determine how to use ColumnReaderImpl - see here.
The decision was initially made to hide these docs to allow us to evolve the API, however, I think it makes sense to unhide this API because:

It should be relatively static now
As ColumnLevelDecoderImpl, etc... are still private, this change does not impact our ability to make breaking changes to them
We are making more frequent breaking releases than we were at the time this change was made

Codecov Report

Merging #2090 (707d472) into master (a6379fe) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2090      +/-   ##
==========================================
- Coverage   83.70%   83.70%   -0.01%
==========================================
  Files         224      224
  Lines       58967    58967
==========================================
- Hits        49360    49358       -2
- Misses       9607     9609       +2

Impacted Files
Coverage Δ

parquet/src/arrow/record_reader/mod.rs
89.17% <ø> (ø)

parquet/src/column/reader.rs
62.00% <ø> (ø)

arrow/src/datatypes/datatype.rs
64.05% <0.00%> (-0.36%)
:arrow_down:

parquet_derive/src/parquet_field.rs
65.75% <0.00%> (-0.23%)
:arrow_down:

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 a6379fe...707d472. Read the comment docs.


Does it support cocoapods v1.9.3?

no work
this is my podfile
plugin 'cocoapods-static-swift-framework'
use_frameworks!
all_binary!
platform :ios, '10.0'
target 'CocoapodsBinaryKit_Example' do
pod 'CocoapodsBinaryKit', :path => '../'
pod 'IQKeyboardManagerSwift',  :binary => true
pod 'Alamofire' ,  :binary => true
end

It seems that this plugin does not support binary.

It seems that this plugin does not support binary.


ROS2 Humble Updates

This PR is an attempt to bring the ROS2 forked work back into the main repo. As mentioned https://github.com/nobleo/rviz_satellite/issues/99 to get the ball rolling. :smile:
I attempted to do a rebase to get everything in sync from the great work from

https://github.com/blacksoul000/rviz_satellite
https://github.com/Kettenhoax/rviz_satellite

3.0.3 (2023-02-07)

Fix angles dependency Cmake issue for proper compiling
Update function to using updated due to deprecation

I wish I had better answers for some of your questions.
Here is proof this is up and running
https://user-images.githubusercontent.com/413937/219820140-b216e87d-28ba-4e12-9c80-22c4f49b569d.mp4

Great!
I'll give it a run on my system and merge if all checks out!

Thank you!


Workflow for tests not working

Workflow for tests is not working due to database issue.

Pull request #103


Any plan on providing other language version?

I would be very pleased if I can contribute to this project by translating it into Chinese version.

Chinese version +1

Chinese version +9999

I'd be willing to translate into Portuguese, I think there would be a lot of interest from Brazil specially!

I would like to contribute in translating it to Korean:)

And I would like to contribute in Persian

I would be happy to contribute and translate it into spanish :)

I will be also more than glad to help in the translation into Spanish!

I can help translating to brazillian portuguese if anyone still needs it.


SAPI speaking not working

SAPI is technically supported but it doesnt work - we can see the voices in the GUI but its not playing on the server end

client = SAPIClient('sapi') #SAPI
# Initialize the TTS engine
tts = SAPITTS(client)


Add new font: X in Boomer font

Let me work with this issue.

X is already done under #29 and #65


Publish intents flows

Summary

Scaffolds initial code for SEND_MESSAGE and ADD_MEMBERS intent publishing
Removes usage of ephemeral storage and uses a tempfile instead for everything. This way we get the same concurrency as real applications. The ephemeral store was always weird, since it needed a pool size of 1. Will remove entirely in a subsequent PR.
Scaffolds MlsGroup struct
Group initialization, including saving to the database
Adds some structs for serializing group intents to the database
Fixes an issue overwriting entries in the SqlKeyStore

Notes

I am using Protobuf to serialize the intent data. It's not the nicest for ergonomics, but it's a set of tools that we already have setup and it does allow us to make breaking schema changes and handle past versions without migrations. Also more performant/compact than JSON.
This needs a more robust set of e2e tests, but that's not so straightforward without the ability to properly read and parse messages from the network (which doesn't yet exist).

make sure to cargo fmt until we add that to CI

@insipx running that script gives me a bunch of errors. Our rust-toolchain.toml has us on the stable channel, which feels like the right channel for us. If some of the formatting rules require a nightly toolchain, I'd suggest we axe them.
Warning: can't set `wrap_comments = true`, unstable features are only available in nightly channel.
Warning: can't set `format_code_in_doc_comments = true`, unstable features are only available in nightly channel.
Warning: can't set `comment_width = 100`, unstable features are only available in nightly channel.
Warning: can't set `imports_granularity = Crate`, unstable features are only available in nightly channel.
Warning: can't set `group_imports = StdExternalCrate`, unstable features are only available in nightly channel.


LEAPP Artifacts to do

MyLink/Intellilink artifacts https://github.com/abrignoni/VLEAPP/issues/35 - provides sample data
Crosh artifacts in Chrome's OS Settings.json - see the issues of RLEAPP for an example data.
OS Preferences (non-priority preference): "OS Preference": [         {"preference": {             "name": "OobeMarketingOptInScreenFinished",             "value": "true" }},         {"preference": {             "name": "ash.filesapp.ui_prefs_migrated",             "value": "true" }},         {"preference": {             "name": "launcher.result_ever_launched",             "value": "true" }},         {"preference": {             "name": "settings.language.enabled_extension_imes_syncable",             "value": "\"\"" }},         {"preference": {             "name": "settings.restore_apps_and_pages",             "value": "2" }},         {"preference": {             "name": "settings.language.preferred_languages_syncable",             "value": "\"en-US,en\"" }},         {"preference": {             "name": "settings.multi_profile_never_show_intro",             "value": "true" }},         {"preference": {             "name": "OobeMarketingOptInChoice",             "value": "true" }},         {"preference": {             "name": "crostini.terminal_settings",             "value": "{\"/hterm/profile-ids\":[\"default\"],\"/nassh/profile-ids\":[\"62d6\",\"1821\"],\"/nassh/profiles/1821/argstr\":\"\",\"/nassh/profiles/1821/description\":\"admin@example.com\",\"/nassh/profiles/1821/hostname\":\"example.com\",\"/nassh/profiles/1821/identity\":\"\",\"/nassh/profiles/1821/nassh-options\":\"--help\",\"/nassh/profiles/1821/port\":null,\"/nassh/profiles/1821/terminal-profile\":\"default\",\"/nassh/profiles/1821/terminalSSHDialogCommand\":\"admin@example.com\",\"/nassh/profiles/1821/username\":\"admin\",\"/nassh/profiles/62d6/argstr\":\"\",\"/nassh/profiles/62d6/description\":\"beluga@thetechrobo.ca\",\"/nassh/profiles/62d6/hostname\":\"thetechrobo.ca\",\"/nassh/profiles/62d6/identity\":\"\",\"/nassh/profiles/62d6/nassh-options\":\"\",\"/nassh/profiles/62d6/port\":null,\"/nassh/profiles/62d6/terminal-profile\":\"default\",\"/nassh/profiles/62d6/terminalSSHDialogCommand\":\"beluga@thetechrobo.ca\",\"/nassh/profiles/62d6/username\":\"beluga\",\"/nassh/welcome/notes-version\":60,\"/nassh/welcome/show-count\":3}" }},         {"preference": {             "name": "settings.language.preload_engines_syncable",             "value": "\"xkb:us::eng\"" }}     ],     "OS Priority Preference": [         {"preference": {             "name": "shelf_default_pin_layout_rolls",             "value": "[\"default\"]" }},         {"preference": {             "name": "sync.os_demographics",             "value": "{\"gender\":1,\"birth_year\":1979}" }},         {"preference": {             "name": "intl.app_locale",             "value": "\"en-US\"" }},         {"preference": {             "name": "user_image_info",             "value": "{\"image_index\":-2}" }}     ],
Chrome Sync Settings,  multiple artifacts, see here. This has a variety of artifacts you need to do, like Web Apps, Apps, Extension/App Settings (for SS TV Remote in my case), and all kinds of settings from theme to priority to non-priority. Translate-related stuff should be their own artifacts, and content settings for disabling plugins or features should be their own as well, with keyboard shortcuts and extension lists.
Google Takeout Album Archives and Chrome Canvas: https://archive.org/download/takeout-20230802T040042Z-001/takeout-20230802T040042Z-001.zip

This project has nothing to do with the LEAPP projects, closing this comment.


How do we build the demo project?

The demo project doesn't seem to build.
#import <DTCoreText/DTCoreText.h> not found

The header search path includes $(SYMROOT)/../.. so that if you have the DTCoreText submodule present the headers can be found. Please make sure that you cloned the project recursively or loading all linked submodules before attempting to build it.

PS: I just tried it out, again. And the Demo App builds without problem.