Built-in xterm termcap's t_AU and t_8u settings cause blinking/faint text in mintty

Describe the bug
Vim currently sets the t_AU and t_8u termcap extensions (set underline color indexed and RGB, respectively) as follows:

let &t_AU = "\e[58;5;%dm"
let &t_8u = "\e[58;2;%lu;%lu;%lum"

These are originally kitty extensions, but have since been added to more terminals. (hterm, iTerm2, mintty, and VTE are the ones I know of.)
Like the 38 and 48 SGR codes to set RGB foreground and background colors, the SGR 58 code has the same choice of semicolon or colon as subparameter delimiter. However, unlike 38 and 48, there's a lot fewer legacy terminals using the semicolon delimiter. As such, it seems that at least mintty only implemented the colon delimeter, which offers better compatibility with older SGR parsers.
To Reproduce
Detailed steps to reproduce the behavior:
For indexed:

Run vim --clean in mintty.
Execute hi clear SpellBad.
Execute hi SpellBad cterm=underline ctermul=1.
Execute set spell.
Type a misspelt word.
Observe that the misspelt word is now blinking and the underline color is not changed. It appears mintty has parsed this as SGR 58, SGR 5 (blink).

For RGB color:

Run vim --clean in mintty.
Execute hi clear SpellBad.
Execute hi SpellBad cterm=underline guisp=#00ff00.
Execute set termguicolors.
Execute set spell.
Type a misspelt word.
Observe that the misspelt word is now not underlined at all. It appears mintty has parsed this as SGR 58, SGR 2 (dimmed).

Expected behavior
The text in the first case should have a red underline, and in the second case should have a green underline. The text should not blink or be dimmed.
Vim uses semicolon as a subparameter delimiter for SGR 38 and 48, and that's probably needed for compatibility; however, for the newer and much less widespread SGR 58, it looks like the colon delimiter actually has better compatability. It's also more likely be be ignored (instead of incorrectly processed as SGR 2 or SGR 5) on a terminal that doesn't support colored underlines at all. So I suggest the builtin xterm termcap be changed as follows:

let &t_AU = "\e[58:5:%dm"
let &t_8u = "\e[58:2::%lu:%lu:%lum"

(Note the double colon in t_8u; this is indeed part of the syntax.)
I've tested these colon-delimited sequences in hterm, kitty, mintty, and VTE (Sakura) and they all work properly. I can't test iTerm2 since I don't have a Mac, but maybe @gnachman can help verify that?
Environment (please complete the following information):
$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jun  1 2020 06:42:35)
Included patches: 1-869
Compiled by <https://www.msys2.org/>
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             +mouse_sgr         +tag_binary
+arabic            +file_in_path      -mouse_sysmouse    -tag_old_static
+autocmd           +find_in_path      +mouse_urxvt       -tag_any_white
+autochdir         +float             +mouse_xterm       -tcl
-autoservername    +folding           +multi_byte        +termguicolors
-balloon_eval      -footer            +multi_lang        +terminal
+balloon_eval_term +fork()            -mzscheme          +terminfo
-browse            +gettext           +netbeans_intg     +termresponse
++builtin_terms    -hangul_input      +num64             +textobjects
+byte_offset       +iconv             +packages          +textprop
+channel           +insert_expand     +path_extra        +timers
+cindent           +ipv6              +perl/dyn          +title
-clientserver      +job               +persistent_undo   -toolbar
+clipboard         +jumplist          +popupwin          +user_commands
+cmdline_compl     +keymap            +postscript        +vartabs
+cmdline_hist      +lambda            +printer           +vertsplit
+cmdline_info      +langmap           +profile           +virtualedit
+comments          +libcall           +python/dyn        +visual
+conceal           +linebreak         +python3/dyn       +visualextra
+cryptv            +lispindent        +quickfix          +viminfo
+cscope            +listcmds          +reltime           +vreplace
+cursorbind        +localmap          +rightleft         +wildignore
+cursorshape       -lua               +ruby/dyn          +wildmenu
+dialog_con        +menu              +scrollbind        +windows
+diff              +mksession         +signs             +writebackup
+digraphs          +modify_fname      +smartindent       -X11
-dnd               +mouse             -sound             -xfontset
-ebcdic            -mouseshape        +spell             -xim
+emacs_tags        +mouse_dec         +startuptime       -xpm
+eval              -mouse_gpm         +statusline        -xsmp
+ex_extra          -mouse_jsbterm     -sun_workshop      -xterm_clipboard
+extra_search      +mouse_netterm     +syntax            -xterm_save
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim82"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -I/usr/include/ncursesw  -march=x86-64 -mtune=generic -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -pipe -fstack-protector-strong -pipe -Wl,--as-needed -o vim.exe        -lm -lelf    -lncursesw -liconv -lacl -lintl   -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong  -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -ldl -lcrypt

$ uname -a
MINGW64_NT-10.0-19041 holden 3.1.6-340.x86_64 2020-07-17 05:52 UTC x86_64 Msys

$ mintty --version
mintty 3.2.0 (x86_64-pc-msys)
© 2013/2020 Andy Koppe / Thomas Wolff
License GPLv3+: GNU GPL version 3 or later
There is no warranty, to the extent permitted by law.

I could also file a bug against @mintty to support the semicolon delimiter for SGR 58, but it may have been an intentional choice on their part not to support it, since the colon delimiter is less "dangerous" (in the sense that it's easier for terminals that don't support SGR 58 at all to ignore). That ship has probably sailed for 38/48, but doing the right thing (colon) for 58 seems reasonable to me.

I verified that tmux also parses the colon-delimited version of this escape sequence, though it requires something like set -g terminal-overrides '*:Setulc=\E[58::2::%p1%{65536}%/%d::%p1%{256}%/%{255}%&%d::%p1%{255}%&%d%;m' to pass it through to the outer terminal.
As such, assuming iTerm2 supports the colon delimiter, I think the change I proposed is a strict improvement (fixing mintty and being more compatible with SGR parsers not aware of SGR 58, without breaking any terminals that work today).

This was discussed before in various places, arguing that either one or the other was a mistake, and explaining some standard depending on how you read it..  Since the current implementation works in existing terminals, and mintty is a new one, best is to make this work in mintty.  Or make sure to set $TERM to mintty, so that the right termcap/terminfo is used.  As always, setting $TERM to "xterm" or something like that is intended to work with an actual xterm.  It might work with a few others, but we can't possibly guarantee that.

This was discussed before in various places....

Not trying to be a jerk, just curious... can you link me to those previous discussions? I only found discussions in the context of SGR 38/48, and from what I could tell, the general consensus was "colons are safer than semicolons, but the semicolon form is too widespread for applications to use by default". For SGR 58, though, I am not sure that conclusion still holds, since SGR 58 is newer and less widespread (in both terminals and applications).
If the "right thing" is to use colons (which I may have misparsed... that was my understanding), then IMO it'd make sure to use colons for SGR 58 (and possibly for terminal emulators not to implement a semicolon form for SGR 58) even if SGR 38/48 are stuck with semicolons for historical reasoning.
I could also see an argument that doing something different for SGR 58 than for 38/48 is more confusing than it's worth.... I'd be mostly convinced by that; I just want to make sure I understand the reasoning.

Or make sure to set $TERM to mintty, so that the right termcap/terminfo is used.

I'd love to just set $TERM=mintty, FWIW, but I couldn't find a good way to make that work with Vim right now. Codes like t_AU and t_8u seem to be Vim extensions that don't exist in published terminfo databases, only in Vim's builtin xterm termcap. (I wish Vim's builtin termcaps were encoded as Vimscript that could be updated and deployed separately rather than being compiled into Vim, but that seems like a big change and I wasn't sure it was worth proposing.)
I can, of course, work around this with something like
if &term =~# '\vmintty%(-|$)'
  let &t_AU = "\e[58:5:%dm"
  let &t_8u = "\e[58:2::%lu:%lu:%lum"
endif

but then mintty no longer passes Vim's "term is xterm" check, and so I lose all the other useful default Vim termcap extensions for things like bracketed paste, etc. (tmux has the same problem, c.f. #6609.)
Maybe what I really want is a way for Vimscript to override the vim_is_xterm check? I haven't thought through the implications of that, but it would at least unblock setting an accurate $TERM instead of lying and saying xterm all the time.

@brammool,

Since the current implementation works in existing terminals, and mintty is a new one, ...

Puzzled. SGR 58 is not supported in xterm and its semicolon usage makes xterm blink like mintty. If you maintain a strict view of things, you should drop SGR 58 from vim.

I don't maintain a strict view, I just do what works for most users.  Considering the lack of complaints it appears to work quite well.  Of course there are a few individuals, especially ones that try out different terminals, that run into problems.  It's unpredictable what will happen if I change the defaults, most likely more users will complain.
How do you make xterm blink?  I have never seen that.  Please give an example starting with "vim --clean".


Broken avatar css on main page

Description

avatar is cun vertically

Gitea Version
trunk
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
docker
Database
None

regression of #30547

->  Fix dropdown text ellipsis #30628


⚠ Processors has degraded performance

In 5ebba5d, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 50 ms

Resolved: Processors performance has improved in 963ed15.


Distinguish mdns advertisements for registration and register

I ran into a small issue debug some of my components tests over mdns. I was not able to tell the v1.2 advertisement from the v1.3 advertisement since they both included the same "instance_name".
I had to modify the following to have different advertisements.
https://github.com/sony/nmos-cpp/blob/0c94436c4dc95a49fb0dbd8b7a02f1f8b9bd16aa/Development/nmos/mdns.cpp#L204
Should this not return "register"
https://github.com/sony/nmos-cpp/blob/0c94436c4dc95a49fb0dbd8b7a02f1f8b9bd16aa/Development/nmos/mdns.cpp#L261
advertiser.register_service( service_name( nmos::service_types::register_, settings ), nmos::service_types::register_, instance_port, domain, host_name, txt_records).wait();

