libreoffice-fresh: strip away BUILDCONFIG, reduce runtime closure size by ~20%

Description of changes
In v7.5.x a change was introduced that writes the BUILDCONFIG into $out/lib/libreoffice/program/libsofficeapp.so including the PKG_CONFIG_PATH containing references to all dev outputs of library dependencies:
$ strings $(nix-build -A libreoffice-fresh)/lib/libreoffice/program/libsofficeapp.so|grep PKG_CONFIG_PATH
[...], "BuildConfig": "[...] 'PKG_CONFIG_PATH=[...]'"

This isn't really needed because this information can also be obtained by nix derivation show. Also, this causes a 20% larger runtime-closure because of all the dev dependencies being referenced by the output and thus downloaded whenever libreoffice is substituted somewhere. The actual numbers look like this:
$ nix path-info -Sh ./result-old
/nix/store/3mzrqh4gg7v27vdrrap9dj3x8myysmyf-libreoffice-<IP_ADDRESS>-wrapped	  2.0G
$ nix path-info -Sh ./result
/nix/store/g5y60s0a2q2v6r58xcayv62z7fjfi816-libreoffice-<IP_ADDRESS>-wrapped	  1.6G

Only libreoffice-fresh is affected, pkgs.libreoffice isn't because it still points to 7.4 whereas the problematic change was introduced in 7.5.
To make sure this doesn't get reintroduced by accident, the derivation also prohibits now to reference any dev output from a build input.
[1] https://gerrit.libreoffice.org/c/core/+/141197

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@NickCao done!

Pretty sure this broke libreoffice-qt.

can take a look later.

Pretty sure this broke libreoffice-qt.

Indeed! It happens in the end of it unfortunately - many of the dev outputs are referenced and Nix fails the build:
error: output '/nix/store/2y0czyy26gcsqhmcvd2mlqa35f0gcl4l-libreoffice-<IP_ADDRESS>' is not allowed to refer to the following paths:
         /nix/store/0hmvklj0mbhrn8flwbcwivvkv45limhg-freetype-2.13.0-dev
         /nix/store/0rnx7rc87hwkbrhsys7mgwq4jw6pz7ma-zlib-1.2.13-dev
         /nix/store/13p48hi1bfgpwgbqqx3s6c0i126gvv96-libXinerama-1.1.5-dev
         /nix/store/1b62rr75sfz00qixad3s4s2zj0c3g8q9-libXext-1.3.5-dev
         /nix/store/2a34x9kp91dlsbg06w903cpv3r3ihxsf-kio-5.108.0-dev
         /nix/store/2xm5rq23mqbsz00g719qymq6fcnpz3cr-gtk+3-3.24.38-dev
         /nix/store/6qqnfjv51qf2xpasssjnsk55sq7072ij-libjpeg-turbo-<IP_ADDRESS>-dev
         /nix/store/7m1px7m2zvidm7w3s93qjgvpkvdzwp8c-qtbase-5.15.9-dev
         /nix/store/7y7plvhsnpb841zd0fwk2q5sp9ah2n6v-libGL-1.6.0-dev
         /nix/store/82p8xgcrb9qn01rabzh6a200yvh4kqhk-cups-2.4.6-dev
         /nix/store/99hw785dmzxllzjxi89palmmd81n1g5c-kcoreaddons-5.108.0-dev
         /nix/store/b8dz2wfxj33ivrq39ga8h0ails3qv3li-graphite2-1.3.14-dev
         /nix/store/db79xky20dvsvs5546ffpv5db70yjlxq-icu4c-73.2-dev
         /nix/store/dcwr090bqdp45z21cdzx6pngacch97mb-glib-2.76.4-dev
         /nix/store/iwnn064wbl64f9vq5gh35y06grr55633-libX11-1.8.6-dev
         /nix/store/k1rfz8y5bgnwkr0y483k4mpy7k9v8p13-libxml2-2.11.4-dev
         /nix/store/l0vnx3ik63qrlj086gq06fjmalsi5dpy-openssl-3.0.9-dev
         /nix/store/mkx285y7r04x83ya9fgrh4wrfdhqn10g-libxslt-1.1.38-dev
         /nix/store/pl74gzzdjagqybwg4srwgvg233rxg12d-expat-2.5.0-dev
         /nix/store/s8filxypfn1c32vcvq6mzxyds00cp52n-libXi-1.8.1-dev
         /nix/store/sfw83wf115jb435rbqql9apmvd2l4y2i-cairo-1.16.0-dev
         /nix/store/wyrba0f8h73cb7ik64myqphi7217fz0g-fontconfig-2.14.2-dev
         /nix/store/x2d20gpjfvjk6raf6ycyskvqh958fj5b-qtx11extras-5.15.9-dev
error: 1 dependencies of derivation '/nix/store/ki2pw9h0638zfijbfsrb40v6nf2qb2ij-libreoffice-<IP_ADDRESS>-wrapped.drv' failed to build

Yeah, because of the QT variant a few more dev outputs are needed already, but that isn't something I'll investigate. Instead, I'd just skip the disallowedRequisites for libreoffice-qt and keep it for the non-QT variants to make sure we don't miss a new buildconfig-like closure bloat in the future.
Already prepared a patch locally, currently building all variants, a PR will follow...

@k900 #245518 %)


runtime: unexpected signal during runtime execution

What version of Go are you using (go version)?
go1.14.7, also observed the same problem with earlier versions: go1.13.7
Does this issue reproduce with the latest release?
Unknown
What operating system and processor architecture are you using (go env)?
Linux 4.14.35-1818.3.3.el7uek.x86_64 #2 SMP Mon Sep 24 14:45:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
(Oracle Linux Server release 7.6)

What did you do?
Original issue reported here: https://github.com/hashicorp/consul/issues/8558
The Consul binary appears to be crashing with errors from the runtime, ex:

fatal error: stopg: invalid status
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
runtime: unexpected return pc for runtime.sigpanic called from 0x0

The stack trace from the application shows the line as a select blocking on a channel from signal.Notify (source). I'm not sure if that is related to the underlying issue, or has to do with the signal from the runtime.

 I saw some related things, but nothing that sounded like exactly the same problem.
One issue mentioned C signal handlers. There should not be any such handlers in this binary.

Sadly, with the release of go 1.15, go 1.13 is no longer receiving active support.
Can you please try with the latest release of Go can confirm if the problem occurs.

Ah, that's right, thank you. I've asked they try with a more recent release, which uses go1.14.x.

cc @aclements @randall77 @prattmic
@gopherbot remove WaitingForInfo

This looks a lot like memory corruption.

Hello to all.
These fatal errors have appeared since version 1.12 and older.
And is repeated only on hosts with Intel optane as RAM.

All the more reason to determine if the binary contains data races or cgo related memory corruption.

@dnephin have you built the app with the race detector?

I've been working on running the tests with the race detector enabled. We run some packages with -race, but not all. We don't build binaries with it enabled. Would that help identify the problem?

A data race could cause memory corruption, so building the app with the race detector may help.

@dnephin any new about this problem?

@dnephin @woblerr I got the same issues in my code, and it broke since Go 1.14 with the introduction of the goroutine async preemption (I do not have control over the C code I am using, but it looks like it mess up with the signals), so I just disable the async preemption when running my tests/building the binary. Your logs suggests it could be the same issue (crash in the garbage collector that preempt the goroutines). Can you try running your tests with GODEBUG=asyncpreemptoff=1 like GODEBUG=asyncpreemptoff=1 go test ./... to see if it is the cause?


LSNocilla fails to populate headers in response

Added headers are omitted from the response object resulting requests failing.

Can you write a failing unit test that shows the code breaking then write to code to fix that? I don't see how the code you wrote changes anything.
The code you wrote copies the headers into a pointer that points to the same object, which would point to the same headers array, and then still returns the original response object, which is the same object that you copied the headers to.

Accidentally closed, reopened so you can make changes/we can discuss the issue and how to fix it.  I am working on getting travis CI up and working again now.

Let's say I made the following stub:
stubRequest(@"GET",@"^http://(.*?)proxy/company_config/v1/config".regex)
                    .withHeader(@"Content-Type",@"application/json")
                    .andReturnRawResponse(COMPANY_SETTINGS_TEST_JSON_V1.JSONData);

I would expect the request header to be passed to the response. This is not happening and causing the tests to fail.

I think you need to put your .withHeader call after the andReturnRawResponse call. Right now it is adding that header to the request, not to the response object.
Again, if it is still failing after those changes, add a unit test, watch it fail, then write the code to make it pass.  Your changes do not include any unit tests.

It's behaving as expected. I will close this PR.

Great to hear.
Thanks!


Stacked Response Time Graphs

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
UI Feature
🔖 Feature description
I would love to have a way to stack the graphs from each item on the dashboard onto one page so I could see when there are issues spanning multiple devices. This isn't always a complete loss of service (e.g. ping timeout), but might be high latency or something similar. Basically, make it easier to troubleshoot network wide issues.
I made a mock up of the idea, hopefully this makes more sense. I think it would be good as an addition to the status page so you could pick and choose what items you want a graph from.

edit: Realized my text got cut off. Should be "but multiple systems experienced an increase in latency"
edit2: Each graph should also have a name above it so you can id the device/system it came from.

✔ Solution
Create a new page showing the graphs stacked on top of one another, and a single time period drop down so that all graphs are operating on the same range. It would also help to have a "custom date/time" option, allowing someone to pick a starting and ending time, so they could focus on, and see, the exact problem time.
❓ Alternatives
Current solution is to go back and forth between items on the dashboard, trying to visualize where a network wide problem might have occurred. There are multiple ways this could be designed, but the response time graphs are the easiest to view
📝 Additional Context
edit: noticed that my graphs don't line up perfectly, and the "issue" that I drew the box around really isn't a good example. This was just supposed to be a mockup, so imaging that there's some universal spike in latency across all devices :P

This would be a powerful tool to have. In addition to this, an aggregate graph would be very useful as well - where multiple monitors could be placed onto the same graph and be shown by different color lines/gradients.

+1 - would love to see this feature!!

@AndrewBadura
Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder.
Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.


Nested specificity fix

