Need Help Model Formatting For HelloLlamaLocal

I have been running into some errors early on in the RAG Chatbot example. I've been trying to execute the steps in a separate repo from the notebook one at a time to get through each step of the recipe. Here is the sequence I've attempted to so far:
hardware: Apple M3 Max Macbook, 128 GiB Memory

downloaded Llama2-70b from Meta.
ran 'convert_llama_weights_to_hf.py' script as advised in llama-recipes that I would need hugging face checkpoints for all demos and examples in the repo. conversion was successful.
in HelloLlamaLocal.ipynb, noticed that the 4th cell instructed to use llama.cpp to convert the model to gguf format, so attempted to do this with the model that I'd already converted to use huggingface checkpoints, and have been getting errors. Here is the cell from that notebook:
`python
Set up the Llama 2 model.

Replace <path-to-llama-gguf-file> with the path either to your downloaded quantized model file here,
or to the ggml-model-q4_0.gguf file built with the following commands:
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
python3 -m pip install -r requirements.txt
python convert.py <path_to_your_downloaded_llama-2-13b_model>
./quantize <path_to_your_downloaded_llama-2-13b_model>/ggml-model-f16.gguf <path_to_your_downloaded_llama-2-13b_model>/ggml-model-q4_0.gguf q4_0

For more info see https://python.langchain.com/docs/integrations/llms/llamacpp
I cloned llama.cpp and installed requirements and ran the following from the llama.cpp root: python convert.py --outfile llama2-70b.gguf --vocab-type hfft ../huggingface/llama2_70`
and received the following logs/stacktrace:
Loading model file ../huggingface/llama2_70/pytorch_model-00001-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00001-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00002-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00003-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00004-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00005-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00006-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00007-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00008-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00009-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00010-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00011-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00012-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00013-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00014-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00015-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00016-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00017-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00018-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00019-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00020-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00021-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00022-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00023-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00024-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00025-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00026-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00027-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00028-of-00029.bin
Loading model file ../huggingface/llama2_70/pytorch_model-00029-of-00029.bin
params = Params(n_vocab=32000, n_embd=8192, n_layer=80, n_ctx=2048, n_ff=28672, n_head=64, n_head_kv=8, n_experts=None, n_experts_used=None, f_norm_eps=1e-05, rope_scaling_type=None, f_rope_freq_base=10000.0, f_rope_scale=None, n_orig_ctx=None, rope_finetuned=None, ftype=None, path_model=PosixPath('../huggingface/llama2_70'))
Found vocab files: {'spm': PosixPath('../huggingface/llama2_70/tokenizer.model'), 'bpe': None, 'hfft': PosixPath('../huggingface/llama2_70/tokenizer.json')}
Loading vocab file PosixPath('../huggingface/llama2_70/tokenizer.json'), type 'hfft'
fname_tokenizer: ../huggingface/llama2_70
You set add_prefix_space. The tokenizer needs to be converted from the slow tokenizers
Vocab info: <HfVocab with 32000 base tokens and 0 added tokens>
Special vocab info: <SpecialVocab with 0 merges, special tokens {'bos': 1, 'eos': 2, 'unk': 0}, add special tokens {'bos': True, 'eos': False}>

result = futures.pop(0).result()
         ^^^^^^^^^^^^^^^^^^^^^^^

File "/Users//.pyenv/versions/3.12.2/lib/python3.12/concurrent/futures/_base.py", line 449, in result
return self.__get_result()
^^^^^^^^^^^^^^^^^^^
File "/Users//.pyenv/versions/3.12.2/lib/python3.12/concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
File "/Users//.pyenv/versions/3.12.2/lib/python3.12/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 1101, in do_item
tensor = lazy_tensor.load().to_ggml()
^^^^^^^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 649, in load
ret = self._load()
^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 659, in load
return self.load().astype(data_type)
^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 649, in load
ret = self._load()
^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 737, in load
return lazy_tensor.load().permute(n_head, n_head_kv)
^^^^^^^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 649, in load
ret = self._load()
^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 809, in load
return UnquantizedTensor(storage.load(storage_offset, elm_count).reshape(size))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users//code/llms/llama.cpp/convert.py", line 793, in load
fp = self.zip_file.open(info)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users//.pyenv/versions/3.12.2/lib/python3.12/zipfile/init.py", line 1643, in open
raise BadZipFile(f"Overlapped entries: {zinfo.orig_filename!r} (possible zip bomb)")
zipfile.BadZipFile: Overlapped entries: 'pytorch_model-00001-of-00029/data/11' (possible zip bomb)
I'm not trying to attack my own machine and I got these files 100% from Meta and converted them with code from this repo, guessing that this may be llama.cpp convert.py intended for me to use the model downloaded from Meta directly with the original checkpoints, but I wasn't sure because the overall README.md for this repo suggested as a first step converting my downloaded Llama2 model to use HF checkpoints.
If it is a documentation interpretation issue, that would be good to know and probably I'd raise that as an issue. if it is an issue with the way I'm attempting to convert this model to gguf format then I would really appreciate some assistance.
Thanks for making these open sourced and giving people like me a chance to get familiar with them, love the work you are doing!

Ok, going to close this because I think I'm asking in the wrong repo. So I don't think it was necessarily to do with my model checkpoints so much as my python version. I was using 3.12.2 given I'm on a new machine, and I think llama.cpp and the convert script specifically might have an issue with this because the zip utility in python may have new protections in it. that or the model file is vulnerable and the new core cPython is correctly protecting me if I weren't getting this file from a reputable source.
downgrading to 3.10.13 resolved my issue.

so I might have issues since I kept the Meta checkpoints in place. That part of the docs could actually be clearer. so keeping open just for that ambiguity to be addressed in this cell:
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
python3 -m pip install -r requirements.txt
python convert.py <path_to_your_downloaded_llama-2-13b_model> # is this model using HF checkpoints as described in the overall README.md?
./quantize <path_to_your_downloaded_llama-2-13b_model>/ggml-model-f16.gguf <path_to_your_downloaded_llama-2-13b_model>/ggml-model-q4_0.gguf q4_0

to test my theory that I needed hf checkpoints I converted the llama 13b model to .gguf format and attempted to use it with this notebook. this model had not been converted to huggingface checkpoints yet. I was able to instantiate the 'llm' object with LlamaCpp runner, but when I attempted to run the cell which performs inference I got a kernel failure. my virtualenv only has the dependencies that are loaded by this notebook and is on python 3.10.13. Will troubleshoot if this is the checkpoints or something about the environment by attempting to convert the original 70b model with HF checkpoints to gguf and use that instead.

I ran HelloLlamaLocal with llama2-70b, downloaded from Meta, converted to HF checkpoints, converted to gguf by llama.cpp and run with it. here are the inference metrics for an M3 Mac 128 GiB:
The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, generally referred to as The Innovator's Dilemma, first published in 1997, is the most well-known work of the Harvard professor and businessman Clayton Christensen. The book focuses on disruptive innovation and why industry-leading businesses can fail "by doing everything right." It is one of the most well-known business books ever written.
In his book, Christensen examines how successful businesses can lose their market leadership when confronted with disruptive technologies. He argues that good management and operational efficiency are not enough to guarantee success. Instead, companies must be willing to embrace new technologies and business models, even if they threaten their existing business.
Christensen's theory of disruptive innovation has been widely influential and has been applied to a variety of industries. It has also been criticized by some for being too simplistic and for not taking into account other factors that can contribute to a company's success or failure.
Despite its critics, The Innovator's Dilemma remains one of
llama_print_timings:        load time =  107660.07 ms
llama_print_timings:      sample time =      31.55 ms /   256 runs   (    0.12 ms per token,  8113.59 tokens per second)
llama_print_timings: prompt eval time =  227701.84 ms /    15 tokens (15180.12 ms per token,     0.07 tokens per second)
llama_print_timings:        eval time = 36132243.40 ms /   255 runs   (141695.07 ms per token,     0.01 tokens per second)
llama_print_timings:       total time = 36361330.68 ms /   270 tokens
This was very slow. I'm wondering if the issue has to do with the way I set up the model and all of those conversions or using the basic defaults from LLM CPP to run it, like I'm not taking advantage of all my hardware. I did some of the inference on battery and some with power supply. Was wondering if there were ways to do more detailed diagnostics on this. I was also thinking of trying ollama or other options and wondering if those would be successful. Thanks for any help!

As a test, I used ollama instead to pull the model from its registry and perform inference and this had results more aligned to my hardware, so I suspect I took a wrong turn somewhere between getting the model from Meta, converting its checkpoints and format and using this notebook to initialize it with LlamaCpp. I'm still curious about where I might have gone wrong, but also I have a workable solution now so I'm happy to close the issue as a one-off mistake on my end if others don't experience similar issues.