Is there a particular reason for the current behavior?

The same service (i.e. Registration API) instance, with the same txt records (pri, api_ver, api_proto), is being advertised via two different service types. I don't understand why you would want the instance information to be different.

Simply so that the different service advertisements can easily be distinguished by the name.
I had not come up with they are the same instance so they should be named the same. I just wanted to understand the reasoning behind the current implementation. Thank you for the insight.

If it's necessary to distinguish between them for debugging purposes (on the Node side?) is it possible to just use the service type itself?

Of course that would be possible, however it was faster to modify the server to have different entries. The component test simply were not imagined with that complexity.

OK. Thanks. I can't see a good reason for any change at the moment, so I'll close for now.


PulsarAdmin has a significantly slower performance for creating subscriptions

Expected behavior
PulsarAdmin should have faster performance for subscription creation than creating and closing a Consumer.
At the same time I think that creating 1000 subscriptions during even in ~7 seconds is still a slow performance. It should be much faster.
Actual behavior
When I create subscription with PulsarAdmin, it is significantly slower than if I create a Consumer.
Steps to reproduce
Note: At least until 1.22.0 (including) you can run this performance comparison test only against single-node cluster due to bug #1615
Run the following unit test to check the performance:
    @Test
    public void subscriptionCreatePerformanceComparisonTest() throws Exception
    {
        String host = "vv";
        String cluster = "vv";

        String webServiceUrl = "http://" + host + ":8080";
        String brokerServiceUrl = "pulsar://" + host + ":6650";
        String property = "test-prop-performance";
        String adminRole = "test-admins";
        String namespace = "test-namespace-performance";
        int numberOfSubscriptions = 1000;
        String subscription = "test-subscription";
        ClientConfiguration pulsarConfig = new ClientConfiguration();

        PulsarAdmin pulsarAdmin = new PulsarAdmin(new URL(webServiceUrl), pulsarConfig);
        // create property if not exists
        try
        {
            PropertyAdmin propertyAdmin = new PropertyAdmin();
            propertyAdmin.setAdminRoles(Collections.singletonList(adminRole));
            propertyAdmin.setAllowedClusters(ImmutableSet.of(cluster));
            pulsarAdmin.properties().createProperty(property, propertyAdmin);
        }
        catch (PulsarAdminException.ConflictException ignored)
        {
        }

        String namespaceName = property + "/" + cluster + "/" + namespace;
        // create namespace if not exists
        try
        {
            pulsarAdmin.namespaces().createNamespace(namespaceName);
        }
        catch (PulsarAdminException.ConflictException ignored)
        {
        }

        String result1;
        {
            long start = System.currentTimeMillis();
            CompletableFuture
                    .allOf(IntStream
                            .range(0, numberOfSubscriptions)
                            .mapToObj(i -> {

                                String topic = UUID.randomUUID().toString();
                                String topicName = "persistent://" + namespaceName + "/" + topic;
                                return pulsarAdmin.persistentTopics().createSubscriptionAsync(topicName, subscription, MessageId.earliest);
                            })
                            .toArray(CompletableFuture[]::new))
                    .join();
            long finish = System.currentTimeMillis();
            result1 = "createSubscriptionAsync time: " + (finish - start) / 1000d;
            System.out.println(result1);
        }
        pulsarAdmin.close();

        PulsarClient pulsarClient = PulsarClient.create(brokerServiceUrl, pulsarConfig);

        String result2;
        {
            long start = System.currentTimeMillis();
            CompletableFuture
                    .allOf(IntStream
                            .range(0, numberOfSubscriptions)
                            .mapToObj(i -> {

                                String topic = UUID.randomUUID().toString();
                                String topicName = "persistent://" + namespaceName + "/" + topic;
                                return pulsarClient
                                        .subscribeAsync(topicName, subscription)
                                        .thenComposeAsync(Consumer::closeAsync);
                            })
                            .toArray(CompletableFuture[]::new))
                    .join();
            long finish = System.currentTimeMillis();
            result2 = "subscribeAsync+closeAsync time: " + (finish - start) / 1000d;
        }
        pulsarClient.close();

        System.out.println(result1);
        System.out.println(result2);
    }

Actual output (FYI my ping to the node in test is ~50ms):
[pulsar client logs skipped]
createSubscriptionAsync time: 20.565
subscribeAsync+closeAsync time: 7.113

System configuration
Pulsar version: 1.22.0
Single node/standalone.

@sijie commented:

I think the different is admin.createSubscription is using http protocol, which I think each createSubscription is creating a new connection and close it. (If I remember correctly, http/1.0 doesn’t support multiplexing). while create consumer/close is binary protocol over tcp connection, so connection is multiplexed for different commands.

I would think some features like creating a subscription should be moved to PulsarClient for faster performance with binary protobuf protocol.
At the same time @merlimat noted:

The multiple requests should be using HTTP/1.1 with Keep-Alive

Anyway creating 1000 subscriptions during ~7 seconds is still a slow performance.

Anyway creating 1000 subscriptions during even in ~7 seconds is still a slow performance. It should be much faster.

@zubchenok is this still an issue in 2.2?

Close this issue for now since it was idle for years. Please reopen a new one if needed.


Add back missing ament index path exporting in CMakeLists

Address #32
Adding back the fixes submitted in #22.

@mxgrey it seems like PR https://github.com/open-rmf/rmf_battery/pull/23/files removed these changes that were previously merged in. May I check if that was intentional?

Gotcha, I'll merge this in then.


apriltag_ros: 3.1.0-2 in 'rolling/distribution.yaml' [bloom]

Increasing version of package(s) in repository apriltag_ros to 3.1.0-2:

upstream repository: https://github.com/christianrauch/apriltag_ros.git
release repository: https://github.com/ros2-gbp/apriltag_ros-release.git
distro file: rolling/distribution.yaml
bloom version: 0.11.2
previous version for package: 3.1.0-1