Fix for issue #309
All tests were passing except one, which it seems was using the old specificity value in the assertion. I have changed that to the correct value.

Can you add test cases that cover the new code?

Yes, I'll get on that today


[MRXN23-120]: fixes PU count with protected area set

Fixes PU count with protected area set
Overview
This PR attempts to fix the issue reported here where, once a user created a scenario and sets a protected area, the locked-in PU of the protected area were reflected in the summary in the panel. This lead to display of the Clear button but actually it does nothing as it's trying to revert to the original state of the PUs when it is already there.
Before:

The solution is filtering the, in this case, locked-in PUs (included ones for humans) by the property setByUser as the protected area setup is not run by the user (well, it is, but the user does not set explicitly the status of the PU) so we can assume there's nothing to clear as there isn't anything set by the user yet.
This also implies those PUs won't be set with the same styles as if the user sets them (which I think is fine).
After:

Note: this filtering also applies now to locked-out and available PUs.
Designs
–
Testing instructions
Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.
Feature relevant tickets
Link to the related task manager tickets

Checklist before submitting

[ ] Meaningful commits and code rebased on develop.
[ ] If this PR adds feature that should be tested for regressions when
deploying to staging/production, please add brief testing instructions
to the deploy checklist (docs/deployment-checklist.md)
[x] Update CHANGELOG file

@hotzevzl I am including in this PR as well displaying always the summary of locks, in case you want to review and merge.


Any way to filter records in csv?

Hi,
Sorry if it sounds silly, I have a csv file which have column called status.
i cant seem to find a method where i can filter records with the status of 'Pass' as to filter students who have passed.
can someone please help me?

@mpixelz thanks for using the library I will point you to the documentation website where all is explain.
https://csv.thephpleague.com/9.0/reader/statement/
If you find the explanation intimidating or not that well written you can then head over PHP forums where dedicated users will gladly help you. This venue is more reserved for feature requests and issue tackling.
Hope the link will be of help


Add grim-hyprland

Add grim-hyprland, a drop-in replacement fork of Grim with support for Hyprland's window capture protocol.
(Also update regular grim's url to point to Sourcehut where it is now hosted.)

From what I can tell slurp is still hosted on Github.

From what I can tell slurp is still hosted on Github.

Bruh


Error with onSelect in Calendar with react-hook-form?

I am trying to use the Calendar picker with react hook form. At the end of this page they have an example of how to do it - https://ui.shadcn.com/docs/components/date-picker#react-hook-form
I copied the exact same page to my vscode, but I keep getting this error:
Type '(event: Date | ChangeEvent<Element>) => void' is not assignable to type 'SelectSingleEventHandler'.
  Types of parameters 'event' and 'day' are incompatible.
    Type 'Date | undefined' is not assignable to type 'Date | ChangeEvent<Element>'.
      Type 'undefined' is not assignable to type 'Date | ChangeEvent<Element>'.ts(2322)

Here's the full code:
"use client";

import { zodResolver } from "@hookform/resolvers/zod";
import { format } from "date-fns";
import { CalendarIcon } from "lucide-react";
import { useForm } from "react-hook-form";
import * as z from "zod";

import { cn } from "@ui/lib/utils";
import { Button } from "@/components/ui/button";
import { Calendar } from "@/components/ui/calendar";
import {
  Form,
  FormControl,
  FormDescription,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from "@/components/ui/form";
import {
  Popover,
  PopoverContent,
  PopoverTrigger,
} from "@/components/ui/popover";
import { toast } from "@/components/ui/use-toast";

const FormSchema = z.object({
  dob: z.date({
    required_error: "A date of birth is required.",
  }),
});

export function DatePickerForm() {
  const form = useForm<z.infer<typeof FormSchema>>({
    resolver: zodResolver(FormSchema),
  });

  function onSubmit(data: z.infer<typeof FormSchema>) {
    toast({
      title: "You submitted the following values:",
      description: (

          {JSON.stringify(data, null, 2)}

      ),
    });
  }

  return (
    <Form {...form}>
      <form
        onSubmit={(e) => void form.handleSubmit(onSubmit)(e)}
        className="space-y-8"
      >
        <FormField
          control={form.control}
          name="dob"
          render={({ field }) => (
            <FormItem className="flex flex-col">
              <FormLabel>Date of birth</FormLabel>
              <Popover>
                <PopoverTrigger asChild>
                  <FormControl>
                    <Button
                      variant={"outline"}
                      className={cn(
                        "w-[240px] pl-3 text-left font-normal",
                        !field.value && "text-muted-foreground"
                      )}
                    >
                      {field.value ? (
                        format(field.value, "PPP")
                      ) : (
                        Pick a date
                      )}
                      <CalendarIcon className="ml-auto h-4 w-4 opacity-50" />
                    </Button>
                  </FormControl>
                </PopoverTrigger>
                <PopoverContent className="w-auto p-0" align="start">
                  <Calendar
                    mode="single"
                    selected={field.value}
                    onSelect={field.onChange}
                    disabled={(date) =>
                      date > new Date() || date < new Date("1900-01-01")
                    }
                    initialFocus
                  />
                </PopoverContent>
              </Popover>
              <FormDescription>
                Your date of birth is used to calculate your age.
              </FormDescription>
              <FormMessage />
            </FormItem>
          )}
        />
        <Button type="submit">Submit</Button>
      </form>
    </Form>
  );
}

I managed to "fix" it by changing the onSelect to onDayClick

It's caused by an update in react-hook-form, pinning to 7.44.3 helps (see https://github.com/shadcn/ui/issues/735#issuecomment-1609416635)

I managed to "fix" it by changing the onSelect to onDayClick

Thanks! This helped me to avoid that error. How did you get to making that change?

I managed to "fix" it by changing the onSelect to onDayClick

Hero

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

Hello! Is there an update for this? I encountered the same issue with the calendar component.
my react-day-picker version:
"react-day-picker": "^8.10.1",

@0xCyyy3000 selected={field.value ? new Date(field.value) : undefined}


Fix dev-dependencies scan if target.XYZ clause also has dependencies

In the event that a dependencies table exists in addition to the dev-dependencies table with the same target.XYZ clause, only the dependencies table would get read when we instead desire both.
Fixes: c2a4c91 ("Also walk target.'cfg()' for dev-dependencies next to dependencies")

Thanks again for the quick merging and release @bkchr, sorry for the noise! I have no idea how #15 fixed my issue initially since this was clearly blocking it too...

No problem. I should have reviewed it better :P


build: install Meilisearch and Aspects

Product asked for Meilisearch and Aspects to be enabled on this sandbox.

FYI, I already installed them manually.  This is basically just codifying it for the future.


How can we print connection pool statistics

For investigating the following Kubernetes - Redis cluster connection issue with redisson,
java.util.concurrent.CompletableFuture@6b13e4ea[Completed exceptionally: java.util.concurrent.CancellationException]Increase connection pool size. Node source: NodeSource [slot=3053, addr=null, redisClient=null, redirect=null, entry=null], command: (HMSET), params: [[114, 101, 100, 105, 115, 115, 111, 110, 58, 115, ...], [108, 97, 115, 116, 65, 99, 99, 101, 115, 115, ...], [-84, -19, 0, 5, 115, 114, 0, 14, 106, 97, ...]] after 3 retry attempts,
we want to see/log connection pool statistics from the redisson client.
Yes, we can enable logging for all org.redisson to see acquiered / released connection logs but this still doesn't provide information regarding redisson connection pool status. ( ref https://github.com/redisson/redisson/issues/3565 )
We want to have better way to see the pool statistics for investigating the issue.
Thanks in advance
Ramazan

connection metrics are available here: https://redisson.org/docs/observability/#metrics-list

@mrniko so you mean without Redisson PRO, we can not have Connection metrics, right ?


Zeroing

Zeroing is a language-specific reduction technique that replaces (non-optional) nodes with a specified, pre-configured "small" version. For example, the string node in the Python grammar might be replaced with "".

This is done and I introduced a few for C; other languages should follow.


Improve replacing of dialcode

This fixes some of the dialcode replacing issues.

Thanks @JelteF ! Can you please write tests for the fix?

Done

Thanks @JelteF. It's out in 3.7.3 release


Android: Delete doesn't work as expected

#Nexus 5, delete issue
It's hard to show this issue but I have captured it via USB debugging. When you try and delete the last letter it doesn't change the value, then (seemingly) randomly after a certain amount of attempts it will delete the whole field.
You can see on the right hand side when the elements flash I am typing in the box.

Only thing I can work out from this is that you are deleting the letters but the auto fill just puts the first matched value back in.
So the only time you can delete the whole word is when you delete it fast enough, maybe? Not sure on that last theory

This is happening to me as well.
I also have to tap each letter on the keyboard multiple times before it will enter. This happens with both static and async data.


<EMAIL_ADDRESS>decompress error

Extracting twilio-win32-x64.tar.xz ... ERROR Exit code was 2!
Failed to extract files from C:\Users\shail\scoop\apps\twilio\5.3.3\twilio-win32-x64.tar.
Log file:
~\scoop\apps\twilio\5.3.3\7zip.log
Please try again or create a new issue by using the following link and paste your console output:
https://github.com/twilio/scoop-twilio-cli/issues/new?title=twilio%405.3.3%3A+decompress+error

This looks like a duplicate issue. Can you please try running this cmd in Powershell ran as an admin ?


what is the performance gap between lora and full finetune

Thank you for your interest.
Our early experiments found that, there exists 2 score improvement of LoRA than fully fine-tuning in MMBench dev split (64.69 vs 62.46), under certain setting.
Should you wish to proceed, feel free to try to fully fine-tuning Bunny and see the performance gap, which has been supported by our code.

For SigLIP + Phi-2

Thanks for your comprehensive experimental results! We are all very interested in the effective reasons of Bunny, and it would be nice to show more ablations about data, architecture in the technical report! Thanks a lot!

We are working on that. (:

Close the issue for now if there's no further discussions. Feel free to reopen it if there's any other questions.


Parse /// comments for @@ annotations

Discussed in https://github.com/prisma/prisma/discussions/20899

Originally posted by m1212e August 30, 2023
Question
Hi, did you consider parsing /// comments for @@ annotations?
See this issue for detailed context: https://github.com/Brakebein/prisma-generator-nestjs-dto/issues/28
I use a generator that outputs DTOs based on the schema. In concept, this happens:
The parser sees this model
model Role {
  id            String @id
  name      String
  attribute String

  @@unique([name, attribute])
}

And generates this
export class FindRoleDTO {
  id?: string;
  name_attribute?: RoleNameAttributeUniqueInputDto; // this is basically { name: string, attribute: string }
}

The generator allows ignoring certain fields you don't want to appear in the output by adding a comment like /// @DTOHide to a field. Now if I would like to disable output of the name_attribute I can't because the parser does not pick up the comment for the @@ annotation.

Do I understand correctly that you want to add a /// before @@unique and that to be present in the DMMF?

To be honest I'm not super into how the parser works but if DMMF ist the thing that describes the parsed information of the schema.prisma and what is available to generators to do stuff with then yes, thats what I suggest :D


Initial commit

Feels a little brute-forcey not sure if there's a better way to do this
Resolves #172

Codecov Report

Merging #183 (fa52e25) into master (3568d61) will decrease coverage by 0.15%.
The diff coverage is 27.27%.

@@             Coverage Diff              @@
##             master     #183      +/-   ##
============================================
- Coverage     62.68%   62.53%   -0.16%
- Complexity      670      671       +1
============================================
  Files            94       94
  Lines          2573     2584      +11
  Branches        332      336       +4
============================================
+ Hits           1613     1616       +3
- Misses          863      867       +4
- Partials         97      101       +4

Impacted Files
Coverage Δ

...a/seedu/address/logic/parser/LogCommandParser.java
46.66% <27.27%> (-11.23%)
:arrow_down:

Continue to review full report at Codecov.

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


Inbearably slow in Laravel Projects

The suggestions being loaded make fluid typing impossible.

then it's up to you to take out the ones that don't work well for you or at least point them out.

I've the same problem. I work with Laravel. Try my fork that has a lot of changes (for laravel too).

@FiloSpaTeam : were there nay specific plugins that were slowing you down?

I understand this:

syntax highlight terrible slow and buggy so i changed to another
autocompletion was veryvery uncomplete without YouCompleteMe, another good thing of YCM is async
a lot of plugins for a simple work or duplicated when i can use one like unite (that is aync too)
i think another is the integration with git for symbols at left.
i think powerline is better than airline but i ve problem with first one.

what did you change the syntax highlighthing to?  BTW there's an open ticket for integrating unite, but i'm not sure of the status of that.

I changed for this.
In bigger files works well.
Unite is very good with async.
in my fork i changed the system of bundle too, it is divided into 2 groups: functions and languages.
I replaced plugins with others for better integration with tagbar and so on.
My experience with Laravel projects is quite goodgoo, sometimes i ve slow performance but only for big blade files. in services and others all works. Only problem that i m solving is slow autocompletion due to big big big words.

i'm planning on trying out neovim myself to solve some of the async plugin issues.

Yeah in fact i m porting this conf locally (neovim gentoo version). A lot of plugins doesn t load correctly but i m solving ;-)

@FiloSpaTeam I just checked out your fork, vim still crashes when typing in a somewhat big controller file. Can you keep me posted on the results of your neovim port?

Have you cleaned up your .vimviews folder and .vimswap??
I don-t have at the moment a repo with NeoVim port because i'm testing it locally :+1:

it's crashing, no matter what.
would be awesome to check out that repo

Mmmh strange. In my office this doesn't happens (we are 4 pc's).
I'll investigate. :+1:

I meant it's crashing when I'm typing in a large laravel controller file. The autosuggests slow down the fps to 1 and sometimes it just freezes.
No need to investigate for me, it's not that critical, I'll find my way. Just let me know once you've got it running on neovim and what the performance is like.

http://kevin.colyar.net/2011/05/fixing-vim-auto-complete-slowness-in-large-projects/
this seems to have fixed it for me!
can you confirm it filo?

This night i ll put in my conf and i ll try! :)
;-)