@nsubordin81 Thanks for all the updates. Running Llama2-70b locally with llama.cpp used to be at least slow (I haven't checked out their latest update). How fast were you able to run Llama 2 7b using Ollama?

so with Ollama + langchain I was able to get the following with a llama2 model, using a chain that retrieved embeddings from a vectorstore holding a single epub book (just did a simple time.time() before and after call to .invoke, did split() on the result string and manually divided):
num tokens in output = 395
total_time = 78.57125115394592
Tokens/Second = 5.027284079084729
by contrast, the setup I had with llama.cpp when I was trying to follow the local llama notebook as you can see above was more like the kind of thing where I had to get up and leave my machine eventually it was taking so long. I'd be curious just to know the core issue, though it may be hard to figure out from my metrics above without additional input.
Going back through the steps, trying to figure out where I could have diverged or whether my hardware and architecture require with the M3 Max special configuration that aren't called out  in the docs or I didn't see in any case. It def. feels like I wasn't taking advantage of the capabilities of the machine, but it did run so that just leaves me guessing for the most part.


Updated to Node-Wit 3.3.0 API

The current botkit-middleware-witai is incompatible with the current Wit api.

I made adjustment to follow the same style that botkit-middleware-witai was using which requires using intent entities.
Another iteration should probably be made towards this that tries to use the converse api but that can be another attempt imo.
If I updated anything wrong in the way not expected of howdy, I'm happy to change or just throw this away altogether.

Well I think this is deprecated too now based on API responses. I'm going to try to figure out how to do it another way to use the converse api...


Drouot connector update hidden fields

Instead of using the bid list, the connector now uses a dedicated hidden div to display the latest bid origin, bidder id and bid amount


Load date on client to avoid building page every night

Not doing. We build every night so we can do static site generation and optimize it for SEO, if we leave everything on the client we could not optimize SEO and page loads with static site generation.


[Event Request] CodeUnit 5988 Serv-Documents Mgt. "OnSetNoSeriesOnBeforeOnServDocMgt"

Can we please get the following event?
    procedure SetNoSeries(var PServHeader: Record "Service Header"): Boolean
    var
        NoSeriesMgt: Codeunit NoSeriesManagement;
        ModifyHeader: Boolean;
        IsHandled: Boolean;
    begin
        ModifyHeader := false;
        with ServHeader do begin
            if Ship and ("Shipping No." = '') then
                if ("Document Type" = "Document Type"::Order) or
                   (("Document Type" = "Document Type"::Invoice) and ServMgtSetup."Shipment on Invoice")
                then begin
                    TestField("Shipping No. Series");
                    "Shipping No." := NoSeriesMgt.GetNextNo("Shipping No. Series", "Posting Date", true);
                    ModifyHeader := true;
                end;

     //Event Request Begin
        IsHandled := false;
        OnSetNoSeriesOnBeforeOnServDocMgt(ServHeader, ServMgtSetup, Invoice, Consume, IsHandled);
        if not IsHandled then begin
   //Event Request End

                if IsHandled then begin
                    if Invoice and ("Posting No." = '') then begin
                    end;
                end;
                if ("No. Series" <> '') or ("Document Type" = "Document Type"::Order)
                then
                    TestField("Posting No. Series");
                if ("No. Series" <> "Posting No. Series") or ("Document Type" = "Document Type"::Order)
                then begin
                    "Posting No." := NoSeriesMgt.GetNextNo("Posting No. Series", "Posting Date", true);
                    ModifyHeader := true;
                end;

  //Event Request Begin
        end;
  //Event Request End

            OnBeforeModifyServiceDocNoSeries(ServHeader, PServHeader, ModifyHeader);
            Modify;

            if ModifyHeader then begin
                PServHeader."Shipping No." := "Shipping No.";
                PServHeader."Posting No." := "Posting No.";
            end;
        end;
        exit(ModifyHeader);
    end;

    [IntegrationEvent(false, false)]
    local procedure OnSetNoSeriesOnBeforeOnServDocMgt(var ServHeader: Record "Service Header"; var ServMgtSetup: Record "Service Mgt. Setup"; var Invoice: Boolean; var Consume: Boolean; var IsHandled: Boolean)
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Onboarding Request

Your Twitch username
mrrafael04

I checked and you removed yourself from the service. If you want to be onboarded you'll have to go through it again.


Slow synchronous socket communication

The current method for doing synchronous socket communication is rather slow.
To remedy this we can use a C extension for Node.js to do synchronous socket reads rather than our sync-socket method.

After some thought, I considered the two possibilities: (1) always sending event.preventDefault() and (2) the approach proposed above.
Both require hacks. The former requires faking input events and the latter complicates the build process greatly.
As of today, and given the information I have, I'd lean on (1).

Even if we do simulate fake input events, the input will still be unbearably slow, so I think we should very carefully consider. It is easier to make a build process robust than to improve the speed of a socket.

Closed by #43.


LICENSE file

Hello 🙂
Can you please add a LICENSE file to this repository?

Published in 1.1.1

Thank you! 🙂


Easy "ng build" improvements to make "platform":"server" work well on Windows & Visual Studio

I work on the ASP.NET team and am looking at changing the default Visual Studio ASP.NET + Angular templates to be based around Angular CLI. One thing that's stopping us right now is issues with publishing and deploying such Angular CLI apps.
Basically, for ng build to work well with Universal on Windows/VS, it's essential for it to have an option to produce self-contained builds, i.e., ones that don't rely you to deploy node_modules to your production server.
Why this is needed
Originally, the default official ASP.NET templates for Angular, which have server-side rendering on by default, expected developers to deploy node_modules to their production servers. This led to many, many issue reports, because it turns out that from Windows, people cannot deploy node_modules reliably. This isn't really developers fault. Two basic problems:

On Windows, path length limitations mean that MSBuild fails to publish deep nested folder structures, such as those that appear in node_modules.
Visual Studio's MSDeploy mechanism processes every file one-by-one quite slowly, so trying to deploy 20,000+ files from node_modules is a process that has you waiting for an hour and very frequently will fail with a network-related error eventually.

So in the default ASP.NET Core Angular template, we solved this by changing the default Webpack config not to treat node_modules as a Webpack external, causing Webpack to bundle all the server-side rendering dependencies into its single bundle output file. That output file is then large (4MB+) but that's OK: people can reliably deploy one 4MB file, as opposed to 20,000 tiny files. And it's only used server-side - this file is never sent to browsers.
Now we'd like to change the default Visual Studio ASP.NET templates for Angular to use Angular CLI, but we can only do this when the resulting projects can be published and deployed reliably. And that means a self-contained build option.
Fortunately, the implementation for this in Angular CLI is pretty much trivial - see below.
Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [x] feature request

Versions.
1.4.2
Repro steps.
If you run ng build to build an app configured with "platform":"server", then observe that the resulting dist directory's bundle files are not self-contained. That is, they only include the application's own code - they don't include the @angular code from NPM or any other required packages. The only way it can work at runtime is if you have node_modules on your production server, which causes great difficulty in practice as described above.
Desired functionality.
Ideally there would be an option for the "platform":"server" builds to be self-contained - i.e., can run without any node_modules, simply by not telling Webpack to treat those files as externals during the build. The use cases is to simplify publishing and deployment, especially on Windows/VS.
Mention any other details that might be useful.
This is pretty simple to implement. In server.ts from line 13, we see the Webpack config for externals used in server builds. All we need is a build option that disables this, i.e., leads to the externals array being left empty. Then Webpack will produce completely self-contained bundles that work correctly without node_modules being on the production server.
One minor complication is that, for some reason, Angular CLI tries to minify (via uglify) the server-side bundle in production, which leads to a build error with self-contained bundles. I recommend that server-side builds should not minify by default, because (1) that will fix the error, and (2) who wants to minify their server-side code anyway? It's much easier to understand/debug unminifed server-side code. If necessary this could be another option, but I really think it would be enough just to avoid minifying server builds altogether.

Hello @SteveSandersonMS,

And that means a self-contained build option.

Thank you for providing an actual use case for this option. When designing the Universal, we found a lot of problems with using a self-contained build (I'll explain in a bit), and couldn't possibly find reasons to provide an option for bundling up. So it was decided to remove the option entirely.
Adding the option itself is trivial (as you mentioned), but there is a large cost on the developer and you're turning your project into a minefield. You're basically painting yourself in a corner, for the following reasons:

every dependency used need to be the same within the bundle and outside of it. That means that if you are using RxJS in your backend and passing a reference to an Observable to your application, that Observable will not be compatible (unless you go the extra length to export RxJS from your bundle).
This also means that if you want to replace providers (which the platform-server provides), you wouldn't be able to do it outside the bundle anymore. A good example is replacing the Router code with something application specific (e.g. to redirect routes).
We do not provide you with server code (the express code itself). There are too many way to build a backend and we don't want to be a generic build tool for your server.
It's relatively trivial to create a webpack or rollup configuration that bundles your server code, once the application itself is built from the CLI.

Given all that, it was significantly dangerous for users for us to not allow self-contained builds. So we decided that there should simply not be an option. Remember that the CLI builds the application bundle, but it's up to the developer to bring their own server. As a result, we do not know how to bundle the backend code (we're not a generic build tool, after all), and I'd like you to consider point 4 above and add a rollup configuration to separate building and bundling the application into 2 separate steps.
That being said, if you know what your server is going to be, or if your server can be exclusively in main.server.ts (ie. just render as a string and returns it), then self-contained builds are possible. They're still not a great idea, but they can work.
Therefore, I'm personally okay with adding a flag that will build a fully bundled server application, with showing up a warning that the user needs to know what they're doing. This is something though that will need to be discussed internally with our relationship team, as it has a lot of impacts on usability of universal.
For frameworks like ASP.Net that do not run within NodeJS as part of the server, this might be good enough and help you move along.

@hansl - thanks for your feedback!
Yes, I totally understand that for Node-based application servers, it's preferable for bundles not to be self-contained, since developers have no choice but to deploy node_modules anyway, and might frequently try to reference their bundle from other Node modules. All the drawbacks you mention make sense in that case. I'm glad you also recognize the need to allow for self-contained bundles in other scenarios (e.g., main application server is not Node based, but instead just calls into the bundled code for prerendering), since without this, experience shows that Windows+VS devs will commonly be unable to deploy their apps to production successfully in practice.
What's the best way to proceed with this? Do you want me to send a PR? I'm very happy to do so if that would help. Or given that the key thing is more about designing how this should appear and be described in help text, is it something you'd prefer to do yourself?

FYI. I talked to the concerned parties and we decided internally that having an additional flag for this isn't a problem. It will only affect server applications, and default to false. Thinking of along the lines of --externals=none, with default --externals=node_modules. That way we can have other versions if need be (like angular_only) Still tinkering with the name, if you have any suggestions (naming is hard).

Great to hear it! The name externals for this option sounds ideal to me.
If it's possible for this to be configured in .angular-cli.json as well as being a command-line option that would be perfect, but at least having it as a command-line option would be enough.

@hansl can you please confirm if this option is still supported? Since 1.5.0 --bundle-dependencies=all  doesn't seem to work as reported here https://github.com/angular/angular-cli/issues/8616
ASP.Net team plans to ship the final version of Angular CLI based template in January, it would be really great if we could have this option working again. As mentioned by @SteveSandersonMS on Windows the path length limitations prevents MSBuild to publish deep nested folder structures, such as those that appear in node_modules directory. Currently this seems to be the only hurdle that could prevent .Net developers from using this template for large production apps that want to take advantage of SSR.
Thank you for the awesome work :)