The package build is failing because of a warning (#warning This header is obsolete, please include cv_bridge/cv_bridge.hpp instead). This does not sound critical. Nevertheless, I expected to receive an email if this warning blocks the build.
I am listed as the maintainer and the CI log states

Sending e-mails to: [...]<EMAIL_ADDRESS>
but I did not receive any notification via email (also nothing in the spam folder).
@clalancette  Do I have to do something else to receive the buildfarm emails? Or am I not supposed to receive a notification because this is just a warning?

@clalancette Do I have to do something else to receive the buildfarm emails? Or am I not supposed to receive a notification because this is just a warning?

You only receive notification if the build fails.

You only receive notification if the build fails.

The build log says:

E: Building failed
apt-src build ros-rolling-apriltag-ros failed.

So I assumed it failed.

So I assumed it failed.

You are right, it did fail.  You should have gotten an email.  @nuclearsandwich any thoughts?

You are right, it did fail. You should have gotten an email. @nuclearsandwich any thoughts?

Email deliverability is a deeply complex problem. The build farm attempted to deliver messages to these addresses according to the log
Sending e-mails to<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
I received the message corresponding to that build failure
from: | ROS 2 Buildfarm<EMAIL_ADDRESS>to: | ros2-buildfarm-rolling@googlegroups.com,steven+build.ros2.org<EMAIL_ADDRESS>date: | Jan 24, 2023, 11:03 PM
subject: | Build failed in Jenkins: Rbin_uJ64__apriltag_ros__ubuntu_jammy_amd64__binary #4
mailed-by: | build.ros2.org


CAS-481: wait for message bus

On k8s, even before even attempting to start mayastor we should make
sure that the nats service is ready.

bors merge


fix default options set at SolrDocumentProvider

It just changes the hash key names of the options hash to put them into the :provider key.

I forgot to mention that this PR includes as well the ability to pass lambdas as options hash values. This will allow setting the provider options per request.

This seems like a good idea to me.  I spun up a local instance of our oai provider and it seems to work perfectly fine (at least in our case at Temple).


chore: updated interactive-clap, stated all the features

CC: @race-of-sloths

🙁 This repository is not a part of the Race of Sloths
Please ask the maintainer to contact us to join the race!
What is the Race of Sloths

Race of Sloths is a friendly competition where you can participate in challenges and compete with other open-source contributors within your normal workflow
For contributors:

Tag us inside your pull requests
Wait for the maintainer to review and score your pull request
Check out your position in the Leaderboard
Keep weekly and monthly streaks to reach higher positions
Boast your contributions with a dynamic picture of your Profile

For maintainers:

Score pull requests that participate in the Race of Sloths
Engage contributors with fair scoring and fast responses so they keep their streaks
Promote the Race to the point where the Race starts promoting you
Grow the community of your contributors

Feel free to check our website for additional details!

@race-of-sloths

❓Unknown command
Please check the command and try again


Update node count for kind cluster on CI

Signed-off-by: Sneha Chhabria<EMAIL_ADDRESS>Description:
Affected area:

Functional Area

CI System
[X]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? no

Did you notify the maintainers and provide attribution?

Is this a breaking change? no

Codecov Report

Merging #3813 (8c742b8) into main (6a113b2) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #3813      +/-   ##
==========================================
- Coverage   67.52%   67.51%   -0.01%
==========================================
  Files         198      198
  Lines       10926    10926
==========================================
- Hits         7378     7377       -1
- Misses       3499     3500       +1
  Partials       49       49

Flag
Coverage Δ

unittests
67.51% <ø> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...icate/providers/certmanager/certificate_manager.go
85.91% <0.00%> (-0.71%)
: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 6a113b2...8c742b8. Read the comment docs.


Add media upgrade offer callback for a new call

MOB-1880 broke the "start new Audio/Video engagement" flow . That's why acceptance tests are failing now (example app crashes on 'Start new audio call' menu item tap).
What this pull request does:

Adds media upgrade offer callback for a new Audio/Video engagement flow  -  callback still need to be added from the init() function.
Changing collection type to Set to prevent callback duplication.

!merge


Fix the wrong value of queryId in example files

Modified the value of queryId from integer to string in example files
To fix the Linter Validation Error

/azp run

/azp run


what is the meaning of ‘box_loss_scale’ and why calculate in this way? I am confused

box_loss_scale = 2 - y_true[l][..., 2:3] * y_true[l][..., 3:4]

The box_loss_scale is a value in the range of 1~2.
It means that for smaller objects, they will have larger weights.
On the other hand, larger objects will have smaller weights.

oh,I see. Thank you very much!


Fix the build

First thing I'm trying, don't run trusted type tests in ancient browsers.

I'm going to try some things on this branch too


Fasttext models seems too slow

It might be due to the models loading during the encoding process

Yeah, the model definitely loads at the first encode() call, which happens before we monitor speed. FastText is just hella slow.
I was actually thinking about potentially dropping it for this reason. I have a couple of ideas for what to replace it with it if we want to:

Use SpaCy models' Tok2Vec layer as it is a bloom embedding, aka way less memory, and is also significantly faster.
Package some static word embedding models as SentenceTransformers, as they do here. This would take a bit of time, as we would have to build the models from scratch, but we would need significantly less code in SEB, and would make it easier for others to use and download prepackaged scandinavian word embeddings.
Use Gensim with hand-picked static word embedding models. This would have the same result as the SentenceTransformers solution, but would result in more code in SEB as the models have to be downloaded and used.

@KennethEnevoldsen do we want to do anything with this beyond removing them from the tests or just close this?

Yeah, the model definitely loads at the first encode() call, which happens before we monitor speed. FastText is just hella slow.

I right might just be how it should be then. Will close this for now then

re-opening this as it is likely to look suspicious in figure in the paper.

I'm not sure it's a bug though, the thing is really damn slow, and again the model loads before the speed test, so the numbers should be accurate. The only thing we can do is choose a different model.

in the #143 I reran the fasttext models. They were waaay faster (nothing changed just reran it), might have been run in debug mode the first time.


I can see who the author of a given resource is

As an OSS Concourse user when I go to https://concourse.github.io/dutyfree/ I see the full list of resources and the author handle associated with each resource
So that I can know if the resource has been authored by someone I trust.
Acceptance criteria:
When I go to https://concourse.github.io/dutyfree/ I see the list of resources and the Author handle associated with that resource.
And
The Author handle is linked to the Author profile.
And
The Author profile opens in a new tab
PM Notes: We should include the author beside the resource as agreed with design as per the prototype.
Dev tasks

[x] Add function to Resource to extract author handle (eg concourse)
[x] Add function to Resource to extract author link (eg https://github.com/concourse)
[x] create an <a> tag with author handle as text, and href author link in the index.html page and target blank
[x] Rename resources.go to something else

Accepted by Pivotal-Kevin-Curley . Behaviour is as expected in acceptance criteria. This story was implemented before the page structure so no need for Design input.


Support options when defining and calling functions

Options are now supported:
{ put $opts[a] } &a=haha # outputs haha

However, it is not yet possible to specify which options are accepted in the function signature -- closures now accept all options and store them in $opts.

Slight change in design: Options should have default values:
fn print-ab [a b &verbose=$false]{
    if $verbose; then
        echo "a = "$a", b ="$b
    else
        echo $a$b
    fi
}

print-ab foo bar
print-ab foo bar &verbose=$false # equivalent to above
print-ab foo bar &verbose=$true

(Also updated to reflect syntax change.)


[9.x] introduce a fake() helper to resolve faker singletons, per locale

This PR introduces a global fake() helper to allow you to easily access a shared (singleton) faker instance across your application.
The helper is only created if the function doesn't already exist AND if Faker is installed, which it is only in "dev-dependencies" out of the box.
This is super useful in different scenarios.

Prototyping
Testing
Factories / Seeding

Now some of these are already covered with their own implementations, but this improves the scenario across all.
First, this IMO is much nicer to look at...a little more "high end" some might say 🧐
return [
    'name' => fake()->name(),
];

When it comes to a Rapid Application Development framework like Laravel, speed of prototyping a feature is through the roof. But often you will want to prototype a view without having the even create any backing models or anything. You just wanna throw some tailwind and some blade at the problem and get some eyes on it.
@for($i = 0; $i < 10; $i++)

Name

{{ fake()->name() }}

Phone

{{ fake()->phoneNumber() }}

@endfor

You can also swap between languages, and you'll be guaranteed to always have a singleton for each locale...
fake()->name() // config('app.faker_locale') ?? 'en_US'
fake('en_AU')->name() // en_AU

This makes it nice when you want to ensure unique values across all the different things. You might want to use faker in your factories and in your seeder and be sure that you are getting unique values when you run them in the same thread.
// UserFactory...
function definition()
{
    return [
        'name' => fake()->unique()->name(),
    ];
}

// DB Seeder...

function run()
{
    DB::table('users')->insert(['name' => fake()->unique()->name()]);
}

As with all the helpers, don't use them if you don't like them 👍
PRs suggesting a faker helper have been proposed previously, but hoping with a few more examples of its utility, this might be reconsidered.
This won't conflict with any of the existing framework faker bindings (see DatabaseServiceProvider) as the key is the container is suffixed with a colon and then the locale, .e.g \Faker\Factory:en_US and it is only bound at runtime, not during boot, so if you do not call this function nothing changes.
Previous PRs:

https://github.com/laravel/framework/pull/23451
https://github.com/laravel/framework/pull/41130

pretty handy but I prefer the use of faker() over fake(), since the latter indicates something like a mock-object to me (or some no-op function).

Let me introduce you to Faker memory leak. Now available globally.

Not sure if a Faker instance, which should only be used for testing purposes, should be available at global scope in all environments this way.

@DarkGhostHunter can you elaborate?

Not sure if a Faker instance, which should only be used for testing purposes, should be available at global scope in all environments this way. I'd tend to agree with Taylor in one of the linked PR, if you need it, just implement it in the userland.

Feel free to correct me if I'm wrong, but you've said "in all environments" but the PR defaults to only environments using dev-dependencies rather than all environments?

More often than not I tend to have memory exhaustion problems when I use some of faker texts generators on tests or seeding. Maybe it’s a problem on PHP itself.
Try ‘realText()’ 10.000 times and you will hit the roof.
Italo Baeza C.

El 18-06-2022, a la(s) 01:47, Taylor Otwell @.***> escribió:

@DarkGhostHunter can you elaborate?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@DarkGhostHunter that issue exists regardless of this PR though. The faker instance utilised in database factories is already a container bound singleton.

@DarkGhostHunter that issue exists regardless of this PR though. The faker instance utilised in database factories is already a container bound singleton.

Then I'll have to rant there.

I’m always here for a good rant. I do them often myself haha ☺

More often than not I tend to have memory exhaustion problems when I use some of faker texts generators on tests or seeding. Maybe it’s a problem on PHP itself. Try ‘realText()’ 10.000 times and you will hit the roof. Italo Baeza C.
…
El 18-06-2022, a la(s) 01:47, Taylor Otwell @.***> escribió:  @DarkGhostHunter can you elaborate? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

Off-topic though but I tested some stuff out:
$faker = \Faker\Factory::create();
$start = memory_get_usage();
for ($i = 0; $i <= 10000; $i++) {
    $faker->realText;
}
var_dump(memory_get_usage() - $start);
die('done');

Output (in bytes):
int(6963512) done

Now call the same thing using $faker->realText() (so a function call vs __get() overload):
int(752) done

Idk if that resolves your issue but it appears that calling properties does indeed increase the memory output considerably, also if you increase the length of the loop. It remains mostly static if you use the function call, regardless of loop length.
However I noticed that the Faker code says:
trigger_deprecation('fakerphp/faker', '1.14', 'Accessing property "%s" is deprecated, use "%s()" instead.', $attribute, $attribute);

So it's not recommended to call it using a property anyway.

Thanks, I’ll have to rework some factories then because i always preferred clean property calls.
Italo Baeza C.

El 19-06-2022, a la(s) 10:05, Bert @.***> escribió:

More often than not I tend to have memory exhaustion problems when I use some of faker texts generators on tests or seeding. Maybe it’s a problem on PHP itself. Try ‘realText()’ 10.000 times and you will hit the roof. Italo Baeza C.
…
El 18-06-2022, a la(s) 01:47, Taylor Otwell @.***> escribió:  @DarkGhostHunter can you elaborate? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Off-topic though but I tested some stuff out:
$faker = \Faker\Factory::create();
$start = memory_get_usage();
for ($i = 0; $i <= 10000; $i++) {
$faker->realText;
}
var_dump(memory_get_usage() - $start);
die('done');
Output (in bytes):
int(6963512) done
Now call the same thing using $faker->realText() (so a function call vs __get() overload):
int(752) done
Idk if that resolves your issue but it appears that calling properties does indeed increase the memory output considerably, also if you increase the length of the loop. It remains mostly static if you use the function call, regardless of loop length.
However I noticed that the Faker code says:
trigger_deprecation('fakerphp/faker', '1.14', 'Accessing property "%s" is deprecated, use "%s()" instead.', $attribute, $attribute);
So it's not recommended to call it using a property anyway.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

I know I am not (shamely) a member nor a contributor to the Laravel framework (I will one day!) but after working at least 5 years with Laravel, through out a lot of developers (seniorities), I just found this addition to be very bad:

Why fake and not faker? Looks very confusing when we are all used to faker
I saw lot of ugly and really bad bad BAD code, so allowing someone to use a faker helper globally is really a BAD idea

I do know it is limited to having Faker installed locally in your project (required-dev), but that will allow anyone to do use fake() anywhere and then (if no one catched that) will fail on production because we have the faker installed check on the helper.
As any helper/tool, it can be a double edge sword, you must know what you are doing (most of the time...) but specially helping new people using Laravel + PHP or even joining the development world...
One more "rant", if we want to use it on seeders (as the author mentioned), then we cannot truly do so, as you do not have Faker on production but if you are using a seeder in there you are done...
What I just want to say is that there is no possible test to catch that you are using fake() outside a testing environment, because you would need to remove/delete Faker, but that would prevent tests from running/passing...
That looks like a code smell or similar... Sorry for the rant, but I truly do not believe this adds value at all, specially for new developers (most people using Laravel)...
Still, you are already a member, so thanks for any possible additions you can do to the framework ❤


"state: present" creates basejail but doesn't set changed: true

Creating a basejail does not set "changed: true" as one would expect:
TASK [servers/jail : iocage jail - iocage - XXXXX - create basejail] ***
ok: [jailguest -> jailhost] => "iocage_releases": ["11.0-RELEASE"], "iocage_templates": {}}, "changed": false, "msg": "Jail 'jailguest' was created with properties {'ip4_addr': 'igb0|x.x.x.x/32'}.\n\n/usr/local/sbin/iocage create tag=jailguest release=11.0-RELEASE ip4_addr='igb0|x.x.x.x/32' ", "stderr": "", "stdout": "", "stdout_lines": [], "uuid": "3b21a6ba-1a32-11e7-ab5d-a0369f98b4a0"}