I tried but no differences. What changed for you??

autocomplete is not so very slow anymore while in insert mode in a bigger controller
did you just try typing
:set foldmethod=manual
while in slow insert mode and watched if something changed?

I have automatically this. (My biggest controller contains 500 rows)
I know your problem maybe. Are you using this plugin instead of this?

yes I'm using PIV as it is the default in this package.

Ok try the bundle the other plugin instead of PIV ;-) i changed because PIV have some bugs and slow down VIM :)

checking out your fork now. seems quite promising. how come you're not issuing pull requests?

I ve twitter @CMaradonna ;-)
i ve done some pull request some times ago but no integration, a lot of times for single pull.... i decided to maintain myself a configration :)

I switched to mawww/kakoune from vim.

https://github.com/Te-cho/compile-blades


PowerToys Run - Alt + Spacebar now longer works

Windows 10 1909 fully patched. Since 0.19.2 alt and space now longer opens PowerToys Run. Infact it opens the little top left submenu of the current window. Changing the hotkey to something else and it still doesn't launch. Uninstalled, rebooted, reinstalled no change.
ℹ Computer information

Windows build number: [run "winver"]
PowerToys version:
PowerToy module:

📝 Provide detailed reproduction steps (if any)

…
…
…

✔ Expected result
What is the expected result of the above steps?
❌ Actual result
What is the actual result of the above steps?
📷 Screenshots
Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form

Version 0.19.2 has lots of issues with power toys run key remapping.  I constantly get conflicts where keys get virtually stuck down or stop responding because they're trapped by power toys and I can no longer type certain characters or key combinations.  Which keys get stuck are random.  I've had backspace, letters, space bar, windows key and various others.  It is also multiple keys that break at the same time.
When a key stops responding, quitting the program leaves broken keyboard hooks registered and the only work arounds are to restart power toys to reset the keyboard hooks, or log off/log on/restart PC.
This happens almost daily and doesn't require using power toys run, only to have a custom key mapping.  I believe I had ALt + space or Win + space as my mapped keys

I think @Jordan-Meyer  mentions another issue, but i can see the issue (it opening the following menu).