What is the difference between ds and fsdp?

What is the difference between ds and fsdp?

I think the implementation of FSDP and Deepspeed is different.
For my own experience, fsdp enables zero-3 techniques but I failed to enable the cpu-offload technique. But the codebase using deepspeed can enable cpu-offload successfully with zero-2. But I failed to use zero-3 with deepspeed.
Generally, I recommend fsdp since its implementation is easy to understand. Deepspeed supports more complex techniques beyond data parallel. FSDP is a tool for data parallel only and I didn't try other techniques of fairscale currently.

BTW, deepspeed + zero-2 + cpu-offload may allow you to train large model on single GPU, which cannot be done using FSDP (I just cannot run it successfully by myself).

Thank you for your reply and detailed answers.
I also would like to ask if you could give me some suggestions when I just want to finetuning PLMs(e.g. BERT\T5\BART) in downstream tasks for research (Maybe using many models and many datasets).  Which one suits me better?

If you plan to use this template, I could give a brief introduction about how to use it (I didn't write the necessary readme).
The trainers between deepspeed and fsdp have no difference concerned with the other modules, e.g., the data processing or model. Training loop is decoupled with other modules through hydra, which can configure different components in the config file instead of hard coding for calling interface.
For different downstream tasks, what you should write by yourself are:

Data loading. Just ensure that the function specified by the read_tensor field in the config file should return a dataset overriding torch.utils.data.Dataset, since which is the input to dataloader. If you need a specific batch collator, just write it by yourself and specify it in the collator field.
Model. Any huggingface model is OK. You may refer to the interface I used in the examples to learn how to use the metrics.
Metrics if you need. Metric class defined as the class or simple calculated coupled in the model implementation are both OK. (I have just uploaded the examples of roberta and mt5 for your reference).

I also uploaded a example for data loading and corresponding config for your reference.

Thank you  !!!
I am going to learn and use your template. This is helpful for me.
Thank you again :)
Best wishes


Create a new release of JmxTrans

Lot of things have changed (hopefully for the better) but it's been a long time since we have a new release of JmxTrans. I think it is time for a new one.
I'd be happy to do it and to make sure it is published to Maven central, but would like to have the approval from @lookfirst.

Side note: I'd like to have an automated process for releases, based on pull requests. We could create a "release" branch and when a PR is approved for this branch, it would create the release and upload it to central. What do you think?

New release created. Release process streamlined (next one should be easier ...)


Bedrock Model API

Hi, does this library support the Amazon Bedrock API (for example, using Claude through Bedrock)?

Hi, we don't currently support the Amazon Bedrock API, though we'd gladly accept a PR adding an LM class for this.
Are there any sample code snippets invoking the bedrock API? in an ideal world, if the Bedrock API supported an OpenAI-like API, we could run it through the existing local-completions model type to minimize overheads in maintenance but this may not be possible.

Hi @haileyschoelkopf thanks for your response. The Bedrock API can be called through the bedrock-runtime client using boto3 SDK for Python. Here's an example:
import boto3

bedrock_runtime_client = boto3.client(service_name="bedrock-runtime")

enclosed_prompt = "Human: " + prompt + "\n\nAssistant:"

body = {
	"prompt": enclosed_prompt,
	"max_tokens_to_sample": 200,
	"temperature": 0.5,
	"stop_sequences": ["\n\nHuman:"],
}

response = bedrock_runtime_client.invoke_model(
	modelId="anthropic.claude-v2:1", body=json.dumps(body)
)

response_body = json.loads(response["body"].read())
completion = response_body["completion"]

Docs: https://docs.aws.amazon.com/code-library/latest/ug/python_3_bedrock-runtime_code_examples.html

Thanks @austinmw ! Would you have any bandwidth / interest in contributing this?


Mix ephemeral-static DH output into MAC keys for v2

Also mix in index into MAC nonce.

Coverage increased (+7.1%) to 93.313% when pulling<PHONE_NUMBER>fa0510a6afc4f3fd9fc177c886c28a on akalin/mac-v2 into 9059405deaaeb6450145da80e2eb8c60c1ba3ccb on master.

This PR kinda sprawled a bit, so I might try to break it up. But interested in whether I'm on the right track, and if you have any strong opinions about any of the refactorings.

Coverage increased (+7.1%) to 93.313% when pulling 9d8c381aa2d0ffd332e9d1a6f42f410a0b9a74f7 on akalin/mac-v2 into 9059405deaaeb6450145da80e2eb8c60c1ba3ccb on master.

Coverage decreased (-6.2%) to 80.0% when pulling c9e9dbc6bbcd1a7838b023aae79a298a66dc69d0 on akalin/mac-v2 into 9059405deaaeb6450145da80e2eb8c60c1ba3ccb on master.

Coverage increased (+0.4%) to 86.58% when pulling df89cb841b2ca65ffd6b6a5815c9eea32590c0fc on akalin/mac-v2 into 9059405deaaeb6450145da80e2eb8c60c1ba3ccb on master.

Thanks Fred! Will get to this this afternoon.

Coverage increased (+0.4%) to 86.58% when pulling 1d48b0816fc582c71eac7cfe1548c77b7a933ab4 on akalin/mac-v2 into a5352c4421c37856db346939ff6d267af0bcaea3 on master.

Coverage increased (+0.4%) to 86.58% when pulling 4f4f8b96047933d347894a010beeff5f4934ac62 on akalin/mac-v2 into a5352c4421c37856db346939ff6d267af0bcaea3 on master.

Okay, this is ready for review again!

Coverage increased (+0.4%) to 86.233% when pulling c52678a37ee5b8c2878c3079ecc505e63cdfa838 on akalin/mac-v2 into 078e7361b6d07e62d6420b72444b7d726fdccea8 on master.

Coverage increased (+0.5%) to 86.273% when pulling b83e501ee25ff6012d067039a06c1c9316b82d05 on akalin/mac-v2 into 078e7361b6d07e62d6420b72444b7d726fdccea8 on master.

PTAL!

Coverage increased (+0.5%) to 86.296% when pulling 7ddf4e7c73b7aa7c2ec86ce4b998c35bfaa8988f on akalin/mac-v2 into 288a46109dd6f059520d65742b8709d445b1acfd on master.

Coverage increased (+0.5%) to 86.296% when pulling 7ddf4e7c73b7aa7c2ec86ce4b998c35bfaa8988f on akalin/mac-v2 into 288a46109dd6f059520d65742b8709d445b1acfd on master.


Use JTSKit/json-table-schema-py instead of typecast

I think it is better to use the type casting of JTSKit rather than the new typecast lib.
Why?

Better support for JTS Spec (eg: types and formats)
Much more likely to get updated and stay in sync with spec: We are trying to keep https://github.com/okfn/json-table-schema-py and https://github.com/okfn/json-table-schema-js at feature parity and in line with spec changes

I guess it's your call since this lib exists on the okfn org, but I do intend to support as much of the JTS spec in typecast as appears reasonable.
To be honest, the exact purpose and development path of jtskit have really confused me, which is why I didn't want to base any software on it. It seems to me to be a mix of JTS reference functions and half an implementation of messytables. I've also found that it doesn't work under Python 2, crashing with ASCII errors upon infer.

@pudo can you open an issue for any bugs you have found with jtskit (or have you done so already)? They should definitely get fixed.

Yep, https://github.com/okfn/json-table-schema-py/issues/19

@pudo I know you have a penchant for rolling your own, but, why not help us get JTSKit in better shape rather than starting a new one?
I don't see the relationship to messytables - IMHO messytables is a real kitchen sink library that does lots of different things, and this is one of the reasons why a standalone json table schema lib exists - explicitly not to be tied to the rest of messytables.