I'll look at this one but not before one week at least...

I can't reproduce here… could you elaborate ?

I can't reproduce here… could you elaborate ?


feat: protect admin routing

protected admin routes in Routes.js and conditionally rendered create sauce button in AllSauces.js

forgot to add the update sauce switch case, will do so in next PR


Resolve context depending picking on picking readback, not during scene build up

We should always render the same picking layer out no matter what is selected at the moment, but right now we may or may not write out InstanceKey::SPLAT for instance keys depending on whether an object or an instance is selectable. This ofc means that the picking layer needs to transfer this semantic so it can be picked up again when resolving a retrieved picking layer rectangle - 0 would mean instance 0, SPLAT means all instances. Instead, we should put this logic in the code that reads the picking layer back.
This would simplify & speed up scene setup a bit. Also, as the default picking layer instance id is zero, it would be easier/more natural to setup rendering of objects without instance ids - right now they need to use the SPLAT instance constant instead.
Related to #1893

Fixed by

#2504


60 tell user report takes time to run

@Andrew-Dickinson Any edits to this?  I could pass the message into upload_report_file() possibly so all the copy is in the same file?


Add pyproject.toml for Custom Node Registry

We are building a global registry for custom nodes (similar to PyPI). The registry makes using custom nodes more reliable by reserving globally unique names for each custom node, and supporting semantic versioning.
Here’s some more information on the registry.
Action Required:

[ ] Go to the registry. Login and create a publisher id. Comment it here and we will update the PR (or just merge it and change it yourself).
[ ] Write a short the description.
[ ] Merge the separate Github Actions PR and run the workflow.

If you want to publish the node manually, install the cli and run comfy node publish
Please message me on Discord if you have any questions!

Thanks! I'm adding this outside the PR so I can update the file contents. Appreciate the add


Due to an error, the doctor check did not complete.

Steps to Reproduce

Installing Android Studio
I check: flutter doctor
I receive a message:
"Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.2.2, on Microsoft Windows [Version 10.0.19042.985], locale ru-RU)
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[√] Chrome - develop for the web
[☠] Android Studio (the doctor check crashed)
X Due to an error, the doctor check did not complete. If the error message below is not helpful, please let us know
about this issue at https://github.com/flutter/flutter/issues.
X FileSystemException: Exists failed, path = 'C:\Program Files\Android\Android Studio" .plugins' (OS Error:
Syntax error in file name, folder name, or volume label.
, errno = 123)
[√] VS Code (version 1.57.0)
[√] Connected device (2 available)

! Doctor found issues in 1 category."

I found a solution from colleagues.
Launch: flutter config --android-studio-dir="C:\Program Files\Android\Android Studio"
Now everything is all right:
"
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.2.2, on Microsoft Windows [Version 10.0.19042.985], locale ru-RU)
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[√] Chrome - develop for the web
[√] Android Studio
[√] VS Code (version 1.57.0)
[√] Connected device (2 available)
• No issues found!
"

@Vladislav-wn If your issue has been solved, it will be great if you close the issue.
Thanks.

Closing this as resolved based on above comment.


711 - publish new function after all changes done

@znotdead There is an open PR with the same fix since Jan 13, 2022: https://github.com/nficano/python-lambda/pull/714

@znotdead There is an open PR with the same fix since Jan 13, 2022: #714

Ooops. Haven't noticed one. Thanks! Wonder why release still not done since JANUARY. Does library supported?


Add 2 additional processing types to taxonomy

Overview
Add processing types that appear on the facility claim profile form but are not yet represented on the taxonomy
Describe the solution you'd like

Add Dyehouse under Printing, Product Dyeing and Laundering
Add Warehouse under Warehousing / Distribution

On Slack Natalie and Mariel confirmed that we can add aliases rather than new entries.


rdio-scanner: init at 6.6.3