Easiest to reproduce it seems to open taskmanager.
(I'm on lastest master version as of now on latest insider build)

is PowerLauncher running in the task manager?
0.20 is pending release this week with a ton of more fixes as well.

I'm having the same issue the last few days, hoping the fix comes soon...

@crutkas Yes, PowerLauncher running in the task manager. but still exisits if Keyboard Manager is enable. if i disable it at-least Alt Space started to show up.

Running PT run as admin also prevents this issue from happening.

are there applications where the quirkiness happens?  Such as task manager or others?
Issue with running PT Run as admin is all apps it launches also launch as admin.
Right now we expressly do not have PT Run under admin due to the scenario above even if you run PowerToys as admin

Not really. It sometimes works and sometimes it doesn't. Currently working with Chromium Edge maximised. Will keep an eye out for you.

@rwnash / @richard4339 we need to better understand when it doesn't work.  knowing what the app that was in focus helps.  What is your activation keystroke as well.

does it just start working again out of no where?
Is it running in task manager when it doesn't work?

In my case, the autoupdate for 0.20.0 applied, and once it relaunched, Alt+Space simply didn't open the window anywhere, be it the desktop, in the PowerToys UI, etc. I restarted the app twice, tried changing the shortcut, turning the run option on/off, everything. After reading through this thread, I turned off Keyboard Manager, and it works again. Nothing else has fixed it.
On my work computer, which is still running 0.18.1, the run option hasn't worked since the very first update. I just turned the keyboard manager off for it, and run is working fine in that version too now.
I just tried toggling Keyboard Manager back on now on both machines, and Alt+Space still works on my work machine. But on my home machine, I had to exit the app a few times, and ultimately had to kill both the UI and runner processes and relaunch to ultimately get Alt+Space to respond again.
In Task Manager, it always opens up the window context menu, but in my case, it was not responding in any window period before.

V0.20 seems to be working for me now.

Windows 10, PowerToys 0.20.0, I can reproduce the menu appearing instead of PowerToys Run search on demand.  Run "regedit", and make sure it has focus.  Now press Alt + Space Bar, and the menu "above and to the right" of the File menu appears instead.
Get that menu normally by Alt-F then Left arrow key.  If memory serves me correct the Alt-Space Bar keyboard shortcut for this menu goes back to the Windows 3.1 days, certainly it has existed for years, but most people don't seem to know of it.
I have seen the same problem randomly with other programs having focus, but not always reliably.  regedit is reliable for me.
PowerToys is Not running as admin, in case that matters.

closing as it has been resolved for @rwnash.
@cat38275 , if this is still happening on 20.1 please open a new issue!

I am having the same issue; alt + spacebar isn't working on my windows 10 machine

The issue with the Alt+Spacebar PowerToys Run utility is still in persistence and is not working after the latest update.


Generic "getHash" helper

Is your feature request related to a problem? Please describe.
The existing getCssHash won't return the hash if the css ins't included in a javascript entry.
Describe the solution you would like
Create a getHash that would behave just the same BUT it wouldn't check the "type" here, but just return the hash based on the filename returned from the manifest.
Additional context
This would allow us to have css entries (per v4.0.5) but still implement critical cookies.

Given their changes to the manifest, probably this makes sense.
Have you removed that single line of code that tests the tag type? Does it work for your purposes with that removed?


[server][test] Cleanup VeniceWriterFactory

Cleanup VeniceWriterFactory

Use VWF::createVeniceWriter(VeniceWriterOptions) instead of VWF::createBasicVeniceWriter(String)
and VWF::createVeniceWriter(String, VeniceKafkaSerialize, VeniceKafkaSerializer, boolean).
How was this PR tested?

Does this PR introduce any user-facing changes?

[x] No. You can skip the rest of this section.
[ ] Yes. Make sure to explain your proposed changes and call out the behavior change.

Thanks, Jialin for the review!


perf: speed up slow NumberTheory file

I took the slowest file within NumberTheory (the sixth slowest file in a recent speedcenter run), which took ~105 seconds to build on my machine and attempted to speed it up by

setting up (local private) instances to speed up instance search
squeezing simps
replacing a couple of _ by explicit arguments (gaining ~15 seconds!)
replacing some slow tactic invocations by something faster

This reduces the build time to about 20 seconds on my machine.
The build time in CI goes down by a factor of 3; see the timings below.

!bench

~Mathlib.NumberTheory.RamificationInertia	instructions		-	375,76 Mrd.	-247,092 Mrd. -65,758 % 	128,668 Mrd.
Speed-up by a factor of 3 and from no. 7 on the list of slowest files to no. 131.

Closing this; there is a less invasive attempt at #12679.


Small Fix on Linptech Wall Switch Name and Entity Category

Thanks!

https://github.com/AlexxIT/XiaomiGateway3/releases/tag/v3.3.3


ARM64: Build Pipeline -> Podman Support

Meta Issue: #1028
Build Pipeline -> Podman Support
This issue covers the validation of Podman support within the build pipeline of Garden Linux on ARM64 / AARCH64 architecture.
Tests
Within this issue the following components will be validated and tested:

Build Pipeline

Dependencies
Packages
Podman Support
Secure Boot

Successfully tested and validated.


Final touches for v1.0

Some things caught during bug bash:

Secret env var restrictions (now limited to profiles.yml + packages.yml)
Updated deps logic for package prerelease versions
Update on-run-* hook behavior (include test + build)
Update flags

Also, building off @emmyoop's wonderful work:

Document new event + logging interface
Question: Do we want to document EVENT_HISTORY at all? My sense is, in order to use it, you'd need to hook into dbt's python API for execution, and that's still an uncontracted + undocumented interface

To-do before merge

Pre-release docs
Is this change related to an unreleased version of dbt?

[x] Yes: please

update the base branch to next
add Changelog components: <Changelog>[New/Changed] in v0.x.0</Changelog>
add links to the "New and changed documentation" section of the latest Migration Guide

[ ] No: please ensure the base branch is current
[ ] Unsure: we'll let you know!

Checklist
If you added new pages (delete if not applicable):

[x] The page has been added to website/sidebars.js
[x] The new page has a unique filename

Thanks for the quick review @runleonarun!


A question about the test set

The trains set is sampled on a large dataset. Can we use a larger or even the entire test set to train our model? Thanks very much!

Sure.


Work around Windows Activation Context problems

For a detailed explanation of the problems, see https://github.com/zeromq/pyzmq/issues/861.
Fixes #87.

Coverage decreased (-59.1%) to 0.0% when pulling 4cf2fb020e3e0d1305bed2020525df3dccc9e3d2 on JuliaComputing:kf/actctx into ee0897b94268d3d380bfc810b08fa666f01a8f88 on stevengj:master.

Thanks for doing this, @Keno.   I'm in favor of merging this.
Is ActivatePyActCtx expensive compared to a typical pyimport?  If I have to do a whole bunch of pyimport calls, would it be better to have a way to do this once?  I'm hoping it is cheap enough that I can not worry.

Is ActivatePyActCtx expensive compared to a typical pyimport? If I have to do a whole bunch of pyimport calls, would it be better to have a way to do this once? I'm hoping it is cheap enough that I can not worry.

We could cache the activation context lookup, which is the expensive part. Activating the context itself should be very cheap. Windows basically does it on every call to a dll that has a different context from the calling one.

Can you add a test?   Maybe change this test to use pyzmq instead of conda-api?

Caching the lookup sounds like a good idea if it is expensive.

I'm not sure if it is expensive, but certainly more expensive than the actual activation. I'll add code to do the caching and adjust the test as you suggested.

Coverage decreased (-59.1%) to 0.0% when pulling cd75d12a992560e09a34e400f3025389b3cc8ff4 on JuliaComputing:kf/actctx into ee0897b94268d3d380bfc810b08fa666f01a8f88 on stevengj:master.

I tested on Linux and there was no problem with both pyzmq and ZMQ being loaded. I would test on Windows, but I can't get WinRPM to work. If it becomes a problem we can disable the tests if we find ZMQ already loaded.

Coverage decreased (-59.1%) to 0.0% when pulling b6209174c73b0470d4c7be18156871a65009681c on JuliaComputing:kf/actctx into ee0897b94268d3d380bfc810b08fa666f01a8f88 on stevengj:master.

Coverage decreased (-59.1%) to 0.0% when pulling 947ddaa7a56a49527c4a23ba54004d1629208c21 on JuliaComputing:kf/actctx into ee0897b94268d3d380bfc810b08fa666f01a8f88 on stevengj:master.

Coverage decreased (-59.1%) to 0.0% when pulling 947ddaa7a56a49527c4a23ba54004d1629208c21 on JuliaComputing:kf/actctx into ee0897b94268d3d380bfc810b08fa666f01a8f88 on stevengj:master.

Good to go?


Fix flipped y-axis in SVG writer

Edges are flipped in the y-axis when writing the SVG file. Not really noticeable for large trees, but obvious for small trees. This fixes that.

Codecov Report
Patch and project coverage have no change.

Comparison is base (db7491c) 26.68% compared to head (5538984) 26.68%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #99   +/-   ##
=======================================
  Coverage   26.68%   26.68%
=======================================
  Files          11       11
  Lines         371      371
  Branches       42       42
=======================================
  Hits           99       99
  Misses        272      272

Impacted Files
Coverage Δ

napari_arboretum/io/svg.py
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Implement automated test runs

Especially on pull requests?
Using Jenkins on my server maybe?
need to study this.

https://resources.github.com/whitepapers/practical-guide-to-CI-with-Jenkins-and-GitHub/
Blue Ocean might help

Done


Releases are failing

Now that we use pypa/gh-action-pypi-publish@release/v1 it is hard coded to publish everything in dist.
Therefore we need to move requirements*.txt out of dist.

This has been fixed in 3.2.2 by moving requirements*.txt into a lockfiles folder.


dockerize application

If would be great to be able to run the application using Docker itself.

automated image build added in #3


update# Official brand upgrade, changed from opside to lumoz

Official brand upgrade, changed from opside to lumoz

hi there @cppfuns.
This change sadly won't work here as this is generated code that you're manually updating and as such will get overwritten.
To make the change you're trying to make please do one of these 2 things:

Make the changes in a PR to: https://github.com/ethereum-lists/chains -> this will automatically then get updated in a subsequent build on our side.
Alternatively go here: https://thirdweb.com/solutions/chains and fill out the form -> we will then take the information you provide there and make the update in our system.

Thanks!
I'll be closing this as this code change won't actually work, please feel free to raise an issue if you have questions!


User cert-manager-controller cannot create resource "dnspod" in API group

hi, thank you for supplying a updated version. but when I use the cert-manager v1.12.4, I got the following error when applying a certificate:

E0913 06:09:16.070831       1 controller.go:167] "cert-manager/challenges: re-queuing item due to error processing" err="dnspod.acme.mydomain.com is forbidden: User "system:serviceaccount:cert-manager:cert-manager-controller" cannot create resource "dnspod" in API group "acme.mydomain.com" at the cluster scope" key="default/crdev.mydomain.com-crt-mbdgz-418508954-627544746" *

so I have to create a  clusterrole with the permission and bind it with serviceaccount "cert-manager-controller". I don't know if this helm chart forget to create the clusterrole, or this is a bug ?
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cert-manager-controller:dnspod
rules:
- apiGroups:
  - acme.mydomain.com
  resources:
  - dnspod
  verbs:
  - create
  - get
  - list
  - watch
  - delete

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cert-manager-controller-dnspod
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager-controller:dnspod
subjects:
  - apiGroup: ""
    kind: ServiceAccount
    name: cert-manager-controller
    namespace: cert-manager

RBAC is auto created in the chart https://github.com/imroc/cert-manager-webhook-dnspod/blob/master/chart/templates/rbac.yaml#L67
How to reproduce it?

my enviroment:
kubernetes: TKE v1.24.4-tke.7
bitnami cert-manager cert-manager-0.12.1
cert-manager-webhook-dnspod install parameters:
helm install cert-manager-webhook-dnspod ./cert-manager-webhook-dnspod --namespace cert-manager --set groupName=acme.mydomain.com --set clusterIssuer.secretId=xxxxx,clusterIssuer.secretKey=xxx --set<EMAIL_ADDRESS>--set image.pullPolicy=IfNotPresent --set cert-manager.enabled=true

RBAC is auto created in the chart https://github.com/imroc/cert-manager-webhook-dnspod/blob/master/chart/templates/rbac.yaml#L67
How to reproduce it?

I think it's because the default value of serviceaccount  is not  as same as it in cert-manager. when I change the value to "cert-manager-controller", it works.
helm install cert-manager-webhook-dnspod ./cert-manager-webhook-dnspod --namespace cert-manager --set groupName=acme.mydomain.com --set clusterIssuer.secretId=xxxxx,clusterIssuer.secretKey=xxx --set<EMAIL_ADDRESS>--set image.pullPolicy=IfNotPresent --set cert-manager.enabled=true  --set certManager.serviceAccountName=cert-manager-controller


Investigating how the colocalization step can be further optimized

As a user I want the colocalization pipeline to be fast and robust because currently it is too slow and potentially won't scale for future expansion of the dataset.
Background
The colocalization pipeline of the Genetics Portal release process has been identified as a mayor bottleneck taking around a day to complete. @Jeremy37 made huge improvements by optimizing the data flow, the conditional analysis still a mayor bottleneck and takes ~1 day to complete.
Tasks

[ ] Run the pipeline for a single chromosome (eg 21 so it should be fast) step by step.
[ ] See which step actually takes so long, and were we could get improvements.
[ ] The slowest bit is certainly calling the GCTA tools to conditional analysis, however it is not trivial how to go about it.

I think that you are unlikely to find much more speed improvements without a fundamental change in how we structure our analyses in OT genetics. For example, I think that the GCTA step (3/4 of the time) is fairly close to being as optimised as it can be, unless you think that GCTA itself can be reimplemented. It takes a day to run on 200 cores, with 100% CPU utilisation. Would you plan to use more than 200 cores on e.g. Dataproc? How would you run GCTA?
The ultimate optimisation will be to change how we do fine-mapping, and to store those intermediate results rather than recomputing them.
In the normal case we shouldn't have to recompute coloc for all past studies, so future runs should be less burdensome.