Some clarification: I need typecast for jsonmapping, which does not use JTS (instead JSON Schema), and I'm hoping that it will be adopted by messytables so that the lib becomes less of a kitchen sink.
I really think that type casting is a piece of functionality that makes sense as a package, since it requires a good bit of complexity to get right (the code in typecast, which comes from messytables, has matured for four years now and there's still plenty to do).
There are other steps that should be taken to make messytables better, but let's discuss those in the other issue tracker. Still, given that messytables is a mature library which is adopted across OKFN's and other products, I would propose we don't give up on it easily and instead make it rock in the context of the JTS suite of tools!

Sure, as you suggested here, we can probably depend on typecast for parts of the JTS typecasting in JTSKit. But, because we'll always be following the JTS spec, and particularly the interplay between type + format there, then there remains a clear and string usecase for "JTS-specific typecasting", in a way that probably should be in messytables anyway, as far as I see. For the moment, what is called "JTS" in messytables barely reflects the current JTS spec.

Also @pudo if you have issues with the JTSKit API, please do open issues for them: bugs and design issues alike. Thanks.

@pwalsh + @pudo one possibility is that messytables "v2" fully supports JTS. In that case messytables v2 would be "JTS infer" and we could depend on that.
Also for this current library (jts-sql) I think we could assume that typecasting has happened - we have the JTS already (?). In that case all we need is to use JTS + CSV to load into SQL. The question of how the JTS is generated can come from any of several JTS inference libraries (and we can work out asap which one to focus on). PS: I think i will try and create a diagram showing the various library parts and post in https://discuss.okfn.org/c/open-knowledge-labs/data-packages

+1 on messytables v2

OK, here's the diagram and post: https://discuss.okfn.org/t/data-package-libraries-overview/957 - next thing to add is a list of the various implementations and how they fit together.

Closing in favour of https://github.com/okfn/jsontableschema-sql-py/issues/7
Also see https://github.com/okfn/jsontableschema-sql-py/issues/3#issuecomment-166253429


Merge pull request #2 from mattpker/master

Merge from parent repository. Version 0.3.3

Wrong pull request. Sorry, my failure. Closing


quest Helper not showing up in plugin list

the quest helper plugin stopped working suddenly. I cant see it on the runelite side task bar. any help

Ditto.
I assume it's new patch related. 100% the plugin I'm most reliant on, without even being aware.

Ditto

Same here

It's back in the list now.
@jeraziah @Fre4ked @McSheehy @neprulers

Yes it is back i can see it now. This plugin is very helpful


Can't login after logging out by other user

Laravel Version: 5.6.39
PHP Version: 7.2
Database Driver & Version: Mysql 5.7.24

Description:
Lets assume we are using session driver for you auth guard, we have two users user 1 and user 2. If you have logged in by user 1 and then logged out, you won't be able to log in from same device (without clearing session cookie) at once, you will only be able to do that after second try.
Steps To Reproduce:

Set auth guard driver to session
Log in by user 1
Log out
Try to log in by user 2

Reason
When you are using session driver, after logging in password_hash key will be added to current, which will have hashed value of current user's password (from DB), as per https://github.com/laravel/framework/issues/16311.
But after logging out that item won't be removed from session, so when you are trying to login by another user, the new user's id will be putted in session and when after it \Illuminate\Session\Middleware\AuthenticateSession middleware will be called, after some if-else chain, user will be logged out cause password_hash attribute will not match current user's (user 2) hashed password.
After logging out user, given middleware will flush the session, after which you will be able to log in (from a second try).
Solution
Remove password_hash attribute from session after logout

I encountered something similar, and debugging, I found out that the password_hash remained on the session after logout.
To fix this, I manually remove the password_hash on logout.
Session::remove('password_hash');
It's not super fancy, but it's something

Hello. I can confirm this is still an existing issue in 5.7.28 as of 28-aug-2017, just under the wire for security fixes, according to the support policy :) Only if the AuthenticateSession middleware is active (uncommented), log in as user 1, log out, log in as user 2, get the authentication exception thrown. Similar to @juampi92 , my attempted fix was to use Session::flush() in the auth login controller logout action, which seemed to fix things. I'm going to try their more surgical solution, too, just to give it a whirl, but will probably simply comment AuthenticateSession back out... But I'm glad I'm not the only one who was encountering this situation


Update docstring

Signed-off-by: Jael Gu<EMAIL_ADDRESS>

Codecov Report

Merging #723 (eb386f0) into main (4b924be) will decrease coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head eb386f0 differs from pull request most recent head 074359e. Consider uploading reports for the commit 074359e to get more accurate results

@@            Coverage Diff             @@
##             main     #723      +/-   ##
==========================================
- Coverage   72.40%   72.39%   -0.02%
==========================================
  Files         168      168
  Lines        7303     7303
  Branches     1144     1144
==========================================
- Hits         5288     5287       -1
- Misses       1676     1678       +2
+ Partials      339      338       -1

Impacted Files
Coverage Δ

towhee/trainer/modelcard.py
65.51% <ø> (ø)

towhee/trainer/utils/layer_freezer.py
86.79% <ø> (ø)

towhee/hub/repo_manager.py
80.18% <0.00%> (-0.91%)
: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 4b924be...074359e. Read the comment docs.


Add new ru_ru localization

Thanks!

I'll try to make it better when I see it in the game.

The web book is updated now: https://hexcasting.hexxy.media/v/latest/main/ru_ru/

@object-Object Is that my translation or someone else's?

This needs serious improvements, I am working on it right now.


bump cloudformation version: 65 -> 132

also migrate dev env to haskell.nix

Do you know when this might be merged into the master branch?

currently CI timeout when compile and build and test(maybe due to the new cf version added too many. resources)
if you don't need the binary cache and require the new version what you can try is import dhall directly in this branch
e.g.
let Fn = https://raw.githubusercontent.com/jcouyang/dhall-aws-cloudformation/cfv130/Fn.dhall


openssl: updated a patch for Darwin

@peti
Fixed the patch failed to apply to OpenSSL 1.0.1p. That prevented bootstrapping from staging branch on Darwin platform. FYI, the patch removes -arch x86_64.
#10269 may relate to this.
Tested on OS X 10.11, staging branch.

I haven't noticed this and pushed 4ba34e705.


how to use distributed tensor2tensor

Hi, I am a newbie for distributed tensorflow. I followed the instruction here
https://github.com/tensorflow/tensor2tensor/blob/master/tensor2tensor/docs/distributed_training.md
I created the TF_CONFIG, But, I don't know how to use it  during the training in commanline or anyother way.
could you give me some advice or some document instructions.

Sure, I'll add an example invocation to the doc.

Should be more clear now. Please take a read.

And please upgrade to 1.0.8


Question: Why session does not exist right after creating?

Operating system: Windows 10
language version: Python 3.8
Cortex version: 'v2.2.0-636-gaf1ff8f

I have developed a simple code in Python to connect to Emotiv EPOC+ with free BCI API license, which executes the following steps:

ec.testConnection()
ec.requestAccess()
ec.generateToken()
ec.connectedHeadset()
ec.controlHeadset()
ec.openSession()
 ec.subscribe()

The problem is that I can open and activate a new session, but as soon as I want to subscribe to the session, I get the The session does not exist error. Anyone has experienced the same issue?

Hi @jracp
If the method createSession is successful then you should be able to subscribe.
Can you show me the JSON request and response for createSession and subscribe ?
Maybe some parameter is wrong.

Also, if you are using Cortex v2.2 and no v1, then you should post on this forum:
https://github.com/Emotiv/cortex-v2-example/issues
Thanks :)

Hi @jracp
If the method createSession is successful then you should be able to subscribe.
Can you show me the JSON request and response for createSession and subscribe ?
Maybe some parameter is wrong.

Thank you for your reply. I found out that the websocket object was closed for some reason right after creating a session so the subscribe was not going through. Fixed the problem with websocket object and everything is working fine now.

Also, if you are using Cortex v2.2 and no v1, then you should post on this forum:
https://github.com/Emotiv/cortex-v2-example/issues
Thanks :)

Sorry for posting the issue in the wrong place. Will do for future issues.


[SPARK-9558][DOCS]Update docs to follow the increase of memory defaults.

Now the memory defaults of master and slave in Standalone mode and History Server is 1g, not 512m. So let's update docs.

Merged build triggered.

LGTM

Merged build started.

Test build #39547 has started for   PR 7896 at commit a77626c.

Test build #39547 has finished for   PR 7896 at commit a77626c.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Thanks - merging this in.


MethodFilter respects distinct=True, closes #367

I ran tests, this is the output:
(venv)user@host:~/workspace/django-filter$ python runtests.py
Creating test database for alias 'default'...
.......ssss...s..x.ss..x..x.....................................u....................xx...................................u.......x............................s.............x.................s........................sss........................................
----------------------------------------------------------------------
Ran 259 tests in 0.832s

OK (skipped=12, expected failures=7, unexpected successes=2)
Destroying test database for alias 'default'...

I'm not inclined to have this. If you want it just add the distinct call to your method. (If you want it conditionally, just use the if self.distinct check.)

Ok, maybe you are right, but i still think that it would be more helpful if we can see which fields have distinct and which fields don't, from the serializer body which we define our fields on it. So now i need to scroll down to see which method fields have distinct. The actual problem was that.


Windows: Remove TP4 support from test code

Signed-off-by: John Howard<EMAIL_ADDRESS>Removes the TP4 hacks from test code (both unit and integration-cli). Bumps some comments to TP5 where platform support still doesn't exist, such as testing read-only volumes.

LGTM

Failing validate-vet. Fixing...

Fixed. @icecrime

lots of C:/busybox/busybox.exe not found failures in TP5, think that's a known issue, so restarting

LGTM 🐸

@thaJeztah

lots of C:/busybox/busybox.exe not found failures in TP5, think that's a known issue, so restarting

Is this tracked and being worked on? Thanks!

@icecrime Yes - highest priority bug internally right now. We don't yet have a fix.

@jhowardmsft Thanks for the info, no pressure!

There's a problem with one of the enabled tests. Need to fix. Don't merge yet.

LGTM

re-LGTM :wink:


Error when Adding Baseline Images The following configuration option is invalid:   - testFiles

Hello,
I'm fairly new to using Cypress and coding so go easy on me... I'm trying to get Visual Regression working, and I am at the point of adding baseline images but getting this error about the testFile part of adding baseline images command. I see this is due to being on a higher version of Cypress but I'm unsure what to replace on that command to get it going.

Hi, this is more of a cypress problem and shouldn't have to do with this plugin.
Nonetheless, let me try and help:

In words: in your screen shot, on the second line, I can see that the command contains the testFiles option as part of the --config flag. Just remove it, or replace it with specPattern :)

Thanks for the reply! I have tried that and get this error message.

I see I was missing the = after specPattern, working now! Thank you for your help!


True and False  interpretion

How true and false is  interpreted by python.

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.

@Sarvesh-yadav Please tick all the checkboxes to let us know that you've gone over them.

@Sarvesh-yadav Please fill out the checkboxes next time

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Add updater script for xorg.* packages

xorg.* packages use https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/x11/xorg/generate-expr-from-tarballs.pl to generate about 200 packages based on https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/x11/xorg/tarballs.list tarball list.
There are a few problems with it:

It's tedious to update these packages: need to change the file, fetch 200 tarballs from internet to generate one hash
The autogeneration script injects questionable and outdated things like hardeningDisable = [ "bindnow" "relro" ];. I don't think it's relevant for most packages (or any at all).
It uses custom builder.sh we probably don't need any more.
It has massive overrides file
Most packages have no maintainer assigned. Probably because it's not as easy to plug yourself in via overrides.

I suggest moving packages out of xorg.* one by one until xorg.* disappears.
I suggest at least adding an updater that can handle there packages via $ nix-shell maintainers/scripts/update.nix  --argstr package $p. That way r-ryantm (or lazy me) can update packages at least individually.

Not sure about moving the packages out of xorg.* but I support having one combined and not auto generated nix file.

The autogeneration script injects questionable and outdated things like hardeningDisable = [ "bindnow" "relro" ];. I don't think it's relevant for most packages (or any at all).

personally i like the autogeneration script

The autogeneration script injects questionable and outdated things like hardeningDisable = [ "bindnow" "relro" ];. I don't think it's relevant for most packages (or any at all).

https://github.com/nixos/nixpkgs/commit/27b9f5d65ee452c9a1a49a2e245b2a45ee1d65ab

Breaks the module system at runtime otherwise.

The autogeneration script injects questionable and outdated things like hardeningDisable = [ "bindnow" "relro" ];. I don't think it's relevant for most packages (or any at all).

personally i like the autogeneration script

If we are to keep it it would be nice to have an update script for its packages. It looks like our existing scripts assume 1-to-1 mapping of .nix<->package.

The autogeneration script injects questionable and outdated things like hardeningDisable = [ "bindnow" "relro" ];. I don't think it's relevant for most packages (or any at all).

27b9f5d

Breaks the module system at runtime otherwise.

Do you know the details of it? What module system is it talking about: Mesa's, Xorg's or something else? I would like to poke at the details to narrow it down to really affected programs.
The only time I saw problems with any of that is non-inline IFUNC resolvers: https://bugs.gentoo.org/788625#c9. Anything else has a high chance of being a genuine bug.
I don't see any reason to apply it to, say, xorg.xset.

Reworded the issue to be less ambitious.
I personally just want these packages not lag too much behind as I keep getting into bugs that were already fixed upstream.
We can sort out minor things later.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/why-is-it-that-nixpkgs-freshness-isnt-closer-to-its-maximum/25168/11

https://github.com/NixOS/nixpkgs/pull/262669 will close this

It's tedious to update these packages

Yeah, but how often do you need to do this? Most of the packages have not changed substantially in 20 years.

The autogeneration script injects questionable and outdated things li
It uses custom builder.sh we probably don't need any more.

Then update the script, I guess.

It has massive overrides file

So does haskellPackages, why do you think this is a problem?

Most packages have no maintainer assigned

Because, again, most of the X.org software have not changed in ages: there's not much to maintain...

It's tedious to update these packages

Yeah, but how often do you need to do this?

git log says I did it 19 times. None of them was as simple as running nix-update. I think none of those should be as tedious. If we look at the past history for the last year it was updated 46 times:
$ git log --oneline --no-merges --since='last year' tarballs.list | wc -l
46

That makes updates weekly on average.
I find the visual view of tarballs.list history a good indicator of typical maintenance churn: https://github.com/NixOS/nixpkgs/commits/master/pkgs/servers/x11/xorg/tarballs.list
Those xorg.* commits brought nixpkgs staleness back on track.
And for completeness the release frequency of a mailing list at a glance (as nixpkgs used to lag for quite a while behind upstream):

4 releases on October: https://lists.x.org/archives/xorg/2023-October/thread.html
4 releases in September: https://lists.x.org/archives/xorg/2023-September/thread.html
3 releases in August: https://lists.x.org/archives/xorg/2023-August/thread.html
...

Most of the packages have not changed substantially in 20 years.

I would say the important detail here is if the packages were changed/released or not.
I would not judge the "substance" of the change in the software over so long periods of time. Many things came and went over that time. Especially on a set of 200 packages.

It has massive overrides file

So does haskellPackages

I would prefer not to drag into discussion a massive package ecosystem with a dedicated set of maintainers.

why do you think this is a problem?

It spreads a package definition over multiple files. in xorg's case it has at least 3 files: tarballs.list, default.nix and overrides.nix. Each of them is prone to conflicts. Existing tooling does not know how to update it automatically.

Most packages have no maintainer assigned

Because, again, most of the X.org software have not changed in ages: there's not much to maintain...

You might want to look at the history of a tarballs.list file to see the amount of churn it experiences: https://github.com/NixOS/nixpkgs/commits/master/pkgs/servers/x11/xorg/tarballs.list

If we look at the past history for the last year it was updated 46 times:

It's not that much considering it contains more than 200 packages. I didn't make a histogram, but it looks like most of the updates are coming from a few actively developed libraries.
Wouldn't it be easier to split out those on a needs basis?

It spreads a package definition over multiple files
Existing tooling does not know how to update it automatically.

Agreed, but again, only a few of these packages requires overrides and/or frequent updates.

If we look at the past history for the last year it was updated 46 times:

It's not that much considering it contains more than 200 packages.

Or you could look at it as nobody wants to update them until it looks too bad. For example these 3 commits updated ~200 packages:

90 libs and apps: https://github.com/NixOS/nixpkgs/commit/5a450bdd9f3d5f79b5a95c5c0905509516bd7ab7
73 fonts: https://github.com/NixOS/nixpkgs/commit/3c176486ef173b050edcb44b71048be888873c33
106 apps: https://github.com/NixOS/nixpkgs/commit/528afff1f95bf82c4e3d4f24a8f740500c9bdebf

But that's my point: right now it's easy to update all of them at once and there's not much checking to do because the X.org fonts and apps are almost never changed.