Description of changes
Add rdio-scanner, software that ingests and distributes audio files generated by various software-defined radio recorders.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.11 Release Notes (or backporting 23.11 and 24.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.

Add a :+1: reaction to pull requests you find important.

Thanks for the reviews, @SuperSandro2000 and @pluiedev


ci: using trusted publisher release process

Following PyAnsys guidelines, this PR is to implement the ansys/actions/release-pypi-public.

@clatapie - be mindful of the commit name. "maint" is not allowed.

Indeed, thank you @RobPasMue!


feat(cactus-core-api): added new htlc aspect

Resolve #586

Thank you for your comment. I think the idea of HTLC itself is interesting, and when I see the issues, I think it is well planned.
However, regarding this plan, the HTLC application layer issue and the positioning of HTLC as a function of the CACTUS platform are important issues, and I would like to discuss them in the next meeting.
I would like to review this PR after the contributors' opinion is reached. So, would it be possible for you to wait until next week for approval?

@takeutak Sure! No problem!

Related art:
https://github.com/hyperledger/cactus/pull/580
https://github.com/hyperledger/cactus/pull/582

@sfuji822 @takeutak Been on a while on this one. Could you please put it down here how would you change this? (That's the last thing I remember us talking about on one of the maintainer meetings where the conversation was cut short because we ran over time)

@petermetz  As we discuss about this PR on maintainer call 2021-03-16, we decide to move HTLC feature on core-api to extension ledger-specific feature on smart contract on connected ledgers.
Core-api is managed to deal with abstract operation independent on each ledger, and each ledger deal with ledger-specific operation as much as possible.

@takeutak I would say that the mentioned move has been performed in the PRs that hold the HTLC implementation and this one only contains what is considered abstract operation because the only change in here is the addition of a new item to an enum type which is meant to enable the implementations that reside in the other packages. Without this enum change the implementation packages won't compile because the PluginAspect enum is needed for it. Any chance that I managed to convince you? :-)

@sfuji822 @takeutak Kindly requesting that you review or follow-up on the review discussion within this pull request. Thank you very much in advance.

@petermetz Sorry for late replying. I was told by Peter's agenda that we would discuss this at the previous meeting, but in the end, the discussion turned to sprint development in the middle of the meeting, and I didn't have time to discuss it. Would it be possible for you to explain at the next meeting?

@takeutak

Sorry for late replying.

No problem, thank you for replying.

I was told by Peter's agenda that we would discuss this at the previous meeting, but in the end, the discussion turned to sprint development in the middle of the meeting, and I didn't have time to discuss it.

The previous meeting's agenda said that it was about planning specifically:
If we are left with time after the planning then continue with the topics that we didn't have enough time to finish in the last meeting
https://wiki.hyperledger.org/display/cactus/2021-04-13+Cactus+Maintainers+Agenda+-+Planning+Session

Would it be possible for you to explain about this PR at the next meeting?

The agenda for the next meeting is quite full already so we might not get to this one.
I can explain it here right now though (see below paragraph) and that way we can make progress on the discussion asynchronously without having to be blocked by the limited meeting time.
It's also important to make progress on the discussion asynchronously/as soon as possible because this pull request has been open for 2 months now.
Another reason why I think it would be great if we could have the discussion here is because it lowers the probability of misunderstandings.
PR explanation:
It's a one liner change adding a plugin aspect enum entry with the HTLC value so that plugins can be filtered/differentiated based on what is the aspect that they are solving.
If you feel that instead of HTLC it should be called something more generic like ATOMIC_SWAP or even more generic SMART_CONTRACT then I can't say I disagree, I also considered those values myself, naming things is hard (for me at least).

Did this explanation help at all? If not, would you mind letting me know specifically which part didn't make sense and then I'll try to expand further based on that.

@petermetz Thank you for your comment.
I reviewed it again including the latest HTLC PR (PR 873), but it seems like I am just throwing away the HTLC smart contract as I deploy it, and it is hard to understand the positioning of your HTLC, which is frankly what I am talking about.
I am sorry but I will have a vacation until next week, but I want to prepare the alternative plan as soon as possible. I am sorry to have kept you waiting so long.

@takeutak Thank you too!

but it seems like I am just throwing away the HTLC smart contract as I deploy it

Throwing it away as in deleting it? From the ledger?

@takeutak Never mind.


chore: upgrade bullmq to v5

Change npm repository to be github
Made minor bump even if bullmq upgrade is major bump (no one except us relies on this package)

what are the breaking changes in bullmq?

Nothing big:
https://bullmq.io/news/231221/bullmqv5-release/


Remove PHP Version requirement or move it to first requirement

Not sure the PHP version require for this is required since this is a meta package for us.
We should remove it, or at least when we're adding PHP version as a requirement in composer.json it should be the first required so it doesn't get buried under all of our other require packages.
I'm fine leaving it so long as we move it to the top.

Suggested change:


[ALLUXIO-3316][WIP] Replace FSMaster thrift service w/ gRPC

https://alluxio.atlassian.net/browse/ALLUXIO-3316
In this PR:

A new module called base is added. Classes are moved from common into this module and acts as API for Alluxio services (fs, block, meta, etc)
protobuf module is renamed to transport. All grpc generated code lies here. For dependency management we relocate grpc/proto.
Options definitions from master and client modules are abstracted and placed in base

Misc:

All thrift references are removed from base module for dependency management
Conversions from wire type to proto are moved to transport module
Master and client fs options are limited to default constructors

The following will be addressed in follow-up PRs:

Authentication (no auth in present code)
Service version checking
RPC metrics
Other master services (only FileSystemMaster implemented so far)
grpcGen proto plugin binary is referenced in bin/alluxio for now. This may change

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/387/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/391/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/401/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/403/
Test FAILed.

Thanks @aaudiber for taking a look.

How about alluxio-core-api instead of alluxio-core-base? This module was split from transport because to remove a cyclic dependency b/w transport and common. The general guideline for what goes in base is the service interfaces and any dependencies
Makes sense. Will move to proto3 in a follow up PR
The FileSystemMasterOptions interface is used by the transport module to instantiate options with the server side defaults (which is done in the master module)

+1 for alluxio-core-api. I think right now there's a lot of stuff in there that belongs back in core-common, e.g. IndexedSet.

I don't like how we have master-specific logic in the core-transport module. What we want is to pass partial options over the wire, then have the master fill in the rest using its own defaults. But we can't do it that way currently because we don't have a concept of partial options, except in the transport layer. So the current code works around that by having options go from master to transport, then back to master. I see a few ways to get around this:

Pass proto options (partial options) to the master API, and let it resolve them against its defaults, then pass full options to the rpc implementations. This requires shading proto within the master module.
Get rid of our non-proto options completely and use proto. This saves us a ton of hand-written boilerplate, and lets us take advantage of the proto object APIs which are much more comprehensive than our hand-written options. We can implement client-side defaults by updating unset fields after the user passes us their options. This approach will require shading proto in more places.
Update our options to act as partial options (e.g. box all fields in Optional), then pass those from transport to master.
 This doubles our boilerplate, but contains proto to transport.

I prefer (2) because it minimizes duplication and boilerplate, and makes options easier to work with.
Basically, we can pay one layer of boilerplate to avoid the dependency on proto (what we are currently doing), and we can pay another layer to differentiate between partial and complete options (not currently doing this, which is why we got into the master -> transport -> master pretzel).

yeah there's a lot more in alluxio-core-api that doesn't belong there. will remove stuff in follow up PRs, the refactor was becoming a little too bug


Fastpass create: don't fail if project already exists

Prevously, fastpass create --intellij <target> was failing if the BSP
workspace was already existing. Now it does not fail and opens IDE, in the
same way as it was doing previously for newly created BSP workspaces.

@olafurpg CI is green now, but I had to change cache keys because it looks like the old cache was invalid, probably due to some system changes in GitHub Actions.

@olafurpg could we merge this now?


Update README.md

Fix the chart repo url

the current instructions are out of date. please merge this one, thanks!


Minify the generated c code?

We could minify the generated C code, i.e just squash it all together, except the preprocessor directives. Perhaps there could also be a flag to not minify the generated code, like --no-minify or something. It's not like the generated code will be read by humans anyway, since it's just an intermediate representation, however, the developers will need to read it every now and then for debugging purposes.
So perhaps the -c flag -- which will output the c code and not remove the files -- can also not minify it too? I'm not sure, just throwing some ideas around.
@vnev

Might have to pivot this issue into something else since we're considering ASM/LLVM IR?

Nah it's fine. I've already implemented this, it's just not  toggle-able with a flag, but rather a define in the code itself.


Manager Ready: Removing Job Poster Creation from Managers

Description
While we wait on the new job poster builder (currently in design and testing), we're going to remove the ability to create job posters from managers. In exchange, we'll allow admins to create these by providing a UI where the admin can select a manager from a list, and click a button to generate a job poster attached to that manager. This eliminates the immediate need for validation on this form (we won't be using it once the builder is in place), and it eliminates the worry that managers will arbitrarily create posters and run into a validation bug.
Criteria

[ ] Remove "Create a Job Poster" button from manager UI.
[ ] Add an Admin UI that allows job poster creation:

[ ] Admins should be able to select a manager from a dropdown.
[ ] Admins should be able to then click a button to create a job poster attached to that manager, as if they had created it themselves.

[ ] This task requires a unit test.

Wireframes

@gobyrne Can you confirm that this is sufficient until the job poster builder is dev'd based on our conversation?


Allow HTTPX instrumentation to capture more request info, and improve API docs

Description
We should add the following kwargs to instrument_httpx:

capture_request_headers: bool | None = None
capture_request_body: bool | None = None
capture_response_headers: bool | None = None
capture_response_body: bool | None = None
capture_all: bool = False - just sets all the above to True

We can raise an error if you use these together with async_request_hook etc.
We can add a note saying that capturing the body in production might increase the amount of data collected significantly.
Also HTTPXInstrumentKwargs is not included in docs which makes it basically undocumented.
We should probably do the same for requests.

@Kludex is currently working on headers in https://github.com/pydantic/logfire/pull/671 which is close to finishing.
After that comes capturing JSON bodies which @Kludex will also work on, I've provided him with a PoC implementation in slack.
Then https://github.com/pydantic/logfire/pull/668 can go through.
We discussed eventually capturing other types of bodies:

Forms, which could be done by walking up the stack to retrieve the data from a frame instead of parsing bytes
Arbitrary non-streamed bodies
Arbitrary streamed bodies

I briefly toyed with the last case, leaving the code here in case we want it:
from dataclasses import dataclass
from typing import Iterable
import httpx
from httpx._content import IteratorByteStream
import logfire
from logfire.propagate import attach_context, get_context, ContextCarrier
from opentelemetry.trace import get_current_span, Span

def content():
    yield b"Hello, "
    yield b"world!"

logfire.configure()

@dataclass
class LoggingStream:
    stream: Iterable[bytes]
    ctx: ContextCarrier
    current_span: Span

    def __iter__(self):
        result = []
        for chunk in self.stream:
            result.append(chunk)
            yield chunk
        body = b"".join(result)
        if self.current_span.is_recording():
            # TODO this requires the bytes to be decodable as text
            self.current_span.set_attribute("http.body", body)
        else:
            with attach_context(self.ctx):
                logfire.info("Streamed body", body=body)

def request_hook(span, info):
    record_body(info)

def record_body(info):
    if isinstance(info.stream, IteratorByteStream):
        info.stream._stream = LoggingStream(
            info.stream._stream, get_context(), get_current_span()
        )

logfire.instrument_httpx(request_hook=request_hook)

r = httpx.post("https://httpbin.org/post", content=content())
print(r.text)

capture_response_text_body
Documentation of all the capture_* args
capture_all
Replacing Unpack[HTTPXInstrumentKwargs]
Optionally refactoring response info similar to https://github.com/pydantic/logfire/pull/722
Optionally moving the enhanced request/response info classes into the public logfire.integrations.httpx module and documenting them with example hooks, the simplest being how to capture only request or response headers with a single method call in a hook.

@Kludex can you do 2-4?

You working on 3? If so, I can work on 2-4 after.

I am not.

I am not.

I don't understand if you are going to, if you think it shouldn't be added, or if you are implying that I can and should work on it.

Waiting review:

https://github.com/pydantic/logfire/pull/753
https://github.com/pydantic/logfire/pull/751

I'll document tomorrow.


Improved handling of missing dependencies and support scenarios where…

… users re-create the same env (#9136)Fixes #
Ports the fixes to ensure we don't use the cache when starting with Jupyter.
This is because The kernel process starts and Jupyter hangs for a long time.
& when it fails we don't check if ipykenrel is isntalled or not.
The fix now doesn't cache & also prompts users to install ipykernel after kernel fails to start.

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/release-2022.02.101@deaea66). Click here to learn what that means.
The diff coverage is n/a.

@@                      Coverage Diff                      @@
##             release/release-2022.02.101   #9241   +/-   ##
=============================================================
  Coverage                               ?     57%
=============================================================
  Files                                  ?     382
  Lines                                  ?   24850
  Branches                               ?    4033
=============================================================
  Hits                                   ?   14211
  Misses                                 ?    9306
  Partials                               ?    1333


Fix select widget infinite loop

If an attempt is made to update a selection item that is not in the
choices, an infinite loop occurs. This can be caused by rare conditions
of a stale browser state.
This infinite loop has to be guarded by a condition in setState to
avoid triggering another component render and thus breaking the infinite
loop.

@reebalazs I just merged the long running PR with the improvements of the selects. Could you please adapt it and test it with the current code?
Also, could be that the problem does not happen in the new code.
Thanks!

I've checked and the new release does contain the condition to break up the infinite loop which this fix was meant to correct. So I close this PR. Thanks!


Upgrade Playground to 2.2

The Playground doesn't understand object or the Mixin pattern.  I suspect it is not running 2.2:
http://www.typescriptlang.org/play/index.html#src=type Constructor<T> %3D new(...args%3A any[]) %3D> T%3B

class A extends Timed(C) {

}

function Timed<T extends Constructor<object>>(superclass%3A T) {
  return class Timed extends superclass {
    startTime%3A number%3B
    endTime%3A number%3B
    get duration()%3A number { ... }
  }%3B
}

class C { }

It would also be helpful if the compiler version was stated somewhere on the page (I've often wondered what version I'm playing with compared to the version in my project), or even better if you could select compiler version from a list.

updated. having different versions is tracked by https://github.com/Microsoft/TypeScript/issues/15662


⚠ Bofrost.lu has degraded performance

In 5e254d5, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1549 ms

Resolved: Bofrost.lu performance has improved in b004b74 after 6 minutes.


Using Service Tag in Access rule instead of IP address based rules

Rather than manually downloading the IP address list of the Cognitive Management Service Tag or using the script to configure IP based on the App Service as per the existing documention it is probably better to use the new Service Tag based filtering capability instead.
i.e. Instead of this:

Do this:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0b86095e-a45d-11af-da8c-0e9557b34551
Version Independent ID: 0bc6feb9-90a9-1c91-0040-41af360822b5
Content: Network isolation - Azure Cognitive Services
Content Source: articles/cognitive-services/QnAMaker/How-To/network-isolation.md
Service: cognitive-services
Sub-service: qna-maker
GitHub Login: @nerajput1607
Microsoft Alias: nerajput

Thanks for brining this to our attention. We will investigate it further and update you shortly.

@nerajput1607  Hello Neha, could you please check on this suggestion? This is a good feedback. ^^
@pnarsi Thanks for the feedback again, I have assigned this to the content author for improvement.

@pnarsi Thanks for your feedback.
We were in the process of updating the specific documentation and have made it simpler for understanding. Your suggestion was something in line with the updates we had planned to make. The new documentation has been published.
Do share any additional feedback if you have. Thanks!

@jaydeepn - that particular part around the App Service Access Restrictions via Service Tags looks much better now.
In terms of additional feedback on the page, I know this is supposed to be an "How to" page that focuses on how to do the configuration of the various components but I think it would have been useful to have an overview diagram with an overview of the various network isolation capability  the components at the top before we get into the detailed configuration.
There are quite a few different components to QandA maker and this page assumes that the user knows how everything hangs together. Having maybe a simpler version of the diagram below would have been extremely helpful to enable us to understand the overall network isolation solution for QandA maker. If not in this "How to" page then maybe in a separate "Security Concepts" page.

@pnarsi , Thanks for your feedback. We will consider your suggestion for future updates that we may do on this topic.

Closing this issue out based on PM team response.

#please-close


VersatileDiffusionPipeline - supported image variation inputs

Hey,
I am currently working with the VersatileDiffusionPipeline implementation to perform image variation. While this works as promised on single PIL Image inputs, the pipeline does not seem to work with a list of PIL Images or with a PyTorch tensor input. However, the documentation (https://huggingface.co/docs/diffusers/api/pipelines/versatile_diffusion#diffusers.VersatileDiffusionPipeline.image_variation) states both input possibilities. For example, when running the following code:
image = Image.open( 'data/img.jpg').convert( "RGB")
image = [image, image]
out = pipe.image_variation(image=image,
                           num_inference_steps=5,
                           guidance_scale=5,
                           num_images_per_prompt=1,
                           negative_prompt=None,
                           output_type='np.array').images

The following error message is given:

Traceback (most recent call last):
File "/workspace/test_augmentation.py", line 31, in
out = pipe.image_variation(image=image,
File "/opt/conda/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion.py", line 209, in image_variation
return VersatileDiffusionImageVariationPipeline(**components)(
File "/opt/conda/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion_image_variation.py", line 396, in call
self.check_inputs(image, height, width, callback_steps)
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion_image_variation.py", line 265, in check_inputs
raise ValueError(f"image has to be of type PIL.Image.Image or torch.Tensor but is {type(image)}")
ValueError: image has to be of type PIL.Image.Image or torch.Tensor but is <class 'list'>

Also, PyTorch tensors lead to errors regarding the input shape. So when feeding in tensors with the standard PyTorch dimensional orientation, the following error is raised:
image = torch.randn((2, 3, 224, 224)) out = pipe.image_variation(image=image,                            num_inference_steps=5,                            guidance_scale=5,                            num_images_per_prompt=1,                            negative_prompt=None).images

Traceback (most recent call last):
File "/workspace/test_augmentation.py", line 31, in
out = pipe.image_variation(image=image,
File "/opt/conda/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion.py", line 209, in image_variation
return VersatileDiffusionImageVariationPipeline(**components)(
File "/opt/conda/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion_image_variation.py", line 407, in call
image_embeddings = self._encode_prompt(
File "/opt/conda/lib/python3.10/site-packages/diffusers/pipelines/versatile_diffusion/pipeline_versatile_diffusion_image_variation.py", line 188, in _encode_prompt
image_input = self.image_feature_extractor(images=prompt, return_tensors="pt")
File "/opt/conda/lib/python3.10/site-packages/transformers/image_processing_utils.py", line 437, in call
return self.preprocess(images, **kwargs)
File "/opt/conda/lib/python3.10/site-packages/transformers/models/clip/image_processing_clip.py", line 351, in preprocess
images = [
File "/opt/conda/lib/python3.10/site-packages/transformers/models/clip/image_processing_clip.py", line 352, in
self.resize(image=image, size=size, resample=resample)
File "/opt/conda/lib/python3.10/site-packages/transformers/models/clip/image_processing_clip.py", line 165, in resize
return resize(image,
File "/opt/conda/lib/python3.10/site-packages/transformers/image_transforms.py", line 263, in resize
image = to_channel_dimension_format(image, ChannelDimension.LAST)
File "/opt/conda/lib/python3.10/site-packages/transformers/image_transforms.py", line 75, in to_channel_dimension_format
image = image.transpose((1, 2, 0))
ValueError: axes don't match array

Ok, I think I found the bugs. Made a pull request in the diffusers repo: https://github.com/huggingface/diffusers/pull/1568

Hi thanks for pointing the bug, will contact HF team.


don't abstract away toplevel eval calls

Codecov Report

Merging #48 into master will decrease coverage by 0.24%.
The diff coverage is 78.94%.

@@            Coverage Diff             @@
##           master      #48      +/-   ##
==========================================
- Coverage   86.31%   86.07%   -0.25%
==========================================
  Files           9        9
  Lines         709      718       +9
==========================================
+ Hits          612      618       +6
- Misses         97      100       +3

Flag
Coverage Δ

#unittests
86.07% <78.94%> (-0.25%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/TypeProfiler.jl
53.70% <ø> (ø)

src/virtualprocess.jl
94.14% <78.94%> (-1.39%)
: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 35886c1...871ea28. Read the comment docs.


Support embedded-hal 0.x and 1.0-alpha.x

Rebased dbrgn 1-alpha branch
This moves support for different versions of embedded-hal to separate modules eh0 and eh1 as suggested at https://github.com/dbrgn/embedded-hal-mock/issues/70#issuecomment-1555003903

see my comment on https://github.com/dbrgn/embedded-hal-mock/issues/70#issuecomment-1616625227 for why i (now) think that not merging e-h 0 and e-h 1 mocks in the same e-h-m release would be better.

fair enough. though then it might be worth it to move eh0 stuff into the eh0 module and either have all eh1 things top-level or at least re-export them at the top-level so that they don't need a breaking change in the future (and this way e-h-m can match e-h in terms of API structure). WDYT?

Thanks for your work, @tomgilligan and others! This looks great at first glance! I'd like to take a closer look before merging (since it's a major change), but don't know yet when I find time to do that. Hopefully by next week... If I forget about it, feel free to ping me in this thread at any time! 🙂 (I do get notifications, but sometimes they drown in the flood of e-mails.)

I did take a closer look now, and also ported one of my project's tests to your branch. It is looking good!
Let's merge this branch, and I'll try to publish a release (maybe an rc1) soon. Thanks for your work!

This is now released as embedded-hal-mock version 0.10.0-rc.1: https://crates.io/crates/embedded-hal-mock/0.10.0-rc.1


Jupyter notebook 5 compatibility

Adds on to quantopian#44 to make the changes suggested by this comment: https://github.com/quantopian/pgcontents/pull/44/files#r192937051

@ssanderson I've made those changes, and also fixed the travis build.  Could you approve if everything looks good? I need an approval to be able to merge in this repo apparently.


Update .eslintrc.js

Simplified Rule Management: Removed redundant or unnecessary rules that were either off by default or covered by extended configurations.
Organized Imports: Grouped and sorted the dependencies for better readability and easier maintenance.
Rule Refinement: Consolidated common rules and reduced the use of repetitive OFF(UNKNOWN) statements, ensuring the configuration is cleaner and more concise.
The original ESLint configuration contained redundant and overlapping rules, which made it harder to maintain and understand. By optimizing the configuration, we ensure that the codebase remains consistent, and the linting process is both efficient and effective
Verified that the ESLint configuration works correctly by running linting on the codebase.
Ensured that the optimized rules do not introduce new linting errors or warnings
Merge the pull request after review.
Ensure all contributors are aware of the updated ESLint configuration to maintain consistency across future code submissions.

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


major version change to<EMAIL_ADDRESS>

Description
This is to communicate an upcoming major version change to @adobe/aio-lib-core-networking to 2.0.0.
Your @adobe/aio-lib-core-networking version is ^1.0.0 and will not be affected by an npm install unless you manually change it to ^2.0.0
PR for discussion: https://github.com/adobe/aio-lib-core-networking/pull/14
What Changed
The major change to take note if you upgrade, is the export of the library.
In 1.x.x the export of @adobe/aio-lib-core-networking returns an instance of the HttpExponentialBackoff class.
In 2.x.x the export of @adobe/aio-lib-core-networking returns an object, which contains the HttpExponentialBackoff class (which you need to instantiate).
Migration
1.x.x:
const fetchRetry = require('@adobe/aio-lib-core-networking')
fetchRetry.exponentialBackoff('http://example.com', {})

2.x.x:
const { HttpExponentialBackoff } = require('@adobe/aio-lib-core-networking')
const fetchRetry = new HttpExponentialBackoff()
fetchRetry.exponentialBackoff('http://example.com', {})

done


[FLINK-12772][hive] Support mapping ARRAY, MAP, ROW (STRUCT) between Flink and Hive in HiveCatalog

What is the purpose of the change
This PR added mapping of ARRAY, MAP, ROW (STRUCT) between Flink and Hive in HiveCatalog, such that HiveCatalog can persist tables of these types in Hive metastore and later read them.
Note: this PR is based on https://github.com/apache/flink/pull/8662
Brief change log

added mapping of ARRAY, MAP, ROW (STRUCT) between Flink and Hive in HiveTypeUtil
added unit tests

Verifying this change

added testComplexDataTypes() in HiveCatalogGenericMetadataTest

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (yes)
If yes, how is the feature documented? (docs)

Docs will added later

cc @xuefuz @lirui-apache @zjuwangg

cc @xuefuz @lirui-apache @zjuwangg

Thanks @xuefuz for your review.
Merging


Squash schema

We shouldn't do this too late, because if we wipe the data, the recent packages query will be weird until updates straighten them out. We should also consider this for a potential move to MacStadium.
One way to correct that is to manually fiddle with package creation dates in the db - but that's a bit ugly...

This is a good point. I'll think about chasing that email tomorrow to see where we stand.

As we do this, let's change the materialised view to have a limit of 100 so that #64 can include more than 10 packages in the feed.


Update dependencies to k8s 1.22

Kubernetes v1.22 or later is required, and the AnyVolumeDataSource feature gate must be enabled

/lgtm
/approve


Using autocomplete with form field

Hello, I'm trying to use autocomplete in my form. I have installed everything and I'm trying to test it by using the examples in the docs.
Please see snippets of my code below:
autocomplete_light_registry.py
import autocomplete_light
class OsAutocomplete(autocomplete_light.AutocompleteListBase):
choices = ['Linux', 'BSD', 'Minix']
autocomplete_light.register(OsAutocomplete)
forms.py
import autocomplete_light
class PartDetailsForm (forms.ModelForm):
region = autocomplete_light.ChoiceField('OsAutocomplete')
city = forms.CharField(required=False, label='City', max_length=128)
....
In my base.html

{% include 'autocomplete_light/static.html' %}
In my urls.py I have
....
url(r'^autocomplete/', include('autocomplete_light.urls')),
I'm new to django and python so not too sure if it is something simple I am overlooking. Ultimately I would like to use autocomplete in conjunction with cities_light in order to allow the user to enter their city and country in the form.
Any advice is appreciated.

So what's the problem here exactly ?

BTW here's an example with cities_light to tie 2 autocompletes which might look like what you'd want to do with region and city fields.

The problem is when I being to type in the "Region" field, nothing happens. I'm not too sure if the JavaScript has been configured properly.
In the example you posted above, what file should the JavaScript be pasted into. I'm at the "JavaScript" step?
Thanks again!

It doesn't matter where you put the JS, as long as it is loaded.
If nothing happens when you type something in the region field, maybe the js is not properly loaded (autocomplete.js, widget.js) or maybe the extensions it installed are overridden (ie. jquery is being loaded again in your page).
Anyway, I recommend that you try to reproduce this problem in a sample project.

Thank you, it was the jquery being loaded multiple times that caused the issue. Seems to be working now.
With regards to the styling of the form, is there any way to edit this? As you can see in the pic below, the autocomplete fields are displayed different from the standard fields.

Many thanks

I'm sorry but we support django admin which relies on overflow: hidden
instead of the clearfix technique to clear floats and it makes it a bit
harder to design.
Pull requests are welcome, CSS is not my area of expertise but I'd love to
ear you out.

I created a separate stylesheet to override the default style:
label {
display: block;
max-width: 100%;
margin-bottom: 5px;
font-weight: bold;
}
.autocomplete-light-widget {
display: block;
}

Looks neat B) anything else ?

That's all for now. Thanks very much for your support and patience.
On 20 Jul 2015 23:36, "James Pic"<EMAIL_ADDRESS>wrote:

Looks neat B) anything else ?
—
Reply to this email directly or view it on GitHub
https://github.com/yourlabs/django-autocomplete-light/issues/467#issuecomment-123074918
.

NP, enjoy


fix: The Switch widget also changed in Material 3.

The Switch widget also changed in Material 3.
It seems to be closer to our Figma design than before so this is good for us.
We just need to adapt the thumb size to match our design.
This image is the expected Switch widget from Lenra's Figma design.

Originally posted by @jonas-martinez in https://github.com/lenra-io/lenra_components/issues/123#issuecomment-2033996234

Make sure there the problem persist if you define useMaterial3: false in the theme, since for now we don't want to use material 3


[AVM Module Issue]: The given value is not suitable for module.virtual_network.var.subnets declared at .terraform\modules\virtual_network\variables.tf:102,1-19: element "address_prefixes": object required.

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Bug
(Optional) Module Version
0.1.4
(Optional) Correlation Id
No response
Description
This is the code we have for the module:
module "virtual_network" {
  providers = {
    azurerm = azurerm.Identity-prod
  }
  source                        = "Azure/avm-res-network-virtualnetwork/azurerm"
  version                       = "~> 0.1"
  name                          = "vnet-${local.SERVICE_NAME_IDC}-${var.SERVICE_ENVIRONMENT}-${var.SERVICE_IDENTIFIER}"
  resource_group_name           = azurerm_resource_group.IdentityConnectivity-prod-001.name
  location                      = azurerm_resource_group.IdentityConnectivity-prod-001.location
  virtual_network_address_space = [local.virtual_network_address_space]
  subnets = {
    address_prefixes = ["<IP_ADDRESS>/26", "<IP_ADDRESS>/26"]
  }
}

The documentation says module.virtual_network.var.subnets should be an object, however module.virtual_network.var.subnets is declared at .terraform\modules\virtual_network\variables.tf:102 as list of string.
Is this a bug or have I done something wrong?
We've also tried passing address_prefixes as an object, as per the documentation:
module "virtual_network" {
  providers = {
    azurerm = azurerm.Identity-prod
  }
  source                        = "Azure/avm-res-network-virtualnetwork/azurerm"
  version                       = "~> 0.1"
  name                          = "vnet-${local.SERVICE_NAME_IDC}-${var.SERVICE_ENVIRONMENT}-${var.SERVICE_IDENTIFIER}"
  resource_group_name           = azurerm_resource_group.IdentityConnectivity-prod-001.name
  location                      = azurerm_resource_group.IdentityConnectivity-prod-001.location
  virtual_network_address_space = [local.virtual_network_address_space]
  subnets = {
    address_prefixes = {
      "snet-IdentityConnectivity-abc-001" = "<IP_ADDRESS>/26",
      "snet-IdentityConnectivity-def-001"            = "<IP_ADDRESS>/26"
    }
  }
}

and the error we get is:
The given value is not suitable for module.virtual_network.var.subnets declared at .terraform\modules\virtual_network\variables.tf:102,1-19: element "address_prefixes": attribute "address_prefixes" is required.
We previous had it reference a variable, as is done in the AVM lab:
module "virtual_network" {
  providers = {
    azurerm = azurerm.Identity-prod
  }
  source                        = "Azure/avm-res-network-virtualnetwork/azurerm"
  version                       = "~> 0.1"
  name                          = "vnet-${local.SERVICE_NAME_IDC}-${var.SERVICE_ENVIRONMENT}-${var.SERVICE_IDENTIFIER}"
  resource_group_name           = azurerm_resource_group.IdentityConnectivity-prod-001.name
  location                      = azurerm_resource_group.IdentityConnectivity-prod-001.location
  virtual_network_address_space = [local.virtual_network_address_space]
  subnets                       = local.subnets
}

variable "SUBNETS_AND_SIZES" {
  type        = map(number)
  description = "The size of the subnets"
  default = {
    snet-IdentityConnectivity-abc-001 = 26,
    snet-IdentityConnectivity-def-001  = 26,
  }
}

# Caluculate the CIDR for the subnets
locals {
  virtual_network_address_space = "${var.ADDRESS_SPACE_START_IP}/${var.ADDRESS_SPACE_SIZE}"
  subnet_keys                   = keys(var.SUBNETS_AND_SIZES)
  subnet_new_bits               = [for size in values(var.SUBNETS_AND_SIZES) : size - var.ADDRESS_SPACE_SIZE]
  cidr_subnets                  = cidrsubnets(local.virtual_network_address_space, local.subnet_new_bits...)

  skip_nsg = []
  subnets = { for key, value in var.SUBNETS_AND_SIZES : key => {
    name             = key
    address_prefixes = [local.cidr_subnets[index(local.subnet_keys, key)]]
    network_security_group = contains(local.skip_nsg, key) ? null : {
      id = module.network_security_group.nsg_resource.id
    }
    }
  }
}

however, because the variable is a map, map keys are iterated in lexicographical order and therefore I if we add another subnet it may destroy an existing one in order to maintain lexicographical order. So I don't think map is the best thing to use here.

Hopefully this is resolved in v0.2.0, but please re-open if not.


Problem installing Chatterbot

Hello,
I fail to install Chatterbot. I am using 64bits python, and I don't understand where the problem comes from.
Here is what appears in the shell (I use Pyzo):

pip install chatterbot
Collecting chatterbot
Using cached https://files.pythonhosted.org/packages/6c/0e/dac0d82f34f86bf509cf5ef3e2dfc5aa7d444bd843a2330ceb7d854f84f2/ChatterBot-1.0.5-py2.py3-none-any.whl
Collecting spacy<2.2,>=2.1 (from chatterbot)
Using cached https://files.pythonhosted.org/packages/1f/e2/46650d03c7ff2b57ed7af211d41c3f606540f7adea92b5af65fcf9f605c0/spacy-2.1.9.tar.gz
Installing build dependencies: started
Installing build dependencies: finished with status 'error'
ERROR: Command errored out with exit status 1:
command: 'c:\users\yona\appdata\local\programs\python\python38\python.Error in pip command:
'utf-8' codec can't decode byte 0xe9 in position 5339: invalid continuation byte

I also tried directly typing 'pip install chatterbot' in the cmd. The result is in the pdf.
Chatterbotfail.pdf
Thank you

I have the same problem to install this package on windows.

My friend use pip install chatterbot==1.0.2

It worked ! Thank you very much !


Supported configuration file extension check does not use the per-generator default

The setPagesConfig function uses different error messages depending on whether the generator configuration file has a correct extension. However, the configuration file used for this check is based on the context generator_config_file input only, rather than the default configuration file for the generator used that is computed by the getConfigParserSettings function.
As a result, if generator_config_file is not specified, then errors within the setPagesConfig function will always be blamed on an incorrect file extension.

Basically the check:
https://github.com/actions/configure-pages/blob/b490f538fb047e8461be7770e7347f9c197aeddc/src/set-pages-config.js#L80-L90
should return isSupportedFileExtension true if !generatorConfigFile and that's all I guess.
(It would be better to use settings.configurationFile output instead that should have the template config path filled in if no passed config, but that's another scope and the actual getter might have thrown so no point getting the output again, oh well…)
So maybe just something like:
--- a/src/set-pages-config.js
+++ b/src/set-pages-config.js
@@ -76,12 +78,12 @@ function setPagesConfig({ staticSiteGenerator, generatorConfigFile, siteUrl }) {
     const settings = getConfigParserSettings({ staticSiteGenerator, generatorConfigFile, siteUrl })
     new ConfigParser(settings).injectAll()
   } catch (error) {
-    const isSupportedFileExtension = SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))
+    const isSupportedFileExtension = !generatorConfigFile || SUPPORTED_FILE_EXTENSIONS.some(ext => generatorConfigFile.endsWith(ext))

     // Logging
     if (!isSupportedFileExtension) {

I believe the main problem here (our failure to log the actual error message) is resolved by:

https://github.com/actions/configure-pages/pull/138

As for failure to correctly detect config files, I'm going to leave that in another issue:

https://github.com/actions/configure-pages/issues/107

@JamesMGreene Thanks for keeping this in mind. The issue here is different than the referenced autodetection. To quote the important bit:

" if generator_config_file is not specified, then errors within the setPagesConfig function will always be blamed on an incorrect file extension."

To simplify, if you don't pass any config file and the action uses its own implicit boilerplate, the conditional logic testing whether to log "We were unable to determine…" or "Unsupported configuration file extension…" fails because https://github.com/actions/configure-pages/blob/fc47e3c8386fa64ae7a2419b64710d432c7a3b90/src/set-pages-config.js#L85 this doesn't work for when there's no config specified, as generatorConfigFile.endsWith(ext) is empty/falsy, so it "seems" that all errors are then blamed on extension, when that isn't the case if you're not providing a config at all;)
It's just cosmetics though.

No worries;) I'd have already demonstrated it better by proposing a fix just by adding the const isSupportedFileExtension = !generatorConfigFile || SUPPORTED_FILE_EXTENSIONS.some… to avoid blaming any errors without config file present on its extension straight away, however TBH I lack the imagination to properly test such change esp. in edge case error handler and not to introduce any potential surface for more issues stemming from it so I leave that to others… I see you've taken more systematic approach to the whole configs magic so I'm just watching from the passenger seat: Good job! 🎩

A fix for this is now included in actions/configure-pages@v5. 🚀


make CapacityIndicator work with other values of splits, not only splits:10

Currently the CapacityIndicator only works with the default value of 10 for splits.
I changed CapacityIndicator to work with other values and IndicatorsPage now uses splits:20.
macos_ui git:(dev) sh ./pr_prelaunch_tasks.sh
Formatted 115 files (0 changed) in 0.45 seconds.
Run dart fix --dry-run? [y/n]
y
Computing fixes in macos_ui (dry run)... 10.5s
Nothing to fix!
Run dart fix --apply? [y/n]
y
Computing fixes in macos_ui... 10.4s
Nothing to fix!
No changes to commit
Run tests? [y/n]
y
00:05 +15: /Users/aschilken/flutterdev/forks/macos_ui/test/buttons/popup_button_test.dart: MacosPopupButton tests debugFillProperties
[itemHeight: 24.0, noAutofocus, popupColor: null, menuMaxHeight: null, alignment: AlignmentDirectional.centerStart]
00:18 +119: All tests passed!

@whiplashoo is Capacity Indicator something still used by macOS devs? I can't find a reference to it in the HIG.

@whiplashoo Pinging you again for your thoughts on this

@GroovinChip  Hi, sorry for not responding. Surely I use it, and I found this:
https://developer.apple.com/design/human-interface-guidelines/components/status/level-indicators/

@GroovinChip  I added an entry in CHANGELOG and a unit test for splits= 20.
I don't know what you mean by "update the version".
I think the unit tests of the CapacityIndicator don't prove anything useful concerning the splits, they just check the properties, not the calculation of the segments, but I have no idea who to test that.
On the IndicatorsPage of the example I changed the splits to 20 to show that the bug is fixed.

I'll take a look at the tests when I get a moment.
By "update the version" I'm talking about incrementing the version number in the package's pubspec.yaml.

Hi @GroovinChip, I added two tests to check the number of segments. Thanks for pointing out the flutter tests. That was very helpful; I did not know the canvas_mock yet.

@schilken looks like you need to format capacity_indicators_test.dart, mock_canvas.dart, and recording_canvas.dart

@schilken Can you pull in the latest from dev so I can re-review, please?

After merging the upstream dev branch into my local branch, I get an exception when clicking the CapacityIndicator on the IndicatorsPage of the example app:
Exception has occurred.
_AssertionError ('package:macos_ui/src/indicators/slider.dart': Failed assertion: line 40 pos 16: 'value >= min && value <= max': is not true.)

The ranges 0-100 of CapacityIndicator and 0.0 to 1.0 of Slider are not compatible.

After merging the upstream dev branch into my local branch, I get an exception when clicking the CapacityIndicator on the IndicatorsPage of the example app:

Exception has occurred.

_AssertionError ('package:macos_ui/src/indicators/slider.dart': Failed assertion: line 40 pos 16: 'value >= min && value <= max': is not true.)

The ranges 0-100 of CapacityIndicator and 0.0 to 1.0 of Slider are not compatible.
A further test reveals, that the release build just works fine, it's just the connection of CapacityIndicator and slider that triggers the assertError.

It's just a problem in the example app, I address it in #342.


Undeprecate MaterialModule

Bug, feature request, or proposal:
Proposal
Instead of deprecate MaterialModule you should provide both options so that the developer can use MaterialModule or create an own module / import the components.
It could be annoying to import every component you want to use. Sometimes it doesn't matter if you download the whole components or only those which are needed.

Yeah, I agree.
It would also be nice if the component names were documented somewhere (not sure if I missed it).

I believe it should be an anti-pattern rather than deprecated. Warnings in console should be enough.

Considering that the possibility of using all of the modules in material isn't discarded it would be reasonable to have a "default" module that export/import all the component modules

Our approach here is to do the thing that will ultimately end up with the smallest code size for everyone. The best tool we have to do that is to get rid of MaterialModule to prevent some people from using it without realizing the cost.
We think that the fact that people can create their own MaterialModule is a good alternative to explicitly pull in all of the components.

@jelbourn Therefor my suggestion was to offer both options.
Think of developers as people who are knowing what they do, even if they are willing to use the whole MaterialModule and take the risk of a performance which is not ideal.  As I mentioned before,  the cost of a larger download sometimes doesn't matters because they are working on an offline app or on an intranet project.
And when I look at the comments and thumbs up I'm not alone with my opinion.

@NCC1701M could you not just create a "sharedMaterialsModule" feature module that exports all of the material components?

@mackelito Of course I could do this but then I have to update this module every time a new component is introduced. But both, supply such a module and maintain its component should be done by the Material team. It's one developer at the Material Team against hundreds or thousands of developers at their own projects

I do not understand reasoning behind deprecating MaterialModule. A developer wouldn't import it if he did not want to compromise performance, but why would you not give people a choice?

I'm a newbie developer in Angular and I'm only getting started with everything. It's almost overbearing to research every single material component that I need to import. A single module would make life a lot easier. Maybe, a middle way would be to add the code for a whole module to the docs.


🐛 FIX: Avoid importlib.metadata

importlib.metadata is not present on versions of python before 3.8, but we use it here: https://github.com/princesslana/smalld.py/blob/master/smalld/smalld.py#L5
Modify to use pkg_resources to get the version. Also add a unit test that at least ensures the version value works.

Fixed by #18


Update README.md

Added new project in kotlin-multihash:
https://github.com/erwin-kok/multiformat

Thanks for your reviews Mische!


Add custom colors and sass helpers classes

Hi,
I'm using Vuestic Admin for my project and i need to add new custom colors and generate helpers class. ¿What is the best way to do it? I need also branded colors and classes like
text--{brandName}--success
text--{brandName}--lighten--success
text--{brandName}--error

...
Please, can you help me with this? I can not understand how colors, palettes and components colors works.

We moved to tailwind, which solves this issue


Support CSS URLs in the component styleUrls when loaded from imports folder

SASS and LESS will in<EMAIL_ADDRESS>

released!
great work @barbatus