I should have said - there are a few design issues that could definitely be addressed with the colocalisation pipeline.

For each coloc test, it creates a folder nested about 16 levels deep, with folder names representing column values when these files are later read in Spark. But this is 16 folders for each file with a single line. For 4 M coloc tests, that's 64 M folders just for the results, and another 64 M just for the logs, etc. Just doing rm -rf on the directory containing these would take days. If we could design a better way of outputting the results and the logs for each test, it would probably speed up the pipeline somewhat and would make other aspects of running it easier.
The pipeline uses docker, but currently this only adds overhead and no value. We should find a way to make a docker image that contains all the software that needs to be installed and can be re-used rather than built each time. But it should contain none of the data or code, which we might like to change easily outside of docker.
Steps which generate commands are single-threaded, whereas most of the work is done multi-threaded with gnu parallel when running GCTA or coloc. These single-threaded steps waste compute when running on a big machine.


Mark codemirror files as vendored

GitHub lists datasette as a Javascript project, primarily because of the vendored codemirror files. This is somewhat confusing when you're looking for datasette, knowing it's written in Python.
Luckily it's possible exclude certain files from GitHub's code statistics: https://github.com/github/linguist#using-gitattributes

This is a neat fix, thanks!

Before applying this fix, GitHub showed the following statistics:
Python 50.1% JavaScript 46.0% HTML 3.0% Other 0.9%

Afterwards, it shows:
Python 92.8% HTML 5.5% CSS 1.3% Dockerfile 0.4%


New action request: konradpabjan/move-labeled-or-milestoned-issue

Action name
uses: konradpabjan/move-labeled-or-milestoned-issue
Reasons
konradpabjan/move-labeled-or-milestoned-issue

Intended usage
konradpabjan/move-labeled-or-milestoned-issue

I have checked the internal marketplace for similar actions and couldn't find one that works for us.

[X] I have checked the internal marketplace first

:robot: Found these results:

Check
Results
Links

CodeQL on the forked repo
:white_check_mark:
CodeQL run

Security scan:

Check
Result

No Dependabot configuration found
⛔

No CodeQL Init found
⛔

No CodeQL Analyze found
⛔

:robot: Check completed with result: ⚠
Found 9 Dependabot security vulnerabilities:
5 where high and 4 where moderate.
Use this link to verify the alerts.


README.md: correct headers level

Codecov Report

Merging #1522 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1522   +/-   ##
=======================================
  Coverage   40.82%   40.82%
=======================================
  Files          23       23
  Lines        2920     2920
=======================================
  Hits         1192     1192
  Misses       1451     1451
  Partials      277      277

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 b6a0fb1...e1ce48d. Read the comment docs.

LGTM

LGTM

@qingyunha thanks!


docs: adds docstrings for some properties of InvokableSlashCommand and SubCommand

Summary
Adds docstrings for the following properties:
.description (added to InvokableSlashCommand and SubCommand)
.options (added to InvokableSlashCommand)
additionally i feel like we should document some attributes of the Option class, the reference fo SubCommand.description (which is Option.description) is already failing 'cause we're documenting only methods for the Option class
also why the API representation is called  and documented as option in this class? https://docs.disnake.dev/en/stable/ext/commands/api/app_commands.html#disnake.ext.commands.SubCommand.option
shouldn't it be called body (which already exists) like other slash command classes?

Checklist

[ ] If code changes were made, then they have been tested

[ ] I have updated the documentation to reflect the changes
[ ] I have formatted the code properly by running pdm lint
[ ] I have type-checked the code by running pdm pyright

[ ] This PR fixes an issue
[ ] This PR adds something new (e.g. new method or parameters)
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[x] This PR is not a code change (e.g. documentation, README, ...)

additionally i feel like we should document some attributes of the Option class

Yup, otherwise CI will continue to fail. Option already has a list of parameters which mostly matches the list of attributes, so that section could be rewritten for this purpose.
In that case we should also consider turning this from Option() into Option to show the parameters in the signature.

shouldn't it be called body (which already exists) like other slash command classes?

it's aliased to that, I honestly don't remember if there was a reason for it - @EQUENOS might know

shouldn't it be called body (which already exists) like other slash command classes?

it's aliased to that, I honestly don't remember if there was a reason for it - @EQUENOS might know

It's called option because internally subcommands and groups are actually options with a special type, that's how discord API designed them. We added a body property for convenience, as it's useful in several places.


How to set limits on flow data without affecting geom_gate

Flow data often time has off-boundary events
p <- ggcyto(gs, aes(x = CD4, y = CD8), subset = "CD3+")
p <- p + geom_hex(bins = 64)
p <- p + geom_gate("CD8")
p

And we've been trying to remove them by ggplot's native xlim/ylim (i.e. Scale)  layer.
 p + xlim(c(0,4e3))

The side effect of scale transformation also causes the data in geom_gate layer (especially polygonGate)  to be truncated and thus will lose its geometrical shape.
There is some discussion about having ggplot to support layers that are free from scale limits
https://github.com/hadley/ggplot2/issues/187
However no actions have been taken by @hadley .
@raphg suggested the interpolation remedy a while back. The idea was to ensure polygon has sufficient number of points so that it still keeps its shape even after losing some vertices.
This was working fine until we encountered the extended gates (from flowJo or gatingML) that has exaggerated vertices on the far left, which makes it difficult to interpolate enough points within the displayed range that can prevent the polygon from losing shape.
As discussed before, we can't use coord_trans here either because we do need to remove these off-bound data through scale transformation because large number of these events often screw up the scale_fill_gradientn for hexbin.

@gfinak , looking at gate extension code for parsing flowJo xml, it is already extending the gates to the actual data limits. But this step is served as the preprocessing to gates prior to any actual gating, thus only raw(root node) data is available for lookup.  Therefore, the extended points can still be far left.  It is not impossible to modify the code to move the gate extension into the gating step.
The same issue exists for parse.gatingML.
So I still wonder if there is something cheaper we can do on ggcyto side.

The polygonGate vertices are truncated by the actual data range compared to the original vertices points.

This truncation was originally for preventing interpolation on the very extreme polygon vertices (e.g. Inf generated by openCyto). So we should only skip it by default.

addressed by 6f0fa93ddbbc12227015aa3804c3c7fa4a4ac229


Want to get idea for running test in parallel

Hello,
I would like to know how can I run test in parallel. I would like to get idea from all of you. I try to use for packaging but feel that it is not work for me. I am using latest of behat version.
Thanks for collaboration,
Sakona

In past, when I didn't know parallelisation is a solution to the wrong problem, I used GNU parallel to execute my features in parallel. See http://zalas.eu/running-behat-in-parallel-with-selenium-grid/
Google "Behat parallel" for more options and even some Behat extensions.
Alternative to parallelisation is making your tests fast by avoiding going through the UI all the time (executing most of scenarios through your service layer, decoupled from the infrastructure like db).

for UI tests with behat we are use simple bash script that create db and host for every worker and that run every testsuite in workers. For Travis-ci we are use only 2 workers, but locally I setup 4 workers and it works well - all my 4 cores was loaded by 100%.

Thanks for your suggestion @jakzal and @spolischook, Before asking that I try to use this one https://packagist.org/packages/tonicforhealth/behat-parallel-scenario I seem not understand, it works as run one scenario then open the browser then finish, and then it run other scenario. Do you think it work as parallels?
For @jakzal  I will try out your suggestion.
I use OS Ubuntu 14.04 for my current working