There are two orthogonal issues being discussed here: having a generation script and implementing an updater script.
It should be possible to write a script that updates tarballs.list and runs generate-expr-from-tarballs.pl, if the generation script is kept. AFAIU, there is no such script right now and one has to manually check whether any of the packages needs an update?
I do think the generation script as it is right now is not optimal. I just went through the process of updating xorg-server (#263689). For even a single update, the script needs to download all the tarballs, which is pointless IMO.

the X.org fonts and apps are almost never changed.

This is actually a reason for moving them out of the generation script. If they are never updated, why go through the process of downloading their tarballs and generating the nix expression every time.

AFAIU, there is no such script right now and one has to manually check whether any of the packages needs an update?

There was a (partially working) update script that I used in https://github.com/NixOS/nixpkgs/pull/241012
https://gist.github.com/NickCao/fa592237f768c32ff26688d99b20f81f

Ah nice. Maybe we can add this as a passthru.updateScript?

Still has to be modified to work with individual packages, and polish some rough edges.

Yeah it works for me with some changes. Doesn't look like there are any updates apart from xorg-server :)

Still has to be modified to work with individual packages

Right. I think the simplest things to do for now would be to add this script alongside generate-expr-from-tarballs.pl so atleast there'd be a way to check for updates without having to manually go through tarballs.list. @NickCao would you have a chance to do this anytime soon?
Next step could be to add support for individual packages, although generate-expr-from-tarballs.pl will still need to run for all. We can wait to see if #262669 gets merged.

Added a simplified script (based on @NickCao's) to update all xorg packages together at #293704.
It uses the perl script which regenerates all expressions even if only 1 package is updated. Next step could be to put the package expression in default.nix in separate  files so that they can be generated independently.


There are thumbs up / thumbs down reactions available when Cody provides a response to a smell prompt

see https://github.com/sourcegraph/jetbrains/issues/104


Implement site for "instansi"

Create a site mimic "pelayanan" for "instansi"
showing address, google map, operational hours just like "lokasi"
and services they offer

done


Modify School - very buggy

The fields go off focus as soon as you enter a letter.
There's no validation
Mandatory fields need to be marked.

The fields go off focus as soon as you enter a letter issue resolved.

Validation added to schools.
Mandatory fields are marked.


Adding spectator.earth

Hi! Great list! Just adding another one.

Thank you for this PR.
Is the app in a state where it can be used? I tried to set-up a channel as well as track the satellites in real-time. Both failed with current versions of Chrome and Firefox (or I am clicking the wrong buttons). I don't see what it would add to the current set of tools.

Yes, although it's in beta so some bugs still to be cleaned. There's been an issue with one of the satellites which caused your problems. Fixed now, thanks to your feedback 👏 .
Regarding adding to the list, seems like most of the tools have a common denominator and Spectator adds tracking Sentinels and overpass computation and soon much more. If I misunderstood the idea for this list, please feel free to decline the PR.

Sorry for the late reply, I am swamped at work right now.
Now that I am able to create the channels I can see the appeal of this tool. Being able to get the overpass times for an AOI is indeed very cool!
Do you estimate the overpass times from the data provided by the satellite ground stations or are you using some kind of API provided?

Wow, took me only two months to discover your question ;)
We're actually relying on multiple sources for overpass estimation, observations made by ground stations being the core for all satellites. For better estimation we use additional data but that largely depends on which satellite we're talking about. Obviously for Sentinels we get plenty of information, so we can get pretty good estimates.


Add GitHub actions workflow

Pull Request Test Coverage Report for Build 363414462

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.0%

Totals

Change from base Build 31:
0.0%

Covered Lines:
97

Relevant Lines:
100

💛  - Coveralls


gnome3.gnome-keyring: CAP_IPC_LOCK gnome-keyring-daemon

From gkd-capability.c:

This program needs the CAP_IPC_LOCK posix capability.
We want to allow either setuid root or file system based capabilies
to work. If file system based capabilities, this is a no-op unless
the root user is running the program. In that case we just drop
capabilities down to IPC_LOCK. If we are setuid root, then change to the
invoking user retaining just the IPC_LOCK capability. The application
is aborted if for any reason we are unable to drop privileges.

Motivation for this change
Seen the warning
insufficient process capabilities, insecure memory might get used

for the last time when debugging :smile:
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I've tested this and I no longer see the aforementioned warnings at runtime.


fix: refactored notifications to correctly display pr and diff on but…

…tons

Description
Please provide a summary of the change and the issue fixed. Please include relevant context. List dependency changes.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist

[ ] I have read the CONTRIBUTING doc
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have already been accepted and merged

Further comments

Thanks for the PR!
Deployments, as required, will be available below:

Frontend
Backend

Please create PRs in draft mode.  Mark as ready to enable:

Analysis Workflow

After merge, new images are deployed in:

Merge Workflow

merge will now correctly notify with pr#...
There is a case where a pull request may come in without a PR number, not sure how that is possible as its an attribute of the pr event.  More iterations needed.


store command for sqlite not working, timeout?

Server side:
[16:36] - <IP_ADDRESS>:44288 -- [HUMGSK] POST //v6.1/CodeCheckerService
[16:36] - <IP_ADDRESS>:44298 -- [HUMGSK] POST //v6.1/CodeCheckerService
[ERROR] [16:36] - File ID for ***/abc.h is not found in the DB with content hash 0832d7b9619e0962dab86fc5020ca7dd2192be2de3cbecc0237e1725088aefd. Missing from ZIP?
[ERROR] [16:36] - File ID for ***/abc2.h is not found in the DB with content hash 71f645179ab1489c158b83cf4f858155af582ff4d52be3ec21e7def5aa0de7bf. Missing from ZIP?
[ERROR] [16:36] - File ID for ***/abc3.h is not found in the DB with content hash 003f934b263873ace48bef1c08ac2ce0eb9b69f7242346454066f1a3aeee4f5b. Missing from ZIP?
[ERROR] [16:36] - File ID for ***/abc4.h is not found in the DB with content hash 13b66efeaae02bc30bbe2c0019bcb4e320047d6d2b5f77e68ad5a678cd5cad29. Missing from ZIP?
[ERROR] [16:36] - File ID for ***/abc5.h is not found in the DB with content hash 8d250e32277774dbd8e8bc09e6f4b3ee28626ac3650e00f00a7cc79c582952c4. Missing from ZIP?
[ERROR] [16:36] - File ID for ***/abc6.h is not found in the DB with content hash acc9b97eb153ae155347258f6b50f0e96abc83e16daf9416b191d28a2318287b. Missing from ZIP?
[16:36] - Session timeout for run 1
Exception in thread Thread-16:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 1073, in run
self.function(*self.args, **self.kwargs)
File "/usr/local/src/codechecker/build/CodeChecker/lib/python2.7/libcodechecker/server/api/report_server.py", line 389, in _timeout_sessions
self.abort_session(run_id)
File "/usr/local/src/codechecker/build/CodeChecker/lib/python2.7/libcodechecker/server/api/report_server.py", line 361, in abort_session
transaction.rollback()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 828, in rollback
self.transaction.rollback()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 482, in rollback
transaction._rollback_impl()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 512, in _rollback_impl
t[1].rollback()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1563, in rollback
self._do_rollback()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1601, in _do_rollback
self.connection._rollback_impl()
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 670, in _rollback_impl
self._handle_dbapi_exception(e, None, None, None, None)
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception
exc_info
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", line 203, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 668, in _rollback_impl
self.engine.dialect.do_rollback(self.connection)
File "/usr/local/src/codechecker/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 420, in do_rollback
dbapi_connection.rollback()
ProgrammingError: (sqlite3.ProgrammingError) SQLite objects created in a thread can only be used in that same thread.The object was created in thread id<PHONE_NUMBER>67648 and this is thread id<PHONE_NUMBER>08160
Client, store command:
API call error: massStoreRun
RequestFailed(errorCode=2, _message='RequestFailed(errorCode=2, _message="'NoneType' object has no attribute 'filepath'")')
[16:36] - Storage failed: RequestFailed(errorCode=2, _message='RequestFailed(errorCode=2, _message="'NoneType' object has no attribute 'filepath'")')

@mbodmer sorry for replying just now, but do you still have this problem?

I think this is no longer a problem. Please try out our latest CodeChecker and if you still have this kind of problem please feel free to reopen this issue.


fix: add select sidebar flatten

Contributes to #1618
reworks the sidebar to use the carbon Accordion to display selected items and adds a utility function to flatten the list of items to make nested items easily searchable.

@matthewgallo updated the base AddSelect component to require required props in the items array

@matthewgallo also updated the sidebar string issue


CI: Store RPMs by SHA

Store RPMs in object storage based on their SHA rather than the Jenkins
build ID. This allows tests to be re-run without repeating the mock
build step.
Signed-off-by: Major Hayden<EMAIL_ADDRESS>

Download issues again on F31, but that's unrelated to this PR. Merging.


Operator pod - priority class and resources

hey guys,
please feel free to correct me if I am wrong.
I dont see how we could specify the priority class and resources for the operator pod, it must survive during a peak demand event and not get killed due to running as Besteffort.
I must admin that my deployment is not via helm so none of my pods have resources specified but the operator is a special case, right?

This is gonna be fixed by https://github.com/metallb/metallb-operator/pull/239

closing as this is done


reportFile should allow TypeScript tests

Is this a bug report? No
I'm using CRA with TypeScript and followed the docs to integrate typescript.
My problem is that npm run build does not fail when there is a TypeScript error in the tests. I noticed that the webpack.config.js ignores errors in test files. See the reportFiles array. It would be awesome to report TypeScript errors in test files too so that a team can know if a change caused a TypeScript error in a test.
Alternatively, npm test should report TypeScript errors.

Closing as dupe of #5626.


Add date i18n to Grav Core

Hello there,
I am a french developer who is trying Grav CMS to replace Wordpress projects.
From now I can do whatever I want and I am pretty happy with Grav, there is just one point on date internationalization.
I can assure you this is a very important problem for foreign users.
From the Grav manual, there is an explanation on the problem and fixes for it :
https://learn.getgrav.org/16/cookbook/twig-recipes#displaying-a-translated-month
From my point of view this fixes are not correct :

you should not have to install a plugin for i18n of dates
the 2 solutions are not using server locales nor date formats from configuration
in configuration override_locale is useless

An another problem is date format i18n : you could have different date format depending on localization.
Possible solutions :
1. use strftime for date formatting instead of DateTime format :
Install and set teraone/twig-strftime-extension in Grav
By default strftime format is localized, so replace Twig date filter by strftime filter do the job.
strftime format is very different of date format so this is a problem on backward compatibility.
2. use PHP Intl in core :
Like the plugin https://github.com/Perlkonig/grav-plugin-twig-extensions
Integrate Intl to Grav and create a Twig filter like localizeddate() based on datetime object (like actual Twig date) and without the need to specify the locale (it should take the default locale or the current locale if override_locale is set).
Date format i18n
This is a less critical problem, it can be solve by using languages.yaml in your theme, specifying date formats for each languages, and get date format in Twig :
t('MY_THEM.DATEFORMAT.LONG')
A better approach should be to create a Twig function to return date format for any language (if override_locale is set in configuration) or the default date formats.
The current list of date formats in Admin plugin could be completed.

i agree with these points, having to work on many multilang websites with grav.
In the meantime, i am using the localizeddate extension too to make things work like this:
{{ "now"|localizeddate('long', 'none', grav.language.getActive()) }}

Thanks for your message, after looking at Intl functions, I think using it is the correct solution, because it can handle datetime formats too (so adding it will allow backward compatibility with configuration date formats).
IntlDateFormatter formats are i18n, so it solve date formats i18n too.
I am thinking of a rewrite of localizeddate filter with less parameters :
localizeddate( $format, $pattern=null )
$format could be :

'config_default', 'config_short', 'config_long' (date formats of configuration)
'none', 'short', 'medium', 'long', 'full' (IntlDateFormatter formats)
null (for pattern specific)

set $pattern like 'mm/dd/yyy'
the locale would be automatically set depending on override_locale
It could be interesting to rewrite localizednumber and localizedcurrency from the same plugin and add them to Grav Core too.

yea if we are to integrate something like that into core we would make the parameters a bit cleaner imo

ok so i spoke to andy for the go ahead and i will begin to integrate it into Grav core

It would be advantageous to do this with a thought to fallbacks, ie. only load a third-party library if the Intl-extension is missing, and further fall back to the generic date-parser if the third-party library is not installed.
Two especially well-developed and -maintained libraries for this are Carbon and Date, where the latter extends the format and possibilities of the former. It would also be beneficial to focus on localizeddate, as suggested, but also create some thin wrappers in Twig for similar functionality - like localized formats for time ago, parse by locality, time differences, various getters, etc.


client_name parameter to allow applications to identify themselves

As requested by @egrefen

 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.

I'll let @mkozakov have a look rather than merge myself.


interpreters/python: Add Python's port to NuttX

Summary
Say Hello to Python!
This is the NuttX's port of Python (CPython)!
Initial support of Python includes building the Python's static library and the python (Programs/python.c) application. Python's modules are stored in pyc (byte-code file) and loaded as needed from flash.
Considerations
Please note that this is the initial port of one of the most used programming languages for NuttX (and, maybe, for embedded RTOSes). There is a long list of To-Do to make it fully functional. NuttX is perhaps one of the best embedded RTOSes for working with Python due to its POSIX Compatibility and on-demand paging (https://nuttx.apache.org/docs/latest/components/paging.html#ondemandpaging). I hope this PR engages NuttX community to keep improving Python for use in embedded applications with NuttX.
Please consider that:

This PR aims to make it work with rv-virt (RISC-V QEMU). That being said, its interpreters/python/config.site and interpreters/python/Setup.local are somehow tied with the features enabled by the attached defconfig (Yes, I will submit a PR on https://github.com/apache/nuttx for it)
The "To-Do" list includes, for instance, generating these files dynamically depending on what features are enabled.
This initial implementation uses Make-based build system. Contributions for CMake are welcomed!
The pyc modules are loaded from a ROMFS image at startup. Therefore, we need an application to mount it (that's the mount_modules role!).
Also, the user needs to set PYTHONHOME and PYTHON_BASIC_REPL environment variables.
The "To-Do" list should include a wrapper application that 1) mounts the modules, 2) set the env vars and 3) runs main python application.

Impact
Provides initial support for Python on NuttX. Please note that it supports, initially, only the rv-virt (RISC-V QEMU) "board".
Testing
Internal CI testing + rv-virt:cpython.
Building
Create a defconfig file at nuttx/boards/risc-v/qemu-rv/rv-virt/configs/cpython/defconfig with the following content:
#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the installed .config file.
# You can then do "make savedefconfig" to generate a new defconfig file that includes your
# modifications.
#
# CONFIG_DISABLE_OS_API is not set
# CONFIG_NSH_DISABLE_LOSMART is not set
CONFIG_16550_ADDRWIDTH=0
CONFIG_16550_UART0=y
CONFIG_16550_UART0_BASE=0x10000000
CONFIG_16550_UART0_CLOCK=3686400
CONFIG_16550_UART0_IRQ=37
CONFIG_16550_UART0_SERIAL_CONSOLE=y
CONFIG_16550_UART=y
CONFIG_ARCH="risc-v"
CONFIG_ARCH_BOARD="rv-virt"
CONFIG_ARCH_BOARD_QEMU_RV_VIRT=y
CONFIG_ARCH_CHIP="qemu-rv"
CONFIG_ARCH_CHIP_QEMU_RV32=y
CONFIG_ARCH_CHIP_QEMU_RV=y
CONFIG_ARCH_CHIP_QEMU_RV_ISA_A=y
CONFIG_ARCH_CHIP_QEMU_RV_ISA_C=y
CONFIG_ARCH_CHIP_QEMU_RV_ISA_M=y
CONFIG_ARCH_FLOAT_H=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_RISCV=y
CONFIG_ARCH_STACKDUMP=y
CONFIG_BOARDCTL_POWEROFF=y
CONFIG_BOARDCTL_ROMDISK=y
CONFIG_BOARD_LOOPSPERMSEC=6366
CONFIG_BUILTIN=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_FULLOPT=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEV_URANDOM=y
CONFIG_DEV_ZERO=y
CONFIG_ELF=y
CONFIG_EVENT_FD=y
CONFIG_EXAMPLES_HELLO=y
CONFIG_FRAME_POINTER=y
CONFIG_FS_HOSTFS=y
CONFIG_FS_PROCFS=y
CONFIG_FS_ROMFS=y
CONFIG_FS_TMPFS=y
CONFIG_IDLETHREAD_STACKSIZE=4096
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INIT_STACKSIZE=4096
CONFIG_INTERPRETER_CPYTHON=y
CONFIG_LIBC_ENVPATH=y
CONFIG_LIBC_EXECFUNCS=y
CONFIG_LIBC_LOCALE=y
CONFIG_LIBC_LOCALE_GETTEXT=y
CONFIG_LIBC_PERROR_STDOUT=y
CONFIG_LIBC_STRERROR=y
CONFIG_LIBM_NEWLIB=y
CONFIG_LIB_SYSCALL=y
CONFIG_LIB_ZLIB=y
CONFIG_NFILE_DESCRIPTORS_PER_BLOCK=6
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_LINELEN=300
CONFIG_NSH_READLINE=y
CONFIG_NSH_VARS=y
CONFIG_PATH_INITIAL="/system/bin"
CONFIG_PIPES=y
CONFIG_PSEUDOFS_SOFTLINKS=y
CONFIG_RAM_SIZE=33554432
CONFIG_RAM_START=0x80000000
CONFIG_READLINE_CMD_HISTORY=y
CONFIG_RISCV_SEMIHOSTING_HOSTFS=y
CONFIG_RR_INTERVAL=200
CONFIG_SCHED_WAITPID=y
CONFIG_SERIAL_UART_ARCH_MMIO=y
CONFIG_STACK_COLORATION=y
CONFIG_START_MONTH=12
CONFIG_START_YEAR=2021
CONFIG_SYMTAB_ORDEREDBYNAME=y
CONFIG_SYSTEM_NSH=y
CONFIG_TESTING_GETPRIME=y
CONFIG_TESTING_OSTEST=y
CONFIG_TIMER_FD=y
CONFIG_TLS_NELEM=10
CONFIG_TLS_TASK_NELEM=10
CONFIG_USEC_PER_TICK=1000

Build it with:
make distclean && ./tools/configure.sh rv-virt:cpython && make -j$(nproc)

Testing
Run it with RISC-V QEMU:
qemu-system-riscv32 -semihosting -M virt,aclint=on -cpu rv32 -smp 1 -bios none -kernel nuttx -nographic

On NuttX:
nsh> mount_modules
Mounting ROMFS filesystem at target=/usr/local/lib/ with source=/dev/ram1
nsh> export PYTHONHOME /usr/local
nsh> export PYTHON_BASIC_REPL 1
nsh> python

Check the following record to run Python
(yes, you can copy the commands from there)

[Experimental Bot, please feedback here]
This PR does not fully meet the NuttX requirements, although it presents a significant feature addition. Here's a breakdown:
Summary: While the summary explains the what and why, it lacks details on how the Python integration works internally. More specifics on memory management, interaction with the OS, and the build process would be beneficial.  The "Considerations" section highlights important limitations and to-dos, which is good, but some of these should be addressed before merging.
Impact:  The impact section is incomplete. While it mentions the target architecture, it needs to address all the points:

Impact on user: YES. Users will need to set environment variables, mount filesystems, and potentially adapt their applications.  The required steps should be documented.
Impact on build: YES. A new configuration (cpython) and additional build steps are introduced. This needs detailed explanation, ideally with changes to the build system documentation.
Impact on hardware: YES. Currently, it only supports rv-virt. This needs explicit mention.  Future hardware support should be discussed.
Impact on documentation: YES. Documentation is required for building, configuring, and using the Python integration. This is crucial for users.
Impact on security: Potentially YES. Introducing a complex interpreter like Python can have security implications. This needs investigation and documentation.
Impact on compatibility: Potentially YES.  The use of ROMFS and specific environment variables may impact compatibility with other NuttX configurations.
Anything else to consider: YES. The long "To-Do" list suggests this is an early-stage integration.  Consider whether it's ready for merging in its current state or if it should be staged.

Testing: The testing section is insufficient.

Build Host(s): Missing information about the host OS, compiler version, etc.
Target(s): While rv-virt:cpython is mentioned, more details on the configuration are needed. The provided defconfig is helpful but doesn't replace a detailed description.
Testing logs before change: N/A (as expected for a new feature), but should be stated explicitly.
Testing logs after change: The asciinema recording is a good demonstration, but it doesn't replace textual logs showing the Python interpreter's output and any relevant NuttX messages.  Simple Python scripts demonstrating core functionality should be included and their output logged.

Recommendations:

Expand the Summary: Provide more technical details on the integration mechanism.
Complete the Impact section: Address all points thoroughly.
Improve the Testing section:  Provide detailed host information, more comprehensive test cases with logged output, and clear instructions for reproducing the tests.
Address the "To-Do" list: Prioritize essential items, like dynamic configuration generation and a wrapper application, and consider whether they should be completed before merging.
Provide documentation:  Document the build process, configuration options, and usage instructions.
Consider staging the PR: If the "To-Do" list is extensive, consider breaking the integration into smaller, more manageable PRs.

This PR has great potential but needs more work to meet NuttX's standards for completeness and maintainability.  Addressing these points will make the integration more robust and easier for the community to adopt.

Great, nice work!

need add cmake?

need add cmake?

Yes!
There is a long list of to-do, but I preferred to submit upstream because I need more hands working on it (and I think we can engage the NuttX community by doing that).
NuttX would be one of the first RTOS supporting Python ;)