@sakonachhoeurng by the way, I'm not sure if this is the right place to discuss this. This tracker is used for Behat development, and Behat doesn't have (or will have) native support for running tests in parallel (see https://github.com/Behat/Behat/issues/159#issuecomment-168751860).

@jakzal yes, sure for this. I can try other way, thanks for anyway suggestion.


parse_curl_response: Handle duplicate headers

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Before #parse_curl_output was introduced and related methods were updated to use it, #url_protected_by_cloudflare? and #url_protected_by_incapsula? were checking a string of all the headers from a response and using a regex to check related header values.
However, when #curl_http_content_headers_and_checksum was updated to use #parse_curl_output internally, the :headers value became a hash generated by #parse_curl_response. The #url_protected_by_* methods were updated in #13198 to work with the hash value but this wasn't able to fully replicate the previous behavior because #parse_curl_response was only keeping the last instance of a given header (maintaining pre-existing behavior). This is an issue for these methods because they check Set-Cookie headers and there can be multiple instances of this header in a response.
#parse_curl_response only keeps the last instance of a given header (following pre-existing parsing behavior), so the #url_protected_by_* methods went from checking all headers to only checking the last instance of a header. This is an issue for these methods because they check Set-Cookie headers and there can be multiple instances of this header in a response.
This PR updates #parse_curl_response to collect the values of headers that appear more than once into an array (otherwise continuing to use a string value if there's only one instance of a given header in a response). Going forward, we'll have to be careful to check a header's type when we know a given header can appear more than once. With headers that should only appear once, we can continue to assume the value will be a string when present.
With that change in place, this updates the #url_protected_by_* methods to handle an array of strings in addition to the existing string support. This change ensures that these methods properly check all Set-Cookie headers, effectively reinstating the previous behavior.
Lastly, this updates one of the early return values in #url_protected_by_cloudflare? to be false instead of an implicit nil. After adding a type signature to this method, it became clear that it wasn't always returning a boolean value and this fixes it.

Past that, I've added docs comments, type signatures, and tests for the #url_protected_by_* methods. The Incapsula tests are currently contrived (i.e., not necessarily representative of a real response) because I couldn't find a website that would trigger the Incapsula/Imperva protection response. I used to encounter this in the wild somewhat regularly when running an automated browser (e.g., using chromedriver and geckodriver) through a commercial VPN but I haven't seen it for a while.
I tried parts of corsair.com (referencing the existing comment before the method) but didn't have any luck (again, using an automated browser behind a VPN to try to look more suspicious). If anyone knows of a website that uses Incapsula/Imperva and can trigger the protection under certain circumstances, let me know and I'll update the tests. Otherwise, I left a TODO comment and we can revisit this if/when we encounter a working example in the future.

Review period will end on 2022-05-04 at 16:14:31 UTC.

Review period ended.

Merging now. Thanks for the feedback, as always!


Remove legacy Convolution.conv2d etc methods

I don't believe these have been maintained or updated:
https://github.com/deeplearning4j/nd4j/blob/bb0b237281ccd7b23b295ed380377a9861c71ec2/nd4j-backends/nd4j-api-parent/nd4j-api/src/main/java/org/nd4j/linalg/convolution/Convolution.java#L349-L422
Either they should be removed, or updated to ensure they work (with tests).

I believe some of those were used as comparative tests for new implementations
With best regards,
Vyacheslav K.

On Apr 12, 2018, at 22:54, Alex Black<EMAIL_ADDRESS>wrote:
I don't believe these have been maintained or updated:
https://github.com/deeplearning4j/nd4j/blob/bb0b237281ccd7b23b295ed380377a9861c71ec2/nd4j-backends/nd4j-api-parent/nd4j-api/src/main/java/org/nd4j/linalg/convolution/Convolution.java#L349-L422
Either they should be removed, or updated to ensure they work (with tests).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


gpio options not working

I wired up my led and button as shown in https://github.com/ZerBea/hcxdumptool/blob/master/docs/gpiowait.odg, but when I start hcxdumptool with hcxdumptool -i wlan1  --enable_status=19 --gpio_button=4 --gpio_statusled=17, hcxdumptool instantly terminates after startup. When I omit the --gpio_button option, hcxdumptool works but the connected LED still doesn't light up.
hcxdumptool output:
start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan1
INTERFACE HARDWARE MAC....: 940c6d896175
DRIVER....................: ath9k_htc
DRIVER VERSION............: 4.19.118-Re4son-v7+
DRIVER FIRMWARE VERSION...: 1.4
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......: 00bb3ae6be05 (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 00bb3ae6be06 (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 00bb3ae6be07 (incremented on every new client)
ROGUE (CLIENT)............: b0ece17ff7f7
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 61448
ANONCE....................: 440ca3a8bada6205a2f6986ad721d5b9e10e0150bf01dd18a3b4540010360380
SNONCE....................: 8073bb4b89c5b2759eb3c444f08ae11a4585363b2ba285808e3c1faba1e66fe4

terminating...

My hcxdumptool version is 6.0.7-33-g570cca4

Double check you circut. On startup hcxdumptool check the status of the pull down resistors (330 Ohm and 10 KOhm). This resistors are mandatory to ground the line. Otherwise hcxdumptool assume the line is high and terminates.

What Raspberry Pi model do you use?

 I'll rewire the entire thing

Let's do another test to make sure the RPI 3 is detected correctly:
Please add a printf() here:
https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L5774
gpiobasemem = getrpirev();
printf("\n\ndebug  %08x\n\n", gpiobasemem);
if(gpiobasemem == 0)

we expect to see value of GPIO_PERI_BASE_NEW = 0x3F000000

BTW:
It happened very often to me, that the wires are connected the wrong way. The RPIU doesn't break, because the lines are secured by resistors, but it will not work as expected.

What I did wrong in my photo was that I assumed that the main lines in that breadboard are interconnected vertically, when they're actually connected horizontally...

Correct, I have a similar kind of a board.

Alright, I did the change in hcxdumptool.c and now I get this output
kali@kali:~/hcxdumptool$ sudo hcxdumptool -i wlan1 --enable_status=19 --gpio_button=4 gpio_statusled=17
initialization...

debug  3f000000

warning: NetworkManager is running with pid 485
 (possible interfering hcxdumptool)
warning: wpa_supplicant is running with pid 578
 (possible interfering hcxdumptool)

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan1
INTERFACE HARDWARE MAC....: 940c6d896175
DRIVER....................: ath9k_htc
DRIVER VERSION............: 4.19.118-Re4son-v7+
DRIVER FIRMWARE VERSION...: 1.4
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......: 18421d7f2343 (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 18421d7f2344 (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 18421d7f2345 (incremented on every new client)
ROGUE (CLIENT)............: b025aa7426ff
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 64539
ANONCE....................: 287f33bad44643f069753c780c2894586c954fd6cd831bf6dc157a72bf252d90
SNONCE....................: d958f7b67edf7e6567100d5a329f923c571fcf249c1274046c988d069ad3fc1a

terminating...

My new circuit looks like this:

(red = 3.3v, black = ground, yellow = 7 (gpio 4), orange = 11 (gpio 17)

Great. The RPI 3 is detected and teh GPIO is initialized as expceted.
warning: NetworkManager is running with pid 485
(possible interfering hcxdumptool)
warning: wpa_supplicant is running with pid 578
(possible interfering hcxdumptool)
Both services must be stopped.
But there is still something wrong with the wiring.
Please try without --gpio_button=4 and check if the LED is flashsing.
Also please use --enable_status=95 to get more warnings and status messages.

NetworkManager and wpa_supplicant aren't interfering, I sucesfully used hcxdumptool before with both of these running and no issued occured.
However, I stopped wpa_supplicant service and marked wlan1 as unmanaged in nmcli.
Test without button:
kali@kali:~/hcxdumptool$ sudo hcxdumptool -i wlan1 --enable_status=95 gpio_statusled=17
initialization...
warning: NetworkManager is running with pid 485
 (possible interfering hcxdumptool)
warning: wpa_supplicant is running with pid 1613
 (possible interfering hcxdumptool)

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan1
INTERFACE HARDWARE MAC....: 940c6d896175
DRIVER....................: ath9k_htc
DRIVER VERSION............: 4.19.118-Re4son-v7+
DRIVER FIRMWARE VERSION...: 1.4
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......: 00a0546e6b08 (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 00a0546e6b09 (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 00a0546e6b0a (incremented on every new client)
ROGUE (CLIENT)............: b025aa186414
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 63025
ANONCE....................: 2a2883f393fa281c32584b8f848b7652ea6a1fb3a0b2e997c9fce44407cda29d
SNONCE....................: 174aa5c442803c4ff96174aff964d3a0f9ee5eb22e48cf1cef158c694ffc9f0e

... normal hcxdumptool activity

LED is NOT blinking.
Test with button:
kali@kali:~/hcxdumptool$ sudo hcxdumptool -i wlan1 --enable_status=95 --gpio_button=4 gpio_statusled=17
initialization...

debug  3f000000

warning: NetworkManager is running with pid 485
 (possible interfering hcxdumptool)
warning: wpa_supplicant is running with pid 1613
 (possible interfering hcxdumptool)

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlan1
INTERFACE HARDWARE MAC....: 940c6d896175
DRIVER....................: ath9k_htc
DRIVER VERSION............: 4.19.118-Re4son-v7+
DRIVER FIRMWARE VERSION...: 1.4
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......:<PHONE_NUMBER>34 (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......:<PHONE_NUMBER>35 (BROADCAST OPEN)
ROGUE (ACCESS POINT)......:<PHONE_NUMBER>36 (incremented on every new client)
ROGUE (CLIENT)............: dc70147d8cd5
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 62787
ANONCE....................: 3b19d3e8d2a3026fa3255f446b3b4d15bee434eb6f226bb80c7d35983ab8a010
SNONCE....................: 72dc85d8211cda47f9eed6adf8984c08ae93ce868f71920f5e6bc1a053084ede

terminating...

ACT LED on Rpi blinks once

To stop the services, was only a notice. That doesn't affect the GPIO.
Let's double check that the besemamory is ok:
$ xxd -c 4 -g 4 /proc/device-tree/soc/ranges
should show something like this:
00000000: 7e000000 ~...
00000004: 3f000000 ?..
00000008: 02000000 ....
...
where this
3f000000
is the base mamory.

Please check also the value of the pull down resistors (should be 330 Ohm and 10KOhm).

Additional you can use wiringpi to verify that the pus butto is really working:
https://raspberrypihq.com/use-a-push-button-with-raspberry-pi-gpio/
http://wiringpi.com/examples/quick2wire-and-wiringpi/install-and-testing/
And you can use the "blink" program to test your LED.

xxd -c 4 -g 4 /proc/device-tree/soc/ranges output:
00000000: 7e000000  ~...
00000004: 3f000000  ?...
00000008: 01000000  ....
0000000c: 40000000  @...
00000010: 40000000  @...
00000014: 00001000  ....

I checked resistor values with my multimeter and confirmed that they're correct.
While probing the circuit, I noticed that the button was in a wrong rotation so it wasn't working - I had to rotate it 90 degrees clockwise so the pins are actually working...
After this fix, it seems that the led and button are indeed working correctly.  Thank you very much for all your help and time.

No problem. Wiring the circuit is a little bit tricky. After assembling a new system, I always had to double check the circuit. And every time I checked it, I found some wiring issues (due to finger trouble).

Push button and LED are not hard coded, so you can use every GPIO pin you like.

Yeah, I'm aware of that. I'll see if I can design a case for Rpi3b+ that will also house an RTC and the whole setup will run both Kismet on internal WiFi and hcxdumptool on external.

Correct. Additional hcxdumptool has a big advantage. Neither kismet, nor aircrack-ng nor Wireshark/tshark provide this:
hcxdumptool request missing packets from the target! So we have no(!) packet loss.


onModelAfterUpdate hook blocking writes to collection

The onModelAfterUpdate hook is triggered after successfully updating an existing model in the DB. My understanding is that fields in the collection are updated, and only then is the hook is triggered once that data is written into the DB meaning that any code in the hook is run only after the record has been updated in the DB. However, I'm finding that if I write data into the DB using the admin UI, but my hook has an error in it, it prevents the data being written to the DB.
Steps:

Create hook in pb_hooks folder

// onModelAfterUpdate hook is triggered after successfully updating existing model in the DB.
onModelAfterUpdate((e) => {
	throw new Error("Not implemented");
}, "test_collection");

Go to Admin panel and modify existing record in the test_collection collection
Admin panel shows error: Failed to update record.

Please do shout if I've misunderstood the expected behaviour!

The record is updated (you can refresh the admin) but the error is surfaced to the API and this is expected.


Dishonored 2 - Overallocating memory

I tried to play Dishonored 2 with DXVK, and problem occurs with memory allocation. I tested it out on both, Linux and Windows backend and problem source seems to be the same. I have 4GB of VRAM on my graphics card (usually enough for me), but in case of Dishonored 2, game started to allocate more than 4GB. On Linux game allocated memory in swap and killed performance, on Windows+DXVK application gets terminated because of insufficient memory. The same problem doesn't happen with native DX11.
I already tried to report that through comment on Proton issue, but it seems to be strictly DXVK related
https://github.com/ValveSoftware/Proton/issues/823#issuecomment-502182111
Problem recorded with OBS, settings very high with high textures at the end https://youtu.be/JBmaR1pT4tI?t=195
Software information
Dishonored 2, settings on high
System information

GPU: Radeon RX470 4GB
Driver: Mesa 19.0.6 / 19.6.1 on Windows
Wine version: 4.10
DXVK version: 1.2.2

Log files
(Files from Windows, I can revert my rig to Linux if needed)
Dishonored2_d3d11.log
Dishonored2_dxgi.log

If you don't have enough memory, don't use settings that require more memory that you actually have.
DXVK does inherently have some memory overhead (mostly on system RAM) since it has to keep both the D3D and Vulkan representations of each object in memory, there's nothing to fix here.

@doitsujin the game does this with 8gb vram at 1440p too: if I enter a new area and then alt-tab 1-2 times then it'll consume all of the vram and the fps will drop below 5. This is relevant for #1148 and for many proton reports this is the source of the slow-downs and crashes: https://www.protondb.com/app/403640

@trialism, since then, I have modified my setup a bit. For this game and this game only I have switched Vulkan driver to AMDVLK (it's still Mesa for any other application) and this problem is gone! I don't know if this issue is to be reported rather to RADV team than here anymore.


Invalid write to a sparse field doesn't give an error

https://github.com/dawn-ico/dusk/blob/ad57bd5a3a2568e83b3bd13aacc9daedbcdf86f4/tests/stencils/test_sparse_fill.py#L104-L112

will be fixed with (this dawn PR)[https://github.com/MeteoSwiss-APN/dawn/pull/1025]


Keyboard avoiding broken second and subsequent time a text input is focused

Hi,
Thanks so much for making this available!  Your components look great and I'm eager to use them.
There seems to be a bug in your keyboard avoiding on text inputs in your Kitten Tricks iOS app.  I just downloaded the latest version from the iOS App Store, 1.0.9, on iOS 11 on an iPhone 6.
Here's what happens:

Launch app.
Tap Auth from Grid Menu.
Tap Login V1 from Login Menu.
Tap Username text input field.  The scrollview containing the Username field scrolls up to avoid the keyboard.  Good!
Type something into the Username field using the onscreen keyboard.
Tap Login to dismiss the screen.
Repeat steps 3-5 again.  This time, at step 4, the scrollview does NOT scroll up to avoid the keyboard, and it obscures the the Username field.  This seems broken.

I do notice that in step 6, the first time around, the keyboard does not dismiss until after the login screen has been popped off the nav stack and we've returned to the main Login Menu.  Not sure if that helps.
I'm happy to try stuff or attach debug logs if you can give me some hints.
I'd really love to use (and credit) your kitten UI, but I'm hesitant to do so if the keyboard avoiding behavior doesn't work consistently.
Any ideas?
Thanks, and thanks again for making this available!

Sorry, I didn't see https://github.com/akveo/react-native-ui-kitten/issues/36 when I created my issue, but they seem to be related ...


[Android] use explicit not-exported flag for AudioBecomingNoisyReceiver

Add RECEIVER_NOT_EXPORTED flag support to AudioBecomingNoisyReceiver for Android 14 support. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, apps using this dependency and targeting SDK 34 will crash when we attempt to register this receiver:
SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts

@AndyG were you able to compile library without bumping androidx.core version? currently we have 1.1.0 but  RECEIVER_NOT_EXPORTED seems to be added in 1.9.0

nope, def want to bump that, will make the necessary changes, test, and ping when ready. thanks for taking a look!

@KrzysztofMoch I bumped that dependency and some related dependencies to keep them roughly in sync. I was able to use this source on a local build of my own app. Please let me know if you have any further concerns -- excited to help here but my react-native build tools experience is limited to be totally candid so a second opinion is extremely valuable.

Thanks, I do some tests and we need to change some versions in order to keep kotlin version at 1.7.0:

androidx.core:core:1.12.0 -> androidx.core:core:1.9.0
androidx.activity:activity:1.8.0 -> androidx.activity:activity:1.6.0

And we need to set minimal kotlin version to 1.7.0 (currently 1.6.20) but I will do it in separate PR.
@freeboub I have checked and this (1.7.0) is recommended version in react native library template

okay thanks for the heads up. I have made those two changes in this PR, but not the kotlin version. Let me know how I can best support you to get this merged and released!


feat(210) settings page

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Please provide enough information so that others can review your pull request:
MR adds new settings page for admins. For the time being this is more of a proof of concept for future settings.
At the moment one can change two values, app_logo and app_name.
App_name is to be a pretend value for the apps name.
App_logo stores the page to an image file uploaded and this will be used as the app's logo image.
Explain the details for making this change. What existing problem does the pull request solve?
This does not solve any bugs. Adds Settings page feature.
Test plan (required)
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Unit tests for the Settings model and controller can be run with php artisan test
Frontend Tests can be run with npm run jest
Closing issues
List all issues this PR resolves.

Closes #210

Pre-Merge checklist
Complete these items before requesting reviews

[ ] Static Analysis Rules Validated
[ ] All commits follow naming conventions

Sub-tasks Checklist

[ ] UI Implementation
[ ] UI Test
[ ] Backend Implementation
[ ] Backend Tests
[ ] Integration Tests
[ ] System Tests

@alexstojda Once this feature is complete and ready, i will need to make sure CI is using the latest version of our docker image. At the moment, it is failing because it is missing the php GD plugin.

Functions as required, code looks ready to extend into a full settings page. The issue mentions restricting access to the page based on a system setting permission, are we putting this out of scope for now? Assuming we are, I approve.

As we are having issues for Permissions, the application and restrictions will be out of scope for now. Once we have this feature, we will implement the required permissions.


circleci tests not running

.circleci/config.yml was added in https://github.com/prometheus/prombench/pull/213 but tests don't seem to be running on new PRs. prombench is enabled in circleci as @krasi-georgiev stated.
more info: https://circleci.com/docs/2.0/enable-checks/#github-checks-waiting-for-status-in-github
cc @SuperQ  @simonpasquier

I believe it should be fixed now (see https://github.com/prometheus/prombench/pull/216 which also reuses the new Circle CI orb). The last missing bit was to enable the CI for pull requests from forks.
You'd need to update your open PRs to trigger the CI again.


Fine-tune SAM model on smaller image sizes for efficient feature extraction.

The issue you're encountering is due to the fact that the pretrained SAM model expects input images of size 1024x1024. While you could resize the images, as you mentioned, it may be computationally and memory inefficient.
One solution to this problem is to fine-tune the SAM model on your specific dataset with smaller image sizes (e.g., 64x64) before using it for feature extraction. By fine-tuning the model on your smaller images, the model will be better suited to handling the reduced input size.
To do this, you'll need to adjust the model architecture to accept the smaller image sizes, specifically by changing the positional embeddings in the model. You might need to modify the code to allow for dynamic positional embeddings that can adapt to different input sizes. Keep in mind that making these changes may require a good understanding of the underlying model architecture and some experimentation.
Once you've fine-tuned the model on your smaller images, you can use the image_encoder to extract features more efficiently.

Hi @Aryan-Mishra24 ,
Thanks for sharing the great insights. Would it be possible for you to share some examples of fine-tuning it on customized datasets?

Hi @JunMa11,
Sure, here are a couple of examples to help you understand the fine-tuning process on customized datasets:
Small Image Dataset: Suppose you have a dataset of 64x64 images of animals. First, adjust the SAM model architecture to accept the smaller image sizes by modifying the positional embeddings. Next, split the dataset into training and validation sets. Fine-tune the model using the training set and evaluate its performance on the validation set.
Domain-specific Dataset: Imagine you have a dataset of medical images (e.g., X-rays or MRIs) with varying sizes. First, preprocess the images by resizing them to a consistent size compatible with the SAM model (e.g., 256x256). Then, modify the model's architecture if needed, and proceed to fine-tune it using the training set. Evaluate the model's performance on the validation set to ensure it has adapted to the domain-specific features.
Remember to monitor the training loss and validation metrics (e.g., accuracy, F1 score) during the fine-tuning process to ensure that the model is converging and not overfitting.
I hope these examples help clarify the fine-tuning process on customized datasets. Let me know if you have any further questions!

Am I understanding you, @Aryan-Mishra24, correctly, that the base model does not have to be retrained? How does this work?


To do before release

Hi guys, vue-test-utils has been in beta for a couple months now, and the feedback we've got has been really helpful.
There are a few things left to do before we release 1.0.0:

[x] Add deprecation notice to hasClass, hasAttribute, and hasProp, in favor of classes, attributes, and props
[ ] Add support for async components #245
[ ] Fix bug with keyed transitions #52
[ ] Add docs for testing components that have asynchronous calls #151
[ ] Add support for inheritAttrs #146
[ ] Add support for testing scoped slot values #156
[ ] Improve support for vue.extends #248
[ ] Add docs on what/ how to test

If anyone has any additional items they think should be added to the list, leave a comment 🙂

I think you have the wrong issue reference for Add docs for testing components that have asynchronous calls ?
I am interested in writing docs for this! This basically refers to anything using async or a Promise, right?
Maybe we can put it under the guides section.

Yes, I think we should add it to the guides section. That would be great if you could write it 🙂

I would like to do this, I will have time after the 19th.
Also, I think we should add something about what to test. A lot of people have problems, when they are testing things using vue test utils that it shouldn't be used for (like testing other people's components).
Not directly related to this library, but I think providing an official library that will become a big part of the ecosystem, some solid guides on how to use it, and not just what it does but what it does not/should not do would be valuable.
I gave a presentation last night about vue-test-utils at v-meetup in Tokyo, and talked to a bunch of people, and one of the main feedback points was "better ways to select things, like calendar inputs".
I think what people are doing is unit testing components that have child components which wrap  and , which I don't think should be the job of vue-test-utils (unless of course you are authoring a input wrapper component). The line between unit tests and integration tests is pretty blurred for a lot of people.

Yeah I agree, I'll add it to the list

IMHO,
I think it is better that Add docs on what/ how to test is in cookbook.

@38elements I can see your line of thinking. I feel like some test specific guides, with lots of details, would be great to include with vue-test-utils docs, and some more general ones referring to vue-test-utils in the cookbook.

Is it possible to get beta.9 released in the meantime? Having .attributes() broken is a bit of pain 😄

@robcresswell just released

Would you please update document page?

Great work @eddyerburgh !

These are the two blockers:

Improve support for extended components
Fix synchronous bugs

The synchronous bugs will be fixed with a small amount of work after the next Vue version is released.
The support for extended components is a major issue, and might require a change to how the library works. Currently we extend components from a Vue constructor that includes added instance proeprties/ stubs. This is fine for component option objects, but Vue.extend is not intended to be used with a constructor function. This has lead to a few bugs that are difficult to fix.
Apart from that there are a few smaller bugs that could be fixed (like #973). I would appreciate help with them, but they aren't blocking from release.

Improve support for extended components

I'm now trying to integrate the unit test feature using vue-test-utils into a cli tools.But it was blocking by the issue above because we use typescript and vue-class-component in project.
WISH you guys can fix it. FIGHTING!!

@eddyerburgh I really enjoy using vue-test-utils and am looking forward to release!
However, I am not sure two blockers causes and solutions so I want to clarify them.
Improve support for extended components
Cause
You mean below.

Vue.extend is not intended to be used with a constructor function. This has lead to a few bugs that are difficult to fix.

In my understanding...
// OK: intended usage
const BaseComponent = Vue.extend({
  ~~~~~~ some options ~~~~~~
});

// NG: not intended usage
const ChildComponent = new BaseComponent({
  ~~~~~~ some options ~~~~~~
})

Is it correct?
Solution
You are trying to solve this problem by below issue.
https://github.com/vuejs/vue-test-utils/pull/1084
Fix synchronous bugs
Cause
sync mode of vue-test-utils.
However, you mean ...

The synchronous bugs will be fixed with a small amount of work after the next Vue version is released.

I am not sure what next Vue version(version 3?) brings.
Would you share details ?
Solution
below issue.
https://github.com/vuejs/vue-test-utils/issues/1137

The problem is that our customers don't trust packages that are in beta as a general policy. I personally think this is a great project, especially since I dont find a simple way to unit test without it.
It is also mentioned in all the official docs, tutorials etc. so good job there.
So I have 2 questions:

Is solving the mentioned blockers really necessary for a release?
The same as @Mikilll94  "When will be the stable version released?" as I dont see, if the tickets are planned soon, or how long they would take to fix.

I don't intend to pressure anything, rather trying to find out what decision to make.

@telion2
Exactly. For me it is very strange that almost all Vue tutorial, official Vue docs, official Vuetify docs etc. mention this package although it is in beta. Even Vue CLI add this package to the project if we select "unit tests".
Most programmers and companies don't trust beta packages and this generally not a good practice to use beta software in production.

I'm surprised your customers are looking at the devDependencies in your projects. That's a good thing, I guess!
Anyway, I agree. I think we can look at a 1.0 after the PRs are merged.

https://github.com/vuejs/vue-test-utils/pull/1492
https://github.com/vuejs/vue-test-utils/pull/1491
https://github.com/vuejs/vue-test-utils/pull/1411 <- not sure how breaking this is

And call it 1.0. We could say 2.x will be Vue 3 support. Let me ask some other contributors to make sure everyone is on board: @JessicaSachs @afontcu and @dobromir-hristov
This will mean no more API changes. 2.x will likely have a slightly different API, since Vue 3 internals changed a bit, and some things don't make much sense (createLocalVue and mocks, since attaching to the prototype will be less common).

So looking into them, then the first two PRs only need a Review and the last one needs to upgrade  vuetify related stuff. Thank you for the information and your time^^.

I'm OK with shipping v1, this will leave us plenty of time and a stable context for v2.
by the way, #1309 looks like has some breaking changes, so I guess we should decide if tackle it before a proper 1.0 release.
Thanks for moving this forward!  🙌

Can't wait for the release.

I can't gauge how important it is to merge #1309. I never use shallowMount - is this an important one to merged up?
If it's too breaking, we may just be better abandoning it. I think VTU has had enough breaking changes at this point.

I think we can omit this from the v1 release. There are two workarounds:

use mount
write your own stub that implements the named slots

Just saw this release: https://github.com/vuejs/vue-test-utils/releases/tag/v1.0.0-beta.33
Just so that I dont missunderstand it: Is this an intended beta prerelease and the release is coming, or should it have been the real release?

Alright, after #1492 let's do v1. I'll follow up on it.

Hi there again.
The last beta release notes: "Note: this is the final beta. Next will be 1.0."
#1492 also looks like its merged.
Is there any holdup or PR that needs to be merged for the release?  Thank you in advance!

In VTU next here we made some changes to the API:

when using find(Foo) when finding a component, you will now do findComponent(Foo). find will just be for DOM elements.
destroy is now named unmount (to match Vue 3 API change)
mocks and stubs are "global", so we moved them to a "global" API:

wrapper(Foo, {
  globals: {
    stubs: ...
    mocks: ...
  }
})

As opposed to things like data, which are local to the component.
I'd like to backport, or at least add deprecation warnings for these features before v1. I plan to do that this week sometime.

add a "deprecation" for when people use find with a component. Also support findComponent as an alias to find.
add a globals key (support both mocks and globals.mocks for example). Deprecation message when using mocks (no global key)
deprecation message for destroy. Support unmount as an alias.

The updated VTU next is here.
If you are interested in making these changes, feel free to do so, and we can get things moving more quickly. Not strictly required for v1, but I think it will help people migrating to Vue 3.

Ok, once this RFC is merged in I will add deprecation warnings and release v1.


What 'introduced' version to use in API docs for calls with incompatible changes?

For example, duk_safe_call() gets a userdata argument in Duktape 2.x which is a source incompatible change. Should the call be listed as "new in 2.0.0" in the API documentation, i.e. it would appear in the "2.0.0" tag list of the api.html page?
One alternative is to keep the original introduced-version for calls where the essential semantics are the same as previously with maybe new arguments or flags, but add some metadata key indicating last incompatible change.

So far "introduced" has been bumped for API calls with incompatible changes but this can be changed before 2.0.0 is released.

I think bumping the "introduced" version is misleading, unless the API has changed in some fundamental way.  Adding a separate metadata field seems like a better solution to me.

The issue I'm mostly thinking about is how does one notice that an incompatible change has been made when looking at the API documentation. If "introduced" is bumped, it will be apparent by looking at the list of API calls "introduced" in 2.0.0. If it isn't bumped, the incompatible change won't be apparent at all which would be bad.

Hm, maybe the problem isn't with the bumping itself, but the word "introduced".  We could rename the field, but there's another issue: It's a supported and documented scenario that some users may wish to support multiple Duktape versions.  Bumping "introduced" to 2.0.0 gives no indication that the API is actually available (in a slightly different form) in the previous version(s).

True that. Well, I won't touch the introduced versions for now in other pulls.

Related issue: should the YAML metadata files of removed calls be removed from the tree or should there be a "removed" metadata item which would then drop them from the generated API documentation. So far in 2.x changes the YAML metadata files have been removed when a call was removed.

Hm, keeping metadata for removed calls around could bloat the repository after a while.  I think removing them is probably for the best.  Of course, if we go that route, then there's really no reason not to go all-in and bump the "introduced" versions as well...
Is there any API documentation included in the dist?  If so it'd probably be okay for the git repo to only reflect the latest API.

Documentation is not currently included in the dist package (though that would be easy to fix and it might be nice to have the static HTML files available for offline viewing etc).
The website has snapshots of documentation for earlier releases, e.g. http://duktape.org/1.0.0/api.html so the old API calls are still viewable there.
I agree it'd be nice to just remove stuff that's no longer part of the API, unless there's some actual use case where that metadata matters. For example, removed calls could be part of the API documentation but labelled as such (or perhaps there could be a button "Show removed calls" in the future). In practical terms there's also going to be a longish period where some people will be developing/maintaining a 1.x code base while others will work with the 2.x API only - and the API documentation may need to support both use cases.


feat(dinero.js): minimum and maximum static methods for dinero

static methods minimum/maximum to get from an array of dinero objects the min or max dinero object.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Compliance

[x] My change isn't breaking (it doesn't cause existing functionality to change).
[x] I have read the CONTRIBUTING document.
[x] My code follows the coding style of this project.
[x] I have properly formatted my commit messages with cz-cli, or manually, following the Angular Commit Messages Guidelines.
[x] I have updated the documentation accordingly, or my changes doesn't require documentation changes.
[x] I have added tests to cover my changes, or my changes doesn't require new tests.
[x] All new and existing tests pass.

Really nice implementation @jotaoncode, thank you very much!
I added a bunch of comments as suggestions (so you can apply them directly), mostly naming. Let me know if you have questions!
Also, please don't forget to squash your commits before re-requesting for review.

Hello Sarah, hope you had a great Easter time :) I was wondering if there anything that is missing for this PR, or if I missed anything, will be more than glad to do any change you request.
All the best

Hi @sarahdayan , any plan to release this soon?
Thanks both of you for your work 👍


Revert "build: explicit the build system"

This reverts commit 7bc39e6d9d51e7321bfca8793e21b8066d9859d3.
After this change the readthedoc builds failed because it uses python 3.7

Hi! Do you know why this code was not working?

Hi @Linkid, importlib.metadata has been introduced in python 3.7. And readthedoc uses python 3.7 for building the documents.
I've also reverted https://github.com/jazzband/django-auditlog/commit/a30c8bbfc0a11e510005f80abc3c67cf62226510