Should it be behind a "EXPERIMENTAL" config, to set the right expectations?

Yes, it makes total sense!

Error for esp32-devkitc:nxdiag does not seem to be related to this PR (https://github.com/apache/nuttx-apps/pull/2879#pullrequestreview-2482066426). Checking it.

Error for esp32-devkitc:nxdiag does not seem to be related to this PR (#2879 (review)). Checking it.

I ran the CI locally (https://github.com/apache/nuttx/issues/14601#issuecomment-2452875114) and it didn't fail. However, it may be related to an issue that I fixed at https://github.com/apache/nuttx-apps/pull/2879/commits/f064a198652593b00fba5d5e3355e9b7f84c3d5d (just sent within this PR)

This is awesome.
For the future, I think a good addition would be having the test directory available, so we can the interpreter unit tests in target. Since those are available already, we could use it!


Text with my friend

sample-app > src > androidTest/java/com/atiurin/sampleapp > myPage/myTest/myData/mySteps...


WIP: (Voice Conversation Bounty) a whispering llama named vitsy

Bounty: Have a passable (vaguely mistakable for human) voice conversation with tinygrad (whisper + LLaMA + VITS)

[ ] Streaming support
[x] Easy API-like access of models (VITS, LLaMa, Whisper)
[ ] Performance improvements (multi-processing, caching)
[ ] Queueing

I will update the above task list later.

Update on this?

Closing, no progress in more than a week. Feel free to reopen.


BIGTOP-2836: charm metric collector race condition

Ensure echo 0 is the last thing to run so that the metric hook does not cause a failed deployment. Works in all tested scenarios:
False && False || echo 0

0

True && False || echo 0

0

False && True || echo 0

0

True && True || echo 0

True

wow, an interesting approach indeed. Looks legit, though

LGTM


[Bug] The cast function does not convert string to int as expected

Search before asking

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

Version
2.0.11 & master
What's Wrong?
select cast("123.123" as tinyint)
实际值: None
期望值: 123
select cast("123.123" as smallint)
实际值: None
期望值: 123
select cast("123.123" as int)
实际值: None
期望值: 123
select cast("123.123" as bigint)
实际值: None
期望值: 123
What You Expected?
输出符合期望值
How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

should not change this behavior. becaues be return null when do cast('123.123' as int). we should let fe return same result with be


Cetaceans: Two new codes needed in Order

From the requester:
I was wondering if you could add another couple of terms to the 'PlatformInstance' vocab (https://vocab.ices.dk/?ref=1724). Aerial surveys have observers on the left and right side of the plane, so 'primary' and 'secondary' aren't quite correct for aerial.
Could you add 'Right' and 'Left' to this vocab list please?

@pcrjoana to check with the group if this should be a new field or the present fields can be used for separating observations from the left/right sides of the plane

The group decided that the codes are no longer needed and they can use the field "angleofsearch" for the purpose they wanted to use the codes "left" and "right".


Ignore front-matter

Currently vmd tries to parse front-matter as it's a valid markdown. This PR adds a feature of ignoring front-matter. By default it's configured to ignore yaml front-matter, but there is an option to set the list of ignored formats.

I just did some checking. GitHub actually doesn't strip front-matter but renders it as a nested table. But only if YAML syntax is used. If the front-matter is TOML or JSON style it just renders it like regular text.
vmd should behave the same, if possible. We can strip it (i.e. not render it) and also add support for TOML and JSON but those behaviors should be turned off by default and can be enabled through config parameters / command-line arguments.
I tried some front-matter that I copied from the hugo docs.
YAML:
---
title: "spf13-vim 3.0 release and new website"
description: "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
tags: [ ".vimrc", "plugins", "spf13-vim", "vim" ]
lastmod: 2015-12-23
date: "2012-04-06"
categories:
  - "Development"
  - "VIM"
slug: "spf13-vim-3-0-release-and-new-website"
---

sdasdasd

Is rendered like this:

TOML-syntax front-matter is just rendered as text:
+++
title = "spf13-vim 3.0 release and new website"
description = "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
tags = [ ".vimrc", "plugins", "spf13-vim", "vim" ]
date = "2012-04-06"
categories = [
  "Development",
  "VIM"
]
slug = "spf13-vim-3-0-release-and-new-website"
+++

sdasdasd

Looks like this:

Same with JSON-syntax front-matter:
{
    "title": "spf13-vim 3.0 release and new website",
    "description": "spf13-vim is a cross platform distribution of vim plugins and resources for Vim.",
    "tags": [ ".vimrc", "plugins", "spf13-vim", "vim" ],
    "date": "2012-04-06",
    "categories": [
        "Development",
        "VIM"
    ],
    "slug": "spf13-vim-3-0-release-and-new-website"
}

sdasdasd

Looks like this:

I've created a new issue based on my comment.

@pavloo : I'm not sure if you got the notification emails as it happened in a different issue. But I made a couple changes to the Front Matter behavior in PR #112:

By default Front Matter is rendered as a nested table like on GitHub.
The behavior of ignorefrontmatter = [yaml] can be achieved like this: frontmatter.renderer=none and the rendering for all enabled formats is the same.
YAML and TOML can be enabled through frontmatter.formats=yaml,toml. By default only YAML is enabled.

@maxkueng Sorry was on vacation. Looks nice. Thanks!


feat: Allow hex engine to be used

When using SELECT FROM DUMMY FOR JSON the hex engine falls back to the legacy engines, but when replacing it with an equivalent statement it is possible to have the queries run in the hex engine.
Any suggestions for FROM DUMMY replacements are welcome.

Tests running inside the Github action are using legacy engine as HXE is using SP2.0 which only includes the legacy engines.

@BobdenOs merge?


"Last Bought" tooltip info missing for items in BMAH frame

I noticed that for items in the BMAH frame the Journalator "Last Bought" tooltip info is missing:

I have all tooltips enabled in the settings, and there is definitely a record for a bought item in Journalator's db:

For items in the other AH frame, the info is displayed.

OK, I've just seen a Journalator tooltip on a not-BoP battle pet item in the BMAH, with auction data from the normal AH apparently:

So the problem doesn't seem to be the BMAH frame, but rather the tooltip is missing if the item does not exist in the normal AH? (Like the BoP mount item from above.)

Its probably because the BMAH item has a different item ID to the item purchased from the AH

Well, it's not an issue if it's not in the tooltip, I can always search in Journalator when I want to know when I bought an item and how much I did pay. (And there's also the TSM tooltip that shows me the info, pic 1.). I was just wondering if this was an oversight.

Having a look at the code there's a IsAuctionableItem(itemLink) check so that would be why the item is excluded from the tooltip.
I wasn't expecting BMAH purchases to get recorded, so its an oversight that they did, rather than an oversight that the price is in the tooltip.
I'll leave BMAH purchases to keep getting recorded though until I can move them to their own tab.

Added the price to the tooltip in the latest alphas

I wasn't expecting BMAH purchases to get recorded, so its an oversight that they did

Oh, besides WoW tokens, BMAH purchases is where most of my gold goes! So it would be fatal if exactly that wasn't recorded by Journalator 😉


[startunicorn] Extract methods from loop

Doing this we're solving two noticed bugs;

Preventing the ask_for_star message from spamming;
Fixing the folder creation for nested components[1];

[1] I've noticed that creating two nested components in a row python3 manage.py startunicorn app test_1.test_2.table test_3.test_4.row goes wrong beacuse of component_base_path variable.
I also needed to add the creation os app/templates/unicorn to test file.
Hope it helps! :)

Thank you! I'll merge this in for the next release. 👍


Tools don't seem to be initiated

I get this:
[INFO] Total tools initialized: 0
despite having a mcp_config.json as required by the program:
{
  "mcp_servers": {
    "todoist": {
      "command": "npx"...

Hi, thank you for the feedback!
Since you are getting to this step it is most likely related to the sever dependencies.
May you please check you have node globally installed?
It is not directly required by the MCP server init but depends on it.

I do... I believe
abe@ubuntu:~/.llm/clients/console-chat-gpt$ node -v
v23.4.0

I just realized it was a troublesome MCP server.

Thank you for getting back on this! I hope you will enjoy the chat client. If any other issues or questions please feel free to reach out!


Guide to create a bitbucket-server docker image

I understand that this issue is not jira related, but i am not sure how i would reach you witch such a topic best.
I would like to create a bitbucket server docker image, based on what you do.
Are there any starting points you want to me to look at - i can try to get along with your Dockerfile here, i surely have to somehow adjust the answerfile and things like that.
Any chance you would like to join efforts and do this under your flag, blacklabelops/bitbucket?
There is also https://bitbucket.org/atlassian/docker-atlassian-bitbucket-server - so there is also a question if it makes sense - it seems to be maintained

Your always invited to contribute to blacklabelops/bitbucket: https://github.com/blacklabelops/bitbucket
Please open any issues regaring bitbucket there, not here.

i am must be freaking blind. i am really sorry. I looked for it in your namespace but must missed it.
Joining you there, thanks and sorry


WASM. New scripts are always sh

Script type always switches to when user adds a new script.

Fixed.


Update Composer dependencies (2024-01-12-00-15)

Visual regression test passed!
View the visual regression test report